Game Development Reference
In-Depth Information
The center tile trick
Since we are going to take a different approach than the old Pac-Man style, rather than create a
maze level and then preset or hard-code allowable movement data into our maze, we are going
to set up some ground rules for movement and let the game engine respond dynamically to the
level design. We will do this by using a trick. The trick is to always evaluate movement logic when
a character has reached the center of a tile. This concept works best with square tiles and tiles
where the character sprites and the tiles are the same size. This might sound limiting, but this
trick turns out to solve many problems with maze-based movement.
For example, if you have ever played Pac-Man, you will notice that that main hero cannot turn in
any direction unless there is an open tile in that direction. This very important concept sets a
ground rule for the movement and logic for the game. I don't know how Tru Iwatani (the original
Midway developer of Pac-Man) coded his movement, but we know how to mimic how he did it.
The Pac-Man character cannot move into a space unless its entire body can move, but it doesn't
need or use pixel-perfect collision detection. It uses tile-based collision detection. The game logic
just needs to know what type of tile the next tile is and then it can evaluate if the character can
move into that tile or not. The game doesn't need to check for the next tile when the character is
not at the center of the current tile, because doing so would result in false positives and negatives
as the character moves into the open space between the tiles or if the character is on two or more
tiles at the same time.
Our game will go one step further and force our player character to stop at the center of each tile.
You will see as we start to code and test the game elements that the player character will move in
the direction indicated by pressing the arrows keys if the tile in the direction pressed is a
TILE_WALK
tile. The character will start to move and will continue to move on each subsequent
frame tick until it has reached the center of the next tile and then stop. This will not be as limiting
as it sounds, because if the user holds down a direction key (and there is an open space in the
direction the player wants to move), the player will continue into that open space without
stopping. This movement includes turning and going forward. Reversing direction is even
smoother, as the player can reverse direction at any time, even before the center of the next tile
is reached. This is slightly different than Pac-Man where the only time the player character
stopped was when it hit a wall or corner and could not move any further.
The one caveat to doing this type of movement logic is that the number of pixels a character can
move on each frame tick must be a number that divides evenly into the tile size. So, since we
have 32
32 tiles, our game characters should move 1, 2, 4, 8, 16, or 32 pixels per frame. If they
don't, they may never actually reach the center of a tile, and the logic will fail.
Adding the player (iteration 1)
We are now going to start by simply modifying the code to add the player to the screen in the
GameDemo.as
file, which is the first building block in our game. The player character will be a
TileByTileBlitSprite
instance. Let's start by adding some code to our variable definition section
with all of the variables necessary to handle a player and movement for the player.
We are going to create this as a separate file called
GameDemoIteration1.as
.
Here's the path for the Flash IDE:
/source/projects/notanks/flashIDE/com/efg/games/notanks/GameDemoIteration1.as
