The recent 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, The GUI should be concerned with presenting the gamesetup data,everything else retains g_GameAttributes. not handling what happens when one changes a settingThe exception is gamedescription.js which is common code.
The current approach is a dead end: one cannot easily change the game attributes without the GUI, nor even know the structureGUI-only data is made explicit. It is also difficult to parse a the game attributes to initialise the GUI (see match settings troubles).As things stand, This is all especially problematic for the campaignsthat's only MapFilter.
This new approach, which I intend to gradually implement, will decouple the model and the view in MVC parlance, and will be serialization-compatible so that the JSON gamesettings and the 'gameSettings' object are synchronised. The GUI will only show the relevant data.e separation of responsibility becomes as such:
I use proxies to automatically register watch- g_NewGameSettings handles the gamesetting data, adjusts automatically for incompatible settings, etc.
- GUI Gamesetup is responsible for presenting & GUI behaviour (swapping players, and trigger them when a setting changes.default AI, This is an opt-in approach like the current one,...). but results in cleaner codeThe Player assignments remain here too.
This makes it plausible to create a new GUI for game setting attributes without having to rewrite most of the logic, and also makes it easier to programmatically create settings.draws the beginning of a larger refactoring:
(it also happens to flatten all game setting options in one place- The GUI Gamesetup should probably be cleaned up a bit further: there are controllers (gameSettingsControls, playerAssignmentControls), but that's a bit of a side-effect)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