On Microgame Design
by Owen,
at 16:18 UTC
actual game designs : things made and done | permalink | rss
As I’ve previously mentioned, I love Wario Ware DIY. My only complaint is with the highly restricted content sharing tools, but they do include one redeeming feature: a semi-monthly game design contest! I entered regularly to begin with, although as time has passed I’ve spent less time noodling around in Wario Ware and more time concentrating on Game Maker projects – as much as I love working within microgame constraints, there’s not much point making games if nobody can play them. That said, I have had one minor success: one of the games I made last summer was a contest winner!
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.






