When I first wrote the project page for Salo, I expressed my intent to write a blog post about the development of it. Well, here it is.

Just what exactly is Salo?

Salo (a portmanteau of "save" and "load") is a puzzle game concept that I've been playing for a while now. The entire concept revolves around 5 simple rules and 1 twist. Lets break it down.

1. Every level in the game is made up of the player, some switches, walls (if any) and a single door.

2. Every switch and wall in the game has two states: On or Off.

3. All walls (if any are present in the level) are connected to a switch, their state is toggled whenever their connected switch's is.

4. Switches toggle between states when interacted with. There are two types of switches, buttons and levers. Buttons will switch themselves off once the player moves, levers will not.

5. The goal of every level is to reach and activate the door. A door can only be activated if all switches in the level are in their "on" state.

Simple, right? Get in a room, press all the buttons and pull all the levers and move on. But you might have noticed something.

If all buttons toggle themselves off whenever the player moves, how can you ever activate a door in a level with even a single button in it?

That brings me to the "twist" I mentioned earlier.

The Namesake

Salo's main mechanic is saving and loading. Every object, except the door but including the player, is one of two types: Red or Blue.

Red objects will have a property that persists through saving and loading. For switches, this is their state, for the player, it's their position.

Blue switches and walls will revert to their original state after a load. A blue player will not update their last saved position in the room when the game is saved.

The player can switch between red and blue types with a button press.

The entire twist can be summed up as this simple rule:

Red objects save, blue objects don't. Press "Q" to toggle the player type.

Now we're getting somewhere.

An Example

This section gets a little spoiler-y, so if you want to play the game you can skip it, or just come back after playing the game. The game is free on Itch.io and it only has 5 levels, I promise it will be quick. If you get stuck, the solutions are posted on the Itch.io page as well. Here's the game page, if you want to check it out.

Now on to the spoiler-y part.

Consider this: You load in to a level of salo, there's a blue lever connected 4 red walls that surround the door. You need to pull the lever to proceed, but when you do the walls are "on" and you cannot reach the door. What do you do?

Remember the 3rd rule:

All walls (if any are present in the level) are connected to a switch, their state is toggled whenever their connected switch's is.

The rule states the wall's state will toggle with the switch's, but it never says that the wall state is tied to the switch state. If a button is "off" but the wall is "on", when a player presses the button it will be "on" but the wall will be "off". And remember the twist:

The entire twist can be summed up as this simple rule:

Red objects save, blue objects don't...

The solution then becomes very simple. Activate the lever, the blue lever is now "on" and the red wall is now "on" as well. Save the game, the red walls saved their "on" state but the blue lever didn't. Now load the game, the lever is back to being "off" but the walls are still "on". Activate the lever again, lever is now "on" and the walls are "off". You are now free to walk up to the door and activate it.

Now add in button switches and player positions and you have a recipe for a brain twister. You didn't hear this from me, but some puzzles even require you to have multiple instances of the game open at the same time.

Crazy right?

The Origin of Salo

Believe it or not salo started its life as a rogue-like RPG. Back then it didn't have a name, and was written in a custom engine.

Those slow moments in time (downtime at work, nothing to do at home etc.) really make you do crazy things. For me, it was trying to write a custom ASCII game engine in Python with no external libraries used. I honestly wanted to see how far I could push it, and push my knowledge.

Apologies for the phone recording, apparently I didn't know screen recorders existed in 2019

As you can see, implementing the basics were easy enough. In the video above, the player is indicated by the "@" symbol. The periods indicate tiles that are visible, and the pound symbols indicate tiles out of sight. the "|" symbols are walls that the player cannot move towards. In the video they don't block sight, but that was implemented shortly after.

Cool, we now have a game, that understands "levels". We also have a player that can move, rotate has line of sight and collisions.

Let's build a roguelike RPG!

And so I did.. At least I started to. I added a basic UI, some colors, test objects and much more. I even added a save system.

