Reversal
ROLE
Solo Designer and Developer
DESCRIPTION
Reversal is a first person Puzzle/ Platformer built around the central mechanic of being able to rewind time for objects around the player.
YEAR
2024
GENRE
Puzzle Platformer
PLATFORM
PC
System Design
Basic Functionality
The logic for rewinding time is stored within the objects that are rewindable. This means that the system is quite versatile since if an object shouldn’t be reversed, then it simply won’t be made as a child of the parent rewindable cube class.
This system used a blueprint interface to handle the player controlling all of these objects. The player’s inputs are taken in the player’s blueprint and passed to the objects with the interface.
​
The rewind functions by using two arrays of values that store the position and velocity of the object every tick. Then, when the player rewinds the object’s position, it goes back through these arrays, setting the position and velocity to these values on the tick again.
​
In order to implement the “Replay” functionality, this system was flipped on its head. Instead of just deleting the items from the arrays as the player rewinded, they were added to a second set of arrays that would store these values for the object as it went forward. As such, when the player held the replay button, the object in question would then replay the movement as it was moving forward.
​
Implementation into the gameplay loop
The way these mechanics were specifically implemented took a lot of iteration. A balance had to be struck between player freedom and preventing them from softlocking themselves. Whilst the game did have a level reset, I didn't want the player to have to use it too often as I felt this could create a disjointed experience.
​
The compromise I eventually came to was that when time was working normally, the player would be in a "recording" state. Then, they would leave this state when they froze or rewinded time. Then they would be unable to return to recording until they reached the beginning or the end of the recorded motion. This was necessary because if the player could unfreeze midway through a rewind or replay, the system would either need to clear the stored values, or else produce a situation where the player would be switching between the two sets of recordings from that point forwards (This lead to objects teleporting around between the two timelines).
​
I experimented with the alternative (allowing the player to unfreeze but deleting their recorded values) for a while and most of the levels were made with this system as a placeholder. However it had the problem of relying very heavily on the level reset as if the player unfroze they wouldn't be able to get back to the beginning.
​
I recognised that the mechanic of time manipulation was always going to be somewhat un-intuitive by it's very nature. This first system was made with the hope that I could minimise the mistakes that the players would make with a fairly detailed tutorial.
​
However, with testing, I realised I was going about it the wrong way. It's not possible to teach the player to just not make mistakes. So instead I switched the focus of the Tutorial to introducing the general concept, and the mechanic to minimising the impact of mistakes. The most important factor in doing so was to make it so the player could always rewind to the beginning of a level if they needed to, regardless of how much they had recorded since then.
​
This is why I implemented the system that did not allow the player to unfreeze mid rewind, so they would be able to rewind all the way if necessary.
​
This worked perfectly because it meant that even if the player didn't fully understand how the mechanic worked, they couldn't softlock themselves to the extent that it forced them to reset the level. The previous system discouraged experimentation because the only way to fix it would be to reset. This system did the opposite by encouraging the player to experiment with their abilities.
​
Eventually I managed to amend the system even more seamless to use. Despite the UI indicating it, the fact that players could only unfreeze at the beginning or end just didn't seem to make sense to most people and the majority of testers had issues with it at least once. Fortunately, due to the design of the levels, these issues never stopped people from being able to complete the demo, but it was still something I wanted to address.
​
The new solution was to simply delete all "forward" values upon unfreezing. This meant that the player could unfreeze time at any point and still rewind it backwards as far as they would like. The only downside of this implementation was that the player could delete a replay that they wanted (which was part of what the old system was designed to avoid) but that has, in my current albeit limited, testing, been far less of a problem than the inability to unfreeze was.
​
As it stands right now, the current version of the system is how I intend to leave it for the foreseeable future. However, my philosophy is that design should always be driven by testing and so if future tests suggest that the system should be changed again then I will most certainly do so.
LEVEL DESIGN
Opening Level
The first room of the game serves as a simple introduction to the concept of time rewinding. The player's path is blocked by the falling bricks and time is rewinded through walking through the reversal gate.
​
​
The Second room features a far simpler version of a puzzle for a later level. Once again, the player doesn't have a huge amount of agency in this level in order to not overwhelm them. All they have to do is pick up the cube and place it on the second button to open the first door.
​
However, in my testing it was in this room that most players figured out how the rewind gates worked which was good as it meant that now the player would start using the rewind consciously.
Following on from the previous room, the player receives a gun which they can use to destroy the wall holding up the ramp.
​
As well as introducing the player to their gun, this room is also important as it is the first level that doesn't force the player to walk through the rewind gate. The player isn't chokepointed into it like they were previously and as such it is the first time the player must actively use their rewind ability to solve a puzzle.
​
This will obviously be expanded upon as the game progresses.
Three Doors
A more complex version of the previous cubes and doors puzzle.
​
This level is the first time the player is required to use their rewind as a direct ability. They had this ability in the previous level, however they didn't actually need it in that level (only the freeze).
​
Simiarly, the player has had to solve a puzzle related to moving cubes on buttons previously but this time they have no control over that rewind.
​
Finally, last time there were only two buttons and two cubes, with the cube starting on one of them and as such, there was only really one place for the player to move the cube to.
​
By adding complexity in every dimension of the previous time the player did something similar, it creates a puzzle where the player actually has to consider their actions in the long term in order to reach the solution.
​
Feedback on this level in particular was overwhelmingly positive during testing.
Balls, walls, and buttons
Here we have another take on a rolling ball puzzle and the re-emergence of the ramp supported by a wall of cubes.
​
The player must destroy the wall and use the button to call down a ball to activate the first button, which opens the top door. Then the player must rebuild the wall and ramp (using their time rewind) in order to create a path for another ball to reach the top button, which opens the door to the next room.
​