Save Game
For Sprint 3 and 4 Team 4 decided to implement the save game functionality for the game. This was done to help encourage and facilitate players to play the game without having to worry about progress or having to finish the game in a single sitting. The save game is one of the most complex systems present having to be dependent on every single other system and having the ability to retrieve and load relevant information as needed.
Currently save game functions for loading environmental obstacles, structures, player, crystal, game night and enimeies. Since sprint three many issues and problems have been ironed out allowing for save game to fully functional.
Save State Design Introduction
In terms of design we focused on designing a user interface for the Save and Load game functionality. To achieve that we deployed several user testing sessions along with surveys and interviews to collect data and refine the idea. That way we made sure that the Save and Load state went beyond designing a set of pretty buttons. Overview of the UI Design progress for the Save and Load Game is available here.
Save Game generally functions by using JSON serialization of objects and their respective properties as needed. This meant that customs methods and functions were written for each of the below features. General save location is in assets/Saves/ where there is multiple json files labeled environment, game state, structures etc.
As the SaveGame is a static class, the game state can be saved and located at any point via the two static methods saveGameState() and loadGameState()
Since sprint three the main focus was fixing Save Game to account for the newly UGS system and to generally simplify the SaveGame pipeline in a general code cleanup. The main improvements since sprint 3 is the use of stack tracing where the creation name of the method is stored dynamically into the json serialisation file for each saved entity. This has two big new beneftis
- Refractoring of code will not break the invocation scheme allowing save game to be more robust
- significantly cleaner method then previousally hard coded hashmaps and invocation
From the UGS perspective more details are required to be saved for entitiies. Including the tile position. When loading UGS now must be used in very specific ways and order. Many issues were encounted here from concurrency issues to rendering issues.
The pipeline for saving Environmental obstacles this was that every entity was searched for a environmental component and texture component and if an entity had these two things it was deemed to be an environmental obstacle. From this point critical data was loaded in a Tuple class which stores the name, texture and position of the environmental obstacle. Environmental obstacles were then saved via Json serialization of their attributes into an ArrayList.
The Json file for environmental objects is Saves/Environmental.json and follows the format:
[
{
class: com.deco2800.game.files.Tuple
texture: images/seastack2.png
position: {}
name: Rock@92
tileString: "0,0"
creationMethod: createRock
}
...
]
To load environmental objects the array list is unserialized and a brand new entity is spawned based off a class method invoke system. The details of the object are then updated and corresponding attributes set. This was done to ensure future compatability with changes to the environmental obstacles.
Structures work in a very similar way to environmental obstacles. The pipeline is that all structures are saved from the Structures entity service where their name, position and texture are saved into a tuple class for each unique structure which is put into an array list and serialized via json. The Json file is in Assets/Sabes/Structures.json
The file follows with the loading method working identically to environmental objects just with different attributes and invocation methods:
[
{
class: com.deco2800.game.files.Tuple
position: {
x: 936
y: -4
}
name: "wall(59, 58)"
tileString: "59,58"
creationMethod: createWall
}
{
class: com.deco2800.game.files.Tuple
position: {
x: 944
y: -8
}
name: "wall(60, 58)"
tileString: "60,58"
creationMethod: createWall
rotation: 1
}
]
The player is saved by serialising a dictionary of relevant values, along with the standard attributes (position, etc.). When loaded back in, the existing player entity in the game area has its attributes adjusted, rather than destroying and recreating the player. This limits LoadGame() to being called only after the player (and crystal - see below) have been initialised, but minimises the complexity of the save and load process, and prevents LoadGame() from having to access private methods and attributes in the main GameArea class unnecessarily. The player serialisation is below. It stores the player position, gold, inventory, health, and combatStats:
{
position: {
x: 964.45306
y: 0.11982894
}
name: player
playerState: {
gold: {
class: java.lang.Integer
value: 55
}
weapon: null
chestplate: null
defence: {
class: java.lang.Integer
value: 10
}
attack: {
class: java.lang.Integer
value: 10
}
helmet: null
health: {
class: java.lang.Integer
value: 78
}
wood: {
class: java.lang.Integer
value: 50
}
items: {
class: java.util.HashMap
}
stone: {
class: java.lang.Integer
value: 50
}
}
}
Initially, we considered using the existing Memento and CareTaker classes to save and load player state, but these classes were difficult to serialise and often buggy when called from SaveGame. This would be a valuable avenue for future work, however
Saving and loading the crystal works nearly identically to saving and loading the player, but less complex. Like the player, the crystal can only be loaded in after the crystal entity has been initialised in GameArea
When loading the crystal back in, if the crystal level is larger than 1, this level is applied by repeatedly calling the upgradeCrystal() method in CrystalFactory, which ensures the state of the terrain is also updated.
{
texture: images/crystal.png
position: {
x: 964
y: 2
}
name: crystal
level: 1
health: 1000
}
The Game State comprises the 'DayNightCycleService' and associated features (i.e. 'DayNightClockComponent', attached to the UI entity). The DayNightCycleService details are saved through direct serialisation:
{
currentCycleStatus: NIGHT
lastCycleStatus: DUSK
currentDayNumber: 1
currentDayMillis: 106252
isStarted: true
config: {
dawnLength: 15000
dayLength: 60000
duskLength: 15000
nightLength: 30000
maxDays: 4
}
timer: {
startTime: 1664686569471
}
timeSinceLastPartOfDay: 220547
timePerHalveOfPartOfDay: 15000
partOfDayHalveIteration: 2
lastPartOfDayHalveIteration: 2
}
Though saving is simple, loading was decidedly more complex.
After extensive discussion with Team 9 some modifications to the DayNight Service is required as it was not designed with the ability to load and reset a clock to a specific time point. This is due to the use of the service using the computer's system clock so when resetting the time the clock is instantly overridden by the service itself. This requires a rewrite of the Run function within the DayNight Service.
The biggest problem faced is that it is impossible to serialize the objects directly. This is due to the fact that most objects reference themselves indirectly so when a json serialziation is attempted, stack overflow will ensue. For example take a entity. If you attempt to json serialize then the engine will attempt to save everything within the entity including the components. When saving the components though as the components store the entity the engine attempts to save the entity once again causing a never ending loop of serialization.
This issue has been mitigrated via two methods, the use of adding transient to attributes to stop serialization but this is slow process and requires extensive debugging and makes loading the object difficult. THe other method to store all relevant details, recreate the object and set the details which was the chosen method for most of the above implementations. The issue with this is that compatability is an issue and if new features are added this typically requries a modification to the save method. Due to this it is unreasonable to expect a fully functional save/load game without adequate time for method rewriting and bug fixing.
Due to the complexity of save game significant unit testing was conducted with 15+ units tests and over 700 lines of code written to test indivdual saving, loading and full save/load pipeline. Specifically these tests work by establishing a full recreation of all the services and attempting to spawn and save a predertermined number of entites and types of entites such as structures or environmental obstacles. This is useful as it ensures functionality should be adhered to when other teams merge their content.
The current load/Game state functionality can be seen as of 16/10/2022 below ON MAIN BRANCH.
During Day, Structures and Environmental Objects: https://user-images.githubusercontent.com/87936020/196016774-ab807758-fce3-4fd1-ab00-b00bccae71b3.mp4
