DevLog Update – Additive Async Scene Loading

Haven’t been posting here as frequently. Mostly been dealing with lots of technical challenges – rewriting various systems I implemented months ago so as to work with the current structure of the game. For example, I had to rewrite parts of the code governing the logic of the cubes that can be interacted with, so that their positions and colors can be saved.

I’m continuing to work on Portals. I’ve now added additive asynchronous scene loading as well, so that the portals can serve as transitions between levels.

Here you can see it in actions. For the sake of clarify, I’ve made the “load scene” trigger the blue checkered box, and the “destroy scene” trigger the red checkered sphere. When you walk in to the “load scene” trigger, it loads the other scene, and turns the portal on. When you walk into the “destroy scene” trigger, it destroys the other scene.

portals_top_down2

Of course, in the final game, you won’t be able to see the “load scene” and “destroy scene” triggers, and they’ll be much bigger to anticipate player movement.

DevLog Update – (Semi)Working Portals

It’s 1:30 in the morning, but I finally got portals to work!

portals

It’s not perfect. There are a few issues I need to sort out:

1. You can see that there’s a flash right at the moment when you walk through the portal.

2. You have to be facing the portal in order to go through it (can’t walk backwards into it).

3. You can’t carry objects with you through the portal.

4. Still need to set up portals to teleport between different Unity scenes.

I’m not too sure how to approach these issues yet, except for the last one. I believe I can pull off portals between Unity scenes with additive asynchronous level loading. I think the problem of carrying objects through the portal will be the most difficult one.

However, pretty happy to have gotten portals working. They’re going to play a big role in the game.

DevLog Update – Saving System, Keys, and Bridge

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.

Stage-Map

Respawn System
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.

Key Switch
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.

rubiks_cube

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:

key_switch

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:

teleportation_doorway_opening

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.

Appearing Bridge
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:

bride_forming

And here’s what it looks like now:

bridge_forming_2

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.

DevLog Update – Decals

The last 2 days have confirmed my theory that it’s the most trivial parts of a game that end up being the most time-consuming and tedious to implement.

I cleaned up the code for the Teleportation Doorways, and started to replace the old teleportation areas with this new element. However, I started to notice this very weird bug: the decals around the archway of the door, which show how many keys the player has obtained, and how many are needed to open the door, would fade in and out of visibility.

The way the decals for the door works is that I have 12 of them responsible for the key lights. 6 of them show how many keys are required, and 6 of them show the number of keys the player has.

The decals showing the required number of keys are off-set from the mesh by 0.01. This is because if there is not offset, there ends up being a strange flickering effect because there are 2 meshes overlapping and the engine doesn’t know which one to render.

Then, because the decals showing how many keys the player has need to be shown on top of the decals showing required number of keys, they are off-set by 0.02, show that they are rendered over the other decals.

However, I was noticing a problem where, if I stood at certain angles, some of the decals showing how many keys the player has would become invisible. I double checked the code, and the logic was all correct. As far as the element was concerned, it was detecting the right number of keys, and had the right requirement number. From this, I determined it was just a problem with the decals.

I started to play around with the different settings of the decal projectors: size, culling angle, position, affected layers. Eventually, what I found was that the decal for the required keys and the decal for the number of keys the player has, cannot overlap. Despite having the mesh off-set values be different, if the decal projectors overlap, there ends up being some kind of a problem.

This is what the set up for the decals look like now:

decals_setup

You can see that the decal projectors (represented by the capital D with three lines next to it), are off set from each other.

Not the most satisfactory solution, as I still don’t know what was going on. However, it has solved my problem for the moment, and I’m just glad I can move on and work on other aspects of the game.

DevLog Update – Doors, Keys, and Larger Design Problems

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

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.

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:
Relativity_Game_Screenshot-2014-01-21_01-41-56

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.

DevLog Update – Progress Checkpoint System, Puzzle 1 Redesign

Player Rotation Saving

In the last update I talked about how I was having trouble saving player rotation using Unity’s PlayerPrefs. I was using euler angles at first, but was getting some weird bug, so decided to use another system involving grabbing quarternions from various objects already in the scene.

As it turns out, euler angles is the correct solution (you were right, cjacobwade). The reason why the weird bug was happening was because in saving the player position, there was a typo in the code, and I was saving the Y coordinate as the Z coordinate, so the player was being respawned at a completely different location, without any ground beneath him, which resulted in the weird rotation (I have some code that uses ray tracing to detect the surface normal of the ground in order to determine which gravity field is on, and it requires the player to start the game with ground beneath him).

Game Progress Checkpoint System

I’m also working on a system to keep track of player progress throughout the game. Right now, the structure of the game is like this: There are a number of large open areas, called hubs. Each hub contains entrances leading to independent puzzles. So, for each hub, I assign a number that’s basically n x 1000, for example, hub 1 is 1000, hub 2 is 2000, etc.

Then for each level that the branches off of a hub, it gets a number that n x 100 plus the hub number. So independent levels branching off of hub 1 are 1100, 1200, 1300. Of course, this limits each hub to only 9 levels, but the way I’m structuring the game, each hub only has between 3 – 7 levels branching off.

Then items inside each level, are labelled 1101, 1102, etc. This way, it allows me to keep track of which doors the players have opened, which triggers have been pressed, and which area they’ve already visited.

I’m not totally set on this system yet, as it has its obvious limits. But we’ll see. I think it’s enough for now.

Puzzle 1 Redesign

Continuing the mission of redesigning earlier parts of the game, I’ve been working on redesigning the first puzzle. One of the major changes is that I actually combined two puzzles into this one. It used to be split into puzzle 2 and puzzle 3, but after watching playtesters go through these levels, I realized the two, while different, were sort of testing around the theme, with the latter being an application of something learned in the former. It made more sense for them to be together.

Here are some images:
Relativity_Game_Screenshot-2014-01-19_00-25-57

Relativity_Game_Screenshot-2014-01-19_00-34-03

Relativity_Game_Screenshot-2014-01-19_00-33-36

Relativity_Game_Screenshot-2014-01-19_00-35-03

Teleportation Doorways

Starting to add these entrance areas I’m calling Teleportation Doorways to the levels. Basically, they teleport you from one level to another. They’re really placeholders until I get portals working. Ideally, I’d like the whole world to appear seamless.

Relativity_Game_Screenshot-2014-01-19_14-15-35

DevLog Update – PlayerPrefs, Respawning

Been a little while since the last update. As mentioned last time, still dealing with lots of boring bureaucratic related stuff, so haven’t had as much time to work on the game.

Today I’m starting to work on a position saving system so that players can respawn after falling off platforms. It’s a little bit tricky though as I need to save the player’s rotation as well, but Unity’s playerprefs doesn’t allow you to store quaternions.

It’s turning out to much more difficult than I had originally imagined.

Here’s a picture of a scene with the respawn triggers turned on:

RespawnTriggers