Coming Up with the Game Idea

Everything that has ever been created started out as an idea, and games are no different. Game ideas can come from just about any source you can think of. Perhaps you saw another game that you enjoyed, but thought it would be so much better if it did something differently. Maybe you had a dream that would make the perfect game. Perhaps you realized two unrelated games could be combined to create the ultimate game. Wherever your inspiration comes from, you'll need to tap into that before you can start making your game.

Unfortunately, as no one has yet invented a mind-reading book, you'll have to trust my ideas for this game. I chose the games in this book for a variety of reasons, mainly concerning the level of development difficulty. However, each is in a different genre to cover the wide variety of topics you'll encounter in your game development coding.

The first genre is the puzzle game. It's probably safe to assume you have seen or played puzzle games before. Tetris is a classic puzzle game that just about everyone has either heard of or lost tons of hours of sleep playing. Everyone it seems has also written a Tetris clone, so it likely wouldn't be the best choice for the puzzle game you will be writing. Also, Tetris is a 2D sprite game (although there have been 3D Tetris-type games), so you will probably want to skip it for that reason as well.

Instead, you should write something somewhat unique. The game will have a single character that is on a board. This board will be made up of a series of cubes in an undetermined pattern, with each cube having at least one other cube directly adjacent to it. A chess board would be an example of a board that meets these criteria. Each cube will be a particular color, and when the player steps on one of these cubes, it will change to the next predetermined color. The level will end when every cube in the level is on the correct color for that level.

Detailing the Proposal

Like you learned in the previous chapter, once the basic idea for the game is laid out, you should spend some time coming up with the game proposal, ensuring you answer as many questions as possible. For this game, here is a bulleted list of items to help detail the proposal:

• Puzzle game called Blockers

• Single-player only

• Fully 3D environment

• Score based on time to complete level

• Each level consists of a series of adjacent cubes, such as found on a chess board

• Each cube is always a single solid color

• Each level will end when every cube in the level is the same color, and that color is the predetermined "end" color for that level

• Each level will have a maximum time limit

• Each cube will have a "list" of colors assigned to ithis list will have a minimum of two colors, with a maximum of six

• Players move by "bouncing" on a cube, which will change the color of the cube to the next available in the list

• Beginning levels will have the minimum list of two colors per cube

• Difficulty will be raised by adding more colors per cube in more advanced levels

• If player can finish these levels, difficulty will be raised once more by allowing the color list to "wrap" back to the beginning

• Game is over if player cannot complete level within maximum time limit

Is this an exhaustive list of every feature of the game? Probably not, but it does answer the majority of questions that you need to answer before you can start planning the game. It's important to understand that the planning phase isn't designed to detail every feature of the game before you begin development, but more to get you thinking about the features your game will require. Jumping in and coding without considering the features you really want will lead to more difficult work later in trying to fix the things you missed or did incorrectly because of a rushed plan.

With a plan in place, you can now start designing the object model you will use for this game. Look at the basic program layout diagram shown in Figure 2.1.

Figure 2.1. A high-level object diagram for the game.

As you see here, the object diagram isn't overly complex. You have the mysterious game engine, which maintains information about the player, the current level, and the rendering device. The rendering device is used to display the fancy graphics for the game onto the monitor. The player will need some type of visual representation, and the rendering device will handle this as well.

Much of the game requires information about the current level. The current time is important because it will be used to determine both the high scores and when the game is over (when it runs out), so the current level must have access to it.

The actual levels themselves will be stored in the file system, in the media folder of the application. Because the current level will need to load one of the existing levels, it will of course need access to those as well. The only thing the level really needs to keep track of is the list of cubes that comprise the level. Each level will have at least two cubes, but can add many more to accommodate larger levels.

This game won't be easy to write, but as you can see, there aren't many objects that you will need to create to ensure that the goals of the game are met. The game has the potential to be quite fun as well, as long as the more difficult levels don't become so difficult that they end up frustrating the player. A game can do nothing worse than annoy the player. If the game isn't fun, no one will play it, and the game cannot be considered successful.