The problem:
In my teaching of game programming, I watch students come up with game ideas, try to build them and then fail. I see some fail because they are lazy and just don’t work at the project, I see others fail because though they have good ideas; they cannot translate those ideas into code. My concern is those who have the capability, but cannot express the kind of game they want to build, or who express the ideas poorly and miss out important bits of the concept.I have just finished reading ‘Unity 3D Game Development by Example’ by Ryan Henson Creighton. The book is fair (but I’m sure some of it is out of date by now), but it has a great concept on the design and keeping the game simple. So I will borrow some concepts from there and try to string it together into a coherent whole.
I’m writing this to my students and developers who are in a team of 5 or less people and are trying to get something out in a few weeks-months
How not to do it:
(or just go to the original http://www.youtube.com/watch?v=3hMYF2CRFRo and skip to 6:03)
“My game will be like quake <or some other game>, just better!”
- Brain Dead!
- Define ‘better’?
- And if ‘better’ means ‘more weapons, more monsters, more levels, more ...’, then you must be even more brain dead!
- This may look better, but it’s still impossible.
- Ask yourself the following questions:
- How much effort does it take to design(think up) 5 types of monster?
- How much effort does it take to design(think up) 50 types of monster?
- How much effort does it take to draw/animate 5 types of monster?
- How much effort does it take to draw/animate 50 types of monster?
- How much effort does it take to program 5 types of monster?
- How much effort does it take to program 50 types of monster?
- For the designing and drawing, it will take about 10 times as long to do 50 types of monsters as it will for 5, but for programming, the difference is minimal because of code reuse.
- However the amount of effort to implement the monster system is a lot. Once it’s in, adding new monsters is easy.
- Now look at the idea again: you realise that from the programmer’s perspective, it’s got almost as much code as the full game. Reducing the amount of monsters/quests/classes has not made it any easier.
- This is not a game, this is a story.
- Back stories add colour and mood to your game, but they cannot replace the main game mechanic.
- The early games like space invaders, pong & pacman did not need a story.
- But they did have gameplay, and your game must have that too.
So what do we need?
Ok, for a while I will park all the content (story, levels, graphics, etc...) off to one side and ask yourself the following questions. Each answer should be a few sentences, a paragraph at most:- What is the game mechanic? How does the game physically function? How to you play the game?
- What are the main features of the game? What are the technical items which will need to be implemented?
- Which is the most important feature to making your game interesting/fun/special? (If your answer is ‘Storyline’, then this means that your gameplay must be totally generic and boring)
- What is the goal of the game? Does the game have an end, or does it just go on forever? (When answering this question, keep it short and sweet, don’t use the 50 page background story.)
A couple of examples:
Let’s have a couple of simple examples so we are clear on this:Pong
The one true game. It’s ancient, yes, but it’s easy to describe.- Main Game Mechanic: 2 players, each controlling a bat and bouncing a ball between each other
- Features:
- 2 Paddles/Bats
- Ball, which bounces off the wall & bats
- Score when ball goes off the screen
- Win/lose condition
- Most important feature: The bats & the ball, without it the game is just nothing
- Goal: First player to X points wins (it is 15 or 21 points, I cannot remember)
PacMan
Another old game.- Main Game Mechanic: Player runs around the maze, eating objects and avoiding the ghosts
- Features:
- Player which moves about
- Maze with wrap around
- Items to eat
- Bonus items (fruit) to eat for extra score
- Ghosts which patrol and then start chasing you
- Player killed when ghost catches it
- Power pills which turn the ghosts blue, and allows the player to eat them
- New level when all the items are eaten
- Three lives
- Most important feature: It’s the running around the maze with the ghosts chasing you all the way. That what makes the game fun.
- Goal: After each level the next level is a little harder, no final goal. Losing when you run out of lives
Serious Sam
For those who don’t know, go and look it up on YouTube (http://www.youtube.com/watch?v=uOgnIKjtKyE). It’s an FPS game which doesn’t take itself seriously and requires a 3-4 digit body count every level.- Main Game Mechanic: It’s an FPS! Player runs around a level, sometimes having to avoid traps or jump over gaps & stuff, but mainly just shooting bucket loads of monsters
- Features:
- FPS Player movement
- Large 3D maps
- Moving platforms, doors, triggers, traps & such like
- Weapons (pistols, shotguns, mini-guns, sniper rifles, rocket launchers, lasers, flame throwers, cannons, etc...)
- Smart bomb (yes, that’s right, an FPS with a smart bomb!)
- Items to pickup (health, armour, weapons, ammo)
- Bad guys which chase after the player
- Bad guys which shoot at the player
- Bad guys which kamikaze into the player
- Boss bad guy’s the size of tower blocks!
- Scoring
- Load/save game
- Plus quite a few other bits I missed...
- Most important feature: The thing that makes this game most fun is the ludicrous amount of bad guys which you end up mowing down each level
- Goal: There is a tiny back story, but basically its reaching the end of each level, killing everything in your path
Conclusion
Coming up with a game idea is one thing. Being able to describe it for others and then break it down into features to be implemented is another. I hope that this has helped a bit in getting you to think a bit about describing the technical aspects of your game.Happy Designing, before the coding,
Mark :-)
