Building an Universal Lighting Manager for Games

At least three times on different projects, I’ve had to create a class that includes all the necessary components for lighting. It was used for dynamic day–night cycles, weather anomalies, and simple presets. Each time, I rethought and improved the system — simplifying it further and aiming to make it universal. I think now is the right moment to share my approach to organize the structure of this class.
I’ll start by saying that in my system, any lighting state is a “preset,” or an interpolation between presets when it comes to dynamic changes. Each preset is a data asset. Below, you can see the structure for storing the settings:

The function for updating the current components, the function for saving the current settings into a preset, the function for reading a preset, and the function for interpolating between presets — these are the foundation of the class. Everything else is specific to the individual project.

You can certainly light a level without a lighting manager. However, if your plans include many iterations and you need a flexible and predictable pipeline, you have to create a similar system. It will allow the gameplay logic to work with the weather on an abstract, encapsulated level. Such an architecture will undoubtedly be convenient for the AI API, as it will allow the manager to fully control the process of interacting with the AI.

I hope this post will be useful for you.