mirror of
https://github.com/yairm210/Unciv.git
synced 2025-01-09 06:46:51 +07:00
28 lines
2.0 KiB
Markdown
28 lines
2.0 KiB
Markdown
|
# Saved games and transients
|
||
|
|
||
|
Unciv is a game where many things are interconnected. Each map unit, for example, belongs to a *civ*, is located on a *tile*, can have several *promotions* and "inherits" from a *base unit*.
|
||
|
|
||
|
When saving a game state, we want it to be as small as possible - so we limit the information saved to the bare minimum. We save names instead of pointers, and anything that can be recalculated is simply not saved.
|
||
|
|
||
|
But during runtime, we *need* these links for performance - why perform a lookup every time if we can save a reference on the object?
|
||
|
|
||
|
Classes are therefore *freeze dried* on serialization, and *rehydrated* for runtime. Since these fields are marked in Kotlin as @Transient fields, we call the rehydration function `setTransients`.
|
||
|
|
||
|
Take the map unit for example. How can we calculate the uniques for that unit? They can come from several places:
|
||
|
|
||
|
- Base unit uniques
|
||
|
- Promotions
|
||
|
- Civ-wide uniques
|
||
|
|
||
|
So from the save file, we get the civ name, unit name, and promotion names; for runtime, we'll want a reference to the civ, base unit, and promotions.
|
||
|
|
||
|
We can find these by looking up the civ in the game, and the unit and promotions from the ruleset.
|
||
|
|
||
|
The civ itself - a game object - references the nation - a ruleset object, which is another link. The base unit references the unit type, another link.
|
||
|
|
||
|
The nation, base unit, and promotions, all contain *uniques* - which are saved as strings. For performance, these too get saved at runtime as Unique instances - which contain the unique type, the parameters, conditionals, etc.
|
||
|
|
||
|
Beyond the fact that each ruleset object retains a "hydrated" list of its uniques, the unit's uniques don't change very often - so we can add *yet another* layer of caching by saving all the unit's uniques, and rebuilding this every time there's a change
|
||
|
|
||
|
All of this is VITAL for performance - Unciv is built to run on potatoes, and even hash lookups are expensive when performed often, not to mention Regexes required for Unique parsing!
|