For our game we decided to give SECTR (https://www.assetstore.unity3d.com/en/#!/content/15356) a try. SECTR loads scenes additively into the main scene, which enables us to work on it concurrently. It also unloads scenes when they aren't used.

Time is very important in our game and objects have to perform actions at a certain time or have to be in a certain state at a time. We decided to have those actions/events local to the sector. So now when the sector is unloaded, we lose the current progress of our action/event.

What is a good way to save this progress and how could we apply differences in time between unloading and loading to this progress? How do we handle events happening while the sector is unloaded?

The obvious solution is to use global state for these events, but we'd like to keep it local to the sectors.

  • \$\begingroup\$ Is it possible for an object to perform an action that then causes another nearby object to perform an action (or not perform one)? If so, then is it possible for that to happen across a sector boundary? \$\endgroup\$
    – Victor T.
    Apr 11, 2017 at 16:37

1 Answer 1


You have three requirements here:

  • Sectors can be unloaded
  • Time-based interactions keep running everywhere
  • Interactions are executed locally within each sector

You may satisfy any two, but not all three:

  • If sectors can be unloaded and their interactions keep running, then those interactions must be executed elsewhere, outside of the sector itself.
  • If interactions run locally in each sector and must keep running, then you can't unload any sectors with time-based scripts running.
  • If interactions run locally and you unload sectors, then time-based interactions will sometimes stop running for unloaded sectors.

So, what compromises can we choose?

You could write an editor pre-processor script that, on run/build, scans all of your scenes and logs any time-based scripts in each, using this to build a data model that can execute time-based interactions in a GameObject that's never unloaded. It can communicate with objects that are currently loaded or when they load in, synchronizing them to the state of this global model. That lets you keep the convenience of authoring your interactions locally in each sector, while it can still execute globally even when sectors are unloaded.

Or, depending on the nature of your events, you might be able to save a timestamp when a given sector was last unloaded and, when it's next loaded, have all its scripts read the elapsed time and fast-forward their state, retroactively accounting for everything that "happened off-screen." This fast-forwarding can become complicated though, and won't allow you to handle interactions or propagation between sectors, or events that need to raise some signal the moment they occur.

  • \$\begingroup\$ Hey there, thanks for your thoughts, they confirm my own. Next week I'll talk with my colleagues about our approach again, I'll probably be back with more questions :) Have a +1. \$\endgroup\$
    – ElDuderino
    Apr 13, 2017 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .