The checkpoint/progress saving system is almost done. Made several improvements over the weekend, and also cleaned up the code quite a bit. For the script controlling the lights on the teleportation doorways, I managed to reduce the number of lines of code by about half after figuring out how to use arrays of arrays in Unity.
I still need to spend some time working on the respawn system, which is used when players fall of ledge into nothingness. There’s basically several large invisible collider boxes around the level, and when the player makes contact with one of them, the scene restarts. Right now there are some problems with the player position, since the starting location when a scene begins is based on which entrance the player came in. I think one solution would be to not use a scene restart when a player hits a respawn trigger, but instead destroy the player object, and create another one, all within the scene.
In an earlier design of the game, whenever a puzzle is finished, the player would need to walk into a rotating rubiks cube in order to be teleported to the next area.
It acted as a sort of a key. There wasn’t a reason why it was a rubiks cube – I used it primarily as a placeholder, so I knew the look of it would have to change. There was also another problem with this mechanism – it didn’t allow of backtracking. After you touched the rubiks cube, it disappeared and you were brought to the next area. This worked fine when the stucture of the game was a linear one, but as I began to make it more open-world, it became problematic. Additionally, the “make contact and have it disappear” aspect of the key felt like a very cliched video game trope, and that was something I wanted to stay away from. It didn’t make sense within the context of the world.
I therefore switched instead to these key switches:
Instead of walking into the key and having it disappear, here you’re actually turning a switch on. You’re not teleported to the next area, but the switches act as keys, unlocking doors to certain areas. For example, after you turn on the first blue key, you’re able to walk through any doors that only require one blue key switch to be on:
Notice the blue square in the top left corner of the door. That’s the signal that tells you it requires one blue key, and the fact that it’s lit up informs you that you’ve already switched it on.
To avoid confusion in the game, I’ve made these keys so that you can turn them up, but you can’t turn them off.
I also went back and rewrote the code controlling the bridges that magically appear in front of you. Made the whole thing much more efficient and clean. While I was doing this, I decided to add a bit of offset to the animation of the bridge, so that the segments do not all appear at the same time.
Here’s what it looked like before:
And here’s what it looks like now:
You can notice that in the newer version, the bridge segments that are further away take slightly longer to form than the bridge segments closer to you. In the old version, all the segments would form at the same time.