Let’s start with a recap of my week first, shall we? On Monday, I felt like a bit of a cold is trying to set in, but I soldiered through work somehow. Then, Tuesday hit and I was coughing my lungs out, so I decided to go to my doctor. Turns out, I had to take antibiotics for a week and I felt sick as a dog for the first half of that time. So, progress this week was a bit slower than I anticipated and I had to change the scope of my weekly work a bit. This is also the reason this week’s devlog is a bit late.
However, I did complete two major parts of the game that have been plaguing my mind ever since I started the project and I managed to implement all of the offensive spells (or at least their most basic form). I will not get into much detail regarding the spells right now, so let’s jump straight to the not-so-fascinating bits that I want to discuss in today’s devlog.
Additive Rooms Loading
Ever since I started the project, I knew that I want to make the world as seamless as possible and have it accessible to the player at all times. The obvious answer to this would be to load the entire world all at once and keep it loaded. However, as most of you probably know, this would be a major hit on performance. Furthermore, it will create some complications with respawning cannon fodder enemies and other such features.
So, instead, the best way to move forward appeared to be additive scene loading. This would allow me to keep only a handful of rooms loaded and unload the ones that are currently inaccessible or too far away from the player. When a player moves to a new room, the neighbouring ones would get loaded. At the same time, the ones that become irrelevant get unloaded.
This approach has two main benefits:
- It allows me to not worry about respawning enemies. When a room is unloaded, then loaded back in, enemies also get automatically loaded into the game, as they are part of the scene.
- It saves a lot of processing power. Having just two rooms loaded, instead of 200 is obviously 100 times better (figuratively, of course).
However, this approach also creates some problems. First, and foremost, how do I make sure that bosses do not respawn? Also, what about permanent player upgrades that should only be picked up once? This is where the save system comes in.
The Save System
I managed to lay the foundations for the save/load system this week. Basically, there is a single static class that tracks the player’s progress. This tracks what cards and upgrades they have collected, what bosses they have defeated, and so on. When the player hits a checkpoint, a serializeable object is created. This is then serialized and saved to a file on the player’s hard drive. The file contains all of the progress information, as well as some additional data, such as the checkpoint ID.
Each checkpoint has its own specific ID, corresponding to the ID of the room it is in. This way, when the game has to be loaded again, the save system can simply grab the checkpoint ID and load the room with the same ID, instead of starting from the very first room again.
Permanent upgrades and bosses also have unique IDs. They are also based on the room ID. However, they follow a different structure, as there might be more than one permanent upgrade in the same room. So, when the game loads a room with a permanent pickup in it, it checks the progress class whether it was already collected. If yes, it destroys it in the first frame of the room’s existence and the problem is solved.
Closing Words
I know this was not the most exciting devlog ever, but that’s part of the process. Sometimes, we have to take care of the fundamentals before we make flashy and cool stuff on top of that.
Anyway, thanks for reading and if you have any questions before the next devlog, feel free to reach out on Twitter (@dsm_dastmo) or via my homepage‘s contact form.
