Context Pattern

A very common design pattern I see frequently in game engines is the singleton pattern. The singleton pattern is inflexible and flattens the engine structure into an unorganized set of systems. For example, an architecture where all systems are singletons could be imagined to like this:

A better way to store the systems would be in a hierarchy. Arranging the systems like this inherently forms relationships that dictate how they should interact:

For example, if the level system needs to be restarted, then the physics system does too. With singletons you would have to manually restart both in the correct order, but if they were in a hierarchy with level --> physics, resetting the level would inherently reset the physics.

Unfortunately, however, hierarchies miss out on one important benefit that singletons provide, being that they can be accessed from anywhere easily. Placing systems in a hierarchy tends to make it needlessly difficult to access them:

// Singleton
asset_browser::get_instance().refresh();

// Hierarchy
get_engine().get_asset_manager().get_asset_browser().refresh()

Not only is it tedious but it also requires the user to know how the hierarchy is laid out. Additionally, if for some reason the layout needs to change, all occurrences of this hierarchy traversal would break.

I decided to combine the logical hierarchy with the easy access of singletons into a single pattern called context. context exposes a single mutually exclusive instance of any class through a function template, e.g.

context<asset_browser>().refresh()

Along with the context access function, Fields Engine also provides multiple class templates for automatically and/or manually managing the state of the context:

// Holds an owning heap allocated pointer (basically a unique_ptr) to the object
own_context<T> 

// Stores the object internally
local_context<T>

// Holds a non-owning pointer to the object
manage_context<T>

These can be used to create a hierarchy of objects that manage the present context automatically so that any context-available class can always be accessed from anywhere just using the context function.