Case study 2: Block Game in Font

Generate ANSI/AIM Code 128 in Font Case study 2: Block Game

Our first complete game prototype of the book is the imaginatively titled BlockGame, which you ll find in the chapter s source files. Run the SWF, and you ll see that it s a familiar paddle-and-brick game in the style of Breakout, as shown in Figure 4-53. Use the mouse to move the paddle and break the bricks. When 30 bricks have been hit, a Game Over message is displayed.

Figure 4-53. A classic brick-and-paddle game This is a bare-bones skeleton of a game, which I ve kept as simple as possible so that you can clearly see how all the pieces fit together. It s important for two reasons: It employs the circle-versus-square collision system that we looked in this chapter, which is a core game-design technique. It shows that it s just as effective when both the circle and square are in motion. It s structured like a complete game. You can use this structure to build games of great complexity and flexibility once you understand it. Let s pull this example apart and see how all the pieces fit together.

MVC saves the day again!

The game is built around an all-encompassing MVC structure. You understand how the MVC concept works with individual game objects, like spaceships. What you need to do now is expand that concept so that it envelops an entire game. (If you need a refresher on how MVC works, be sure the review the relevant sections in 1.)

The basic concept isn t hard to grasp, but some of the details aren t obvious right away. Here are the main components: Game model: A class that stores all the data of the game. This includes numerical data, such as the score. That s easy to understand, but what s a little trickier to grasp is that it also has all the visual things you can see in the game. This includes the game objects (like the player, enemies, and platforms) and the sprites, which contain the entire game screen. Everything that exists in the game must be contained in the game model. It s like a big, centralized storehouse where all the other classes know they can look if they need something. This will be a bit confusing at first, but we ll look at how this works practically in the pages ahead. Game view: A class that uses the game model data to display the game. It s responsible for adding and removing game elements to the stage. This includes game levels, menus, and score displays. It doesn t handle any game logic; however, it includes logic for the user interface, such as what to do when a player clicks a button. And it also includes any logic it needs to display game data, like the score or to switch levels. Game controller. All the game logic: initialization, level setup, collision detection, and scoring. It also creates all the objects used in the game and adds them to the game model. This is the most complex class. Application class: This is the game s common point of entry. Use the application class to compose the MVC system and add the game view to the stage. The application class has privileged access to the stage object, so we need to feed it a reference to the stage to the view and controller classes. Figure 4-54 shows how this all fits together. Take a look at the BlockGame folder, and you ll find four files, each of which corresponds with the preceding main components: BlockGame.as (the application class) GameModel.as GameView.as GameController.as We ll take a look at each of these in turn and see how they work together to build the game.