Introduction:

I've received a few emails as of late by folks asking what things they should look for when developing a larger scale game. Now, while I certianly don't have all the answers, I've been in this industry long enough to know some of the things that typically kill projects...or at least the enthusiasm for them. There are many additional things that could be added to this as well, so please feel free to add them in the discussions area for this article (see below).

Also, I know that all of these points aren't really applicable to small game hobbyists, but it may provide some insight into the difficulties faced by development houses and the people that work in them.

Most of what I'm going to put here may seem daunting or negative. It's more of a wake-up call to the realities of large-scale game development. It's not intended to discourage, it's intended to help you prepare so you don't get discouraged.

Development Cycle:

The average development cycle for a game these days is between 18-24 months...and that's FULL-TIME. It's extremely unlikely that anyone can churn out a high quality, industry competitive title in 6 months. It's not impossible, mind you, but it'd be a pretty amazing feat.

Planning and Design:

The importance of this can't be overemphasized. Where most game developers fail (yes, even the big ones) is that they don't take the time to plan properly. They have an "idea" of what the game will be and they just work on code and graphics to make that idea come to life. The problem here is that your idea may not be the programmers idea or the artists idea, and so on.

Now if you're making a PacMan clone, who needs a full-scale design? It's a simple game and you probably know it like the back of your hand. But a larger original title is a different animal.

I remember a design document of an un-named game (to protect the innocent) that was astonishing. The design was fantastic and it was ENORMOUS. I'd guess around 800-1,000 pages long. Covered everything from the graphics, sounds, user-interface, multiplayer elements, code-base, story, player characters, non-player characters, etc. Was beautiful, really.

But that was just the game's *creative* design. The piece that described how stuff was to work in the game from the player's perspective.

What they failed to do was the game's *technical* design. This is what the programmers use to ensure that they're not stepping on each other's toes, and that they're not just hacking something out that will cause major problems down the road. While clearly not an 800 page document, it should be as thorough as possible. Since this was not done, the implementation of this game was so bad that it was slated to be scrapped. Unfortunately, the corporate machine decided to make what money they could from it anyway...which was really sad because a lot of consumers lost cash on it.

Teamwork

Teamwork is really easy to get going but it's tough to maintain. Everyone's excited for the first couple of months and then everyone starts getting bored. How much fun is it to code input handlers when you want to be coding a 3D engine??? But somebody's got to code the input handlers, right? There are many of these little non-glorious, necessary evils that have to be done, but nobody wants to do it. And that's just the programmers.

Artists and sound folks have just as many issues. Constant criticism is their lot. Artists draw and draw and draw and then they have to redraw because it's not what everyone expected. Music/sound engineers face a similar issue with their creative outlets.

Make sure you choose your team wisely. If you have a person who's the greatest at their job but nobody likes working with him/her, what good will that person do you? Not much. Look instead for people who are competent, enthusiastic, and sociable.

The Team Leader

This is the person that is in charge of keeping the above people happy, working together (by mediating disputes, etc.), and on track. Team Leading is not some wonderful "I'm in charge and therefore you do as I say" position. It's more of a "I'm in charge if I have to be, but my primary role is to be the one who encourages, motivates, and gets the team the things they need to do their jobs." This is the person who charges at the front of the pack to take the hill. Thus, this is the person most likely to take the first bullet. A poor team leader will point the finger at the programmers and artists when questioned on why things aren't working right. A good team leader will realize that it's *their* responsibility to work with the programmers and artists to make sure things DO work out right.

If the team leader is willing to take a bullet for a team member, the entire team will respect and work hard along side that person. If the team leader is a finger pointer, he/she can expect a subpar game.

Working Environment

Build an environment that is suitable to development. Cover it with toys, sci-fi/fantasy action figures, etc. Keep the mindset one of fun and excitement for being in the games industry.

Play Games

Play A TON of games as a group and discuss what's good and what's bad about each. You can take the good and avoid the bad. This is important for reasons beyond seeing what's bad and good though, it builds comradery and helps to show the team where your game will be better. That's key because that's the type of belief that keeps the team enthusiastic.

Start Small

Prove yourselves as a team by developing an original title that is much smaller in scope. Basically you're looking for a 3-6 month project that will help you learn about each other's styles. This will show you right away whether or not you can handle a 2+ year project as a team, and will point out problems right away.

There's not much worse than getting 6 months into development on a game only to find that you have to scrap everything and start again. Learn from something that's not as large and then you'll have a decently solid foundation to start the larger project(s).

Why Are You Doing This Anyway?

What's the reasoning behind making the game? If it's financial gain you may as well save yourself some headache and stop now. You've probably played many games built for financial gain...they suck. Games built by people passionate about making a great game, typically reap the financial reward because their games are great!

Professionalism

Be professional. Don't just slop through stuff. Take the time to do it right the first time. If you don't, you'll undoubtedly code yourself into a corner and have to either a) scrap everything or (worse, in my opinion) b) throw out a subpar game.

Focus

Stay focused. This is the biggest challenge you'll face, and I've emphasized it in nearly every point above. But this is really the crux of whether or not your project will succeed. If you find that your team keeps dumping projects left and right and starting new ones...you'll never finish anything.

So, again, start small and see what it's really like to develop a game with the team. If it works out, great! If not, at least you're only in it for a few months before realizing it.

Scope Creep

Be careful to avoid constant additions to your design documents. If you're not careful you'll end up having a game that never gets finished because there's always something new and cool that you want to add. Save these little trinkets of fun for your next project...finish this one first. A game can't have everything in it that you can possibly imagine. Well, at least not if you want to actually finish it. So think ahead, plan ahead, look to the future and predict what will be cool then.

The programmers should endeavor to make their code open-ended, of course, but sometimes that's not 100% possible. And even it is in your case, you still have to stop adding stuff at some point if you intend on ever delivering your game.

Quality Vs. Deadlines

If you ever sacrifice quality in the face of a timeline, your game will be subpar. I'm sure everyone here has heard the awesome hype of a game in magazines, only to find that when it finally hit the shelves, it was terrible.

The design was solid, the art is great, the storyline is good, but there's something that just stinks about the actual released product. Chances are it's buggy, incomplete, poorly balanced, or just plain un-fun. If you have ever found one of these little games, you can bet that it's due to some business wonk (note that not all business types fit this category...some get that quality is more important) forcing a release date as opposed to ensuring a quality release with a delay.

How many Blizzard games have you played that you thought were terrible? I've never played a bad Blizzard game. How many times have you seen Blizzard release a buggy, incomplete, poorly balanced, boring game? I never have. That's because they understand the equation: Make the game FUN for the customer and the customer will give you TONS of business...and they will come back.

Realism Vs. Fun

I have seen so many arguments over things like "realistic physics", "realistic water", "realistic explosions", and so on. The bottom line is that you can spend 6 months making realistic models and the average player won't notice or care. The average player will be more excited about a cool 3D car racing game that has cool physics than a realistic car simulation that isn't fun to play.

If the movie Star Wars had used realistic space physics, it would have been really lame. Forunately, Lucas decided to make the movie fun and scrapped the realism.

The same goes for games. Yes, you want to have it seem realistic enough that it's not stupid, but don't spend months on a realism that few will appreciate while sacraficing the more important aspect of fun.

Conclusion

Until next time...cya!

-Krylar