Skip to content

Instantly share code, notes, and snippets.

Created December 23, 2014 08:03
Show Gist options
  • Star 45 You must be signed in to star a gist
  • Fork 4 You must be signed in to fork a gist
  • Save polm/05db396cf08b9ec2a81c to your computer and use it in GitHub Desktop.
Save polm/05db396cf08b9ec2a81c to your computer and use it in GitHub Desktop.

Following is a translation of a post by Kenta Cho (@abagames) about what he learned making 50 minigames in 2014. The original post is here:

This translation is by Paul McCann (@polm23); please feel free to contact me with any comments or corrections.

The Secret to Creating Fun Games I Learned By Making 50 Games in a Year

... is that there isn't one.

Here's the link to the collection of games I made this year:

Every game has an animated GIF screenshot you can click on to play the game. I ordered them from top left to bottom right by how interesting I thought they were.

Each one is an old-fashioned minigame you can play in your browser. Half are in Flash and half in HTML5. They're written in Haxe or CoffeeScript, and the source is included with each.

I thought if I made 50 games in a year that by the end making a fun one would be a breeze, but even now ideas that are really interesting in my head often turn out really boring in the end, so I'm pretty sure there's no such thing as a simple "theory of fun" for making good games. Or at least I haven't found it yet. To create a good game you just have to make it, play it, and fix it until it's fun.

That said, I did learn some things helpful for making old-fashioned minigames:

Novelty is just a starting point

If you're going go to the trouble of making your own minigame you'll usually have a new gimmick or feature you want to try out, and this almost always results in very original but incredibly boring game. The important thing is to not give up when you find it's boring, but change your very original but no-fun game into a game that's pretty original and pretty fun. Learning to revise towards a conservative design is tremendously helpful for making progress when a design seems stuck.

Force new ideas by making one-button games

Before you can cut down on originality you have to have some, which is its own problem. When you're short for ideas try making a one-button game. The one-button constraint forces you to come up with new ideas, and figuring out controls and mechanics assuming one-button controls gives you an easy-to-understand game as a starting point.

Chain reactions are your friend

When in doubt add chain reactions. Everybody loves it when explosions go off one after another. The only thing to look out for is if you don't polish it correctly you'll end up with a pretty generic game.

Gravity's your friend too

Having characters fall towards the ground or be attracted by the pull of planets or otherwise putting gravity in your game is an easy trick but a good one. The same goes for magnetism.

Learn from Retro Games

The classics are classics because they're overflowing with fun mechanics. Taking just one of those mechanics and putting it in your own game, re-making just one part of a retro game as a completely different game, is often a useful starting point.

Leave level design to the computer

This is more a tip about how to make games quickly than how to make good games, but getting used to using procedural generation for level design is incredibly helpful in making minigames in a short time frame. Making the procedural generation part clever on its own is important, but a good trick to keep it from designing ridiculous levels is to generate the correct path first and just fill in the rest, or, alternately, to randomly generate a level and just add on the correct route afterwards to guarantee a fair design.

Aim for a difficulty curve the player will accept

Most minigames slowly get more and more difficult until the player can't keep up and loses. If the game suddenly gets ridiculously hard or the player loses due to an unforseeable circumstance they'll feel cheated. Ideally the player should feel like if they tried a little harder they could have gotten past the point where they died.

Risk Driven Development

Having said that, if the game starts off too simple the player is just hanging out with nothing to do. You can deal with this by giving the player an incentive to do something dangerous in return for a bonus, and if the risk/reward ratio is just right a player can get a Game Over after one second and feel it's fair. Deciding what kind of risky option to give the player and designing your game around it is what I like to call Risk Driven Development and I recommend you give it a shot.

This is what I've come up with so far. Many thanks to everyone who has played my games this year and to those who have told me what they thought of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment