This is an automated archive made by the Lemmit Bot.
The original was posted on /r/godot by /u/Fysco on 2025-01-20 10:09:46+00:00.
What I mean by "global game state" is all game data relevant for a playthrough. for example inventory, score, health, progress etc.
Let's take a look at the standard way of working: In an object oriented language such as C# or even GDscript we manage data by instancing classes as objects. These objects carry data about themselves. Which is very convenient for us to work with: This way we encapsulate data to stay WITH the entity it belongs to and we can grab data of any object. For example: The player will have all its data on itself: player.health, player.ammo, player.apples, etc.
The problem is that our game data gets spread across many objects. If we want the player to save their game progress, we now have to go collect all this data from all these different objects in memory. It can get very complicated.
The idea of a global state: Instead of keeping data within the objects, we store data to a single repository which can be saved and loaded by itself entirely. All to-be-saved game data should be stored and fetched from this repository; meaning that the objects themselves do not carry their own data.
Let's say we do this with a singleton autoload GameData. We should load that class up with dictionaries and vars of everything we want to be able to save/load. Instead of player.ammo, we will store it in GameData.Player.Ammo. All inventory data will be stored in GameData.Inventory for example. On the actual inventory class, we can have Inventory.GetItem() methods like we do now, but those methods will talk to the GamaData class under the hood.
Centralized data is easier to store, and we use that paradigm in applications where data storage is key. If we can design a good GamaData class with clear separation, I feel like that would benefit us greatly when it comes to saving/loading games. Especially games with a lot to save; such as base builders or puzzle games.
Thoughts?