Before we can jump into the puzzle, we need some sprites for our players to look at! In this example let’s keep things simple with a 3x3 puzzle made from some edits of MZ’s blank tile. By adding the numbers 1 through 8 to the tiles, we can easily tell what order our events are supposed to be in. We’ll also have the tiles in two colors, grey for unsolved and golden for solved so our player can be sure when they’ve succeeded.

Of course we could use an image split into pieces if we wanted a prettier puzzle, but numbers are easier to understand while we’re testing the events. If we were using an image we would need to keep in mind that our pieces shouldn’t be larger than our tile size (MZ’s default being 48x48 pixels) so that our events don’t accidentally overlap.

With our puzzle pieces ready to go, we can get started on building the puzzle!

Setting Up Our Map & Events

First thing we need is our puzzle’s map. Since we’re making a 3x3 puzzle, let’s mark that area out in a different floor tile so both we and our players will know where the pieces will be moving around.

With our map ready, next we need to mark our puzzle area with regions (the R tab when mapping). For simplicity’s sake we’ll mark each tile with a different region, so that the tile 1 event needs to be on the region 1 tile and the tile 3 event needs to be on the region 3 tile, and so on, to have the puzzle solved.

If you’re using regions for something else on your map and don’t want to use a bunch of them for the puzzle you could make them all the same region, just keep in mind that your method for checking if the puzzle is solved will need to be different than in this tutorial.

Last, but certainly not least, is adding our events. We’ll be using 11 events for this puzzle, 8 tiles that can be moved, 1 tile to fill up our puzzle’s empty space when it’s solved, 1 event that will check if the puzzle is solved and turn into the reward if it is done, and a final event that will shuffle our tiles. We could combine our shuffling event into one of our other events, but I find it easier to understand when the events are all separated.

We’ll focus on our events that check if the puzzle is solved and shuffle our tile events later, so let’s focus on our tile events first. Our tiles are all numbered 1 through 8 and it’s important that we name them properly so that we can easily find them later on. Each event has a similar set-up, with just the image different, so let’s look at Tile 1 to see how they’ll all look.

Tile 1 has two pages, the first page where the puzzle is unsolved and the second page activated by our ‘puzzle solved’ switch once it’s been completed. We want to make sure that both pages have the Direction Fix option checked and Priority set to ‘Below Characters’ so that our player can walk on top of the tiles to choose which one to move. All the first page needs to do is call a common event (which we’ll talk about in a bit) that holds all the movement possibilities for the tiles.

Tile 9 only appears once the puzzle has been solved and the switch has been turned on, so it only needs one page. Since the event isn’t active until the switch is on, the engine pretty much thinks this event doesn’t exist until the puzzle is solved so we don’t need to worry about it being in our way.

With our tiles ready to go, next we’ll be working on the actual movement of them.

Making the Events Move with a Common Event

At its most basic, our movement common event needs to offer our tile events a way to move in all four cardinal directions. But if we did that without adding in some checks, we’d have events fleeing the puzzle area and making it impossible for our players to finish. So before we can move an event, we need to make sure that moving in that direction will keep the tile in the puzzle area and that the intended spot doesn’t already have a tile there.

To check if the intended spot is still in the puzzle area, we need to see if the spot has a region (remember how we marked the map with regions? This is one of the reasons why). If the spot doesn’t have a region, that means that it’s outside our puzzle area and the tile event shouldn’t move that way.

We’ll be using some script calls to check the intended spot’s region and passability, which look complicated but are pretty straightforward once we understand what they do.

To check the location’s region, we’ll be using $gameMap.regionId(x, y) to get the region at the tile located at x, y. We can’t just put x and y there though, since the engine needs to know exactly where it’s meant to be checking. Luckily we don’t need to put in actual numbers since there is a built-in way to check our specific event: $gameMap.event(this.eventId()).x and  $gameMap.event(this.eventId()).y. Since we’re calling the common event from the tile event we want to move, the ‘this.eventId()’ part will be replaced with the correct number when the engine checks. So to get the region where our event currently is, we’d use $gameMap.regionId($gameMap.event(this.eventId()).x, $gameMap.event(this.eventId()).y)  .

However, there’s a big problem with that script call... it’s checking where our event currently is, not where we want to move it! To check the spot where we want the event to move to, we need to add or subtract from our event’s x or y to find the right spot. We can check the tile to the right of the event by adding 1 to the x value, or check the tile below the event by adding 1 to the y value, and the same with right or above the event by subtracting 1 from the x or y value, respectively.

