We are going to do an Activision's River Raid (an old Atari console game) clone, but in this chapter we'll create only half of the game features. Since not everyone will remember the original River Raid game features (or will have ever played it), let's introduce the points we'll want to cover in our first version of the game.
In River Pla.Net the player will control a plane that is flying over a top-to-bottom scrolling river. Even when the player isn't moving the plane, the ground beneath it will be moving. As far as we know, the river goes on forever, so the main goal of the game is to live for as long as possible.
Here are some more details about the game:
■ The plane will be controlled by keyboard arrows.
■ There will be some obstacles along the river: ships, planes, and bridges. The ships and planes won't move in the first version of the game.
■ The plane must always bei flying over water; if it flies over land or over an obstacle (bridges, planes, or ships), it will be destroyed.
■ To make the level design easier, the game map will be a text file, in which each character will represent a different tile when the game field is created.
■ There'll be some gas barrels on the river, which will be collected by the player's plane when it flies over them. In the first version of the game, we won't create a fuel counter.
■ After being destroyed, the player's plane will be invincible for a few seconds.
s The game must have background music and different sound effects for each player action: upon being destroyed, when in invincible mode, and while filling the gas tank.
When a team of developers creates a "real" game, the game proposal is normally followed by some drafts showing details about the game (like screen layout and some artwork samples), and must be refined until everyone in the team has a clear understanding of what the game will be. The game proposal goal is to answer the question: What are we doing?
Once everyone agrees about the game proposal, its time to answer the next question we need to ask: How will we do it? The game project presents the technical details to answer this question, but both documents aren't static; they can (in fact, they must) be revised every time a new point of view arises and is agreed upon by the game development team. Care must be taken not to include every suggestion, or the planning stage will simply never end.
The last two important questions in a "real" game development are mainly targeted to commercial games (How long will it take to finish the project? Howmuch will it cost?), and won't be discussed here.
Was this article helpful?