.Netterpillars: Artificial Intelligence and Sprites - The Sprite Class
(Page 8 of 9 )
You’ll use this class, defined in the “Sprites and Performance Boosting Tricks” section, as the base class for all other game objects. Remember that all the members (properties and methods) of this class become members of the derived classes, too.
The Netterpillar Class
The Netterpillar class will control the drawing of the netterpillar characters on screen, both for human-controlled and computer-controlled ones. It’ll have some methods for making the netterpillar bigger (when it eats a mushroom) and to store the bitmaps and current status for the character. Table 2-7 lists the initial suggestion for the members of this class, along with a short description.
| TYPE | NAME | DESCRIPTION |
|---|
| Method | constructor | You’ll have an overloaded constructor, which will load with the multiple images of a netterpillar: the head (looking at different directions) and the body parts. |
| Method | Draw | The overloaded function that draws all the parts of the netterpillar. |
| Method | Move | Instead of Erase, Move is more appropriate here: Move the head and every body part according to the current direction, erasing the field only after the last body part. |
| Method | EatAndMove | If the netterpillar eats a mushroom, the last part doesn’t get erased, because the body length is increased. |
| Properties | NetterHeadN, NetterHeadS, NetterHeadE, NetterHeadW | You’ll need one image for the head for each direction that the netterpillar is looking at/moving to. |
| Property | NetterBody() | You’ll need an array to store all the body parts |
| Property | NetterBodyLength | The current size of the netterpillar, which will be used to keep track of the body parts array. |
| Property | IsComputer | You have to have a way of knowing which players are human controlled and which are computer controlled; this will help with the future evolution of a multiplayer |
| | game. |
| Property | IsDead | Instead of actually destroying the netterpillar, you’ll just set a flag saying that it’s dead, thus avoiding internal tests to see whether a |
| | given netterpillar object exists. |
Table 2-7. The Members of the Netterpillar Class
The Mushroom Class
Because a mushroom does nothing except for standing and waiting to be eaten, all you need is an overloaded constructor that will load the appropriate image file, so you won’t need to pass the filename when creating a new mushroom. The Mushroom class will then have all the members from the Sprite class, plus the overloaded constructor that loads the mushroom image file in a given position.
The Branch Class
A branch will be composed of three different images: one for each branch edge, and a middle one that can be repeated many times to create bigger branches. Since the Sprite base class only stores a single image, you’ll have to create three properties to store these images, and create new overloaded functions for the constructor and Draw methods. Since the branch doesn’t move, you won’t need to create an Erase method. The list of members for the branch class is shown in Table 2-8.
Table 2-8. The Members of the Branch Class
TYPE | NAME | DESCRIPTION |
Method | constructor | This overloaded version of the constructor method will receive the size and orientation (north-south or east-west) of the branch. |
Method | Draw | This method draws the branch according to its size, position, and orientation. |
Property | Size | The size of the branch. |
Properties | BranchTop, BranchBottom | The images of the branch extremities. |
Property | BranchMiddle | The image for the middle part of the branch that will be repeated over and over by the Draw method, until the branch reaches the desired size. |
The AINetterpillar Class
To define a basic set of members for the class that will handle the netterpillar artificial intelligence requires a little more thinking. The first question that arises is, How smart is your computer-controlled character meant to be? Even in this simple game, you can think about some very difficult AI routines. For example, will a computer-controlled netterpillar do any of the following?
- Chase the player (or one another) and try to surround the player with its tail in order to kill him or her
- Analyze its tail positions on every move in order to avoid getting trapped by its own tail
- Analyze the whole game field to look for places where there are more mushrooms or fewer netterpillars
Since all you need here is a simple example, your netterpillar won’t be that smart, at least for the first version of the game. All you want to do is:
- Avoid getting killed by hitting a wall, while eating everything that is near to the head
- Add some random behavior to make the movement of the computer-con-trolled netterpillars more unpredictable to the player
Table 2-9 shows the first suggested methods and properties you’ll create to address these goals.
| TYPE | NAME | DESCRIPTION |
|---|
| Method | ChooseNetterpillarDirection | This method will analyze the netterpillar position and direction and choose the best direction to move to, based on the immediate surroundings of the netterpillar’s head. |
| Method Property | RandomDirection RandomPercent | This method will add the random behavior, based on the RandomPercent property, and take care not to lead the netterpillar straight to collision and death. This property will control how random the behavior of your netterpillar will be. Remember that a new direction will be chosen many times each second, so any number greater than 10 may make the netterpillar’s movements too random to seem intelligent. |
Table 2-9. The Members of the AINetterpillar Class
Of course, these members could also be part of your Netterpillar class, but for this example you’ll create a new class for them in order to have the artificial intelligence code isolated from the drawing code, making it easier to maintain and improve.
The last game class, which deals with the game engine, is discussed next.
The GameEngine Class
For the GameEngine class, you can use some ideas from the .Nettrix sample you saw in the last chapter:
- It’s important to have a method to redraw the game field.
- You’ll also need a direct reference to the game field (such as a handle) to be used in the drawing operations.
- Since you’ll have a dedicated class to control the game, you’ll need a property to control whether the game is running or paused, just like the variable on the form in the previous chapter. A property to control whether the game is over is a good idea, too.
- According to the idea of having an array to control collisions (which seems to be the right choice in this case, since your game will be a tile-based one), you’ll need a property to store the game field array.
- Since the game engine will need to do all the physics of the game, it’ll need to have access to all game objects. The best way to allow this is to let the GameEngine class create and handle them, so you’ll need properties to store the branch objects, the netterpillar objects and the netterpillars quantity, and the mushroom objects and the mushroom quantity.
- You’ll have a configuration screen to set some game properties, and you’ll need corresponding properties to store the configurable parameters, width, and height properties, because your game field can have different sizes; a property to hold the desired mushroom quantity; and another one to hold how many netterpillars will be present.
- Because you’ll control only one netterpillar, you’ll need some property to define, for each netterpillar, if it’s computer controlled or human controlled. Having such a property will help in another game objective: to code a game ready to be turned into a multiplayer version in the future. In this case, in the next version you can add information to tell whether the netterpillar is a local gamer, a remote gamer, or a computer.
Since the sprites will need to erase themselves, you’ll need a property to store the initial background image of the game field.
NOTE That’s a lot of things to be thinking about, and we haven’t covered the methods yet. But don’t expect to remember everything in the first brainstorm. It’s usual to create a first draft, and then refine it. When you think about the game logic and create some pseudo-code for the most important parts of the game, new proper ties and methods arise. When refining the new set, other new details arise. This process is repeated over and over until you have a stable set of classes, properties, and methods. In (very) few words, that’s the basis of what is suggested in most of the books covering object-oriented development currently: Start small and increase complexity as you iterate over the project.
You can list a basic set of methods based on the features coded in the previous chapter—for example, a method to initialize the game field, a method to redraw it, a method to render (which will basically do the physics, update the object states, and then redraw the game field), and some methods to move the game objects and to change their states (such as setting a netterpillar as dead, and asking the Netterpillar object to remove its drawing from the screen).
Based on the previously discussed points, your class will have the interface shown in Table 2-10.
| TYPE | NAME | DESCRIPTION |
|---|
| Method | constructor | This method creates the game field and initializes all properties. |
| Method | MoveNetterpillars | A method for moving the netterpillars, according to the current direction of each one. Also checks for collisions. |
| Method | KillNetterpillar | This method removes the netterpillar from the game field, if it collides with some wall or other netterpillar. |
| Method | Redraw | This method redraws the game field. |
| Method | Render | A method for calling all other methods; in other words, it moves everyone, kills anyone who must be killed, checks for game over, and calls the Redraw method. |
| Property | ScreenWinHandle | The handle of the game field window, used for drawing the game objects. |
| Properties | Width, Height | The game field dimensions, which will be configured by the user. |
| Properties | NetterPillars(), NetterpillarNumber | The netterpillar objects array and the total number of netterpillars. |
| Property | Branch() | The branch objects array. |
| Properties | ObjMushrooms(), MushroomNumber | The mushroom objects array and its total number. |
| Property | GameOver | If true, the game is over. |
| Property | Paused | If true, the Render procedure won’t move any netterpillar. |
| Property | ArrGameField() | The array with the game objects, used for implementing the collision detection. |
| Property | BackGroundImage | The initial background image, which will be used by the sprites to erase themselves (drawing a portion of the background image over them). |
Table 2-10. The Members of the GameEngine Class
Because your class diagram now is stable, it’s time to define how the main program will call the classes. In the next section, we discuss the structure of the game’s main program.
 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 Main Program Structure >>
More ASP.NET Articles
More By Apress Publishing