Now that we know how to check the neighboring tiles, we just need to add one last thing to our script call to make it work in a conditional branch: what we’re comparing the region to. We could check if the intended spot’s region equals one of the puzzle areas regions with ==, but since we have nine different regions it could make for a long conditional branch. Instead, let’s check if the intended spot is in the puzzle area by seeing if it does not equal 0 (since 0 would mean there is no region on that tile) with != 0. That way, if the intended spot does have a region marked on it it will pass the conditional branch and move on to the next check.

So to check if the region on the tile below the event is not 0, our script call is: $gameMap.regionId($gameMap.event(this.eventId()).x, $gameMap.event(this.eventId()).y + 1) != 0

If the intended spot passes that check, next we need to check if the event can actually move onto that spot since if there’s already a tile event there we can’t move our tile to that spot. There are a few ways we could do this, but for this tutorial we’ll be checking passability of the intended spot with $gameMap.event(N).canPass(x, y, D) . The x and y we can replace with the same  $gameMap.event(this.eventId()).x and $gameMap.event(this.eventId()).y we used in the previous script call, leaving use with just the N and D to replace. N we can replace with this.eventId() since we’re still checking the same active event. D determines which direction we’re checking, so we need to make sure that the direction we’re checking matches the direction we want the event to move in. Each direction is tied to a number: 2 is facing down, 4 is facing left, 6 is facing right, and 8 is facing up.

So to check if our event can move to the tile below it, our conditional branch’s script call is: $gameMap.event(this.eventId()).canPass($gameMap.event(this.eventId()).x, $gameMap.event(this.eventId()).y, 2)

If both conditional branches pass their checks, that means the tile event can safely move to that spot, so we can add in the move route (and SE) for our event to move onto the intended spot. If our event does move, then we want to turn on a switch to check if the puzzle is solved and exit the common event so that our tile doesn’t try to move more than once.

Now that we know how to set up one direction, we just need to do it for the other three with minor adjustments to our script calls:

With our common event set up, we can playtest to make sure our tiles all move around like they should. If something, like the tiles refusing to move right, happens when testing, we need to double-check our script calls. But if they’re all moving around well, then we can move onto the puzzle’s final part.

Checking for Success & Mixing Things Up

Now that our tile events can move, we need the event where we’ll be checking to see if they’re in the right spots. While we could do this in our puzzle’s common event, by having it separate from the movement we can have multiple sliding puzzles in our game without making a huge common event.

Our event’s set to autorun and only active when the ‘sliding tile check’ switch is On, since there’s no reason to check the puzzle if no pieces have been moved. We’ll start our event by turning off the switch so that this event won’t repeat until the next tile has been moved.

There are a few ways we could check if the puzzle is solved, in this tutorial we’ll be comparing our events to the puzzle’s regions. Since we marked the puzzle area with a different region on every tile, we can use the Get Location Info command to get our tile events’ current region. Once we have that region info, we just need to check if it doesn’t match where we want that event to be. So if our Tile 1 isn’t on region 1, then we’ll exit the event since the puzzle hasn’t been solved. If we compare each tile event and their current region, and none of them are in the wrong spot then that means our puzzle has been solved and we can turn on the puzzle done switch On and let our player know that they’ve succeeded.

This event’s second page is where we could reward our player’s success with an item or a way to move onto the next area.

Our last event is how we’ll be shuffling our puzzle pieces. An important thing to keep in mind is that RPG Maker resets the location of events if the player leaves the map, so we need to include an event that either mixes the unsolved tile events up or puts the solved tiles in the right spots when our player enters the map. For this tutorial, we’ll have our shuffling event mix up our unsolved tiles which means our tiles will be in the correct spots when we’re working on the map.

Another really important thing to remember is that we can’t just move the tiles randomly, since that could make our puzzle unsolvable. A good way to make sure that our puzzle can be solved is to move each tile one-by-one in the editor following the puzzle rules so that we can be sure the events can all be moved into the right spots.

Once we’ve shuffled our events in the editor to make sure the puzzle can be solved, we can have our autorun shuffling event set all our tile events’ locations to their new spots and then have it erase itself until the next time our player enters the map. Once the puzzle has been solved the event’s second page is turned on, making it so the tile events are no longer shuffled.

Then we just need to put our tile events back into their solved spots on the map, and in-game our tiles should shuffle properly until our player solves the puzzle.

With all that eventing completed, you can playtest and see your puzzle in action!

One last thing to keep in mind is that while our eventing means we can make our puzzle any size we’d like, a large puzzle may not be fun for our players. So make sure that any sliding puzzles you make aren’t so complicated that your players want to give up!

Now that we know how to make sliding tile puzzles, how would you use them in your games?

‍