This is the first post in my “Building a game” series! The aim of this series is to walk through building a game from scratch and try to include as much of the thought process involved as possible. So how about you grab yourself something to drink and let’s sit and chat about game design!

Before I sat down to write this post, I walked to Shawn Hargreaves and Eli Tayrien’s office and talked about game design with them. These guys know a whole lot when it comes to game development and I highly value their input. The question I asked was “How does one go about designing a game?”

There are two different aspects of game design that you want to think about: Game play mechanics and Game architecture. One has to do with how the game will play while the other is about how the game code/engine will work. For this post, we’ll talk about game play mechanics. These are the sort of things that you really need to have nailed down before you write a single line of code. The reason you want to flesh all that stuff out early on is to avoid being halfway through developing the game and then realizing that you really want to add this awesome new game concept. Knowing something like that late in the cycle will probably cause you a lot of pain to get it to fit in. Take your time now, think about stuff early on and get your blue print drafted out.

Project Name

This is the first thing in my opinion that you should come up with. Every project needs a name, and your game is no exception. A project name is not the final name of your game though. I mean, it can be if you want, but most of the time it isn’t. Windows Vista was called Project “Longhorn” for instance. XNA Game Studio v1.0 was “Rogue” while v2.0 was “Shaman” (Yeah… I know what you’re thinking…).

So why is a project name important anyway? Because it gives your project an entity. If you cared enough to name it, then you probably will care enough to finish it. Once an entity gets a name, it starts to get somewhat of a virtual soul. You refer to it by name, you talk about it as if it exists. Plus, depending on your project name, it can make it sound very cool and top secret-ish vs geeky and nerdy like our project names.

So go ahead, name your project something cool! It’s step #1 in the fun.

Game Description

This is a very important step in game design. This is the overall description of what your game is all about. Start with the idea you have for how it will play and then add to it. Someone reading this should be able to know everything about your game without playing it. It’s almost like writing the manual for the game before the game is written. So what kind of things do you want to think about for your game description? Let’s list some out:

• What is the game play about? Is it about a player controlling some entity in the world and shooting enemies? Is it a puzzle like game where you have to solve a puzzle of some sort?
• Is your game single player or multi-player? If it is multi-player, is it co-op or competitive? How are players going to interact together? Will I have to kill my opponent or work with them by sharing powers and/or resurcting them when they die?
• Is your game’s progression based on levels or increasing difficulty? If you’ll have levels, how will they be different from each other? Will levels introduce different challenges to the player or just provide a backdrop?
• What kind of behavior will my enemies have? Will they be coming at me in waves? Will they shoot at me and if so, how accurately? Will they have varying movement speeds? like some will travel fast while others slow?
• If you’ll have weapons, how will they work? Are they upgradable? if yes, then how? Are they balanced? Can you carry more than one kind of weapon?
• How will the player achieve victory or defeat in your game? Do I win if I kill everything on the screen? Do I lose if I take too long to finish a level? How can you make it very clear to the player that they are winning vs losing?
• Do I have power-ups in the game? How do I get them? What do they do? Are there power-downs? as in items that if I pick them up they actually hurt me?
• How does scoring work in the game?
• What happens when I die or lose? Do I have the concept of “lives”? Do I start from the beginning or can I continue from where I died?
• Will my game have network play?
• Will the game have some sort of achievement system? How will that work?
• How will the controls of the game work? If the game is PC/Xbox, then how can you make sure one platform doesn’t have an advantage over the other due to controls? It might be ok to have that, but it’s a decision to be made.

Game Story

So what about the game story! The world where my game is set in? I have this awesome story about an evil alien race that is determined to wipe humanity out by seeking ring like structures left by an ancient advanced race that is long gone! But wait! There’s a twist, there’s another alien race that will start messing with BOTH the humans and the evil aliens!

Yeah… there is a reason that I put game story after game design. According to Shawn Hagreaves, you can spot a good game designer from a bad one by focus on game story first. In the real world of game development, it is very possible that your sci-fi based game will be changed to a Viva Piniata like game by the publisher if they feel the game play mechanic works and the market needs such a game type now vs sci-fi.

