News - Blog: Encapsulated scene architecture for large teams in Unity

News - Blog: Encapsulated scene architecture for large teams in Unity - Printable Version

+- Sick Gaming (https://www.sickgaming.net)
+-- Forum: Sick Gaming Community (https://www.sickgaming.net/forum-1.html)
+--- Forum: Lounge (https://www.sickgaming.net/forum-8.html)
+--- Thread: News - Blog: Encapsulated scene architecture for large teams in Unity (/thread-84545.html)

News - Blog: Encapsulated scene architecture for large teams in Unity - xSicKxBot - 04-07-2018

Blog: Encapsulated scene architecture for large teams in Unity

<div style="margin: 5px 5% 10px 5%;"><img src="https://www.sickgamedev.win/wp-content/uploads/2018/04/blog-encapsulated-scene-architecture-for-large-teams-in-unity.png" width="646" height="215" title="" alt="" /></div><div>The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
<hr />
Development in a big team is always an issue in Unity when we are talking about a scene file.
Multiple people working on the same scene may experience problems when the time for merging parallel work arrives.
Some solutions have been developed to account for that, but more often than not, bumps are present during production stage of the game.
The solution found here at Black River Studios was custom built from ground up and from day 0 to fit development of multiple people on the same scene causing as little interference as possible and the results were quite pleasing.
<img alt="" src="https://www.sickgamedev.win/wp-content/uploads/2018/04/blog-encapsulated-scene-architecture-for-large-teams-in-unity.png" />
Two rules were defined at the beginning of production:
<ul>
<li>Game flow controlled by waypoint;</li>
<li>No direct references shall exist in a scene;</li>
</ul>
By having the team following this two rules, the only possible scene conflict would only fall on the scene composition work.
If two or more artists would add and edit what the scene actually looks like, that could cause a conflict.
Luckily that did not happen during the whole production phase of the game, and rarely there was more than one developer working on the scene composition at the same time.
<h2>Waypoint System</h2>
A waypoint system was created, where the philosophy was that all the game flow of a current waypoint is controlled by it, and every waypoint is self contained.
That means that anyone could set any of the waypoints as the starting waypoint, and the game would work perfectly from that point on.
That meant that each waypoint would guarantee that all the systems it needed to run would exist, all actors were set correctly, and from that point on, the game flow could start flawlessly.
This architecture sped up the development process considerably, since we could focus test each waypoint, and bugs found during the execution of a waypoint would be contained to that execution, making it extremely easy to pinpoint them in matter of minutes.
<img alt="" src="https://www.sickgamedev.win/wp-content/uploads/2018/04/blog-encapsulated-scene-architecture-for-large-teams-in-unity-1.png" />
Playmaker was chosen as the tool that would handle the game flow so game designers would have more control and less dependency of engineers to create their own waypoints, but this system can be adapted to use any type of flow management the team decides to use.
The SceneManager sends an event to the FSM called “Initialize”, and from that point on, the waypoint should do everything it needs to run correctly.
Spawning of enemies, start and end of battles, opening doors, setting traps, triggering big events should all be done by the waypoint, and actors only satisfies the condition of each node in the waypoint flow that triggers the next node to activate.
Ideally, a waypoint could start in any node and work correctly, but that level of encapsulation may hurt the flexibility of the system and is not required.
[embedded content]
<h2>Scene References</h2>
The second part of this system is the indirect scene references.
Only one GameObject on the scene holds references to anything that is inside the scene that might be needed by any script or FSM.
It is a singleton, and the references are mapped via string path, with a custom editor controlling said references.
<img alt="" src="https://www.sickgamedev.win/wp-content/uploads/2018/04/blog-encapsulated-scene-architecture-for-large-teams-in-unity-2.png" />
References in the scene are divided by categories and references, making it easy to map the variables to any script or FSM.
Additionally, an automated FSM variable addition was created to reduce the overhead work for dealing with references this way instead of directly linking a GameObject to a script variable.
This allows the waypoints to be prefabs, and manipulate the scene just by programming using the empty references instead of the actual objects.
At the start of the game, all scripts and FSMs have access to the SceneManager in order to fill the empty references with actual scene objects, allowing the code in them to affect actors and objects in the scene during run time.
<img alt="" src="https://www.sickgamedev.win/wp-content/uploads/2018/04/blog-encapsulated-scene-architecture-for-large-teams-in-unity.jpg" />
<h2> </h2>
<h2>Conclusion</h2>
By building an indirect reference and encapsulated flow from ground up , the scene conflicts during development were practically nullified and stability and control over what is happening made bug hunting the easiest the studio has seen so far.
This system is flexible enough that most projects can at least adapt a version of it, allowing to reap the benefits of disconnecting direct references from development and controlling game flow.
</div>