A platformer is a game in which a character runs and jumps around a level consisting of platforms floating in the air. Although this article focuses on platformers, the philosophy behind each idea can be applied to any type of game, whether 2D or 3D. This list does not only include tips for the product (a fun game), but also for the development process.
1. Keep the user interface simple
The player presses the jump button to jump. That is a simple user interface. The challenge for the player is pressing the jump button at the right time to complete the game. In other words, the challenge is not using the interface, but using it at the right time.
The more transparent and intuitive the interface is, the better. If drivers on the road had to concentrate on how to turn their vehicles, there would be many more accidents.
The simple interface also applies to the menus and all other interactive sections of a game. It must be easy to navigate between menu items and to select items.
2. Make important information easy to see
Make it easy for the player to see important things in the game. Platforms that the character can walk on must stand out from scenery in the background. Collectable items must be easy to recognise. One glance at the HUD should give you all the information you need. An easily readable font is a necessity. The player must know what is going on in the menu.
3. Mind your collision boundaries
The collision boundary of a friendly object is bigger than the object. The collision boundary of a harmful object is smaller than the object. Friendly objects include power-ups, switches, ladders, and swinging ropes. Harmful objects include enemies, enemy bullets, spikes and rotating blades. The bigger collision makes it easier to interact with, or collect the friendly object. The smaller collision makes it easier to avoid the harmful object.
The green rectangles are the collision boundaries of friendly objects, and the red rectangles are harmful objects. The yellow rectangle is the player.
(The collision boundary can also be referred to as collision rectangle, collision bounding box, collision sphere, collision region, collision polygons, etc. The player collides with an object if the player’s collision boundary overlaps the object’s collision boundary.)
4. Make it easy to jump over gaps
The player can jump when he is in the green area. The larger green area on the right makes it easier to jump across platforms (that’s a good thing).
Traditionally in games – and realistically – a player can only start jumping if he is standing on something. Allow the player to start jumping when he is in mid-air, when he just stepped off the edge of a platform. Have a leeway of about one second in which the player can start jumping. (After the one second he can no longer jump, and continues to fall downwards.) This makes it easier to jump from one platform to another.
5. Make it possible to change animation states anytime, anywhere
The character’s animations should follow the player’s movement, not the other way around. In other words, the player’s movements should not be limited by the animations. Ideally, any animation should be able to start from any other animation, at any time. The player wants to run, jump, grab onto a ladder in mid-air, climb up, shoot his gun, and jump off the ladder. The animations should allow him to do that.
Also, the player should never have to wait for his character’s animation to end before he is able to move again. Do not disable input while an animation is playing, causing the player to wait for the animation to end before he can move again.
6. Provide plenty of power-ups and collectables
Most kids collect stuff, purely because it is fun. That same feeling of joy happens when you collect things in a computer game. Put collectable stuff in the game. The more, the better.
There is no logical reason for it. It is just fun.
7. Write generic, but versatile AI
Design and code a small number of base AI agents, each containing a small number of variables. The variables are given different values to create a large variety of AI agents.
Examples of base AI
Walking AI
Walks on horizontal surfaces.
| Variables | |||
| Health | Speed | Jump height | Attack style |
| 1 = Easy
3 = Medium 5 = Difficult |
0 = Static (remains in one spot, e.g. Venus’s flytrap)
1 = Slow 2 = Medium 3 = Fast 5 = Super fast 10 = Slow, but fast when the player is nearby |
0 = Cannot jump
1 = Low 2 = Medium 3 = High 10 = High when the player is directly above |
0 = None, just wander around
1 = Near range melee 2 = Medium range melee 3 = Shoot projectiles |
Examples: Knight, Archer, Fire Elemental, Giant Venus’s flytrap, Elf.
Flying AI
Flies around in the air.
| Variables | |||
| Health | Speed | Fly diagonal | Attack style |
| 1 = Easy
3 = Medium 5 = Difficult |
1 = Slow
2 = Medium 3 = Fast 5 = Super fast 10 = Slow, but fast when the player is nearby |
0 = Cannot fly diagonally
1 = Can fly diagonally |
0 = None, just wander around
1 = Near range melee 2 = Medium range melee 3 = Shoot projectiles |
Examples: Hawk, Gryphon, Ghost, Air Elemental, Dwarf in gyrocopter.
Crawling AI
Walks on any surface: horizontal, vertical, diagonal and upside down.
| Variables | |||
| Health | Speed | Drop down | Attack style |
| 1 = Easy
3 = Medium 5 = Difficult |
1 = Slow
2 = Medium 3 = Fast 5 = Super fast 10 = Slow, but fast when the player is nearby |
0 = Cannot drop from the ceiling
1 = Drop from the ceiling randomly 2 = Drop from the ceiling when the player is beneath |
0 = None, just wander around
1 = Near range melee 2 = Medium range melee 3 = Shoot projectiles |
Examples: Giant Spider, Worm, Killer Snail, Slime Elemental.
8. Have a story and atmosphere in mind
Define the game’s story early on in development. The story is a guideline for the game’s overall atmosphere, art style, and goals. The story can be complex or a single line of text. You can reveal the story to the player in cut scenes and dialogue, or you do not need to show it to the player at all. As long as everyone working on the game knows what the game’s story is.
Example story: A lone marine fights hordes of zombies and demons on a moon base.
From this story we know what the game is about.
- lone – single player, solitary character
- marine – fighter, army, military, tough-as-nails, guns, shoot stuff
- fights – action, fighting
- hordes – many enemies, relentless
- zombies – gore, gun fodder
- demons – supernatural, dark
- moon base – sci-fi, futuristic, remote
9. Define scope and time clearly
Make a list of everything that needs to be done to complete the game. Then estimate how long it will take to implement each item in the list. The amount of time you end up with is the minimum time it will take you to complete the game.
To put it into perspective: If your design document is 50 pages long, and it takes an average of 2 days to implement the features per page, then it will take you at least 100 days to make the game. It is natural to have an initial design doc which does not include everything that will eventually be in the game. More pages will be added to it during development.
To put it into perspective again: If it takes an artist 2 weeks to create and animate a character, then it will take 20 weeks to create 10 characters. That is 5 months – almost half a year. If you have two artists, then it will take half the time to complete the characters. But it still takes 20 weeks of actual work. In other words, you still pay for 20 weeks of work.
It is very easy to think of new features to add to a game throughout the development process. However, every time you add a new feature, you push the release date further away. Continue to add features on a regular basis and your game will never be complete. When you add a new feature, be prepared to take another one away to meet your deadline. Make sure that you prioritise your initial list of features, so that the least important ones can be dropped if (or when) you run out of time.
Do not be ashamed to make a game which has a very limited number of features. The people laughing at you are probably working on an MMO that will take them 15 years to complete.
Remember, one of the most rewarding feelings in the world is to complete a project.
10. Prototype before finalising theoretical fun
The prototype, with placeholder graphics. The green block is the main character, and the red blocks are the enemies. Compare with the image below.
There are thousands of good ideas for computer games, but not all of them are fun. The best way to find out which are fun, is to prototype the game. The prototype is a quick-to-make and quick-to-change version of the game that helps you to test out your ideas.
Why prototype? It saves you time in the long run. Have you ever had to recreate art or reprogram a system because the design changed as a result of the game not being fun?
To save time, use an existing game engine and download free resources from the internet to create the prototype. The prototype may be done in the same engine used for the final game, and some of the code can be reused.
The final game with Renaissance art.
The prototype may also be a completely separate program (or programs) that will be discarded when the final game is in full development. For this reason, there are people who do not like prototyping. They believe it is a waste of resources and time, because the final prototype ‘product’ is discarded. Think of the prototyping as another idea phase of development. During this phase you test out your ideas, change them, replace them, and tweak them, until they are fun. The prototype ‘product’ is, therefore, a tool used for testing ideas.
Remember: Prototyping must also be included in your list of things to do, and, therefore, must be part of your schedule.
11. Involve everyone in the team in the design
Would it be better for an artist to work on a character if he or she was involved with designing the character? Or better yet, if he or she came up with the idea for the character? Would it be better for a programmer to code a system if he or she was involved with designing it?
The answer is yes. It will also be better for the game.
A game is a creative collaboration. If only one or two people design the game, then it will be creatively limited. People generally feel happier and more devoted to a project if they are included in the design process. Therefore, encourage everyone to be involved in the design process. And it does not always need to be a formal process. In other words, you do not always need to schedule a meeting where everyone is involved. People can send emails, talk in the kitchen, or shout across the room.
Further Reading
- A Detailed Cross-Examination of Yesterday and Today’s Best-Selling Platform Games is a must-read for any platform game designer.
- The Wikipedia entry Platfrom Game gives a nice historic overview of the genre.
Related posts
- How to design levels for a platformer This article looks at the process of designing levels for...
Diorgo Jonkers
Diorgo Jonkers has been working in the computer game industry since 2001, mostly making mobile games. Companies include I-Imagine, Smallfry mobile and Luma Arcade. Currently he works part-time for Luma Arcade, primarily as a game designer and occasionally as a programmer. He also writes, edits and publishes comic books (http://www.gep-comic.com/).
Awesome!
Nice list… I’ll remember that point about being able to jump despite being in mid-air, it’s wonderfully counter-intuitive.
There is a very important point I thought of that you didn’t include, your point about jumping touches on it. If we’re talking about a jumping platformer (like your Mario Bros image), a really fun 2010 platformer is going to have to include interesting, and powerful, mobility.
I mean wall jumping, wall climbing, double jumping, ledge climbing, grappling hooks, slides, jet packs, human cannons etc. To make a really fun jumpy platformer (like Super Meat Boy) the player has to have a powerful sense of mobility. A lot of the joy in a game like Knytt Stories comes from just that: being able to achieve epic feats of mobility with great ease and control.
Anyway… just though I would mention that. Nice Article!
Thank you, Pungaros and Evan
You’ve mentioned an important point, Evan.
Powerful mobility, implemented well, makes a platformer fun. Some of the most fun platformers have wall jumping, climbing, double jumping, etc.
Someone once asked me why there’s a double jump in games, why not just make the first jump go higher. Because it is fun to get that second feedback when you press the jump button again. Especially when the character makes a sound when he double jumps
It also adds to the challenge, if you don’t jump at the right moment then you miss reaching the platform or power-up above you.
And the most important part you mentioned is “mobility with great ease and control”.
Your last sentence reminds me of Wolfire´s Knytt Stories Design Tour
Thanks for the post!
#4 is interesting..
#6 is horrible
haha great article! The stuff about being able to jump in mid-air is something I think a lot of people don’t realize is in classic platformers.
And the wider collision boundaries for helpful objects and smaller ones for harmful objects is HUGE…I went through that myself when I had testers playing my game (Elusive Ninja: The Shadowy Thief App Store – shameless plug haha) I had collision boundaries that were all the same size for both the dangerous and helpful objects and it only checked for collision on one frame of the animations…this was good for the dangerous objects because you had a little leeway since things had to line up just right to count as a collision.
But using the same code for the helpful objects, while efficient code-wise, it meant you’d often just barely miss them.
The best way a tester put it was “It’s not necessarily unfair, but I’m not catching the helpful objects when I feel like I SHOULD be catching them, and that’s frustrating” I changed it up so the helpful objects have a much wider collision boundary and are active for a couple extra frames and it made all the difference in the world in the feedback from my testers.
What the player expects to happen is sometimes more important than what should logically happen.
- Jeff
Thanks for the compliments, qubodup and Jeff
Jeff, I like your quote:
“It’s not necessarily unfair, but I’m not catching the helpful objects when I feel like I SHOULD be catching them, and that’s frustrating”
and what you said:
“What the player expects to happen is sometimes more important than what should logically happen.”
The two key words being “feel” and “logically”.
When you program a game, you think logically about what happens in the background of the game. You even use this logic to judge how fun the game is.
But a player does not see the logic in the background. He/she judges how fun the game is by how fun it feels.
For example, a programmer might say: “I wrote this awesome physics code for making those boulders bounce randomly and change speeds. It’s gonna be fun to run around and dodge the boulders.”
The player might say: “These boulders are unpredictable. Why don’t they just role in a straight line so I can avoid them. This ain’t fun.”
Thanks, this is a great set of tips! Very useful for me personally.
Thank you so much! It’s really useful!