Addressable Chunk Loader System
Addressable Chunk Loader is a package for loading rooms(mainly for the castle area) as addressable chunks/scenes for SS2 using addressables. It handles:
Loading/Unloading rooms/addressable chunks based on distance from player.
Marking rooms/chunks to always keep loaded for particular areas or game needs.
Async await API + events for handling room loading/unloading.
Scene Setup:
- Each room has an exterior and an interior scene.
- Both scenes are addressable.
- Exterior is loaded when player is in range
- Interior is loaded when player enters the room(via door or function call)
- The room interior should have a RoomInstance monobehavior with a RoomEntryZone.
- RoomEntryZone detects player entry into a trigger collider.
- You can hit play mode in any interior scene
- Keep a master scene and bake all scenes with that as the active scene. See lighting notes for details.
Room loading:
A room can be loaded because:
- It is in always load list of current room radius distance from player within some threshold.
- It is in always load list for current room/floor. We may want to add other ways to determine if rooms should be loaded. As long as one system says that a room should be kept loaded, we should keep it loaded.
- If a room is no longer required at all, it is unloaded after a timer RoomLoader handles actual loading:
- It keeps a Dictionary<Room, RoomLoadHandle> for exterior and interior Any room that will be loaded/is loaded is in the dicts
- Once a room needs to be unloaded(timer expired), it is also removed from the dict RoomManager handles loading rooms in player range/ adding/removing must load rooms(based on story reqs or whatever)
- You can wait till a room is loaded. In the samples, the door does not animate the door until the room is loaded.
Usage:
- Ensure that a RoomManager singleton exists in your scene. Set the player ref on the RoomManager.
- Use separate exterior and interior scenes per room.
- The RoomData scriptable stores and uses room world position.
- The scene root should always be in the room's correct position.
- When the root position has been moved, go to the RoomInstance object and update the position
- The gizmos indicate when they don't match to aid you.
- You are responsible to ensure that the scriptable is updated.
Known issues:
Don't put the player objects in the rooms if you use RoomEntryZone:
- If multiple rooms each with RoomEntryZone and player objects are loaded.
- The roommanager will consider the player to be at the last room.
- This depends on execution and room dependency order. Don't do it.
- Sample scenes has a player spawning example that avoids the above scenario .
Lighting Notes:
Do:
Baking workflow:
- Keep a "master" scene containing lightprobes for the other rooms.
- Load the master scene.
- Ensure that it is the active scene.
- Additively load room interior and exterior
- The additive scenes should share the same light settings asset.
- Bake. You must do this for any light update.
In runtime:
As of yet, it doesn't seem necessary to actually load the master scene in runtime after baking. So the package currently just loads assets separately.
Do not:
- Do not bake rooms separately.
- Do not light probe them separately. Only the master scene should contain the light probes.
Note:
Unity can handle lightmaps from different additive scenes. But not light probes. The above workflow using a master scene is a workaround for that.