{"id":16656,"date":"2018-04-05T15:01:00","date_gmt":"2018-04-05T15:01:00","guid":{"rendered":"http:\/\/www.gamasutra.com\/view\/news\/316109"},"modified":"2018-04-05T15:01:00","modified_gmt":"2018-04-05T15:01:00","slug":"blog-encapsulated-scene-architecture-for-large-teams-in-unity","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2018\/04\/05\/blog-encapsulated-scene-architecture-for-large-teams-in-unity\/","title":{"rendered":"Blog: Encapsulated scene architecture for large teams in Unity"},"content":{"rendered":"

The following blog post, unless otherwise noted, was written by a member of Gamasutra\u2019s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.<\/small><\/em><\/strong><\/p>\n

\n

Development in a big team is always an issue in Unity when we are talking about a scene file.<\/p>\n

Multiple people working on the same scene may experience\u00a0problems when the time for merging parallel work\u00a0arrives.<\/p>\n

Some solutions have been developed to account for that, but more often than not, bumps are present during production stage of the game.<\/p>\n

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.<\/p>\n

\"\"<\/p>\n

Two rules were defined at the beginning of production:<\/p>\n

    \n
  • Game flow controlled by waypoint;<\/li>\n
  • No direct references shall exist in a scene;<\/li>\n<\/ul>\n

    By having the team following this two rules, the only possible scene conflict would only fall on the scene composition work.<\/p>\n

    If two or more artists would add and edit what the scene actually looks like, that could cause a conflict.<\/p>\n

    Luckily\u00a0that did not happen during the whole production phase of the game, and rarely\u00a0there was more than one developer working on the scene composition at the same time.<\/p>\n

    Waypoint System<\/strong><\/h2>\n

    A waypoint system was created, where the philosophy\u00a0was that all the game flow of a current waypoint is controlled by it, and every waypoint is self contained.<\/p>\n

    That means that anyone could set any of the waypoints as the starting waypoint, and the game would work perfectly from that point on.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    \"\"<\/p>\n

    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.<\/p>\n

    The SceneManager\u00a0sends an event to the FSM called “Initialize”, and from that point on, the waypoint should do everything it needs to run correctly.<\/p>\n

    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\u00a0flow that triggers the next node to activate.<\/p>\n

    Ideally, a waypoint\u00a0could start in any node and work correctly, but that level of encapsulation\u00a0may hurt the flexibility of the system and is not required.<\/p>\n

    [embedded content]<\/p>\n

    Scene References<\/strong><\/h2>\n

    The second part of this system is the indirect scene references.<\/p>\n

    Only one GameObject on the scene holds references to anything that is inside the scene that might be needed by any script or FSM.<\/p>\n

    It is a singleton, and the references are mapped via string path, with a custom editor controlling said references.<\/p>\n

    \"\"<\/p>\n

    References in the scene are divided by categories\u00a0and references, making it easy to map the variables to any script or FSM.<\/p>\n

    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.<\/p>\n

    This allows the waypoints\u00a0to be prefabs, and manipulate the scene just by programming using the empty references instead of the actual objects.<\/p>\n

    At the start of the game, all scripts and FSMs have access to the SceneManager\u00a0in 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.<\/p>\n

    \"\"<\/p>\n

    \u00a0<\/h2>\n

    Conclusion<\/strong><\/h2>\n

    By building an indirect reference and encapsulated flow from ground up , the scene conflicts during development were practically nullified and\u00a0stability and control over what is\u00a0happening made bug hunting the easiest the studio has seen so far.<\/p>\n

    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.<\/p>\n","protected":false},"excerpt":{"rendered":"

    The following blog post, unless otherwise noted, was written by a member of Gamasutra\u2019s community.The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company. Development in a big team is always an issue in Unity when we are talking about a scene file. Multiple people working on the […]<\/p>\n","protected":false},"author":2,"featured_media":16657,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[],"class_list":["post-16656","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/16656","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=16656"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/16656\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/16657"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=16656"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=16656"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=16656"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}