Puzzle Designers Wanted

While creating something as complex as Tetris is a tall task, creating a simple puzzle is a great way to learn how to code a variety of game mechanics in GB Studio. In this introduction to scripting puzzle games, we will start by recreating a digital version of the Sliding Tile Puzzle. To create a good puzzle game, you need a good foundation, which stems from good design. Critical to establishing a strong design, you first need to consider the needs of the puzzle itself. In our Sliding Tile Puzzle, we need a grid, some tiles, and a means to move them around.

Remembering from childhood, these puzzles were often won as cheap prizes at arcades and were a 4×4 sized grid. Housed in a brightly-colored plastic case, they slid around the grid using rails built into the case itself. To modernize this design, we’ll use a thick housing to encompass the tiles and round the corners off to give it a cleaner look.

To make the design pop, we’ll use a custom background with the two lighter shades of the Game Boy palette to make it stand out. I pulled a background from 2bitcrook’s excellent Gameboy Background/Pattern Pack for our puzzle design. It’s simple, yet effective.

For our tiles, I wanted a sleek-looking digital look for the font, so I went with bold, thick lines for the numbers. Feel free to choose whichever font you prefer, as long as it can fit within each tile. To better distinguish between the tiles and the case, use a black-lined outline for the tiles, with an in-line of white to make them spaced apart from each other and their boundaries clearly defined.

Finally, since the player sprite will move around the grid, we should create a cursor sprite with the opposite colors of the tiles beneath to show when a tile is hovered over. Now that we have all the design foundations for the puzzle ready, we are prepared to begin the most important part: “a means to move them around.”

Cursor Control

To set up the puzzle properly, we should always start with the control of the puzzle within it. There are only a few options, such as a cursor that is moved with the directional controls, or moving the cursor through the puzzle, one option at a time. Since we don’t have puzzle parts around the screen, moving the cursor one tile at a time is likely the best way to handle this.

We create a trigger in each Tile square, aligned to the bottom left. I like to start from the top left, renaming that trigger “1” and following along with each number, until we get to the blank space, which should be named “16.” These triggers also represent a Tile # variable corresponding to the trigger’s name, which we will set up later.  When entered, these triggers attach movement scripts that allow (or limit) our movement around the grid. They also will move a hidden actor named “Slide Move Actor” to the player’s grid position to show the visual of the tile being slid between slots.

Let’s break down the script part by part. Each group is labeled according to its function using an [Event Group] event, and renamed according to its purpose. At the top, we have our [Set Actor Position] event, which we use to set the position of our hidden Slide Move Actor.

Next, we have a group of control scripts with the [Attach Script To Button] event. As commented, you’ll notice a section that attaches “blank controls” to a particular direction. Every trigger other than the middle four will have this because otherwise, we could move off the grid, which is troublesome in a locked control system like this.

Inside that event, the actual controls are attached with a [Set Actor Relative Position] event, which will move in the intended direction. It’s good practice to create a set of the four potential directions inside of an [Event Group] and alter the ones we do not need into the blank controls event, which we can then use to paste and manipulate within each trigger script.

After setting up our triggers, you should be able to move your cursor around the ‘playing field.’ This is a great milestone in setting up our puzzle and a great time to test that everything is set up correctly by moving through all the rows and columns to ensure you haven’t missed anything.

Some Extra Spice

If you feel adventurous, you could even code in the edges to allow a “wrap-around” directional system. Instead of blanking them out like we did in a previous step, you could remove the direction you are changing from the blank [Attach Script To Button] event and add a new [Attach Script To Button] event with the corresponding direction(s).

Then, simply change the [Set Actor Relative Position] to:

• Bottom
  • {-6,-6} for the Right Button and {0,-6} for the Down Button on the Bottom Right Trigger
  • {0,-6} for the Down Button on the Bottom Middle Triggers
  • {6,-6} for the Left Button and {0,-6} for the Down Button on the Bottom Left Trigger 
• Middle
  • {6,0} for the Left Button on the Middle Left Triggers
  • {-6,0} for the Right Button on the Middle Right Triggers
• Top
  • {6,0} for the Left Button and {0,6} for the Up Button on the Top Left Trigger
  • {0,6} for the Up Button on the Top Middle Triggers
  • {-6,0} for the Right Button and {0,6} for the Up Button on the Top Right Trigger

You can follow this project and download the files over on itch.io!

In Part 2, we will get our code set to move our tiles around, check for a win state, and talk about debugging and options for finishing our Sliding Tile Puzzle.