Feature Reference - The Game Maker's Companion: Game Development - page 351

Start with: Reference/Framework/explorer3.gmk

Creating Grid Movement

1. The first step is to check the requirements for grid movement. Our example contains

block and explorer sprites that are 32x32 pixels, so each square in the grid will be
32x32. In a room of 640x480 pixels, this means that the room consists of 20x15 squares.
It also means that the explorer will have to move 32 pixels horizontally or vertically to
go to the next square. The dimensions are important to know when setting or adjusting
the speed of the instances, because we need to make sure objects are always set to
move at a speed that allows them to line up exactly with the next square!

For obj_explorer , open the Step , Step event and double-click on the Execute Code
event. The good thing about this object is that all the logic relating to movement is
contained in a single script—we don't have to check four arrow key events to see if we
can allow the player to change direction! Insert the following line of code at line 2:
if ( !place_snapped(32,32) ) exit;

2.

This single line checks if the instance is not snapped to a horizontal and vertical
position in a grid using squares of 32x32 (notice the exclamation mark just before the
function—it means the same as checking the NOT option for an action). So, if it's not
snapped into position, it immediately exits the script. The result of this is that the
player can't adjust the direction until the condition becomes true. The speed of the
explorer is 4 when it moves, which means it will end up on the next square in 8 steps
(because 8x4=32). A speed of 3 wouldn't work correctly because 32 doesn't divide into
steps of exactly 3!

Result: Reference/Result/grid_movement1.gmk

Now let's add an enemy to the room that starts to follow the explorer around. It lives by the
same rules as our explorer: its sprite should be 32x32, it can only change direction at the grid
positions, and it should keep on moving until it hits the next square. Just like the explorer, it
should not be able to walk through walls.
But there are a few more problems when you start to introduce several enemies with the
same behavior. For example, we don't want two enemies to occupy the same grid spot, otherwise
the player can't see how many enemies there are. In other words, one grid spot should contain
exactly one instance. So, we need to make sure enemies won't go where other objects are already
standing, and we should also avoid two enemies walking toward the same grid square because
both “see” it as empty at the same time. We need to find a way to keep a position reserved when
one instance has decided to start moving there. Be prepared for a little bit of advanced scripting!
Obviously, our next example is just one out of many possible enemy behavior patterns, but it
should give you a good idea of what is involved in creating grid movement intelligence.