This will not be an article on how to make games. Nobody knows how to make games... being in the game industry has made that abundantly clear. This will be an article on how to fail to make a game. Or, rather, the 6 most common reasons why people who are about to embark on the great journey for the first time fall flat on their face with their first step. While these may contain the extremes of archetypes, chances are they all, in one way or another, apply to your project.
"I'm going to make an RPG with 3,000 enemy types, real-time combat, and a first-person shooter mode. And dancing, lots of dancing."
You have 2 designers, one coder, and a part time artist. You have the staff, in other words, to make Tetris. Be realistic about how much you can accomplish. Take your most basic game ideas, and make them smaller and smaller until they can't physically get any smaller. 3,000 enemy types? More like 3. An FPS RPG with an all-new engine? Make a top-down shooter in Flash. 100 hours of content? How about a game you can beat in 30 minutes?
These "kitchen sink" game designers don't take into account that the reason current games don't do those things is largely because any single genre game is amazingly time intensive to make. Making 4 different games simultaneously, and making them all integrated together, is a task so Herculean as to be Sisyphean. Multi-genre games almost always come out like The Adventures of Bayou Billy: three main courses so totally undercooked as to be inedible.
The fact of the matter is it takes a team of 50 people working full-time for a year to make the average game. The really stand out games, like Half-Life or Zelda, take teams of a hundred people 3 years to make. Anything remotely close to that, or beyond that, is way out of scope for your first project.
There are a few things you have to watch out for in a design. Any time a story is being told in a non-linear fashion with a multitude of possible outcomes, a red flag should go up. Any time two or more genres are being mixed, consider cutting large portions of one or both. If you ever want to see sunlight again, and you will, make one game instead of three.
"I've got my design in my head, and now I just have to make it."
Believe it or not, Game developers don't make games. We don't slave away for 10 months so that a game can pop into existence. No, what game develoers make is milestones. The first milestone might just be some little code for a salmon swimming around in the water, the next milestone might add a player-controlled rod and reel, and the third milestone might have the fish biting the bait off the rod and reel if you wiggle the joystick just right.
No game gets out the door without this series of plateaus, the last of which happens to be something a publisher can sell (sometimes). People have said that game development is the process of hacking out a demo to entice a publisher, polishing the demo for E3, then polishing the E3 demo for sale. It's a series of little and big milestones, and deadlines where everything has to work perfectly.
If you don't set your milestones, and you don't develop your system, you just aren't going to get anywhere. You're not making a game. That's too big of a hurdle for any team. You're making a 5 - 10 pre-determined steps, all of which lead up to whatever want to make. Take the time to figure out how long each part of your development will take, breaking it down further and further until you are at about week-sized chunks. Your development map may be completely wrong, but if you don't have a map of some sort you can't know if you're making progress.
"It'll be finished when it's done."
There have been two games this has famously been said about... Warcraft 3, and Daikatana. Guess which one you're developing?
The fact of the matter is that sometimes games just don't work out. You plan a great story, you designed great gameplay, the artists created great artwork, the programmers wrote great code, and when everything comes together somehow it's far, far less than the sum of it's parts. It's ok, but not as great as it should be. Or maybe you feel your game will be finished when it's done because it's so truly bad, and the development so messed up, that nobody can realistically say when your team will be out of the bog you found yourself in.
There is a saying in the industry. "Ship it!" You can tweak and adjust a game forever, slightly improving graphics and creating more gameplay, but at some point you really need to put whatever you have in a box and shove it out the door. You have to move onto other projects, and the only way you can do that is if you finish the one you're on, or salvage what you can of it. I've never shipped a game that I didn't still want to work on and make changes to. I've never shipped a game that was perfect. Nobody has ever done such a thing, and nobody every will.
Your first game most certainly won't be perfect. But what are your goals? When I ship a game, my goal usually is to entertain people, and maybe get them thinking about gaming in a new way. Your goal for your first game is probably to get street cred in the game development industry, a feather-in-your-cap if you will. Always keep that goal in mind when developing your game. You needent make a 100 hour monstrosity if your target is going to be someone who is reading your resume and will have a grand total of 10 minutes to play. A single-level tech demo will more than suffice. You don't need to write a cinematic engine if you only have one cinematic in the game. Can you cut the cinematic, or is it key to how you are trying to get your cred? Can you cut the network multiplayer, or is it key to your cred? Always keep your goals in mind when developing your game, and always be thinking about what your next project will be.
It's better to have a good finished game than a great game that will never be done. This will not be your magnum opus, nor the only project you ever make. Get it done.
"I don't understand this. I'll figure this part out as I go along."
Some things are self-evident. Some things are so self-evident that you feel you needn't describe them ahead of time... How your revolutionary natural-language parser is going to work, how "getting an education" will effect your character's stats, or how role playing elements in a multiplayer game will affect actual gameplay. "Clearly it will work." Yes, but how exactly? If you can't answer that question about fundamental or key gameplay properties, you're not ready to start making your game.
Despite my sarcasm, some things really are self-evident. You'll figure out about how many power-ups to sprinkle around a level. You can design side-scroller boss mosters once you hammer out how many levels you are going to have. But never let a thorny issue of an original design sit unexplored. How are you going to give phone conversations gameplay value? How do you get the board game to interact with the videogame component? If you can't figure out how to make the "revolutionary" component of your design work as a game, maybe that's why nobody else has either.
We fell into this trap on a little side project I helped out with called The Story Game Initiative. Our revolutionary aspect was to give story gameplay value. it wasn't until a three months into the project that we had to push everything aside and think long and hard about exactly what it was this meant. Years later we're still sitting and thinking, and one of us has since gone off to get his masters degree in figuring it out.
"I have a binder full of 300 pages of design documentation meticulously pieced together over many, many years."
Ironically, one of the worst things you can do to a design is to get too detailed too quickly. There is a flexibility of design that you really need to create an experience as parts of it come online. "The hero is a heavily armed mouse" is a good one-line description for the beginning of a project. "The hero is a mouse with a shotgun, rocket launcher, and whip, who gets 5 shots of ammo per pack" is not. Until you have your gameplay more fleshed out, you won't know exactly what weaponry you will need to balance play, and you certainly won't know how much ammuntion your player will need. A lot of what goes into the game does so based on good ideas from across the length of the project.
You may think this is harmless, but the fact is that besides wasting time you're creating a structure that won't fit the final game, and anything built on that structure won't fit the final game. Design may be king, but a king has to dynamically respond to the situation he finds himself in. Your design too must be flexible enough not just to change and adapt, but to grow in the proper direction. And to do that it needs to be a little amorphous and undefined in places.
Keep your initial design doc a skeleton framework. As your team grows, add walls and a celing. Try not to design everything too early, or you will be left with a design that doesn't fit your game. Anything that is "Fun" (or whatever emotion you're attempting to evoke) gets attention and expanded upon. Anthing that isn't gets cut. Have your programmers create general systems for movement, rather than specific systems for moving characters whose designs aren't final. Have your artists start by sketching out "visions" of the world, rather than specific power-ups. Try not to throw final polish onto things that haven't been tried in-game: nothing discourages like throwing out weeks of work.
"I'll just do the music for the game myself. And the art. And the programming. I'll schedule it. I'll then promote it, I'll do bug fixes, I'll handle customer support..."
Laboring alone, or with the wrong people, is the greatest killer of independent projects. You might be OK with a compiler, a midi synth, and a pen and piece of paper, but it will take you forever to do everything yourself. Not only will it take you much longer to do something than someone who specializes, you won't be as happy with the results. A competent artist might churn out a 3D object every day in their spare time, while a week later you're still trying to make a chair using the lathe tool. You may be able to use a compiler, but you may spend two weeks writing and optimizing a custom binary search tree while a programmer might just call a prewritten hash table function and be done in five minutes.
The only commercial art form that has a single author anymore is books. Everything else is a team effort. Games are no exception.
People management, especially in small projects, is an interesting thing. You don't want to bring people in too soon, or their enthusiasm will wane with nothing to do. You don't want to bring people in on an emergency basis, because they'll still need time to ramp up. The key is geting a good, clear overview of your project's lifespan, and building from there. Since it's your project, it's your responsibility to find people and let them know what you're relying on them to do to make the project work. Don't be afraid to tell people what needs to get done.
Game development is a fun and interesting adventure, but it is a much bigger mountain to climb than many people realize. It involves a lot of factors that need to come together just right to be successful. Build your plan, build your team, and build your game. Just be aware of the paths treaded before you, and the reasons why people wound up skeletons by the side of the road.
To you budding indie developers: I salute you. Good Luck! ...You're gonna need it.
(Chris Canfield is a game designer at Harmonix Music Systems)
![]](images/rt_edge3.gif){kind=small}
![[P]](images/print3.gif){kind=small}
