Quantum Shift

Post Mortem

My first published solo-project, Quantum Shift was created using Unity 6.5 and C#. I began this project in May of 2024, and would complete it in July of 2026. In January of 2026, I would reduce the scope substantially for a more minimalist aesthetic. My goal with this game was to create a dimension-travel mechanic, akin to the Time Gauntlet from Titanfall 2. The following are what went right and wrong with this solo-project.

Play on itch.io

What Went Right

Core Mechanic: The Teleporter

I partially doubted that this mechanic would work for one specific reason: it's a mechanic you really see be the focus of a game. And when it is, either that game is 2D, or the mechanic is only used for a single level, rather than the entire game, such as the Time Gauntlet from Titanfall 2. I'm proud that it turned out the way I wanted it to. Even the first working prototype was pretty close to my vision of it.

Minimalist Aesthetic

I had it right at the start of its development to make this game minimalist, and only focus on the core mechanic of the game. The scope of this game would escape me for the middle portion of its development, but I eventually would come back around to realizing the benefits of a minimalist design.

Saved Highscore & Settings Data

This was my first time implementing saved files, specifically the player's highscore and their desired settings for volume and camera sensitivity. I felt the short length of the game didn't warrant saving the player's current run.

Playable Demo

I made sure not to spend too much time on one task. Once the part I'm working on gets to a playable state, I leave it and move on to my next task. Only after I release a playable build and receive feedback do I return to that part of the game to finalize it.

Playtesting

Playtesting helped me out with level design. For one, it revealed to me that the first puzzle needed to incentivize the player to jump, so that they pay attention to how different it is based on what map they're in. And for another, it let me know that the second level was too difficult.

What Went Wrong

Lack of Scope

The biggest obstacle that led to this game taking two years to be made, was a lack of scope. I did not know how big I wanted this game to be. This led me to over-scope it during the middle of its development, turning it from a minimalist aesthetic to a haunted mansion theme. It took me way too long just to build the mansion's exterior (walls, roof, etc.). By the time I had to do its interior, I just threw my hat and returned to a minimalist design.

Lack of Level Communication

The first puzzle was meant to implicitly show the player how the different maps work in regards to gravity. What I forgot to do was give the player a sign to pay attention to how jumping works different across maps. There still needs to be a level of communication, even for implicit level design that shows rather than tells.

Level Difficulty

The second level originally was a huge spike in difficulty from the first level. Both its floor and ceiling were covered in lava. There was a small floor platform on the other side of the room, but was too far away to jump. The player would have to teleport to another map to get anywhere. After playtesting, I realized it was too difficult for a second level, maybe even the entire game. So, I scrapped it and toned the difficulty way down for most of the levels.

Lack of Interactable Objects

I intended to add more interactable objects than just the cube. There was going to be a key to unlock doors. Levers to rotate bridges. Coins to collect and spend on upgrades.

Lack of Environmental Hazards

I had also intended to add more environmental hazards beyond lava. There would've been gas leaks that deal damage over time, simple water that the player could drown in, electricity fields that stun the player.

Conclusion

Regardless of the scope of this game, I'm just really glad to finally publish a solo project, instead of it going into prototype limbo. What I'm most proud of, is seeing all of the different systems I created for this game (State Machines, Saving, Input Device Handling, etc.) working in tandem. If I could give one piece of advice to myself at the start of development, it would be to prioritize a playable demo first, and then finalize after playtesting. I believe that leads to a more productive timeline than what I ended up doing.