-
Notifications
You must be signed in to change notification settings - Fork 0
Philosophy
Bootstrap is built around one promise: you should be able to click Play, have your architectural code initialize in a predictable way, and then get loaded back into your edit mode scenes transparently. Everything else in this framework exists in service of that idea.
"Predictable" means a service never has to guess whether the rest of the app is ready. It doesn't mean every service initializes in some fixed, memorized order that every other service has to know about. By default, a Service List initializes its services in the order they're listed, and that's enough for most projects. When order actually matters, a service says so explicitly through IServiceWithInitPriority, rather than depending on where it happens to sit in the service list.
This is also why self setup and cooperative work are kept separate. A service's own InitService can only assume its own state is ready. Anything that touches another service is deferred until every service has had a chance to initialize, so that dependency never has to be reasoned about at the call site, it's structural.
The same idea shows up in how services are found. DI libraries are great, but are often overcomplicated for the needs of games. Bootstrap aims for simplicity and performance. There's no constructor injection, no dependency graph to configure. A service is either there or it isn't, and Bootstrap makes that binary instead of probabilistic: look it up, and either get it or get a clear failure, never a silent null value. There's no reliance on expensive reflection operations either. Syntactic sugar should always come for free.
Clicking Play should never require you to think about bootstrapping at all. You shouldn't need to remember to open a specific scene first, and you shouldn't need to build (and then maintain) a debug menu just to get back to the scene you were actually working on. This is a commonly accepted notion of the reality of working on Unity projects, and the goal of this library is to prove that reality as unnecessary.
The Bootstrap Flow means that clicking Play always redirects through the same bootstrap scene, initializes the same way regardless of what you had open, and then hands you back your original scenes and selection automatically. This flow is the default, while providing the option to easily bypass all of it when necessary.
Services are low level objects that shouldn't share the same lifecycle as the rest of the objects in a scene, and using DontDestroyOnLoad is just a workaround that doesn't quite bring the object lifecycle back into user control. Utilizing System.Objects that are more outside of Unity's direct control also has other benefits, such as the