I should say in advance that there’s a lot of rambling in this devlog post. Mostly just trying to work through some design problems. Read at your own discretion.
I spent the last two days working on a design problem that I initially thought would be simple and trivial, but turned out to be quite complicated as it was very closely related to the central structure of the entire game.
Doors, Keys, and a larger design problem
I mentioned at the end of the previous update that I was starting to work on these Teleportation Doorways, which are basically triggers that teleport the player from one scene to another. For now, they are primarily placeholders until I get seamless looking portals working.
It seemed like a pretty simple element to design and implement. However, as I started to get into it, I realized I was actually tackling a much bigger problem.
You see, the game is structured as an open world game, within which are a series of linear puzzles. I’ve described the game as a mix of Portal and Myst, here I will go into detail why.
Portal is clearly a very linear game. You progress through the set of puzzles in a very specific order, and aside from the little bit towards the end before the boss fight, it’s always pretty clear where you should be headed. In Portal, where there is a strong focus on a core mechanic, this structure makes a lot of sense and works really well. In order to solves the more advanced puzzles, you need techniques developed in earlier levels. In Portal, first you learn to use portals, then you learn to put boxes on buttons to open doors, then you learn to combine the two, and so on and so forth. Towards the end, you’re using all the techniques you’ve learned to solve the puzzles.
For me, personally, I really liked this structure, as far as puzzle solving is concerned. Every time I was stuck, I knew there was a solution, and I just needed to think of approaching the puzzle in a new way to find it. I wasn’t stuck because I didn’t have the right tools, or because the game hasn’t opened up the area yet. I was exactly where I needed to be, and just needed to think through the problem, given the elements on hand. For me, this was really fun and enjoyable. And even though there were parts that were challenging, they were always fair and not frustrating.
Relativity started out like this, with a linear sequence of puzzles that grew progressively more difficult, involving techniques and skills that built up on each other. However, in the course of development, I came to realize that the world in the game is much more important and interesting than the puzzles themselves, and that exploration would actually become the main component of the game. This is where I started to draw influence from Myst.
While I really like the world that’s created in Myst, how encompassing, and detailed it is, I can’t say that I was a big fan of the puzzles. There were many that just felt outright arbitrary, and also, the skills you used to solve one did not necessarily transfer to the others. In some ways, one could say that the puzzles in Myst were more riddles than puzzles. There was no core mechanic that one became better at using to solve progressively more challenging puzzles.
Combining the Two
In Relativity, what I would like to do, is bring together the best elements of Portal and Myst and combine them together. There would be an open world that players are free to walk around and explore, with lots of details and hidden treasures, but at the same time, all the puzzles would focus around variations of a core mechanic. But how do you ensure that players go through the puzzles in the sequence you intended? This is where the doorways come in.
The doorways would be locked at first, and would require keys to open them. By restricting access to the keys, I can ensure the player solve puzzles in a specific sequence. For example, a player may come across the door for puzzle 3 before he comes across the door for puzzle 2. However, in order to open the door for puzzle 3, he needs get the key by first solving puzzle 2.
As such the doorway needs to communicate this information:
1. Whether it is locked or unlocked.
2. Whether the puzzle it leads to has been solved or not.
Regarding the key system, I decided to use a quantity system, similar to Fez. Basically, there aren’t specific keys for specific doors, just certain number of keys. So for example, Puzzle 3 requires you to have two keys to open the door. This is similar to the system in Fez.
The thing with the key system though, is that I don’t want to have an inventory system in the game. I don’t want to player to hit ‘q’ and bring up a screen showing them how many keys they’ve collected. That might make sense in other games, but I think here it would just take away from immersion.
Anyway, here’s the system I came up with:
Basically, here’s how it works: There are 36 keys that can be obtained in the game: 6 blue, 6 red, 6 yellow, 6 green, 6 orange, and 6 purple. Each Teleportation Door requires a certain number of each colored keys. In the above screenshot, to open the door, you’ll need 3 green keys, 4 yellow keys, 1 blue key, 2 red keys, 6 orange keys, and 5 purple keys.
How would you know how many keys you have if the game doesn’t have an inventory screen? Well, the door tells you. If you look at the sqaures, you can see that some of them are slightly larger and brighter. The orange ones are most evident, you can see that there are 5 slightly larger and brighter squares, and 1 dark one. This tells you that you have 5 orange keys already. In other worlds, the doors themselves serve as an inventory screen. In the above screenshot, you can see that the player has already met the requirements for blue, red, and green keys. However, this doesn’t mean that the player only has one blue key, the player could have more, but this door only requires one blue key, and that requirement has been met.
I think this system thus provides just the amount of information that the player needs to know to progress.
Additionally, it doesn’t mean that there will only be 36 teleportation doorways. There are many different combinations of requirement keys, but it ensures that the player always goes into each puzzle having already learned the necessary techniques previously. For example, there could be a door that requires 6 blue keys and 6 red keys, and another that requires only one yellow key. The player could have the requirement for both doors, and could do either one. The door with the yellow key is simply on a different track, and doesn’t require the same techniques needed for the puzzle with the 6 blue and 6 red keys.