Description
Forcing users to use Utility forces them to use global variables. We should move towards a design that doesn't force certain core game components to be globals.
Additionally, including Utility.h is a bit of a heavy include, bringing in a number of standard library headers, which aren't that fastest to parse. Not being reliant on Utility.h may mean faster compiles.
Currently there is a Game object, which is a natural place to access the core components from. We could write accessor methods on it, which for now use Utility internally. That would allow for a transition path, where client could could start to use the Game class to access those components. Once all references are switched over, we can update the Game class to own those components, rather than access them through Utility.
We should maybe consider renaming Game to Application. The name "Game" may be a bit overloaded. Most games have a menu screen that allows you to load a "Game", where the menu screen is part of the application, but not part of what many people would call the "game".
Related:
- Issue Reduce bloat #1245