April 2021 Update: Massive rewrite, now is v2.0 It's fast, it's smarter, it's easier to use. Fully reference-counted scene loading supports progressive loading for large worlds.
What is it?
The short explanation is "Additive Scene Workflow like Photoshop Layers". Curious? Check out the video or read up on the newly updated documentation.
When Unity was young, projects were small and organization was simple: each scene was a different level and that was that. As the projects have gotten larger and more people are touching the same scenes for but for different reasons, the chances of two people working on the same scene at the same time and losing work due to poor merging has become a huge problem. As teams went from one or two developers to dozens, breaking your work into multiple smaller files has become a lifesaver to keep everyone from stepping on each other's changes.
You can do that by using lots of prefabs at the root of your scene, or try using prefab-in-a-prefab to keep things straight, but in the end, it is much easier to work with a scene file sometimes. And Unity does support that. Just... not comfortably.
That's why I wrote SplitScenes. It lets you break up a scene into as many other sub-scene files as you want, organized by content type or developer or however it makes sense for your project. Along with this organizational change, SplitScenes also comes with a new Lock icon that lets you tell SplitScenes whether you intend to make changes in a scene or not.
For example, if the lighting artist wants to place lights, she probably doesn't want to mess with the dynamic gameplay objects or enemy spawners, so she leaves those scenes locked. That prevents her from selecting those objects in the Scene View, and even if somehow something in the scene is modified, when she clicks Save, a popup confirms that the scene should actually save, or if she just wants to skip that file. In vanilla Unity, if you hit save, all the modified scenes save--congratulations, you now have a merge conflict to sort out. Oops.
New in the v2.0 release is a completely rewritten core that handles loading in a more robust way, using a reference counting system. This allows multiple SplitScenes objects to work simultaneously, and be activated at any time, in any order, and the correct set of scenes will be loaded or unloaded as their reference counts change. Mumbo jumbo aside, you can create large flowing worlds or connected levels that trigger when you go through airlocks, all based on these simple primitives and controlled by the most basic action of enabling or disabling a SplitScenes script. It's so easy to use, I built the roaming demo in the video above in just over an hour.
Also new is a much improved custom Inspector for the SplitScenes object. This quick and easy dashboard is a tight but very functional window into your stacks of scenes. Numerous other improvements were added too. One is the ability to specify a GameObject that gets activated immediately after all the scenes load so you can do cross-scene wiring during initialization, and deactivated just before scenes unload so you can save state. Another is the fact that all additive scenes are asynchronously loaded, but are all triggered and activate in order and in one frame, so all the objects are live at the same time, so you can depend on FindObjectByType<>() locating objects in other subscenes during Start(), like always.
I created SplitScenes to make life easier for me and my team. I suspect that once you start using it, you'll wonder how you ever lived without it. I do.