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.
Awesome!
Pingback: Dev.Mag is back
Pingback: Tweets that mention 11 Tips for making a fun platformer » devmag.org.za -- Topsy.com
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
Pingback: 11 Tips for Making A Fun Platformer | .: Blog.FlashGen.Com :: Mike Jones - Flash Platform Evangelist :.
Pingback: Picks of the Week 3 « Japskua's Programming Blog
Pingback: Dev.Mag is back
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.
Pingback: ??“??”???10???????? | GamerBoom.com ???
Pingback: Recursos sobre diseño de videojuegos « Daniel Parente Blog
Pingback: Starting Up | Philip Conrad's Blog
Thank you so much! It’s really useful! 🙂
Pingback: 11 Tips para hacer un juego de plataformas entretenido. | Dpad diseño de videojuegos
Great article!!, now i have a better understanding of the game development process, thanks!
Thanks for the feedback Ben, max and cool math 🙂
Glad you found it useful.
Pingback: 13 More Tips for Making a Fun Platformer » devmag.org.za
Hi! Big thanks for posting this! I was so worried about how I should start writing my platform GDD and this really helped to put things in order. :B
Pingback: 40+ Fantastic Game Development Tutorials From Across the Web | Gamedevtuts+
Pingback: Diorgo Jonkers » Game dev articles
I’d advise against prototyping – it’s a waste of time in my opinion. I personally first do all the graphics and then start to code using this graphics. Sometimes of course I have to make corrections, but the speed is much higher than if I was working on prototypes and later discovered that they were wrong.
Apart from that – great article.
Thanks for all the feedback 🙂
@Magnesus
It’s great that your system works for you and saves you time 🙂 From your description, I assume that you work alone. If you work in a team it may be better to prototype. Imagine if the artists just started creating graphics and when you finally start programming you realise that half the graphics will not be used. Therefore a lot of time (and money) has been wasted.
Prototyping does not necessarily mean you have to prototype the whole game before creating assets. You can prototype in bits, but ideally should prototype the main gameplay first. Essentially, you prototype something before creating large amounts of assets for it.
Here’s a simple example:
Everyone in the team agrees that the player will be able to walk, run and slide. The artists start
creating the player graphics and all the animations. When you finally program the game, you all realise that you spend most of your time running, and never walking and very seldom use the slide. The running turns out to be more fun than walking or sliding. You then decide to drop the walking and sliding from the game.
When I prototyped Pure Fun Soccer, I prototyped the main gameplay before any art was created. The prototype helped define all the team graphics that the game will need. At the end of the prototype, I could give the artist a very specific list of graphics I needed, even down to the number of frames per animation. (Because the prototype helped determine the maximum
texture size for a team, I knew how many frames will fit on the texture.)
Below are screenshots of the prototype graphics I used for Pure Fun Soccer:
http://www.diorgo.com/v1/uploads/2013/01/sg01.png
http://www.diorgo.com/v1/uploads/2013/01/sg02.png
http://www.diorgo.com/v1/uploads/2013/01/sg04.png
http://www.diorgo.com/v1/uploads/2013/01/sg05.png
http://www.diorgo.com/v1/uploads/2013/01/sg07.png
It was much easier and faster to change the prototype graphics (i.e. stick figures) during the prototype phase.
Pingback: 11 Tips for Making a Fun Platformer | Sekedar Catatan Kaki
Pingback: 10 Page Design Document: Olympus Hockey Draft 1 | PolyMth | Business Development
I know this is an older article, but I just want to say thanks for the tips. Most I knew, but some I didn’t realize or consider.
And on prototyping, I only prototype when planning out the workflow for dev. Make sure it’s possible, and only if I can do something simple quickly. There is no point to working months on a prototype.
Also, a prototype will tell you if the game is fun without the graphics. If you can’t enjoy the gameplay without cool art than you need to rethink the game. The art is the icing on the cake that enhances an already fun game. You can have an awesome looking game, but if it’s not fun than you’ve pretty much lost. On the flip side, how many lo-fi games are out there that people love to play, but look like trash? A lot.
When I made my first game where I work I probably did 10 prototypes of different style of games until we decided which one to go with. I did them in a month using different game engines until we decided which would work at that time. I would do the same thing for my personal work as well. If I’m not enjoying the game, the player won’t enjoy the game.
Pingback: Moonman: The Last 2 Years. | BP | I make video games and fun software by fractional distillation.
ish!
boode
Fuq son. If that’s all it took I’d be a billionaire, not even some cheap ass millionaire, I mean billions son, billions. damn… you got sum list for dat? i mean the cash maker.
after reading your articles i consider you the major authority for myself in terms of unity 3d, thanks
i want to ask you, what unity assets you may recommend as must-haves for developing 2d platformer? or, more in general, 2d game. i’m speaking of utilities here, not all thees ‘make platformer in two clicks’ things
although i’m not completely agree with this very article. all you suggest describes one particular type of gameplay. it’s not the only way to make ‘fun platformer’, i think. but for sure, a ‘general platformer’ not following your guidelines will be more hardcore and sell less, unfortunately ^__^
Pingback: [DevLog]Plateformers: Rigidité et manque de precision | Guendeli Omar
Pingback: Primeiro post | Technoverdrive
basedgod
Great site! Full of information for independant developers.
I love the fact that nowadays plenty of independant developers can give birth to otherwise never-born great concepts!
I see plenty of amazing new ideas florishing on kickstarter or indiegogo these days and that’s amazing to see so much creativity.
some very few examples I came across these past days:
https://www.indiegogo.com/projects/dual-madness/x/9643832
https://www.indiegogo.com/projects/pongish-9-to-5-minim/x/9643832
https://www.kickstarter.com/projects/eigenbom/moonman?ref=category
…
all very different bu amazing in concepts and there are plenty others.
This is mainly thanks to blogs like yours and thats awesome.
REALLY Helpful
What is the name of the game in the first screenshot there again please? is there somewhere i can download it?
I also wanted to ask, how to you make variations to the levels so that there is no repetition of design in level 10 for example and level 25?
Pingback: Platformer Level Design |
Thanks for the post Diorgo, lots of good insights. Especially find the prototyping section of your article important. I think game developers / designers don’t always think about the actual user story of the game. Always good to just do a quick play through with some mock assets to determine how the game mechanics feels.