Been a rough week everyone?
An inside look on how our game is being coded!
Sadly this isn't exactly the eye candy that you guys enjoy, but stick in, you might just learn something or get ideas for your own projects!
For Barthory Mansion we are implementing for the first time a level streaming system and, alongside it a Saving System. This comes from direct criticism of our play testers last year saying our previous game was too long and needed a way to save the game. The level streaming however came as a concern for optimization, of course certain areas don't need to be loaded when they aren't needed and well, this is a pretty big mansion so why have everything loaded?
So let us begin.
Level Streaming System
Since we are using Unreal Engine 4 we have our life done easy for us, Epic Games already has a level streaming system implemented in the engine, however, the bounding volumes to trigger events are locked to camera collision, and since we are using static/spline cameras things don't work very well out of the box, as such the solution was to make our own streaming boxes, the contain a list of levels that should be loaded and unloaded whenever the player enters and leaves collision.
Unreal might have the streaming done for us, but managing whats loaded and whats not is our job, thankfully a neat way of doing it is creating a subsystem for handling which levels are loaded and which are not. By using a subsystem loading a new level becomes easy for designers and for others who work with the project. Subsystems have to be coded in c++ but can be accessed in blueprints easily.
Saving System
Saving system is also done using a subsystem. It is linked to all actors and subsystems due to its controlling nature, when something changes, it needs to be recorded, however, whats funny is it also needs to undo changes, which, admittedly, can get tricky.
This becomes even trickier when you take in consideration that due to level streaming, certain actors are not present at all times and are instead unloaded. The solution to fixing this was to create a a base class for all interactibles and things needed to be saved, this base class has a BeginPlay() and EndPlay().
The Begin play is called whenever the object is loaded, so this object will only be loaded when the level streaming decides to load its corresponding level. The begin play checks if there is existing data for the object and if there is, loads it for itself and sees what state it was in. On the end play the data from the interactible will be saved on a temporary variable, that then will be passed to a permanent save as soon as the player decides to save the game.
Other values such as Current items, player location etc etc are also saved, but those are only saved manually.
In the above video, the player loads into a previous save, altering the current camera, position and items.
Well then, that is it for this week's post!
Well, we hope you enjoyed a little sneak peak on how things work under the hood, should interest arise, we can explain better what we have implemented and showcase other systems.
Until next time!
If you want to support us, leave a follow on our Socials, and share with a friend!
The visibility really does help us a ton.
Instagram: Instagram.com
Twitter: Twitter.com
Youtube: Youtube.com
