Separation of configuration data and runtime state

Issue #14 new
Jake Albano
repo owner created an issue

This is a big shift that would be good to implement sooner than later.

Currently there's an awkward ambiguity between what is configuration and what is real live data. The Window class is probably the worst offender: Before the app is started, the value set forInternalResolution will be used when the render surface is initialized, but setting it after the fact has zero effect whatsoever.

The approach I want to take on this is to define a Config class for every engine subsystem -- WindowConfig, RendererConfig, and so on (to includeEngineConfig of course). These types would be serializable and it should be clear that modifying them would have no effect after the application starts up.

This pattern can be applied to other areas of the API besides the engine subsystems -- a prime example would be Spritemap animations and Particle definition instances.

Comments (0)

  1. Log in to comment