The gamestup rewrite in rP23374 opened an opportunity to split the "game logic" of the gamesetup and the "view logic" of it. The GUI should mostly be concerned with presenting the gamesetup, and the data should not be stored there.
It's _technically_ not, because it's in a structure elsewhere, but the available settings & the format is tied to the GUI code which is annoying.
In particular, this makes it really difficult to programmatically create game settings without loading the gamesettings GUI. It's not great.
This diff implements the GameSettings as a separate object, responsible for handling its own state and deserializing/serializing to the older format (for compatibility). The scope here is solely the GameSetup, everything else retains g_GameAttributes. The exception is gamedescription.js which is common code.
GUI-only data is made explicit. As things stand, that's only MapFilter.
The separation of responsibility becomes as such:
- g_NewGameSettings handles the gamesetting data, adjusts automatically for incompatible settings, etc. ATM, it handles persistent settings parsing & map settings parsing.
- GUI Gamesetup is responsible for presenting & GUI behaviour (swapping players, default AI, ...). The Player assignments remain here too.
This draws the beginning of a larger refactoring:
- The GUI Gamesetup should probably be cleaned up a bit further: there are controllers (gameSettingsControls, playerAssignmentControls), a lot of pure view stuff with some control embedded
----
I can essentially quote from the original gamesetup rewrite 'lays the groundwork for':
> UI to control per-player handicap
> Map specific settings
> Multiple controllers setting up the game
> Multiplayer saved games