The contest theme was to make a game inspired by Wario Ware‘s built-in random name generator, and the name I randomly generated was Oh, Samurai! In this post, I’d like to skim over some of the main considerations that went into its design, and in doing so explain some of the principles I work to when designing microgames, most of which is just a concentrated dose of what I consider ‘normal’ design theory.

(NB. This is a terrible screenshot, but it’s the best I can do right now)

To give you a brief description of the game: A samurai is standing on one side of the screen, ready to draw his sword. A crowd of children are randomly moving around in the centre of the screen, each child carrying a balloon. When the player taps on the screen, the samurai instantly dashes to the opposite side of the screen (leaving a little ‘swoosh’ animation where he was standing) and slices a balloon as he goes. The aim of the game is to tap once for each balloon on the screen; taps must be made in rapid succession, and once the player stops tapping the samurai sheaths his sword and all the sliced balloons burst in sequence.

1) Simple controls

Wario DIY‘s only form of player input comes through tapping on the touch screen. There’s no holding, no dragging, no buttons to press, only tapping. The game can identify taps on particular in-game objects, allowing you to create virtual buttons on the touch screen, but I’m very skeptical about this technique. I don’t like the idea of tapping on one object in order to control another – I once made a Klik of the Month game on the subject – and the short timeframe of Wario Ware games means that players just don’t have time to take in complicated controls.

Oh, Samurai! has only one verb – to slice – and it is activated by tapping anywhere on the touch screen. Some players might assume that they need to tap on the samurai; others might assume that they need to tap on the balloons; in any case, the game plays out in exactly the same way. It is intuitive in the sense that it doesn’t care what you do, as long as you do something. Perhaps you could call this ‘interface agnosticism’?

2) Fireworks

In all my microgames, the thing I spend more time on than anything else is rigging up some fun sounds and animations to reward the player for their efforts. By necessity, this kind of feedback needs to be more instantaneous as the length of your game becomes shorter, and 4-second microgames are the razor’s edge! Tapping at a touch screen with a stylus is not very exciting, so it’s important to throw in some flashy special effects – which I would refer to as ‘fireworks’, if anyone bothered to ask me – to let the player know they are actually doing something. Every single meaningful action should make an exciting sound!

In Oh, Samurai! players are rewarded for tapping the screen by a brief animation and a cool ‘slice’ sound effect; they are rewarded for completing a round with a fun balloon-popping sequence; they are rewarded for winning the game with a little victory jingle; most notably, they are rewarded for failure with an animation of the samurai’s trousers falling down. I have mixed feelings about ‘rewarding failure’, but I think throwing in a little visual joke as a consolation prize doesn’t hurt anybody. The reason why this stuff takes me so long is because I usually get bogged down in fine details – such as ensuring that the number of popped balloons matches the number of slices, in this case.

3) Variable requirements

Here’s a more basic point: Games are no fun if you have to input the same routine commands in order to win. I wouldn’t even call that a game. In my opinion the best games incorporate some emotive human element to prevent things from becoming too mechanical, but it’s common practice to just throw in some random numbers instead – it’s usually less technically demanding, and can be applied in a greater range of circumstances.

Oh, Samurai! features exactly this kind of random factor, but it’s really very disappointing. The variation comes in the number of balloons on screen for the player to pop – players must input one tap of the screen for each balloon, without hesitating. Because of the sheer number of animation frames required for the different sprites – particularly the popping balloons – I didn’t have enough memory available to include many children, but at the same time I needed to include a sizable minimum number in order to challenge the player’s counting ability.

In the end I made it so the game has an 80% chance of displaying 5 balloons, and a 20% chance of displaying 4 balloons. This is a very small difference, and it only really starts to become challenging after about a dozen speed-ups. This is probably the worst element of the game.

4) Humour