It was starting to look good, something that resembles a video game. Maybe one from the days of early computing, but a game nonetheless. I added some basic structures, walls and doors for shops and houses. Some would be locked, and some, like dungeons, would require you to pull levers. So I added those too.

Oh, need to get back to work. I'm developing this during downtimes, remember? Let me just save it and...

Oh wait.

I forgot to add the doors to the list of objects that need to save. I'm now forever locked inside this room, unless I load an earlier save.

Wait maybe I can turn this into a mechanic? Make some puzzles for some of the dungeons? Let me prototype it on a separate project...

Thus was born... Dimension Hopper. That's what I called it back then, Or rather "Project DH". Early DH shared much of the look and feel of the rogue-like prototype down to the inventory screen to the right, but with time came some differences here and there. Here's a screenshot from the final state of this version of the game, this time using screen capture rather than taking a picture on my phone.

This is the first level, the UI is easier on the eyes, there's now a functioning message system, inventory is removed, a help screen is ever present and an empty portion of the UI is reserved for the eventual logo.

This version of the game was plagued with bugs that were frankly way above my level of expertise to fix. There were performance issues that wildly differed between different hardware and OS configurations. It was so wild that I couldn't even work on designing more puzzles than the initial 5 because of all the technical issues.

Eventually, like many other of my projects, I dropped it.

The Godot Game Engine

I love designing and making games. Board games, card games, video games... You name them, I design them.

When I got my first bootleg NES I was obsessed, then my PSX came along and it's still my favorite console to this day. When we finally got a PC however, I was like a starving animal, I downloaded every demo and free game (and sometimes an adware or two) I came across. Eventually I stumbled upon the demo of a software called Game Maker.

I can make video games now instead of playing them? Count me in.

Keep in mind, I didn't even speak English at the time. But with the power of MS Paint for graphics and pushing random buttons until things happen I made several "games". It was so much fun.

Over the years I always made prototypes with the languages and engines I came across, until one day in 2020 I came across the Godot Engine.

Godot was like a dream come true. FOSS, scripting similar to Python, easy to use... It ticked all of my boxes. Just one problem though, I wasn't as creative or motivated as I was back when I was a child. I knew I wanted to make a game using this engine, but I didn't know what to make.

Then I remembered, I have DH, I can try to port it to Godot in order to learn the engine. Thus begun the efforts.

I hit my first roadblock pretty early on however, as Godot back then didn't support multi-window applications, and my game needed multiple instances running at the same time. Now, I don't remember if it straight up didn't work, if my save system didn't work like I wanted it to or if it was performance problems but something pushed me to turning the game into a single window application, with the ability to spawn faux "windows" within the game screen.

The development continued until it didn't, here's a screenshot from this version of DH.

Some glorious programmer art depicting the player, the door, some walls, a lever and a new type of object, the timer.

This was the version of the game where the buttons and levers switched functionality, in the Python version levers would turn off when the player moved and buttons wouldn't. It made more intuitive sense to swap them, so I did.

I developed this version for a while, I don't remember why I stopped but eventually, like many other of my projects, I dropped it.

Waiting For Godot

I eventually came across the Stop Waiting For Godot game jam. I desperately wanted to join, didn't know what to make but I knew I wanted to make something, just like when I first came across the engine. Many prototypes came and went since then, but I remembered DH again.

I thought it would be nice to go back to it, finish what I set out to do. I also thought it would be a nice demonstration of my improvement with the engine since I first started to use it.

It was around the time my fondness for 3D game development was budding, so I added the third dimension to the game as well.

For the first time, ever since I first downloaded the demo for Game Maker, I actually followed through with a game dev plan.

I finished the development of the game with all 5 original levels from the Python version ported to this final version. This is also the version of the game that got the name "Salo".

The game released to wide critical acclaim. Out of the 133 people that have seen it, 47 decided to download it. 3 people added it to a collection. 1 person rated it 2/5.

I loved it all the same, I still do. It's the the apple of my eye. Perhaps one day I will revisit it, add more levels if I ever get better at designing puzzles, or improve the graphics or something.

At the end though, unlike many other of my projects, I finished it.