[antiverse]

I'm surprised this is coming to light now.

I evaluated their tech early on, and it struck me right away at how poorly thought out some decisions were. Very basic things, too. One distinct issue I remember is not having any sort of an "Application" object or app-state pipeline interface/object that I can place my non-component logic into, stuff like checking various timers, handling app-level event hooks, and so on. Turns out, people attach this sort of logic to the Camera component. How the fuck did you get to that point without thinking about any of this?

[Jensson]

You use this and then register whatever hooks you need. Can run before or after the first scene has been loaded etc. Put the configuration in some ScriptableObject somewhere in the project and load things based on that, or just hard code the things you need.

https://docs.unity3d.com/ScriptReference/RuntimeInitializeOn...

Edit: Alternatively just have a main scene and load/unload the other scenes as sub scenes, and put the application level objects in the main scene. Or use the above attribute and spawn the global objects and mark those object as "dont destroy on load" to make them survive the simple scene transitions. Or use normal C# static objects. There are so many ways to handle this, unity doesn't really block you from doing things, just code whatever you need.

[seanw444]

This is what confused me the most about Unity in my game dev class in high school. It made no logical sense. Why would I put logic that has nothing to do with specific objects, inside a specific object? And why would I create a random invisible, unfunctional object to attach the code to? It's such a weird system.

[dangero]

You can just create a singleton that never gets destroyed to handle things like this.

[antiverse]

Exactly my point.