Save Game

Save Game Overview

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 Implementation

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()

Envirnonmental Obstacles

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

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)"
}
]

Player

Crystal

Issues Arose

Testing

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.