I'd always loved the idea of the player entering a vast, underground robot factory (those robots emerging from the traps have to be made somewhere, right?), and it seemed logical that such a factory would feature conveyors (and other dangerous machinery - but more of that another time).
However, although I was keen to try out some ideas, it was tinged with the realization that I'd have to revisit the player control routines and bash them into better shape before I could implement the conveyor logic.
One of the key issues was that the player movement code used a system that counted how many pixels the player moved, in order to get the Monitor craft to stop after it had moved one tile. Thankfully, Game Maker allows you to check this with the place_snapped command (as I discovered when implementing basic enemy movement a couple of weeks ago), so my player movement code needed a revamp.
* * *
Once the basic control routines had been tweaked (which, surprisingly, worked first time after I'd fired up the code), next came the task of detecting conveyor tiles and moving the player accordingly. This is the difficult part for me - breaking the problem down through analysis and working out the best solution; sometimes there are multiple solutions, so it's always a big dilemma.
I wanted to use the typical platform game convention that a) when at rest, the player will move at the speed of the conveyor, b) the player will move slower than usual if they try to travel against the direction of the conveyor, and c) the player will move faster than normal if they move with the conveyor.
Essentially, the basic logic works as follows:
- Check that the player is snapped to the grid (i.e. not already moving).
- Check for a conveyor tile beneath Monitor.
- Check to see if the player is trying to move; if so, check direction and adjust speed.
- Otherwise, set the player's speed to that of the conveyor.
Rather than duplicate masses of code, I came up with a nifty script-based system that allows me to feed a bunch of speed parameters to a central control routine, and in practice, it worked beautifully (I actually surprised myself with how simple it was and how well it worked!).
Flushed with that success, I redesigned part of my test level to include some conveyors, and it was really neat to see Monitor riding the conveyor belts around the level!
* * *
Later on, I showed my progress to the Mrs. and (typically!) a bug chose that precise moment to appear: essentially, because the tilesize is a power of two, the player's speed must also be similarly proportioned or the movement routine messes up when the player moves too far and 'skips over' a tile boundary.
On the plus side, I did hit upon the idea of a variation to the conveyor belts in the form of a Portal 2-style Excursion Funnel (which restricts all player movement), or possibly an electromagnetic conveyor that doesn't allow the player to sidestep off the conveyor at any point. And as I was typing up this blog entry, I also hit on the idea of special switches that reverse a conveyor's direction. Hmmm!
