Games / Gates 'n' Ghouls / Behind the Purple Gate

Beyond the Purple gate

A look behind the scenes of Gates 'n' Ghouls

In October 2022 it was time for another Ludum Dare game jam. The theme was revealed to be "Every 10 seconds", pretty much a repeat of the theme that was used 9 years prior, "10 seconds".

Perhaps there's something inherently compelling about the short timespan, especially when the goal is to create an interesting game loop over just one weekend. There is only so much action you can cram into 10 seconds, and even the most simple takes on the theme are bound to create something that keeps grabbing the player's attention.

Despite deciding not to join the game jam, the prompt was stuck in my mind. After having some pico-8 projects grow out of scope and beyond the limits of the fantasy console I was intrigued to make something more contained — like a remix of a classic arcade game.

And after living with this idea for quite a while I wrote down the following in Notepad++

- Pacman style maze game
- Gates that open and close every 10 seconds
- 5 levels
- 2 kinds of enemies
- Leaderboard

Luckily the scope was small enough that it could survive my eventual feature creep, and today you can play Gates 'n' Ghouls with its 12 levels, 4 monsters, leaderboard, and unlockable color palettes.


Prelude to Progress

An early version of the sprite sheet, including the original title "Tangled Tomb".

Usually I start my games by drawing a scene. Seeing a mock-up of a level helps me make a mental map of how the systems should work.

The first version of the game featured two monsters: skeletons and ghosts. And all mazes had the same look.
Those familiar with Pico-8 know that the sprite sheet and map data have a memory overlap, so you have to chose if you want more level or sprite data. Since I wanted the maps to be 2 screens wide and 2 screens tall, that meant I could make up to 8 levels if I used all of the map data. That left only 128x64 pixels for the sprite sheet.

I had intentionally made the maps larger than the screen to increase difficulty and create surprising moments as you realize a monster is coming your way and you suddenly have to rethink your route.
Classic Pacman games had symmetrical maps, so that would be the player's expectation. This led to me designing big maps that were symmetrical across both the x and y-axis. I realized I should only store the upper left corner of each maze and then mirror it as it gets loaded.

And suddenly, there was so much room for activities!

Maze Mapping

This new approach to designing the maps would leave room for up to 28 mazes! You might wonder why not 32 as each previous maze could now hold 4 mazes...
Before I would just store each maze "as is" and I would move the player over to the correct level. With the new "corner map" system, the game has to have somewhere to build the complete maze, without overriding any of the other data. Therefore the game now needs an empty 32x32 tile area in the map editor.

The complete game map, with the empty play area to the left.

If we were to take control of the camera and move it to the right, we would see all the maze corners laid out right next to where the game is taking place!

The odd looking map data can be viewed with the help of a modded camera!

This is all great! But did the game need that many levels...?
Not really, what I wouldn't mind though is some more sprites. I didn't want to add more levels just to have them all look the same! The new plan was to have 12 levels and utilize the larger sprite sheet to add more varied graphics.

The final sprite sheet for the game.

Debuggin Demons

By this time, slimes had already been added. So the game had 3 enemies of increasing difficulty. I thought it would be fun to add a final adversary: The Demon.
These creatures truly lived up to their name, implementing their AI was the biggest development challenge of Gates 'n' Ghouls. To understand the issue let's first look at how the other foes were made.

I built the monster navigation logic based on three main design principles:

  1. Enemies only react to the player when they are nearby or in line of sight
  2. All movements should be "deterministic", with no randomness allowed.
  3. The system should allow for different kinds of behavior based on the enemy type
This resulted in a grid-based system where each tile holds a "heat" value. As the player character touches a tile, that tile gets assigned "100 heat". The heat then slowly goes back to 0. This leaves a "heat trail" behind the player as they walk around the maze.

Visualization of the player's heat trail.

Skeletons
Skeletons were the first monsters to be implemented. At each turn they pick the one with the most heat.
Based on this, Skeletons would hunt down the player. But they would also tend to start a conga line since they all follow the same path. This made it easy to exploit their behaviour.
The trick was to make them cold! All monsters now set the grid tiles they walk over to "-100 heat" which will discourage any fellow monsters behind them from walking the same path.

Skeleton reacting to the players heat trail.
Also notice the cold tiles left by all monsters.

Slimes
The "cold tiles" trick inspired a new enemy type. A shy, slow-moving entity that would act more as a moving blockade than an aggressive pursuer. Slimes acts similar like Skeletons, but they are drawn to corridors with zero heat instead of maximum heat. This makes them avoid both the player and other monsters.