Having a good game story is important and all, but make it a priority 2 while game play mechanics a priority 1. It doesn’t help if you have an awesome story but once the game starts, the player is bored out of their mind. While it is possible – and happens quite often – that a game with a pretty poor story and world but has amazing game play will win in the end. Having both story and gameplay being equally good is the holy grail of game development I guess. Some examples exist, but not many.

Stand on those shoulders damn it!

See those giants? Stand on their shoulders! Once you identify what kind of game you want to make, it is very helpful to go out there and find similar games. Play them. Take notes. Have fun. Spend a lot of time criticizing them and reading what others said about them. Find things that you like about them vs things you don’t like.

For instance, let’s say you’ll be creating a Real Time Strategy (RTS) game. Go out there and find what others have done with RTS games. You’ll find that they can be quite different. Some games like Warcraft 3 have the whole Hero RPG element in the game. Some people love that while others hate it. Some RTS games have very different races to play with like Starcraft. What kind of destructive super powers did you like? What elements seemed really fun while others were meh. Resource management in RTS games can be very different. Some have you gather one or more kinds of resources. Others make you hold points on the map to gain resources.

The point is, see what’s out there and learn from it. It’s not about copying what others have done, it’s about improving and adding your own touch to already successful ideas. It’s a delicate balance between improving upon vs flat out copying. Don’t worry though, if you do copy something, people playing your game will let you know very quickly :)

It’s the little things

This is the trickiest part of game design if you ask me. There are games that do this very well. You’d be playing a game and something very small and seemingly insignificant would happen that would make you feel so good! It’s kind of hard to explain without an example.

Take Call of Duty 4 for instance. One of my favorite games right now. I noticed that one of the things that I LOVE about it and actually makes me want to play it more is the feeling it gives you when you shoot an enemy. It’s a mixture of the way the aiming reticule changes to an X indicating that you are hitting an enemy and that awesome DUB DUB sound it makes when you’ve landed a killing blow. The experience points that show up as well seal the deal. Check out what it looks like:

I don’t know what about this whole experience that makes every kill in CoD4 very enjoyable. You feel you’ve done something! You’ve made a change. Now how do you think something like that sounded on paper?!

CoD4 Design team: “Yeah… so we want the aiming reticule to change to a X when you’re hitting a person. We also want to have this like… eh… DDDUB DDUB sound play as your bullets hit the target. It’ll be awesome!!!”

Dude with $$$ (i.e. Publisher): “Yyyeah… that sounds… like a lot of fun. What else you got?”

Stuff like that are pretty hard to come up with. But it’s better to think about them and try to come up with some than to not at all. Think about how you can make your player feel good when they do the right thing. Prototype such ideas even if on paper. Believe me, once you find that little hook, you’ll be very happy.

Here’s another example for you, I am just so full of them today :) We had a game internally developed by some dude from Rare studios while we were working on version 1.0 of XNA Game Studio. The game just couldn’t be simpler than it was. You and up to 3 other people control 2D ships on the screen and you all have to work together to destroy all the asteroids on the screen. Every level, you have to destroy more asteroids. The hook though was when one of your buddies died. You can bring them back to life if you collect a randomly spawning star that is the same color as their ship. Once your buddy would die, they would instantly start yelling “BRING ME BACK!!! QUICK!!” and everyone would be searching all over the screen waiting for their resurrection star to show up. Once it did, we would ALL rush to it to bring them back and more often than not, we’d all ram into an asteroid and die together. Such a simple concept but it was so fun that we played that game for hours! Probably caused us to delay the release a little bit ;)

Last words

Spend the time doing all this for real. Get yourself some sort of notebook or something, write the project name on it and write down all the ideas you have. Flesh them out, discuss them with others or teammates. Criticize them, find the gaps, find the fun stuff, etc. Before you start coding your game, you should know everything there is to know about it. This way you won’t be slamming your head on a wall later because your design is not flexible enough to add that awesome feature you just thought of.

Next post we’ll actually go through the exercise of me putting all this into practice as I design what will probably be a super lame game :) It’ll get the point across though. In the meantime, start thinking about your game!

• Previous Entry: Dude…where’d you go?!
• Next Entry: Project "Odyssey", The Design