A Selection of Best Practices and Design Patterns for Unity Nick Bucher University of Alabama Department of Computer Science Abstract GameSceneController (GSC) Pattern Conclusion This poster describes a selection of Unity best practices and a set of new design patterns for beginning or intermediate level Unity developers. The implementations of these design patterns have the potential to reduce development time, allow for scalability, and reduce code complexity in many Unity projects, especially for beginning developers. The GSC pattern described in Figure 1 consolidates references to commonly needed objects in an abstract GameSceneController class. Every other class in the scene can then get access to all of these objects by getting a single reference to the GameSceneController class instance in the current scene. The GameSceneController class may also be used for scene setup and logistics, including: Storing the number of times the current scene has been loaded. Storing the name of the last scene that was loaded. Placing Actor objects at different locations at the start of a scene. Actor objects could include any NPC or Player objects in a scene, and locations that the Actor objects would be moved to could be specified by empty GameObjects in the Editor. Creating any starting dialogue or animation sequences, along with the initialization of different background music sources. Figure 2 shows an example code snippet for initializing the GameSceneController reference in another script. By introducing a selection of Unity best practices and presenting resources that provide further knowledge of Unity, this poster provides a base upon which beginning or intermediate Unity developers may build. I have also described design patterns that have emerged throughout my work in Unity. Over time, these patterns were refined to the point at which they currently exist in this poster. This discussion should be useful to developers searching for solutions to some of the problems regarding scene and reference management, object creation, and systems of interaction. I have found that the GameSceneController from the GSC pattern and the IInteractive interface from the Interaction pattern have can be reused effectively in the majority of Unity projects. They have also all been useful when prototyping a new game. Future work may include the building of open source example projects to describe each of these patterns in more detail. Also, an elaboration may be given on potential uses of these patterns beyond this poster. Figure 3. Introduction Figure 4. Many independent game developers choose to use the Unity game engine due to its large asset store, wide variety of platforms it can port to, as well as Unity’s simple and inexpensive license. The following information is pertinent to this poster: C# is used in all of the programming examples shown here, therefore any reference to an interface refers to a C# interface. ‘GameObject’ refers to the base class for all entities in Unity scenes [3]. Every GameObject has reference to a list of components on that GameObject (for example, Monobehaviour scripts, Colli­­ders, Lights, etc.). An ‘asset’ is a file on disk, stored in the Assets folder of a Unity project [1]. A ‘prefab’ is a premade Unity GameObject that has been saved for future reference in the Asset folder. An ‘NPC’ is a non-player-character in a game. ‘Monobehaviour is the base class from which every Unity script derives [3]. Figure 1. Figure 5. Interaction Pattern The Interaction pattern helps to solve the design problem of creating interactive objects for actors in a scene to interact with. The pattern achieves this by creating an interface through which the actors can recognize an interactive object and call its interaction-specific functions. Generalizing player and NPC characters as Actor objects, it follows that all Actors must be able to recognize and select an object which they can interact with. Potential applications of the Interaction pattern occur frequently, and could include: Interacting with a switch to move a platform. Interacting with a door to open it (or attempt to open it if it is locked). Interacting with an item drop to pick it up. Interacting with a vehicle to drive it. Figure 6 shows the structure of the Interaction pattern using InteractiveObject1 and InteractiveObject2 as example interactive Monobehaviour classes which implement IInteractive. The Actor class calls Select() on the focused interactive object when OnTriggerEnter() is called, and Deselect() when OnTriggerExit() is called, storing the selected object in its interactiveObject field while it is selected. Inside the Actor1 and Actor2 classes, Interact() is called on the interactiveObject when Actor1’s and Actor2’s specific interaction criteria are met. OnTriggerEnter() and OnTriggerExit() may be removed if the game requires different selection criteria for each Actor. Figures 3-5 show the code which is used to store the first-encountered interactive object in the interactiveObject field of the Player, and to call the Interact(), and Select() functions when appropriate. References Anon. 2017. Best Practices. (2017). Retrieved February 13, 2017 from https://unity3d.com/learn/tutorials/topics/best- practices Anon. Game Development. Retrieved February 16, 2017 from http://gamedev.stackexchange.com/ Anon. 2016. Scripting API. (November 2016). Retrieved February 15, 2017 from https://docs.unity3d.com/ScriptReference Anon. Stack Overflow. Retrieved February 16, 2017 from http://stackoverflow.com/ Anon. Unity Answers. Retrieved February 16, 2017 from http://answers.unity3d.com/ Anon. Zeef. Retrieved February 16, 2017 from https://zeef.com/ Makin' Stuff Look Good in Video Games https://www.youtube.com/channel/UCEklP9iLcp ExB8vp_fWQseg Figure 2. Best Practices Having a consistent folder structure is important to consider when organizing a project in Unity. All of the project files use the Asset folder as their root. From this root folder, folders for scenes, scripts, materials, and prefabs could be created. Frequently accessed folders may be prefaced with an underscore (‘_Scenes’, ‘_Scripts’, ‘_Materials’, ‘_Prefabs’), so that they show up topmost in the folder hierarchy. Files may be placed into subfolders based on whether the asset is used in a local scene, or globally throughout the project (ex: ‘Game’, ‘Utility’, ‘Global’ folders). Then they could be placed in further subfolders depending on which scene the file is used in (ex: ‘TitleScene’, ‘ForestScene’ folders), or which object the script relates to (ex: ‘Actor’, ‘Interactive’). Suggestions on the best folder structure are largely personal preferences and project dependent, but having a consistent folder structure and naming convention is helpful as a project grows in scope and as more people are added to a team. Performance is often affected by not knowing how a system entirely works. Tutorials covering Unity’s animation system, physics engine, lighting system, and prefab management would serve as a good overview on various best practices. One of my favorite Unity instructional channels is Makin' Stuff Look Good in Video Games [7], where the creator, Dan Moray, introduces animation, particle systems, and shader writing in a very beginner-friendly way. There is also a wealth of solutions to common development problems on the official Unity forums [5], and in questions that have a Unity tag on StackExchange [2] and StackOverflow [4]. Some great compilations of resources on Unity game development have been put together and shared on Zeef [6] (search for ‘unity development’). Figure 6. Figure 7. Figure 8. Figures 7 and 8 show a generic box example to demonstrate how the interaction pattern can be used. Figure 7 shows how the box appears when it is deselected and the Player is not in range, and Figure 8 shows how the box appears when it is selected and the Player is in range. The selection effect is performed here using a particle system object, and the player was created using the third person controller prefab from the Unity standard assets character package.