Devlog #3 - We made a platformer with undos.

Hey everyone!

Just a quick update on how Glowkeeper’s progress has been going. We’ve recently started alpha testing and so far it’s been going pretty well! I think the map and puzzles should be finalized and we’re in the home stretch of touching up the rest of the game :)

Anyways this devlog is more of a technical dive into the mess that is the Glowkeeper undo system. For me, this is also kind of reflection on the design of the undo system, which arguably is the biggest pain in the development of Glowkeeper.

So, in a typical puzzle undos are a basically expected feature and is such an important QoL feature. For most discrete games, this is quite straightforward to do. If the game is continuous, it is possible to implement something like a rewind feature to turn back time.

But well, for Glowkeeper, the movement of the pieces are discrete but the player’s movement is continuous. So I decided a discrete undo system would make the most sense. But this begs two very important questions:

1. What counts as something that can be undo-ed?

2. After an undo, where should the player be placed?

Actions

An action is most basic unit that can be undo-ed in Glowkeeper. What should be allowed to be undo-ed?

I think the most reasonable classification would be that if the pieces on the screen change in any way, that is an action. The most obvious actions that fit this criteria are

• Matching 3 or more pieces

• Pushing a rock

• Collecting a scroll

And because Glowkeeper is set in an open world with checkpoints, there’s also these things to deal with:

• Resetting a room

• Stepping on a checkpoint

• Entering a new room (cause you gotta pick which checkpoint to be active in the new room)

Anyways I decided these shall be the six major things that count as an action and that they can be undo-ed

Where to go?

Okay so here comes the painful part. Now that an action is undo-ed, where should the game place the player?

Some cases are quite obvious, for matching pieces or pushing a rock, just place the player at the position they were at when they did the matching/pushing, and this would be a direct undo the a previous state they were in. Resetting a room is the same too.

Collecting the scroll is similar, though a special case had to be hardcoded to stop you from undoing into the scroll and collecting it on loop.

And so that leaves the two culprits - “Stepping on a checkpoint” and “Entering a new room”.

So where should the player be placed after undoing “Stepping on a checkpoint”? Well, initially I thought that the player should be placed at a position slightly before the checkpoint. Which would work if the player was walking. However, if the player was falling onto the checkpoint, undoing would just place them slightly above the checkpoint, and would probably activate the checkpoint again unless they spam undo.

The even more problematic case is “Entering a new room”. Maybe we could place the player at the transition right before walking into the new room. But this again has the issue of transitions where you fall vertically downwards.

I remember experimenting with many things and almost nothing worked. It’s just not practical to determine where the player should be placed simply just based on where the action happened alone.

Eventually I came to the conclusion I came to was that for both of these cases, the undo should place the player at the position of the previous action.

And thankfully this was the most successful solution I had, after many terrible attempts of undos causing glitches everywhere.

Unexpected warp

So while this works, there is still a big issue with the “Entering a new room” case. Imagine if your last action was over here:

And then after clearing this room, in this room over here, you press undo once.

You’ll be sent all the way back to the previous room! And you have to make the long trip back to the original room, and genuinely this is pretty unpleasant. Many testers also found the behavior unintuitive.

Many of them expected to not be able to undo past the starting state (which for the meta-game purposes is just not possible). But essentially, players will press undo until the puzzle looked right, but one extra undo would send them back miles away.

So to fix this issue, I decided to make an exception to how undos will work. If you’re trying to undo a “entering a new room”, it will instead perform a “fake restart”, which essentially puts you at the spawn point and does not count as an action. Then, if you press undo again, then it will actually perform the undo.

And yeah this seems to work? It’s really hacky but players never had issues with the room warping thing anymore.

Discrete vs Continuous

So this bug happened a ton. In fact this bug was reported at least 10 times from my memory. The issue here is that undoing a room transition puts you at the position of the previous action. In this case, the action before entering the room below is matching the 3 earth blocks.

But well, the player is literally there when it happened. It’s fine originally because the blocks are falling and the player is falling below the blocks. But when undo-ed, the blocks are there so the player gets stuck inside the blocks.

For the longest time we never had a good solution to this issue without somehow breaking this rube goldberg machine of an undo system.

But interestingly, a suggestion came from my friend Cellenite. Go check out her game Little Ghosthunter on steam, it’s really good :O

Anyways the solution is really simple - if the player is stuck, just undo again 🤯 and yeah that just works. Like it’s also not the most elegant thing but I’m sure players won’t bat an eye if you undo a little bit more than usual.

This is an “extra undo”, and in fact after discovering this trick, I also managed to fix another really corner case with vertical room transitions where the player matches 3 pieces right before they fall down. Undoing in that case would make them warp to that point right before the falling down the transition and it would be difficult to undo without spamming undo.

Duct Tape

As of now, after alpha testing and with 2 people 100%ing the game and two more who basically played 90% of it, I can say that the undo… works.

It is kind of held together by duct tape, but somehow it works. I still wonder if there’s any more elegant solution to this whole undo thing, but every single “elegant” solution that works always has one or two issues with the user experience.

I guess ultimately having an inelegant solution is alright? No one actually examines the undo system in detail if it does what they expect it to do. And if no one questions is, means it’s doing it’s job well as a QoL feature, and I think that’s what that matters.

Anyways thanks for reading! I’m just gonna dump some more stuff about undos from the entire development process of Glowkeeper, have fun!