What is a Multi-Scene Workflow?

It’s relatively simple practice that’s often overlooked in smaller projects. It simply means there’ll be multiple scenes loaded at runtime.

A multi-scene workflow isn’t all that viable for something like prototypes since the principle of separation of concerns doesn’t really matter.

Where it’s value becomes most apparent is when we need to maximize reusability, modularity, performance and most importantly collaboration. Of course it’s different on a case by case basis, but I’ve found it to be a very useful practice generally.

Data

There are many places data could live in the game. I like to split them up into two distinct groups.

Scene Dependent

• Game Objects

• Monobehaviours

Scene Independent

• Staticts

• Scripts

• Scriptable Objects

At the end of the day, scenes are just data containers where the data is stored in a hierarchy. There’s no need to duplicate data across scenes when it’s not necessary.

Example

Suppose we have a couple people in a team, all with their own roles. Perhaps there are environment artists, programmers, designers etc.

Splitting up each logical component of the game into it’s own scene will allow each member to work on their own component in isolation.

It really is that simple 😎🤙

Instead of say Level 1 being a single scene, we could have:

• Level_1_Environment

• Level_1_Props

• Level_1_Audio

Or whatever arbitrary names we want. As long as it’s logical.

Maybe, we realize that Level_1_Environment can be split into 3 logical sections or scenes. So, we simply load or unload whichever scene we need accordingly at runtime.

So now, suppose we need to test something specific in the final section of Level 1. We simply load Level_1_Environment_3, and if necessary, setup some required data beforehand to simulate the state of the game and we’re good to go. It’s isolated and testable.

Handling Communication Across Scenes

Scriptable objects are great for cross-scene events. This is a great blog post on the subject:

• Game Architecture with Scriptable Objects(https://unity.com/how-to/architect-game-code-scriptable-objects)

Statics are okay, but they’re not great and I’d advocate against using them in most cases. They’re not flexible and can be a pain to test. I’m not just regurgitating what many others have said, it really is painful. In the last minutes of a jam you really don’t want to be playing through the entire game!

It’s very difficult to simulate a specific state of the game when you have to worry about 50 invisible references scattered across the codebase and a global state.

Source Control

To preface I’m mainly talking about git in this case since I’m not familiar with other solutions such as plastic scm.

Working with source control and monolithic scenes is a massive headache. I’ve had my fair share of merge conflicts 😌👍.

More often than not, if we don’t separate scenes accordingly within a decently sized team, chaos will ensue. Even if you’re working alone, it’s still a good idea to separate scenes logically.

After getting used to it, it felt free of the shackles of coupling.