This one’s entirely subjective, but I like to squeeze jokes into all my games – in fact, I have trouble doing pretty much anything in life with a straight face. Even when I’m making games about suicide and misery, I usually make time for some dark humour. A samurai slicing up kids’ balloons is needlessly mean-spirited but still cute! And if I have to explain why a man’s trousers falling down is funny then there is no helping you.

5) Holistic design

This is a phrase I like to throw around a lot and it’s worth explaining again in this context (before someone convinces me that it’s meaningless). In short, I try to ensure that every element of the game’s design has a relationship to the other elements – that they have a strong ‘purpose’ for being the way they are. It also involves trying to squeeze what you can out of your limitations – in this case, that means working with a limited control system and tight restrictions on the number of objects and animation frames.

Under the terms of the contest, the game name was obviously my starting point for design. I figured Oh, Samurai! would have to be a game about a samurai doing something he shouldn’t be doing, and – yes, drawing lazily on samurai stereotypes such as Goemon Ishikawa XIII (warning: link is an anime music video) – I felt like it would have to involve slicing things up. To keep things simple, one tap of the screen would equal one slice of the sword, and that would be the only control.

I didn’t want any graphic violence, but I did want to include the trope of things only becoming sliced up after the samurai has sheathed his sword. Disappointing children seemed like a good idea – childish, light-hearted, un-samurai-life behaviour – and once I found a good ‘pop!’ sound effect I settled on bursting a collection of balloons. I often use the availability of sound effects to determine the content of my game, rather than the other way around – particularly in Wario DIY, it’s a lot more effective to draw your sprites so that they match your sounds. The number of children, as explained earlier, was determined by a combination of needing to challenge the player ability to count within four seconds, and the animation frame limits hard-coded into the editor. The music was mostly generated by the automatic composer, but the details and instruments were tweaked to make it sound upbeat and vaguely oriental, in keeping with the samurai comedy theme.

Conclusion

All in all I’m pretty happy with how the game turned out, but it’s a shame there isn’t more to be done with distributing the game. I have no idea how many people have played it, there’s no way for them to send me feedback, and after a month or two it was taken off the server and became unavailable again. The only permanent archives of contest winners can be found on fansites such as VixyNyan’s, which require you to use .sav editing tools (like miotool or CrygorTool) to hack the microgame data into your game – far from ideal! If you really want to go down this route and play Oh, Samurai! you can download the .mio file here.

More importantly, I think it exemplifies a lot of the principles I work into all of my microgames, and pretty much all the games I make in general. It’s important to have a clear interface that is rewarding to use – players should be thinking about the effects of their actions, not the act of physical input* – but you also need a substantial depth that holds up once the player has stopped to think about the game.

Basically what I’m saying is that a good game needs to be good in the short-term, and the long-term, and also the medium-term. Don’t all gasp at once!

——————————

*You might want to be a jerk here and talk about games like GIRP and QWOP, but none of these ideas are hard requirements for good game design – they’re simply the things I keep in mind when I am designing.

Perhaps I could have come up with an easier game, but Pong is also extremely elegant – perfectly balanced in strategic terms, and a good mix of reaction and prediction. If you need convincing, I’d suggest you read the theory of Pongism. There was no doubt in my mind that I could knock together a working version in Game Maker, but obviously there was little value in making an exact copy. What kind of changes could I make that would notably change the gameplay without losing its elegance? I thought about games like Llamatron and Galaxian, before realising that it probably wasn’t going to help much. I didn’t want to add or remove anything, just change the way the game was played, and I realised the key to that was to change the timing of the game. It followed that the simplest way to change its timing was to make it turn-based – to split the game into a ‘movement’ phase where the ball is locked but the paddles can move, and an ‘action’ phase where the paddles are locked and the ball can move.

Then I got a new job and suddenly the portfolio stuff didn’t seem so important and the idea was shelved. Here is another valuable lesson in why creative projects don’t get finished.

