From 7c4761f2451043b9f1809d2fe0710e4c54e2730d Mon Sep 17 00:00:00 2001 From: Anant Sharma <10895811+ananttheant@users.noreply.github.com> Date: Tue, 2 Jun 2026 11:18:37 +0100 Subject: [PATCH] Fix typos in README and documentation --- Documentation/Async.md | 4 ++-- Documentation/DecoratorBindings.md | 2 +- Documentation/MemoryPools.md | 2 +- Documentation/ReleaseNotes.md | 20 ++++++++++---------- Documentation/Signals.md | 12 ++++++------ Documentation/SubContainers.md | 8 ++++---- README.md | 16 ++++++++-------- 7 files changed, 32 insertions(+), 32 deletions(-) diff --git a/Documentation/Async.md b/Documentation/Async.md index 5f2156af8..961a29f6f 100644 --- a/Documentation/Async.md +++ b/Documentation/Async.md @@ -38,7 +38,7 @@ Alternatively you can inject an intermediary object that tracks the result of th ### Example -Lets see how we can inject async dependencies through an intermediary object. Async extensions implements `AsyncInject` as this intermediary. You can use it as follows. +Let's see how we can inject async dependencies through an intermediary object. Async extensions implements `AsyncInject` as this intermediary. You can use it as follows. ```csharp @@ -89,7 +89,7 @@ With the above `AsyncInject` binding, the instance is added to the contain Once injected to `Bar`, we can check whether the return value of the `async` operation is already available by calling the `TryGetResult`. method. This method will return `false` if there is no result to return. If result is not ready yet, we can listen to the `Completed` event to get the return value when the `async` operation completes. -Alternatively we can use the following methods to check the results availability. +Alternatively we can use the following methods to check the result's availability. ```csharp // Use HasResult to check if result exists if (_asyncFoo.HasResult) diff --git a/Documentation/DecoratorBindings.md b/Documentation/DecoratorBindings.md index f5193e04d..eda943f78 100644 --- a/Documentation/DecoratorBindings.md +++ b/Documentation/DecoratorBindings.md @@ -199,7 +199,7 @@ Container.Decorate<ContractType>() Where: -* **ContractType** = The type that is being decoratored. An object of this type will be injected into the DecoratorType class. +* **ContractType** = The type that is being decorated. An object of this type will be injected into the DecoratorType class. * **DecoratorType** = The decorator class. This should be a concrete type and also should take as an injected parameter/field an object of type ContractType. diff --git a/Documentation/MemoryPools.md b/Documentation/MemoryPools.md index 405ffcb21..13ab78496 100644 --- a/Documentation/MemoryPools.md +++ b/Documentation/MemoryPools.md @@ -37,7 +37,7 @@ Before understanding memory pools it would be helpful to understand factories, s It doesn't take long when developing games in Unity before you realize that proper memory management is very important if you want your game to run smoothly (especially on mobile). Depending on the constraints of the platform and the type of game you are working on, it might be very important to avoid unnecessary heap allocations as much as possible. One very effective way to do this is to use memory pools. -As an example let's look at at a case where we are dynamically creating a class: +As an example let's look at a case where we are dynamically creating a class: ```csharp public class Foo diff --git a/Documentation/ReleaseNotes.md b/Documentation/ReleaseNotes.md index 7676cd6a2..548ae07d2 100644 --- a/Documentation/ReleaseNotes.md +++ b/Documentation/ReleaseNotes.md @@ -118,7 +118,7 @@ Minor bug fixes, a few extra bind methods, and one minor breaking api change in Notable - Added new bind methods FromScriptableObject and FromNewScriptableObject bind methods for cases where you already have the ScriptableObject reference at install time - Added new subcontainer bind method ByInstanceGetter -- Bug fix - the inject order was wrong in some rare edge cases (ie. sometimes objects would receive injected parameters that have not themsevles been injected yet) +- Bug fix - the inject order was wrong in some rare edge cases (ie. sometimes objects would receive injected parameters that have not themselves been injected yet) - Bug fix - readonly properties were not injectable - Added ability to declare signals at runtime after install - Fixed playmode tests to work inside builds instead of just in editor @@ -382,7 +382,7 @@ Minor release with just a few fixes. Notable - Fixes related to upgrading to Unity 5.6 - Moved Zenject folder to plugins directory -- Changed to trigger injection before Awake / OnEnable / Start for dynamically instantaited prefabs. This is nice because you can treat [Inject] methods more like constructors, and then use Awake/Start for initialization logic, for both dynamically created objects and objects in the scene at the start +- Changed to trigger injection before Awake / OnEnable / Start for dynamically instantiated prefabs. This is nice because you can treat [Inject] methods more like constructors, and then use Awake/Start for initialization logic, for both dynamically created objects and objects in the scene at the start - Marked the [Inject] attribute with MeansImplicitUseAttribute to improve integration with JetBrains Resharper - Fixed bug that was happening when using ZenjectSceneLoader with LoadSceneMode.Single (it was destroying ProjectContext) - Added support for declaring [Inject] methods with return type IEnumerator similar to Start @@ -469,7 +469,7 @@ Bug fixes - Fixed WithArguments bind method to support passing null values - Fixed context menu to work properly when creating installers etc. issue #200 - Fixed issue with ZenUtilInternal.InjectGameObjectForComponent method to support looking up non-monobehaviours. -- Fixed NonLazy() bind method to work properly wtihin sub containers +- Fixed NonLazy() bind method to work properly within sub containers --------- @@ -504,9 +504,9 @@ Bug fixes ## Version 4.5 (September 1, 2016) - Fixed DiContainer.ResolveTypeAll() method to properly search in parent containers -- Fixed exception that was occuring with Factories when using derived parameter types +- Fixed exception that was occurring with Factories when using derived parameter types - Fixed FromResolve to properly search in parent containers -- Fixed exception that was occuring with FromMethod when using derived parameter types +- Fixed exception that was occurring with FromMethod when using derived parameter types --------- @@ -537,7 +537,7 @@ Bug fixes - (bug) Fixed PrefabFactory to work with abstract types - (bug) Fixed some bugs related to convention binding - (bug) Fixed bug with Unity 5.3.5 where the list of installers would not serialize properly -- (but) Fixed minor bug with validation +- (bug) Fixed minor bug with validation --------- @@ -579,11 +579,11 @@ Bug fixes - Renamed GlobalCompositionRoot to ProjectCompositionRoot and FacadeCompositionRoot to GameObjectCompositionRoot. - Added more intuitive bindings for creating subcontainers. eg: Container.Bind().ToSubContainerResolve().ByPrefab() - Added WithGameObjectName and WithGroupName bind methods to prefab or game object related bindings -- Made another big chagne to the fluent interface to avoid having duplicate methods for with Self and Concrete. Now you choose between Container.Bind().ToSelf() and Container.Bind().To(). ToSelf is assumed if unspecified +- Made another big change to the fluent interface to avoid having duplicate methods for with Self and Concrete. Now you choose between Container.Bind().ToSelf() and Container.Bind().To(). ToSelf is assumed if unspecified - Changed Triggers to directly expose the signal event so they can be used as if they are signals - Added concept of ScriptableObjectInstaller - especially useful for use with settings - Added ZenjectSceneLoader class to allow additively loading other scenes as children or siblings of existing scene -- Changed scene decorators to work more intuitively with the multi-scene editting features of Unity 5.3+. You can now drag in multiple scenes together, and as long as you use DecoratorCompositionRoot in scenes above a main scene, they will be loaded together. +- Changed scene decorators to work more intuitively with the multi-scene editing features of Unity 5.3+. You can now drag in multiple scenes together, and as long as you use DecoratorCompositionRoot in scenes above a main scene, they will be loaded together. - Removed IncludeInactive flag. Now always injects into inactive game objects. This was kinda necessary because validation needs to control the active flag - Removed the concept of one single DependencyRoot in favour of having any number of them, using binding with identifier. Also added NonLazy() bind method to make this very easy - Added new attribute ZenjectAllowDuringValidation for use with installer setting objects that you need during validation @@ -656,7 +656,7 @@ Bug fixes ## Version 3.2 (December 20, 2015) - Added the concept of "Commands" and "Signals". See documentation for details. - Fixed validation for decorator scenes that open decorator scenes. -- Changed to be more strict when using a combination of differents kinds of ToSingle<>, since there should only be one way to create the singleton. +- Changed to be more strict when using a combination of different kinds of ToSingle<>, since there should only be one way to create the singleton. - Added ToSingleFactory bind method, for cases where you have complex construction requirements and don't want to use ToSingleMethod - Removed the InjectFullScene flag on SceneCompositionRoot. Now always injects on the full scene. - Renamed AllowNullBindings to IsValidating so it can be used for other kinds of validation-only logic @@ -669,7 +669,7 @@ Bug fixes - Added an Open button in scene decorator comp root for easily jumping to the decorated scene - Removed support for object graph visualization since I hadn't bothered maintaining it - Got the optional Moq extension method ToMock() working again -- Fixed scene decorators to play more nicely with Unity's own way of handling LoadLevelAdditive. Decorated scenes are now organized in the scene heirarchy under scene headings just like when calling LoadLevelAdditive normally +- Fixed scene decorators to play more nicely with Unity's own way of handling LoadLevelAdditive. Decorated scenes are now organized in the scene hierarchy under scene headings just like when calling LoadLevelAdditive normally --------- diff --git a/Documentation/Signals.md b/Documentation/Signals.md index 235cdb204..e0de53899 100644 --- a/Documentation/Signals.md +++ b/Documentation/Signals.md @@ -191,7 +191,7 @@ public class Greeter : IInitializable, IDisposable Note that if you go this route that you need to enable UniRx integration as described here. -As you can see in the the above examples, you can either directly bind a handler method to a signal in an installer using `BindSignal` (first example) or you can have your signal handler attach and detach itself to the signal (second and third examples) +As you can see in the above examples, you can either directly bind a handler method to a signal in an installer using `BindSignal` (first example) or you can have your signal handler attach and detach itself to the signal (second and third examples) Details of how this works are explained in the following sections. @@ -516,7 +516,7 @@ For example, Lets say I have a player and i want to save the game when i finish Ok easy, I create ``SignalLevelCompleted`` and then I subscribe it to my ``SaveGameSystem`` then I also want to save when i reach a checkpoint, again i create ``SignalCheckpointReached`` and then I subscribe it to my ``SaveGameSystem`` -you are begining to get something like this... +you are beginning to get something like this... ```csharp public class Example { @@ -588,10 +588,10 @@ public struct SignalLevelCompleted : ISignalGameSaver{} public interface ISignalGameSaver{} ``` -Now your ``SaveGameSystem`` doesnt knows about CheckPoints nor Level events, and just reacts to signals that save the game. +Now your ``SaveGameSystem`` doesn't knows about CheckPoints nor Level events, and just reacts to signals that save the game. The main difference is in the Signal declaration and Firing - ``DeclareSignalWithInterfaces`` works like ``DeclareSignal`` but it declares the interfaces too. - - ``AbstractFire`` is the same that ``Fire`` but it fires the interfacesjust if you have Declared the signal with interfaces + - ``AbstractFire`` is the same that ``Fire`` but it fires the interfaces just if you have Declared the signal with interfaces otherwise it will throw an exception. Ok, let's show even more power. @@ -651,7 +651,7 @@ public interface ISignalAchievementUnlocker{ string AchievementKey {get;}} ``` It offers a lot of modularity and abstraction for signals, -you fire a concrete signal telling what you did and give them functionality trough Interface implementations +you fire a concrete signal telling what you did and give them functionality through Interface implementations ### Signals With Subcontainers @@ -667,7 +667,7 @@ In some cases it might be desirable to run a given signal asynchronously. Async 3. Unexpected state changes can occur while firing just one signal. For example, an object A might trigger a signal which would trigger some logic that would eventually cause A to be deleted. If the signal was executed synchronously, then the call stack could eventually return to object A where the signal was fired, and object A might then attempt to execute commands afterwards that causes problems (since object A will have already been deleted) -This is not to say that asynchronous signals are superious to synchronous signals. Asynchronous signals have their own risks as well. +This is not to say that asynchronous signals are superior to synchronous signals. Asynchronous signals have their own risks as well. 1. Debugging can be more difficult, because it isn't clear from the stack trace where the signal was fired. diff --git a/Documentation/SubContainers.md b/Documentation/SubContainers.md index 35f60720b..a4e1595eb 100644 --- a/Documentation/SubContainers.md +++ b/Documentation/SubContainers.md @@ -23,7 +23,7 @@ In some cases it can be very useful to use multiple containers in the same application. For example, if you are creating a word processor it might be useful to have a sub-container for each tab that represents a separate document. This way, you could bind a bunch of classes `AsSingle()` within the sub-container and they could all easily reference each other as if they were all singletons. Then you could instantiate multiple sub-containers to be used for each document, with each sub-container having unique instances of all the classes that handle each specific document. -Another example might be if you are designing an open-world space ship game, you might want each space ship to have it's own container that contains all the class instances responsible for running that specific spaceship. +Another example might be if you are designing an open-world space ship game, you might want each space ship to have its own container that contains all the class instances responsible for running that specific spaceship. This is actually how ProjectContext bindings work. There is one container for the entire project, and when a unity scene starts up, the container within each SceneContext is created "underneath" the ProjectContext container. All the bindings that you add in your scene MonoInstaller are bound to your SceneContext container. This allows the dependencies in your scene to automatically get injected with ProjectContext bindings, because sub-containers automatically inherit all the bindings in their parent (and grandparent, etc.). @@ -92,7 +92,7 @@ Note the following: ## Creating Sub-Containers on GameObject's by using Game Object Context -One issue with the sub-container hello world example above is that it does not work very well for MonoBehaviour classes. There is nothing preventing us from adding MonoBehaviour bindings such as FromComponentInNewPrefab, FromNewComponentOnNewGameObject, etc. to our ByInstaller/ByMethod sub-container - however these will cause these new game objects to be added to the root of the scene heirarchy, so we'll have to manually track the lifetime of these objects ourselves by calling GameObject.Destroy on them when the Facade is destroyed. Also, there is no way to have GameObject's that exist in our scene at the start but also exist within our sub-container. Also, using ByInstaller and ByMethod like above does not support the use of interfaces such as IInitializable / ITickable / IDisposable inside the subcontainer. These problems can be solved by using Game Object Context. +One issue with the sub-container hello world example above is that it does not work very well for MonoBehaviour classes. There is nothing preventing us from adding MonoBehaviour bindings such as FromComponentInNewPrefab, FromNewComponentOnNewGameObject, etc. to our ByInstaller/ByMethod sub-container - however these will cause these new game objects to be added to the root of the scene hierarchy, so we'll have to manually track the lifetime of these objects ourselves by calling GameObject.Destroy on them when the Facade is destroyed. Also, there is no way to have GameObject's that exist in our scene at the start but also exist within our sub-container. Also, using ByInstaller and ByMethod like above does not support the use of interfaces such as IInitializable / ITickable / IDisposable inside the subcontainer. These problems can be solved by using Game Object Context. For this example, let's try to actually implement something similar to the open world space ship game described in the sub-container introduction: @@ -213,7 +213,7 @@ public class ShipInputHandler : MonoBehaviour Ship Facade Example -* The idea here is that everything at or underneath the Ship game object should be considered inside it's own sub-container. When we're done, we should be able to add multiple ships to our scene, each with their own components ShipHealthHandler, ShipInputHandler, etc. that can treat each other as singletons. +* The idea here is that everything at or underneath the Ship game object should be considered inside its own sub-container. When we're done, we should be able to add multiple ships to our scene, each with their own components ShipHealthHandler, ShipInputHandler, etc. that can treat each other as singletons. * Try to validate your scene by pressing `CTRL+ALT+V`. You should get an error that looks like this: `Unable to resolve type 'ShipHealthHandler' while building object with type 'Ship'.` * This is because the ShipHealthHandler component has not been added to our sub-container. To address this: * Click on the HealthHandler game object and then click Add Component and type Zenject Binding (see here for details on this feature) @@ -744,7 +744,7 @@ public class TestInstaller : MonoInstaller } ``` -Now, if we instantiate any game objects inside the Greeter subcontainer and we do not specify an explicit parent, then they will be placed underneath a new game object named "Greeter". This can help for organization purposes when reading the scene in the scene heirarchy. +Now, if we instantiate any game objects inside the Greeter subcontainer and we do not specify an explicit parent, then they will be placed underneath a new game object named "Greeter". This can help for organization purposes when reading the scene in the scene hierarchy. Note also that with this approach, you can no longer use `BindExecutionOrder` to adjust the execution order of the subcontainer. However, if you later decide that you need to customize the execution order then you can do that by passing a custom kernel-derived class to the WithKernel method and then using BindExecutionOrder with that class. For example: diff --git a/README.md b/README.md index 451328d4b..54190c979 100644 --- a/README.md +++ b/README.md @@ -315,7 +315,7 @@ As shown in the above example, DI can be used to easily swap different implement More important than that is the fact that using a dependency injection framework like Zenject allows you to more easily follow the '[Single Responsibility Principle](http://en.wikipedia.org/wiki/Single_responsibility_principle)'. By letting Zenject worry about wiring up the classes, the classes themselves can just focus on fulfilling their specific responsibilities. -Another common mistake that people new to DI make is that they extract interfaces from every class, and use those interfaces everywhere instead of using the class directly. The goal is to make code more loosely coupled, so it's reasonable to think that being bound to an interface is better than being bound to a concrete class. However, in most cases the various responsibilities of an application have single, specific classes implementing them, so using interfaces in these cases just adds unnecessary maintenance overhead. Also, concrete classes already have an interface defined by their public members. A good rule of thumb instead is to only create interfaces when the class has more than one implementation or in cases where you intend to have multiple implemenations in the future (this is known, by the way, as the [Reused Abstraction Principle](http://codemanship.co.uk/parlezuml/blog/?postid=934)) +Another common mistake that people new to DI make is that they extract interfaces from every class, and use those interfaces everywhere instead of using the class directly. The goal is to make code more loosely coupled, so it's reasonable to think that being bound to an interface is better than being bound to a concrete class. However, in most cases the various responsibilities of an application have single, specific classes implementing them, so using interfaces in these cases just adds unnecessary maintenance overhead. Also, concrete classes already have an interface defined by their public members. A good rule of thumb instead is to only create interfaces when the class has more than one implementation or in cases where you intend to have multiple implementations in the future (this is known, by the way, as the [Reused Abstraction Principle](http://codemanship.co.uk/parlezuml/blog/?postid=934)) Other benefits include: @@ -450,7 +450,7 @@ Best practice is to prefer constructor/method injection compared to field/proper ## Register Mappings to the DI Container -The core of a dependency injection framework is the DI container. In it's simplest form it's an object which contains a dictionary that holds all the _registrations_. +The core of a dependency injection framework is the DI container. In its simplest form it's an object which contains a dictionary that holds all the _registrations_. In this section we are going to cover the 'register a new mapping' part. In Zenject it's called _binding_. As it creates a binding between an _abstraction_ to a _concrete type_. ### Binding @@ -1080,7 +1080,7 @@ There are three ways to do this. 1. **Prefabs**. You can also directly drag your installer prefab from the Project tab into the InstallerPrefabs property of SceneContext. Note that in this case you cannot have per-scene overrides like you can when having the prefab instantiated in your scene, but can be nice to avoid clutter in the scene. -1. **Prefabs within Resources folder**. You can also place your installer prefabs underneath a Resoures folder and install them directly from code by using the Resources path. For details on usage see [here](#runtime-parameters-for-installers). +1. **Prefabs within Resources folder**. You can also place your installer prefabs underneath a Resources folder and install them directly from code by using the Resources path. For details on usage see [here](#runtime-parameters-for-installers). Another option in addition to `MonoInstaller` and `Installer<>` is to use `ScriptableObjectInstaller` which has some unique advantages (especially for settings) - for details see [here](#scriptableobject-installer). @@ -1335,7 +1335,7 @@ Note that this will also include factories and memory pools, which is especially There are a few things to be aware of: - No actual logic code is executed - only install bindings is called. This means that if you have logic inside installers other than bind commands that these will be executed as well and may cause issues when running validation (if that logic requires that the container return actual values) -- **null** values are injected into the dependencies that are actually instantiated such as installers (regardles of what was binded) +- **null** values are injected into the dependencies that are actually instantiated such as installers (regardless of what was binded) You might want to inject some classes even in validation mode. In that case you can mark them with `[ZenjectAllowDuringValidation]`. @@ -1512,7 +1512,7 @@ The `ZenjectBinding` component has the following properties: * **Lazily instantiated objects and the object graph** * Zenject does not immediately instantiate every object defined by the bindings that you've set up in your installers. It will only instantiate those bindings that are marked `NonLazy`. All other bindings are only instantiated when they are needed. All the `NonLazy` objects as well as all their dependencies form the 'initial object graph' of the application. Note that this automatically includes all types that implement `IInitializable,` `ITickable,` `IDisposable,` etc. So if you have a binding that is not being created because nothing in the initial object graph references it, then you can make this explicit by adding `NonLazy` to your binding -* **Restrict the use of bind commands to the 'composition root' only**. In other words, do not make calls to `Container.Bind`, `Container.Rebind`, or `Container.Unbind` after the install phase is completed. This important because immediately after install completes the initial object graph of your application is constructed, and needs access to the full set of bindings. +* **Restrict the use of bind commands to the 'composition root' only**. In other words, do not make calls to `Container.Bind`, `Container.Rebind`, or `Container.Unbind` after the install phase is completed. This is important because immediately after install completes the initial object graph of your application is constructed, and needs access to the full set of bindings. * **The order that things occur in is wrong, like injection is occurring too late, or Initialize() event is not called at the right time, etc.** * It may be because the 'script execution order' of the Zenject classes `ProjectKernel` or `SceneKernel` or `SceneContext` is incorrect. These classes should always have the earliest or near earliest execution order. This should already be set by default (since this setting is included in the `cs.meta` files for these classes). However if you are compiling Zenject yourself or have a unique configuration, you may want to make sure, which you can do by going to "Edit -> Project Settings -> Script Execution Order" and confirming that these classes are at the top, before the default time. @@ -1732,7 +1732,7 @@ Then, when you start any scene that contains a `SceneContext`, your `ProjectCont Note also that this only occurs once. If you load another scene from the first scene, your `ProjectContext` will not be called again and the bindings that it added previously will persist into the new scene. You can declare `ITickable` / `IInitializable` / `IDisposable` objects in your project context installers in the same way you do for your scene installers with the result being that `IInitializable.Initialize` is called only once across each play session and `IDisposable.Dispose` is only called once the application is fully stopped. -The reason that all the bindings you add to a global installer are available for any classes within each individual scene, is because the Container in each scene uses the `ProjectContext` Container as it's "parent". For more information on nested containers see [here](#sub-containers-and-facades). +The reason that all the bindings you add to a global installer are available for any classes within each individual scene, is because the Container in each scene uses the `ProjectContext` Container as its "parent". For more information on nested containers see [here](#sub-containers-and-facades). `ProjectContext` is a very convenient place to put objects that you want to persist across scenes. However, the fact that it's completely global to every scene can lead to some unintended behaviour. For example, this means that even if you write a simple test scene that uses Zenject, it will load the `ProjectContext,` which may not be what you want. To address these problems it is often better to use Scene Parenting instead, since that approach allows you to be selective in terms of which scenes inherit the same common bindings. See [here](#scene-parenting) for more details on that approach. @@ -1965,7 +1965,7 @@ Note that you can chain together any combination of the below conditionals in th ### Decorator Bindings -Decorator Bindings has it's own documentation [here](Documentation/DecoratorBindings.md). +Decorator Bindings has its own documentation [here](Documentation/DecoratorBindings.md). ## Scriptable Object Installer @@ -2359,7 +2359,7 @@ Putting bindings inside ProjectContext is a fast and easy way to add common long As an example, let's pretend that we are working on a spaceship game, and we want to create one scene to serve as the environment (involving planets, asteroids, stars, etc.) and we want to create another scene to represent the ship that the player is in. We also want all the classes in the ship scene to be able to reference bindings declared in the environment scene. Also, we want to be able to define multiple different versions of both the ship scene and the environment scene. To achieve all this, we will use a Zenject feature called 'Scene Contract Names'. -We will start by using Unity's support for [multi-scene editting](https://docs.unity3d.com/Manual/MultiSceneEditing.html), and dragging both our environment scene and our ship scene into the Scene Hierarchy tab. Then we will select the SceneContext in the environment scene and add a 'Contract Name'. Let's call it 'Environment'. Then all we have to do now is select the SceneContext inside the ship scene and set its 'Parent Contract Name' to the same value ('Environment'). Now if we press play, all the classes in the ship scene can access the declared bindings in the environment scene. +We will start by using Unity's support for [multi-scene editing](https://docs.unity3d.com/Manual/MultiSceneEditing.html), and dragging both our environment scene and our ship scene into the Scene Hierarchy tab. Then we will select the SceneContext in the environment scene and add a 'Contract Name'. Let's call it 'Environment'. Then all we have to do now is select the SceneContext inside the ship scene and set its 'Parent Contract Name' to the same value ('Environment'). Now if we press play, all the classes in the ship scene can access the declared bindings in the environment scene. The reason we use a name field here instead of explicitly using the scene name is to support swapping out the various environment scenes for different implementations. In this example, we might define several different environments, all using the same Contract Name 'Environment', so that we can easily mix and match them with different ship scenes just by dragging the scenes we want into the scene hierarchy then hitting play.