Separate Game Settings from the GUI Gamesetup
Split the gamesetup in two: the 'GameAttributes' part into gamesettings/ and the GUI/Presentation part in gamesetup/. This makes it easier to separate the presentation from the data.
The immediate benefit is that campaigns & autostart scripts don't need to load the gamesetup folder at all. This also makes it much easier for any modder that would want to to change the GameSetup itself.
Each 'game attribute' is given a unique class extending GameSetting (with a few exceptions), in charge of:
- 'Serializing' to the JSON-compatible 'InitAttributes' format, which is used for persisted settings, network synchronization, map script settings, hotloading.
- Deserializing from the same format.
- Watching for settings it depends on (such that e.g. unexploring the map also unreveals it).
The GUI controls remain in charge of presenting the state accurately, however they now directly subscribe to changes of the GameSettings for update. The updating logic in general has been lightened on the GUI side, making it more straightforward to know when something will update, and reducing un-necessary computations (in theory - in practice, I believe the gamesetup was already fairly good about this).
The 'Controller' class of the gamesetup have also been lightened, since more responsibility now lies with GameSettings. In particular, this include code to actually launch a game.
In general the GameSettings class is permissive - the GUI gamesetup has tighter restriction for what the player can/cannot modify. This is intended to give flexibility for campaign maps, which may want to change arbitrary settings.
Further work would be useful, non-exhaustively:
- the setting of default values remains messy. They currently exist somethings in GameSettings, sometimes in the GUI gamesetup, and in the simulation itself (in case attributes are not set).
- the availability and 'lockedness' of settings remains a work-in-progress.
- some attributes, like disabled technologies, should probably be removed and triggers used instead.
- the Handling of AI and player-specific data could be improved.
- settings Persistence should follow its own path - not all settings are worth persisting.
- GAIA settings are added simulation-side but not in the GUI, which is confusing.
Thanks langbart & Freagarach for testing.
Follows the gamesetup rewrite in rP23374.
Refs #3049
Differential Revision: https://code.wildfiregames.com/D3243
