Day 2: A different way to handle collisions in GameMaker

Another pin is on the board. Finding a steady rhythm has been a challenge this past week as I work to get everything ready for the start of the school year, but I managed to get through the next couple of tutorials for the maze game project.

The progress today was foundational. I now have a proper room for the maze and a camera that smoothly follows the player object. These steps were straightforward, but they are the essential building blocks for creating a world that feels good to move around in.

The most interesting part of today's session, however, was a small but significant coding choice in Mr. Ridgway's tutorial. To handle walls, he uses a function called place_meeting() directly within the Step event, rather than using GameMaker's dedicated Collision Event. He didn't explain the "why" behind this choice, but it immediately made me curious.

As a teacher, I know that understanding the "why" is where the real learning happens, so I did a little digging. It turns out this is a common and powerful technique. Using place_meeting() in the Step event gives the programmer more precise control over the order of events. You can check for a potential collision before you move, and then decide what to do. For example, you can check if place_meeting(x + x_movement, y + y_movement, obj_wall) is false, and only then update the player's position. This can prevent a lot of tricky "stuck in the wall" bugs that can sometimes happen with a standard collision event, which typically resolves the collision after the movement has already happened.

It's a fantastic lesson in preventative coding versus reactive coding. There's nothing wrong with the standard Collision Event, but this method gives the developer more direct authority over the game's logic. It's another invaluable piece of knowledge to file away—a new tool in the toolbox that I'm sure will be useful when I start building the more complex, interactive world of Of Mice and Tales.