EngineRefactor

From The Battle for Wesnoth Wiki

This is a page that I will use to organize my thoughts about how the engine looked before I began and how I would like for it to look ultimately.

Feel free to edit but please leave discussion / remarks in the talk page, and sign with three tilde's ~ ~ ~ to get your name and timestamp. Iceiceice (talk)

Object ownership hierarchy

List indicates composition ownership, and I'm only depicting the objects whose lifetime is within that of the play controller. (This ignores the editor.)

Current tree:

  • play_controller
    • units (unit_map)
    • game_map (gamemap)
    • teams (std::vector<team>)
    • game classification
    • game data (carryover + wml variables, approximately)
    • game state
    • TOD manager (manages current times of day and also time area regions, and the turn count)
    • pathfind manager
    • sound source manager
    • undo list
    • whiteboard
    • lua kernel
    • persistence manager
    • game display (game_display singleton)
      • terrain_builder
    • halo manager
    • floating labels manager
    • tooltip manager
    • help manager
    • game event manager
    • mouse event manager
    • menu event manager
    • statistics


Suggested tree:

  • play_controller
    • game_logic <-- contains all info constituting "state of the game"
      • game_board
        • game_map
        • unit_map
        • teams
        • pathfind manager
      • tod manager
      • game_data
      • game_state (merge into this most likely or to game_data)
      • map_labels manager
      • sound source manager
      • statistics
    • visual items manager
      • item manager
      • fake units manager (currently in game_display)
      • halo manager
      • floating labels (non map labels) manager
    • game display (tied to the visual items manager, and perhaps holding state in a "game_view" object.)
      • terrain_builder
    • undo list
    • whiteboard
    • lua kernel
    • persistence manager
    • tooltips
    • help

Resources

Most of the above objects can be accessed from raw pointers from the resources namespace. This is unfortunate -- it means that our full in-game datastructure is quite far from being a tree, which is the preferred configuration to take advantage of automatic deletion and avoid dangling pointers, and that if we try to swap objects in the above hierarchy in or out (say, if the editor reloads a map, or if the replay viewer tries to reset the state, or if the AI tries to make an experimental sequence of moves and then reset to the original state), then we get tons of dangling pointers and must carefully reset all of the resources links and other residual pointers.

It would be much better if instead,

  • The resources:: pointers were const, to improve encapsulation
  • The resources pointers were not raw pointers, but wrappers which call methods of play_controller, which is the object that properly owns these, (or a child of this), so that they might self-update.

Since we began we have made some progress, removing the pointer to "state_of_game" and replacing with const pointers to mp_game_settings, and we've made the game_map pointer const. It would be very good to make as many of these const, or removed altogether, as possible.

This page was last edited on 10 June 2014, at 19:55.