Steps I-III

By Damon Brown

www.geocities.com/SiliconValley/Pines/6547

browndamon@hotmail.com

This series is meant to help beginning game developers (particularly solo) keep in mind the basics of good game design. It is set up differently, however; the nine principles are set up like tips on cooking- a rather unusual, but applicable parallel. This isn’t meant as an end-all, and I certainly have a lot to learn. However, I do have game design experience as a solo developer, so this is meant as a simple guide with solid design principles.

As I mentioned in my other articles, I have had difficulty as a solo game developer changing hats (sound engineer, level designer, lead programmer, artist, etc.), particularly with game programming and game design. For a period of time, I thought game programming and game design were the same thing.

"I programmed the guy to walk across the screen? Great! Now I can make Zelda!" Not quite.

Game programming requires analytical skills, logical creativity and patience. Game design requires psychology- it is a simple as that.

The best way to explain this psychology is to quote Dave Perry, head of Shiny games, describing Shigeru Miyamato, the highly-regarded Nintendo game designer (the Mario series, Zelda, etc.) He said, in Arcade Magazine issue 3, "Miyamato knows what you’re thinking at every moment… When you think you’re being smart, or you do something unexpected, or even go the wrong way, he’s already there with you."

To design well, you have to be the user. You have to get in the player’s head. How many times have you played a game and said "Wouldn’t it be cool if you could…"? That’s how many times game designers have missed an opportunity to expand their game universe. Don’t be that designer. J

Easier said than done. We will never reach perfection, but I hope that my guide with all the other sources out there will help you achieve your personal best. If you have any questions, e-mail me at the address above or visit my webpage above.

Finally, as a warning, I have a dry sense of humor. You’ve been warned…

Enjoy,

DB

-

IV. If The Flavor Is Good, Let That Flavor Come Through

V. Enjoy Experimenting – If It Goes Bad, Start Over

VI. Too Many Cooks Spoil The Broth

VII. Spice Is Nice

VIII. Two hours at 500 degrees isn’t equal to four hours at 250 degrees

IX. Savor The Meal

-

Really important. I imagine most people who have developed games, even solo, can testify to how having your stuff together helps ease the transition of game concept to actual game. In fact, this is even more important for solo developers, because working on a team allows many people to keep the game on track. When you’re solo, you are the team.

It is difficult to find the patience to wait and plan your game before coding and designing. There are many schools of thought on this, the most popular being the (sometimes dreaded) DESIGN DOCUMENT. A design document is basically an outline for your game done before any production begins. Design documents usually cover everything, from the graphics to the plot to the controls to the team developing the game. More complex ones cover your target audience, proposed development time, and budget, among other things.

Design documents for commercial games can run into hundreds of pages. As a beginner or solo developer, however, you probably won’t need one that large. In fact, you may not need one at all. One game I’m working on right now I’ve done four times before (in different programming languages). I know the game inside and out, and I understand everything about it, so I haven’t made a design doc for it.

However, my case is the exception, proved by months of games I’ve started and left incomplete because I realized any of the following: the game sucked, it had no plot, I didn’t know what else to do with it, it wasn’t any fun, my concept was all screwed up, [fill in any game complaint here]. My suggestion: do some type of planning ahead of time, even if you just draw a map and an outline. My last game had a 20-page design doc and three maps, which did fine.

Regarding game documents, look on the Internet at sites, particularly this one, to find excellent articles dedicated to that. At the very least, read over them and understand the logic behind design documents.

"Why don’t we do a game like Quake?"

"Yeah, except it will be like Sim City. You’re mayor of this town and you monitor revenues, organize the growth of the city and then, when they don’t pay their taxes, it goes to first-person mode and you hunt them down…"

A brainstorming conversation like this happens between many groups of designers. Brainstorming is good.

The important part isn’t what ideas come up. The important part is what happens after you get the ideas. Will it really please the player to switch from first-person to third-person to god-view to second-person throughout the game? It might, but as mentioned earlier, you need to be honest and realistic about what you want the player to experience and if that experience is good.

For instance, a shooter (an action game primarily consisting of destroying enemies by shooting at them) is usually about heightening the player’s adrenaline. A strategy game is usually about the player using his/her mind. A strategic shooter? Maybe, but think about what you want the player to experience.

Don’t be afraid to let go of parts of the game that could cloud the gameplay and disrupt the player’s fun. The player’s enjoyment should be predominant over everything: letting go of a section and having a good, focused game is better than keeping it and having a sorry, unfocused game.

Good ideas, like wine, become great with time. Assuming deadline isn’t an issue, sitting on a game concept for a short time may be the best move. It has been scientifically argued that even after you stop focusing on something, your brain continues to work on it. The brain naturally marinates… if you let it.

As a personal example, I worked on a game a short while back that was pretty conceptually sound… except for the control. The hideous control.

People would playtest my game and have the hardest time controlling the character. I studied games along the same lines as mine for ideas and even took suggestions from the testers, but I couldn’t get it right. I made version two a couple months after, but control was still an issue.

Then, a year later, I was doing something, perhaps watching TV, when I suddenly realized what the control scheme should have been. It was so simple, yet I couldn’t see it earlier.

I have the luxury of time since game development isn’t my main source of income. If you have the time, use it. Sure, write down your ideas and draw your characters. But, ask yourself if you can make a quality game in one or two "burn the midnight oil" sessions.

Nintendo’s Super Mario 64, which was hailed by many game journalists as the best game of all time, used a staff of 200 (including Miyamoto) and cost millions to make. Most importantly, however, even with the huge resources, it took two years for Mario 64 to be complete. You can bet that some of that time was spent marinating… remember that it takes time to imagine a whole world, and that is exactly what you are doing when you design a game. Take your time, if you can.

Discuss this article in the forums

Date this article was posted to GameDev.net: 9/7/1999
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Game Design

© 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!