Chadius: Your First Idea

Your First Game Idea
By Chad Serrant
4/21/05

So, you wanna make a game, huh? No problem. First of all, you need some skill in a programming language. C/C++ is my fav, but Java (relatively slow) and BASIC (not as powerful) are OK.

I assume you have some programming skill, and you are thinking of an idea to test your game design skills. Well, here's what I have tried to do while thinking up games. These designs are especially important for first-time designers.

Rule #1: Keep It Simple, Stupid!

I tripped up on this rule too many times. The most important issue to making up your first game is to keep it simple. The fewer elements that are required, the less overhead to bog you down.

Overhead is a killer, and has been the biggest reason for me not completing a game. When you decide to add a cool idea, you also add the exact mechanics for it. You also add the extra code (and debugging) to your engine. You also add balancing issues to the system. If you add too many features, it's going to overwhelm you.

As a first time game designer, there are some "looks good on paper" ideas that I'll snipe out of the way.

1) No 3D. Unless you're an OpenGL or Direct X 3D god and you've implemented 3D grapics engines. Even if you have, the extra dimension is really gonna screw with your game balancing. For most genres, 2D will suffice (hint: FPS are NOT a good genre to begin game design with.)

2) No heavy stories. Thinking up an engaging story might seem like a good idea, until you have to write it. By the time you've thought up an engaging storyline, you'll be too spent to actually make a game. Write a page-long story about the game and shove it into the back of the manual.

Rule #2: Describe the essence of your game in 10-15 words.

You need to be able to describe the vision of your game quickly. Like an objective on a resume, this statement tells you what your game is REALLY about.

I find that 10-15 words is the optimal range. Outside of this range either means that you don't have enough details to make a game (and you have a bad tech demo at best,) or you think extraneous details will save your game (hint: no one plays Tetris because of its pretty graphics or cutscenes.)

As an example, take my more recent game, TASM:

"TASM tests your reflexes and placement while poking fun at goons throughout gaming."

Reading the focus statement, you get three basic points about TASM. 1) It should test your reflexes. 2) It should test placement. 3) It should make fun of goons. Every decision I make should fall into one of those three categories.

Rule #3: To clone, or not to clone?

Every game is a clone, in some sense. Every single one is a combination of ideas from others. Your first game probably borrows most ideas from one, however. There's no shame in playing a really good game and saying, "gee, wish I could do that."

Cloning is not a bad idea for a first one. Back when shareware was all the rage, you could count at least a dozen tetris clones (or variants, or "improvements") on any given web site or BBS board.

There are two advantages to cloning your favorite game. For starters, you know the focus of the game. You're trying to create a game that plays similar to the original. And secondly, you already know the rules of the game, so you don't get bogged down there.

There are also two disadvantages to this technique. For one thing, it sucks the fun out of making your own set of rules. If you have a good vision of the game, then your rules will follow the vision. The second problem is that your game will be forever known as "a clone of the real game." No matter how well-implemented it is, it will never escape the brand of "clone."

And there you have it, folks. Start with a simple idea (or clone a simple one.) Create a short description of the focus of your game. Every game design choice you make should stick to your focus. And make sure you keep the overhead to a minimum!