Hello, Everybody seems to agree that game.cpp is bloated and inflexible in its current form. I prepared a list of responsibilities that game.cpp is taking care of (together with functions doing the jobs):
0. Starting and initializing the game (main(), do_gameloop()) a. Setup of environment (launching SDL, loading fonts...) 1. Parsing command line (game_controller::game_controller(), game_controller::play_multiplayer_mode(), process_command_args()) 2. Running the game_loop (do_gameloop()): a. Controlling titlescreen and tips of the day b. Playing music c. Maintaining jumps caused by choices on title screen 3. Parsing the whole game config (everything in data/ and user addons/ directory) (game_controller::load_game_cfg()) Note: this is the part which makes game.cpp gamestate-dependant. Most of the things it parses should be moved into game_instance.cpp a. Showing loading screen b. Generating data tree checksum which isn't used (? - correct me if I'm wrong) c. Parsing data/ directory inside a locked transaction into cache_ d. Calling functions to find user campaign directories in filesystem and parsing *.cfg in there as well e. Extracting preload scripts from [lua] from lua.hpp f. Setting color range and color palette (it stays in the game_config) g. Generating multiplayer hashes h. Calling unit manager to initialize unit types i. Setting terrain rules of terrain_builder j. Initializing "certain English strings" 4. Starting multiplayer games (game_controller::play_multiplayer()) - sets the ground for launch_game() a. Creating a new, empty game_state and filling it with multiplayer defines b. Calling multiplayer type (local, lobby...) creation dialog c. Calling load_game_cfg() to reparse all the multiplayers scenarios d. Choosing the correct multiplayer server to connect to e. Calling mp::start_client(), passing the whole game_config_ as a constant WML object to the creation functions 5. Starting campaign games (playcampaign.hpp:play_game()) a. Receives reference to game_controller::game_state_ and constant ref to game_config_ b. Determining whether received game_config and gamestate belong to a snapshot or a new game, multiplayer or campaign c. Assigning sides to side controllers based on ids d. Generating random data for the scenario if needed e. Calling playmp_scenario() or playsingle_scenario() based on what the scenario type in gamestate is. The only significant difference between these two functions is creating different type of controller class (playmp_controller vs playsingle_controller) to pass the control later on. f. Depending on the game result (LEVEL_VICTORY etc.), loads next scenario, restarts current and such. 6. Launching game (game_controller::launch_game()) a. Showing loading screen b. Parsing campaign defines and extra defines and updating state_ with them c. Reloading the whole config via load_game_cfg() once again after parsing campaign defines d. Running binary paths manager (didn't look into this one yet) e. Using a magic trick with load_game_exception which I don't yet understand ;-) Some notes: * the same name for game_config_ (game_controller class member variable), and game_config:: namespace got me really confused in the beginning. I'm pretty sure there are a few more occurences of game_config in code, as well. Not to mention preferences:: on top of that, which also contains some settings. Maybe some renaming could be done... Since currently game_config contains both game_instance-relevant data (such as units, difficulty, scenarios, campaign name and stuff) as well as contents of [game_config] from data/game_config.cfg (which contains game configuration relevant for every game, no scenarios, campaigns etc.), it just keeps getting confused when discussing... Some ideas for renaming, any other suggestions? The goal is to have a flexible loading system, which could reparse the whole config (or maybe even only the necessary parts, if somebody has a decent idea how to implement it) from any point of the code. Currently, it's impossible to add a global #define outside of game.cpp without heavy hacking. We have at least two good candidates which would welcome this more flexible define option - namely MP campaigns (or any add-on scenario content) and eras, which could easily have their own #define domains then. With this goal in mind, I think the responsibilities of points 3, 4, 5, 6 (or at least most of them) should be shifted out of their current places. More details will probably come in following e-mails, as the development progresses. The current plan to achieve this goal is to create a game_instance class, which will hold the campaign specific WML data (3c) and take care of switching scenarios (5). After moving out of this responsibilities to this class, it will be more feasible to pass this class around to mp game creation screen, which will be able to define the relevant defines (6b). As for the first steps... I'm not really sure yet. I tried the aggressive approach, that is, trying to move the whole load_game_cfg() to game_instance... and failed. This thing just had too many dependencies. Currently we're working with boucman to come up with an alternative solution, I'll post an update on the ml once we get an agreement. Any suggestions are again most welcome. Cheers, Zaroth PS (For those of you who want to follow up with everything: lots of the refactoring ideas were discussed on IRC: http://www.wesnoth.org/irclogs/2011/05/%23wesnoth-dev.2011-05-12.log http://www.wesnoth.org/irclogs/2011/05/%23wesnoth-dev.2011-05-13.log and the more recent ones (23-25.05) Crab_, boucman, fendrin, zaroth)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
