Before we get started, it’s important to note that there are plugins that can give us the same effect. If your game is going to center around ice puzzles then you may want to look into those plugins and see if their setup will be better for you in the long run. But if you don’t want to use extra plugins or only have a few slippery spots, eventing it may be the way to go. Choose whichever option will fit your game best.

With that out of the way, let’s get eventing!

Slippery Ice

First thing we need is a map with some ice. I’ll be using the blue ice for slippery tiles, and for this example let’s just fill most of the room with it for maximum sliding.

Once our ice tiles are down, we need to mark it somehow so that our game will know when the player should slide and when they should be walking and in control. For this event, we can use region 1 to mark all of our ice tiles.

With our map ready we can move on to our sliding event. Our sliding event’s first page will check if our player steps on to any ice tiles, so it needs its Trigger set to ‘parallel’. A conditional branch checks if our player is on a tile marked with region 1 with the script call $gamePlayer.regionId() == 1 and a short wait keeps our event from running 60 times a second.

If our player is standing on a region 1 tile then we need to turn On self-switch A to activate the event’s second page, where the actual sliding will happen. Let’s also turn On another switch before we jump to the second page that has ‘autorun’ as its Trigger.

Why did we want to turn on a random switch? Because we want to run a move route once to turn Off our player’s walking animation so that it will really look like they’re sliding across the ice. If we turn the walking animation Off on the first page, then its ‘parallel’ trigger will actually let our player turn in place before they start sliding. That’s not exactly something we want to happen when stepping onto slippery ice so we need to turn the walking animation Off at the start of our event’s second page.

But we don’t need to turn it off every single time the second page runs, so by using a conditional branch that checks if our random switch is On at the start of the page we can turn both our player’s walking animation and the random switch Off to make it run only once when we start sliding.

The actual sliding part of our event is pretty straightforward, we just need to set up a move route to take 1 step forward (with ‘skip if cannot move’ checked so that when we do slide into a wall we don’t accidentally softlock the game). Along with the move route, we also should set a variable to the player’s direction so that we can check what’s in front of the player later.

Once our player has moved, we need to check to see if they’ve slid off the ice or into an obstacle that they can’t pass through. Checking if they’re slid off the ice is easy enough, we just need to do the opposite of what the first page did: see if our player is not standing on region 1. We can do that in a conditional branch with $gamePlayer.regionId() != 1 , and if it’s true then we can turn our player’s walking animation On and turn self-switch A Off. That way the first page will start running again and our player can walk around the map.

Checking if our player slid into an obstacle and can’t move forward is a bit more complicated, but still doable if we turn to another script call: $gamePlayer.canPass(x, y, D) , where we need our x and y to be our player’s x and y and D to be the direction our player is facing. By tweaking this script call to start with an ! we can have a conditional branch run if the player can’t pass through the tile in front of them. Our variable we set earlier comes into play here, making it easy to check the tile in front without needing multiple conditional branches, so the script call we want to use is: !$gamePlayer.canPass($gamePlayer.x, $gamePlayer.y, $gameVariables.value(1))

If our player can’t pass, then we need to let them change direction. We’ll do that by including nested conditional branches to check which button our player is pressing and having a move route turn our player to face that direction. That way our player can start sliding again, at least until they hit another wall or slide off the ice.

All that’s left is to set up the rest of the button direction conditional branches and our sliding event is complete! We can playtest to make sure that we slide smoothly across the ice and change direction only when we’ve hit an obstacle. While playtesting it’s easier to know when the autorun page is running by having a visible image, so I set it to have one and just need to remember to remove it once I’m happy with how the event is running.

Sliding wildly on slippery floors is fun, but could we tweak this event to control the direction our player moves in?

Sliding in Only One Direction (aka Conveyor Belts)

For our conveyor belts to work we’ll need to use marked tiles so that our player will know which direction they’ll be moved in, as well as a way to know which tile is being stepped on. MZ has some tiles marked with arrows that are perfect for this, so let’s plan to use them. For this tutorial let’s use terrain tags to track which tile is stepped on, but regions could be used instead if you wanted. Since we’ll be using terrain tags, we’ll need to hop into the database and set each arrow tile to a different terrain tag number.

Before we get to our event, we’ll need a map. One major difference between our conveyor belts and ice is that our player won't be able to change direction on the conveyor belts so we’ll want to make sure that none of the belts slam our player into a wall.

Let’s use region 1 again to mark our conveyor belts:

And then we can work on our event. The first page will be exactly the same as the ice one.

Our second page also contains similar parts to our ice event, with our player’s walking animation turned Off at the start, our player taking 1 step forward, and a conditional branch checking if they’ve slid off of region 1. But instead of setting a variable to check our player’s direction, we need to turn them to face the same way as the tile’s arrow is pointing. Since each arrow has its own terrain tag number, we can do that with a conditional branch with the script call $gamePlayer.terrainTag() == N to check the tag and then use a move route to turn our player the right way.

Once we’ve set up the conditional branches for the other terrain tags, our event is complete. Playtesting should show our player moving around on the conveyor belts properly, but if we seem to be moving in the wrong direction we’ll need to double-check that our player is turned to match the tile’s direction.

And now we can have slippery ice and conveyor belts in our games! How would you use events like these in your games?

‍