Make Scenes (More) Self-Contained

Summary

Duality is hardwired to always have one active Scene and some of its code is built on that assumption. Gradually move away from this by making Scenes self-contained / independent classes as a first step.

Analysis

• Internally, all Scenes share a single static physics World. Replace this with a Scene-local instance that is created on-demand and cleared / re-used.
• Rename scene.IsCurrent to IsActive to clear the way for future changes in behavior.
• Find all references to Scene.Current and evaluate whether they can be removed or replaced with gameObj.ParentScene.
• Make Render and Update API public and allow calling them when the Scene is not the Current one.
  • Modify switch locking behavior to only trigger for the Current scene.
  • Write a unit test to verify whether Component methods for rendering and updates are properly called for non-Current scenes when called explicitly.
• Replace the static OnLeaving and OnEntered handlers with public Activate and Deactivate methods for the scene class, allowing to properly activate and deactivate a secondary / non-Current scene before calling update and render methods.
• When done, consider going a step further and extracting SceneManager functionality from Scene that would handle scene activity and (previously) static global events. This is a new issue that would have to be created afterwards.

[ilexp]

For the overlap check methods, there isn’t really a big semantic difference between the instance and the static methods - they’re both asking “does X collide with (point or area) Y?” while either looking at all bodies, or just at a single one. It’s of course different for raycasts and broadphase queries, but still - not an unheard-of pattern to have a static method that finds instances of its class in a global scope.

Again, not saying the current approach is per se better, but that there’s a figurative score to be assigned to each approach, and a threshold to be crossed to switch from one to another - and that right now, it feels like that threshold is potentially reached, but without being an obvious case.

I’d probably just let that sink in for a bit and come back to it when it comes to actually updating the API. Sometimes you just have to play around with implementations and get some hands-on experience with either approach to see which is a better fit for the situation.

[ilexp]

Reviewed the code in its current state and postponed further refactoring related to a potential SceneManager class in order to move forward with v3.0. Code looks fine so far, tests pass. Merged back, closing this.