.Netterpillars: Artificial Intelligence and Sprites - The Game Proposal
(Page 7 of 9 )
When creating games, remember that the very first step is to write a clearly defined game proposal. This ensures that everyone involved in the game creation process can understand and agree with the game objectives. Even very sophisticated games must start with a simple proposal, so the programmers can build the project upon a previously established goal.
As mentioned in the introduction to this chapter, you’ll learn how to create a fast-action arcade game called .Netterpillars. Here are some details about the game:
- The game objective is to control a caterpillar-like character around the game field, trying not to collide with other caterpillars or any obstacles. If you collide, you are dead.
- The game field must be filled with mushrooms, and every time a netter-pillar eats a mushroom, it gets bigger.
- The game is over when all the players die (computer or human ones), or when the last mushroom is eaten.
- There must be a configuration screen where the player can choose the field size, how many mushrooms there’ll be in the game, and the number of computer-controlled opponents (from 0 to 3).
- The game must allow the smooth inclusion of multiplayer routines in future versions, so all the project and coding must be done with this goal in mind.
The basic idea in creating different configurations for a game is to add endurance to the game. That means that the game will interest the player for a longer time. It’s a common approach to add many different ways of playing in order to keep the player’s attention. A good example of this approach is Microsoft’s Age of Empires: Players can start a new game and go on building from the ground up, or players can choose a quest, where a previously created status quo is presented and they must solve some specific problems to win the game.
In this sample game, the player can choose, for example, a small and mush-room-crowded game field, and try to eat them all without getting trapped by his or her own tail; or choose a big field with fewer mushrooms and more opponents, in order to try to be the longest one, eating as many mushrooms as possible while trying to kill the enemies, trapping them with his or her tail. Many intermediary combinations would be possible, making the game more interesting to play.
With the basic game plan set, it’s time to start thinking about the technical details: creating a project for the game.
The Game Project Once all the team members share the project vision, it’s time to create your project. This can be as simple as a feature list and a scratch class diagram on paper. And even if you are working solo, as you will see, organizing and planning work before actually doing it is highly beneficial!
Your game project will include a simple class diagram, showing the class, properties and methods, a main program workflow definition, and the drafts for each game screen (as discussed in the next sections).
Defining the Game Classes and the Game Engine The game characters are the first natural candidates for game objects, based on your library’s Sprite class. So you can take the nouns on the list of topics from the game proposal and create a first draft of your class diagram, as shown in Figure 2-6.
Figure 2-6. The class diagram-first draft
This looks fine for a first draft. You see here an extra class, not mentioned in the game proposal: the Branch class. You include it just for fun, in order to improve the look of the game with branches at the screen limits.
Following what you learned in the previous chapter, there must be a class for controlling the game field and physics. Since this class will have more features than the GameField class from Chapter 1, you’ll use a more appropriate name for it: GameEngine.
Before putting this class in your diagram, it must be clear what the game engine should and shouldn’t do. It follows that the game engine is solely responsible for creating and maintaining the entire environment where the game characters will act. Usually, the game engine works according to the physical laws (gravity, action-reaction, etc.) in the real world, with more or less realism depending on the game goals.
The game engine doesn’t include the AI control. Instead, it just puts constraints over the game’s characters, regardless of whether they are computer or human controlled. Hence you’ll need another class to control the AI of your computer-controlled netterpillars. Since this class must have a high integration with the game engine (to collect information that will allow it to make decisions— for example choosing the direction to go), you’ll create this class as a child of the GameEngine class.
Because the sprite must have access to the game field background in order to erase itself, you’ll also include the Sprite class as a derived class from the game engine in the class diagram.
The final class diagram (without the attributes and methods) is shown in Figure 2-7. Notice that it’s not the right diagram, or the only approach. It’s just an idea, and if you don’t agree with it—great! You understand your subject so well that you already have your own opinion about it.
Figure 2-7. The class diagram-second draft
As for the properties (attributes) and methods, you can use what you learned before as a starting point, and build on it.
After more brainstorming, you select a set of attributes and methods for each class, as shown in Figure 2-8. Don’t expect any surprises with the classes that deal with the game objects, and the other ones, such as the AI class, are created based on your previous experience of similar projects.
Figure 2-8. The final class diagram
You don’t need to have a totally finished diagram by now, just a guide for your coding. You can return to this diagram later, at the game-coding phase, and adjust it if necessary, when new ideas and problems arise. Even the most detailed projects aren’t steady; modifications always occur after the coding starts. There is a quote from a famous general that fits perfectly in this situation: “No battle is won according to the battle plans, but no battle was ever won without a plan.”
In the next sections we’ll discuss each of the classes shown in the diagram from Figure 2-8, including brief explanations of their properties and methods.
 This chapter is from Beginning .NET Game Programming in C# by Ellen Hatton et al. (Apress, 2004, ISBN: 1590593197). Check it out at your favorite bookstore today. Buy this book now.
|
Next: The Sprite Class >>
More ASP.NET Articles
More By Apress Publishing