Over the last year I’ve been regularly taking part in Klik of the Month Klub, a 2-hour game-making contest fought using the most awkward and unusuable tools it has ever been my misfortune to encounter. This month I decided to kick it up a notch and enter Ludum Dare. I thought it might be a fun way to start my Christmas holiday! Well, right from the start I was disappointed when ‘discovery’ was chosen to be the theme of the contest – considering how popular Minecraft has become since the summer, I was expecting a lot of the games to follow similar themes of digging and spelunking. In a more general sense, every adventure game ever involves discovering strange new locations, characters and artifacts. I wanted to something a bit more unusal, more like the kind of weird junk I turn out for Klik of the Month Klub, so I thought about ways to turn the theme around and make it more interesting.

Instead of being about the act of discovery, my game would be about the fear of being discovered! You are hiding something from someone you care about and you will jump through hoops to prevent them learning your terrible secret. Perhaps you are a serial killer who has invited his friends round for a dinner party, but has carelessly left a load of corpses and murderous implements lying around the house? I decided this was too morbid – like with my experiments with Wario Ware DIY, I think I prefer making games that are broadly family-friendly. How about this: You are a gay teenager and you are trying to hide this fact from your family! It was an interesting idea, and if the subject matter was handled well it could have ended up as a really good game.

But then I remembered the old advice about not being over-ambitious. I scaled my ideas back, thought things over, scaled them back, thought things over, and eventually ended up thinking about my idea for turn-based Pong again. It was perfect! Hide the ball and make it a game of deception, where players use radar sweeps and other tools to bring together partial scraps of information about the ball’s location, deploy decoy balls and counter-intelligence to keep their opponent in the dark, and all in the midst of a regular, back-and-forth game of Pong.

Well. I realised early on the second day that there was no chance of me finishing the game in time to enter Ludum Dare, but I did have time to comfortably complete my original turn-based Pong idea. Instead of trying to fudge in the counter-intelligence effects, I focused on just polishing up the game I had – adding some little messages and visual effects, fixing the one little niggly bug I found regarding deflection angles, etc. I think it came out alright! The bats are a bit too small perhaps, and I think I should compile another version that runs at a smaller resolution – currently it’s running in 1280×720 – but I’m happy with it. It came out pretty much exactly how I expected. The only disappointing element is the name – I couldn’t decide what to call it, and I wasn’t sure if mentioning Pong in the title could lead to legal issues.

Download Generic Turn-Based Video Tennis Game HERE (Windows only).

My original idea was to hybridise the tight spacial challenge of Tetris with the broad elemental planning of Sim City, to create a casual puzzle game in which players would create a patchwork landscape from a series of random tiles. I decided to break away from the topic of urban planning, partly to help cover my inspiratory tracks (sneaky!) but mostly because I wanted to broaden the game’s appeal. Central to the game was the interactions between different elements – such as with Sim City‘s residential, commercial and industrial zones – so I spent some time thinking about real-world situations in which these kinds of interactions occur. I hit upon the idea of an ecosystem, with different groups of animals and plants and things all relating to each other in different ways, and settled on an African safari reserve. Conceptually, I mean.

So, basically, you select your game type and difficulty level and so on, and then  get about ten minutes in which to place a series of tiles representing lions and zebras and trees and roads and things. Making particular tile combinations – such as putting lions next to zebras, or connecting buildings with roads – scores bonus points and creates a little graphical flourish, such as cars driving from building to building. As play progresses, the park ecosystem undergoes a visual evolution that mirrors the player’s developing score. Depending on the game mode selected, the game ends when the players reach a target score, exceed a time limit, achieves an objective, and so on.

For my coursework, I wrote up a basic design document for Puzzle Park, with a word limit of 6,000 words (not including the barrage of tables in the appendix). You can download it here.

(The snazzy title picture was drawn by minkee, for use in my initial game pitch presentation – the lovely vector version she gave me has been marred by my raster resizing, but that’s entirely my fault. The wobbly pixel art screenshot mock-ups are my own work.)