Change Details

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

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 ---- Design questions that remain open after this rewrite: - Map settings are not systematically picked when switching a map (except for scenarios). The 'flatness' of the settings make this a hard problem - Who should be in charge of default settings? Currently it's kinda half and half. I think it's mostly a GUI concern, but the gamesettings should probably implement sane defaults - Who's in charge of saying what's possible? I've gone with the assumption here that GameSettings should generally allow 'impossible' settings and the GUI would be more concerned with what ought be possible. In particular, this means GameSettings only kinda cares if the game map type is skirmish or scenarios. - In general the whole concept of 'map types' seems like a GUI concern to me. Scenarios are just skirmish maps without skirmish entities. I see no reason why we couldn't have random maps with 'locked' settings, for e.g. campaigns. Overall this reeks of hardcoding and I hate it :p. Other open questions: - Should it be possible to add actual settings for GAIA? Not currently implemented

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 ---- Design questions that remain open after this rewrite: - Map settings are not systematically picked when switching a map (except for scenarios). The 'flatness' of the settings make this a hard problem - Who should be in charge of default settings? Currently it's kinda half and half. I think it's mostly a GUI concern, but the gamesettings should probably implement sane defaults - Who's in charge of saying what's possible? I've gone with the assumption here that GameSettings should generally allow 'impossible' settings and the GUI would be more concerned with what ought be possible. In particular, this means GameSettings only kinda cares if the game map type is skirmish or scenarios. - In general the whole concept of 'map types' seems like a GUI concern to me. Scenarios are just skirmish maps without skirmish entities. I see no reason why we couldn't have random maps with 'locked' settings, for e.g. campaigns. Overall this reeks of hardcoding and I hate it :p. Other open questions: - Should it be possible to add actual settings for GAIA? Not currently implemented