Game Development Reference
In-Depth Information
In this chapter, we are going to take a unique approach to creating the final game code. We are
going to start with the
GameDemo.as
file from Chapter 6 and add small pieces of code a little at a
time that will build on one another. We call this building a game through
. There will be
six iterations before we start the final section on completing the game. The result of each iteration
will be a class file that we can compile and view to see the latest version of the game in progress.
Before we get to the iterations, we will start with some theory on moving game characters on a
2D overhead tile-based grid.
iteration
Tile-based movement theory
There are many ways to move game characters on the screen. As you saw in Chapter 6, we are
creating a game that uses 32
32-pixel tiles to make up the game screen layout and the
characters that will go on this screen.
Tile jumping
Tile jumping
refers to a method employed by some early games' attempts to create tile-based
maze/chase games. All of the characters in the game would jump from tile to tile on the grid
instead of moving smoothly between the tiles. They didn't actually jump, of course, but their
movement was limited to the center of each tile. So, each time the user pressed an arrow key, the
on-screen character would simply move directly to the next tile (32 pixels at a time) in the
direction specified. There was no fluid movement between the two screen positions, and it
appeared to the player as if the game characters simply jumped to the next tile. There was no
ability to move on the pixels in between the center positions on the tiles. Unless the animation is
particularly well done (and even so), this type of movement is jarring to look at and is not
particularly fun to control. The opposite of this type of tile-base maze movement would be in the
classic Pac-Man game where the player seems to be able to fluidly move to any pixel on the
screen. In any case, games that employed the tile-to-tile jumping scheme were actually solving
two classic game programming problems:
System resource management
: The capabilities of the Flash Player (and early 8-bit
systems) and the systems running it were limited enough to necessitate creating mostly
simulated arcade games rather than real fast-action games.
Grid-based movement and logic
: Some grid-based movement is difficult to manage
(especially turning corners) but can be made easier if the game characters make
movement and logic decisions at the center of a tile.
For our No Tanks! game, we will employ a much smoother tile-to-tile movement style, much like
the classic Pac-Man game. Even though the latest Flash Player and AS3 are pretty fast at
rendering the screen and executing game logic, we will employ some of our own optimizations to
make sure the game runs well. Also, the system we will use, smooth tile-to-tile movement, will
look good to the user, play well, and allow us to use math and logic shortcuts associated with tile-
to-tile grid-based movement.
Smooth tile-to-tile movement
Smooth tile-to-tile movement solves the ugly visual problems usually associated with tile jumping
games but retains the programming convenience of using the center of a tile for grid-based
