Devlog 1 - Concept and Design

Just wanted to talk a bit about my process in creating Quantum Rift. I hope to post a new entry here every once in a while, like when there’s a major update to the game. In this first one, i’ll just talk about my initial ideas for the game and how i landed on its current design. I hope to post again soon to discuss the technical side of creating the game as well.

Warning: I ramble quite a bit about my thought process, so don’t read if that sounds boring!

Conception

I’ve had the idea for a while about using quantum superposition in a game. I think it started when i was thinking about time travel in games.

Time travel in a game can be tricky to figure out, especially time travel that allows you to replay a section that you’ve already played. What happens to the version of you that played that section before? Does it just disappear and you essentially get to replay the whole section from scratch? Or do you keep the old version of you (how you originally played through it) and have it run alongside of you like a shadow (like in Braid world 5)?

This second option is very similar to the idea of quantum superposition. It’s as if your choice in how you play the game were a quantum event. It produces a world that is in multiple states at the same time. One state is produced by your first playthrough. The other state is produced by your second playthrough.

For Quantum Rift, i essentially took that idea and flipped it on its head: What if the world started in a quantum superposition state and it was up to the player to bring it back to a single, unified state?

I actually like the idea of a game that moves in this direction (from many worlds to one) a bit better for a couple reasons.

It’s Simpler

Keeping track of multiple worlds can be difficult. Of course, it can be hard to code a system to reliably support this kind of gameplay. But also, it can be hard for the player to keep track of everything, which makes for a confusing game instead of a fun one.

On the other hand, a game that starts with multiple worlds can be limited much more easily. As the developer, i can decide how many worlds to start with and be sure that that number will only decrease as the game progresses.

It Makes Sense Philosophically

It also makes more sense philosophically for a person to make choices that bring many worlds into one. I would say it is chance and/or chaos which usually produce multiple worlds. People, on the other hand, generally have the opposite effect. They have goals, and they make choices to achieve those goals, regardless of the state of things beforehand.

A simple example: suppose a person is away from home and wants to return. If they are north of their home, then they will walk south in order to return. But if they are south of their home, then they will walk north. It can start in different states and always result in a single outcome.

So, chance/chaos takes a single world and splits it into many worlds. Personal choice takes many worlds and combines them into one. In a sense, Quantum Rift is an exploration of this idea.

Design Decisions

When deciding the particulars of what Quantum Collapse would look like, I explored a few possibilities before landing where i am now.

Quantum Events

One early idea was that there would be sources of chaos embedded in the game world, such as a box that might or might not explode. My thought was that these sources of chaos would be the cause of quantum events, splitting objects and increasing the number of different worlds that the player had to navigate. It would be up to the player to deal with these sources of chaos and then restore the worlds.

The main issue I ran into with this idea was that the number of worlds would increase exponentially for each quantum event. This could lead very quickly to too many worlds. So i decided it would be better to remove the quantum events from the playing field, so to speak. They would happen before the player arrived so that i had better control over how many worlds were created and what the worlds looked like.

Physics

I went back and forth on physics for a while, trying to decide whether to use a more natural physics system or whether to enforce grid-based movement. On the one hand, natural physics might feel more open to the player and more immersive. Also, it is already built-in to the engine i’m using (Godot), so it might make development easier/quicker. On the other hand, i wanted to focus on puzzles rather than on platforming or other skill-based mechanics. And to me, a grid-based movement system felt more conducive to focusing on puzzles.

Above is a (very) early prototype of the game in which i used Godot’s built-in physics system. (The color scheme was different too.) Doing this actually helped me to decide to go with the grid-based movement. I realized it was dissatisfying to not have things in different worlds snap together when they got close to their counterparts. I could have implemented a mechanic to do that, but i could also get that for free with grid-based movement.

Graphics

For this game, i knew i would need a simple art style that would help to accentuate the puzzles instead of confuse them. This is especially true because of how i superimpose the worlds over the top of each other.

I forget how i thought of the idea of using color to differentiate between the worlds. When it first came to me, i was actually thinking of doing the game in 3D. The general idea would have been much the same: anything that is only in one world would have been saturated/colored, and anything that is in both worlds would have been white or some shade of gray.

In the end, I decided to do 2D pixel art as a way to simplify the art process, since art isn’t really a strong point for me. This also had the added benefit of forcing the game world into a 2D plane, which i think has actually served to limit level-design options in a way that makes the game stronger overall. This game probably could work in 3D, but it would require a stronger visual design in order to keep the puzzles clear and understandable.

Last graphics thing i want to talk about is the world-shifting mechanic. (An early implementation of it is shown above.) I thought of this mechanic pretty early on in development. The goal for it was to provide a way for the player to more clearly differentiate between the two worlds. Honestly, i think this is one of those things that seemed better in my head than it actually turned out. But i’ve kept it in for now because i’m curious what other people think of it.

World Layout

I’m a fan of Metroidvanias and other genres with big, intricate worlds. So, at first I was thinking of developing this game somewhat in that genre. My idea was that there would be some quantum event that affected a whole area of the game. So you’d have to navigate through the area in this quantum state, find the central control room (or something similar), and then restore the area to a unified state.

I ran into a few issues with this idea, however. First of all, what would i do if different versions of the player ended up in separate rooms? In this game, the quantum worlds are superimposed on each other. That works fine if the differences between the worlds are only a few dynamic objects (with all of the static geometry being the same). It would be much less enjoyable to play if the player were in two different rooms at once. (This could be a neat mechanic to explore once or twice in a game, but i think it could get tedious very quickly.)

The other, and perhaps larger, issue is that Metroidvanias might have small puzzles in particular locations, but that is generally not their main focus. Their main mechanics tend to be combat, platforming, and gaining new abilities. But i wanted to create a puzzle game. I’m sure it’s possible to mix the puzzle genre with Metroidvanias, but i have some trouble seeing how to create good puzzles in an open and interconnected world.

So in the end, i’ve decided to go with smaller, discrete levels. It removes any challenges related to connecting different puzzles together, and it enables me to develop the game more quickly. I think there’s a reason it’s a classic for puzzle games.

That said, i would definitely like to add some sort of overarching structure to this game before i finish it. It may just be that i group levels together based on their themes and mechanics. Maybe there will be a central hub that the player can use to access the individual puzzles… something to invoke a greater sense of connection between the levels.

In a future game, i may even return to the idea of a large, interconnected world with a main mechanic similar to this one. For now, though, my goal is just to finish this game.