Ghosts
These spectral beings are the only creatures that can pass through closed gates. Step one of making this happen is simply to let them see heat through gates.
Ghosts mostly passed through gates when the player was in a tough spot, making the player's first encounter with them a very short-lived one. To make the Ghosts telegraph their abilities I decided to make the closed gates very hot. This makes ghost prioritize going through them, and the player got to see that happen from a safe distance.

A ghost that prioritizes the closed gate over the tail end of the player's heat.

Demons
To this point all I needed to do to create new AI was to tweak how each type reacted to the heat grid.
The demons were going to be an aggressive foe that hunts the player consistently throughout the maze. This monster would always know where to go and take the shortest path towards the main character.

Not so fast! Remember the first design principle of the navigation system?
"Enemies only react to the player when they are nearby or in line of sight".
Turns out this made creating the demon's AI a lot harder. Whatever I did they either ran the wrong way or just stopped in their tracks. This was not the behavior of relentless demons...
After a while, I even tried to remove functionality from the game to fit in a second navigation system, but to no avail, the sacrifices I had to make were too great. I didn't want to get rid of the palettes or UI animations. I was stuck in development hell together with non-cooperating demons.

Until one day when I had a stupid thought. "What if heat grid, but more?"

The napkin sketch that changed my life forever.

I'd never considered just duplicating or tripling the amount of memory my heat grid used up. But one day I made a new heat grid just for demons to use.
In this new grid, the player radiates heat in all directions, like warm water flooding the entire maze, slowly cooling off for every step it takes. This results in a grid that always has a "direction of heat" pointing towards the player.
This is pretty compute intensive and has to happen over many frames to not introduce lag. So while the grid is still flooding the game keeps a copy of the previous filled in grid. That means there are three grids at all times. One for the normal ghouls, and two for the demons.
The two demon grids are even active in levels where there are no demons! Since it didn't impact the game's performance it wasn't worth spending the extra tokens turning them on and off.

Gif showing the flooding of the second heat grid.
The demon walk towards the hotter tiles.

Syncing Sounds and Strategies

The last piece missing was the music! I wanted the music to sync with the gates, to help players keep the timing. I'm not a musician by any means. So it was an interesting challenge to dive into an area I've never really explored before and I want to shout out Gruber for sharing his knowledge of music theory and making tutorials aimed at pico-8. After a lot of work I had a 30-second loop that I felt didn't live up to my expectations.

My original track.



So I started looking for musicians who I could collaborate with instead. I knew of John Heinze from being a host of the Pursuing Pixels podcast, where he had mentioned his musical background and use of pico-8 in his work. The topic of making music for a pico-8 game naturally came up on their discord and I asked John if he'd be interested in making the soundtrack for Gates 'n' Ghouls, and the rest is history!
From our very first chats he brought a great energy and had ideas for the music that I'd never considered. I was orignally happy with one track but our discussions quickly led to having one track for each tileset of the mazes. I wasn't sure that would be possible to fit in the cart but he managed to pull it off and delivered something I never could have dreamed of making myself!
I asked John to share some of his experience making the music, and this is what he said:

"I had written music in the Pico-8 sound editor before, but this was the first time I had written something in the context of a game. Robin reached out with the idea of having the music timed with the gates, and he had already worked out the framework of an initial track that tied the frames with the BPM, as well as triggering the loop to reset in case they got desynced. In order to avoid that, the loops had to be relatively short, but I still wanted to get a decent amount of variation in.

Having only ever written individual tracks on the Pico-8, I never had to worry about space, since the slots available for phrases or segments were more than enough for the songs I was writing. But since the game was already close to being completed, there were limitations on space I hadn't encountered before. I also had never had to consider sound effects taking priority over music in the Pico-8's 4 tracks - which meant I had to either reorganize the placement of different sounds in the music, or think of which tracks were "secondary" in the song, and would sound better thematically when the player had collected most of the interactable objects in the level that would otherwise play over it. I don't know how effective I was at delivering on that, but that was the thought process at least!

Overall I had a blast writing music for the game and had a ton of fun collaborating with Robin. I loved sending ideas back and forth or trying to puzzle out a solution to the issues that would pop up. I love making things on my own, but seeing another person's project and creative process is a joy in itself. Make stuff with others, it'll open things up that you could've never thought of on your own."



Labyrinth Legacy

And with that Gates 'N' Ghouls was finished. I'm very pleased with the final product and the response from early players has been positive and very heart warming!
In this article I've shared some of the most crucial design decisions and challenges that I had to overcome.
I hope you enjoyed the read and will see the game in a new light when you play it next time!

I plan to release the pico-8 cart so you'll be able to play it locally on your machine or on the go with a pico-8 compatible handheld.

To stay up to date on all things arrpii, make sure to sign up to my newsletter.