Save Game
For Sprint 3 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 and game state to some degree. Due to the sheer complexity and dependencies involved Save Game encounted significant issues which are discussed below in the issues arose section.
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()
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/landscape_objects/leftPalmTree.png
position: {
x: 936
y: -9.449275
}
name: Tree
}
{
class: com.deco2800.game.files.Tuple
texture: images/shipWreckBack.png
position: {
x: 1064
y: 38.8
}
name: ShipwreckBack
}...
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
texture: images/Wall-right.png
position: {
x: 972
y: 14
}
name: "wall(59, 62)"
}
{
class: com.deco2800.game.files.Tuple
texture: images/Wall-right.png
position: {
x: 988
y: 14
}
name: "wall(60, 63)"
}
]
Current details for the game state are saved by direct serialization of the objects and reloaded back into memory overriding all objects as needed. Currently this has only been implemented for the game clock service and takes the below form in the Saves/GameData.json file:
{
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
}
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.
Throughout this sprint many iterations and attempts to save the game have been attempted. While the final solution is simple the journey to it was complicated with many hours spent trialing, erroring and debugging. 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 2/10/2022 below.
AtlantisSinks.2022-10-02.14-33-13.mp4
Some things to note is that load/save works completely with the exception of game clock and linking to the shop. The shop has some issues with itself as it is an entire new game area but for some unknown reason wipes all of the services and reconstructs them. This breaks the links between event setups for most of the implementation of the game and requires reworking for full integration and is not a fault of load/save game. This can be seen by the fact the structures are loading as expected which utilise the structure service while all other entities are wiped that use the entity service. For reference the issue is in the ShopBuildScreen which has been put below for context which wipes all critical services. This makes limited sense and requires rewriting as the point of the entity services to act as a point of global truth resetting them like this causes signifcant issues to arise.
public ShopBuildScreen(AtlantisSinks game) {
this.game = game;
logger.debug("Initialising main game screen services");
ServiceLocator.registerTimeSource(new GameTime());
PhysicsService physicsService = new PhysicsService();
ServiceLocator.registerPhysicsService(physicsService);
physicsEngine = physicsService.getPhysics();
ServiceLocator.registerInputService(new InputService());
ServiceLocator.registerResourceService(new ResourceService());
ServiceLocator.registerEntityService(new EntityService());
ServiceLocator.registerRenderService(new RenderService());
renderer = RenderFactory.createRenderer();
renderer.getCamera().getEntity().setPosition(CAMERA_POSITION);
renderer.getDebug().renderPhysicsWorld(physicsEngine.getWorld());
loadAssets();
createUI();
MainArea.getInstance().setMainArea(new ShopArea());
logger.debug("Initialising main game screen entities");
TerrainFactory terrainFactory = new TerrainFactory(renderer.getCamera());
}
