.Netterpillars: Artificial Intelligence and Sprites - The Main Program Structure
(Page 9 of 9 )
Now let’s think about how the game will work. You need to define a starting place from which the game engine object and the game window will be created, and from which the Render procedure of the game engine will be called repeatedly.
Because you’ll also need a configuration screen, it’s better to first have an introductory screen, in which players can choose whether they want to start the game or to change the game configuration.
Although it’s common in some OOD techniques to suggest the creation of new classes for the forms (sometimes called interface classes), it’ll be easier not to mix user interface with the game logic for now. Instead, you’ll use common window forms, and create a simple workflow diagram, as shown in Figure 2-9, in order to clarify how the game flow will be.
Figure 2-9. The game main workflow
We could give details of the Render procedure, including in the loop shown on the diagram in Figure 2-9 boxes for such processes as gathering user input, updating game objects, redrawing, etc. (and in a real project we strongly suggest that you do). However, the goal for this diagram is only to make it easier to understand the basic game flow across the many screens and the basic game loop, and it does this effectively.
In the next section, you’ll see how to create a draft of each game screen, thus finishing your game project.
Defining the Game Screens Although the windows implementation will be done in the code phase, it’s good practice to create at least a draft of the screens in the project phase, because when drawing the screen you’ll usually remember more details that can be added to the class diagram. If you can imagine how the previously discussed classes will work in each screen, then there’s a good chance you haven’t missed any important details.
Since C# allows you to create screens quickly, the best sketches are the ones done directly in a form editor like that found in Visual Studio .NET. Let’s call your first screens visual prototypes. The next images will show the visual prototypes for each game screen, starting with the introductory screen on Figure 2-10.
Figure 2-10. The Intro screen
The intro screen will only show an intro image (or splash screen) for the game, along with buttons to allow the player to end the game, start a new game, or change the game configuration. According to the workflow shown in the last section, after a game ends, players will be redirected to this screen.
Figure 2-11. The game configuration screen
Figure 2-11 shows the second draft: the game configuration screen.
On the configuration screen, you can set the number of netterpillars and mushrooms and the size of the game field. Since it’s not up to the user to decide the exact number of pixels in a game or the exact number of mushrooms on screen, you can use domain up-down controls to make the configuration more user friendly: Few/Just Right/Many selections for mushrooms and Small/ Medium/Big selections for the game field size.
As we said before, as the game project evolves, you’ll uncover new details that may require new properties and methods. Looking at the screen shown in Figure 2-11, you need only two enumerations for the GameEngine class, which will lead to simpler and cleaner code: MushroomSizes for the number of mushrooms, and GameFieldSizes for the possible field sizes. You’ll also include two new properties that will receive the values of these enumerations directly from the configuration screen—Mushrooms and Size.
In the code phase, you’ll see how to code properties in C#: You include a pair of procedures in the class that correspond to an object property, allowing you to do some processing—such as setting the Width and Height properties when the Size property is set, and setting the MushroomNumber property when the Mushrooms property is set.
The draft for the next game screen is shown in Figure 2-12.
Figure 2-12. The game field screen is just a form with an image control
You can set the Picture property of the image control in the game field window with any bitmap you want to use as background, since you write a generic code in the Sprite class to do the drawing and erasing. In this case, you set it to a simple sand pattern.
Refining the Game Project You’ve learned about making progressive refinements in the game project, until you reach the point to start the coding phase. But how do you know when to stop making refinements?
If, after you’ve drawn the class diagram and the workflow diagram and also created the visual prototypes for all game screens, you still don’t have a clear idea about how any part of the game will work, it’s important to write pseudocode for this part and check the workflow, the classes, and the screen drafts again until everything seems to fit. Only start the code phase after you have a clear idea about how things will work, but take care not to get stuck on the project, creating an excessive level of details (except, maybe, for big projects where the lack of detail can cost a lot).
Just remember: It’s much easier and faster to correct a class diagram or a screen prototype than to redo a lot of code because you forgot something important!
With these points in mind, let’s get into the next phase: the code.
 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.
|
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
