For the third term at Level 5 of my Computer Games Programming (BSc) degree at University of Staffordshire, I had a Tools Development module where I was tasked with creating a tool that aids some part of the creation of games. There was a few options to choose from but I chose to create an in-engine tool for Unity, created in C#. GitHub Link, or code snippet below.
Tool Idea
The idea I chose to pursue was a code manager / decoupler that helped separation of concerns for game scripts, allowing them to be more reusable. This would help prototyping and faster development, with larger scoped projects possibly requiring less separation due to optimisation needs. In particular, this tool helped combat the over reliance of singletons within Unity development. To create said tool I created a Kanban board on Trello to aid with project management.
Scriptable Objects
Main functionality of the tool utilised Scriptable Objects to store data that can be read from and written to. This allows a component to use a value that can be changed by other components, without either knowing about the other. For example, a character can update a health value, which a health UI component can use to display the current health value.
The created Scriptable Object types created are:
- Variables and references to use like mentioned above
- Events and event listeners using the in-built Unity event system
- Collections to store lists of data (such as a list of alive enemies)
The combination of these types gives a lot of flexibility to create reusable components which can be combined in different ways to build up playable game prototypes.
Debugging
One of the biggest drawbacks in utilising Scriptable Objects in this way is the bigger difficulty to debug as it can be harder to tell where the values are being changed and acquired from. To solve this lots of debugging options were added, such as, a debug output when a variable is updated, ability to fire the events with a custom debug value from the inspector, and debug output when items are added or removed from a collection.
User Interface
Another main feature of the tool that would help debug and use the Scriptable Objects was the creation of UI for tracking references to the Scriptable Objects, which updated when required.
Future Work
- Polishing and improving the user interface.
- More testing and feedback on the tool.
- Create larger examples showcasing the power of the tool.
Interesting Problem
The biggest problem to navigate in the creation of the tool was keeping track of all the references to the Scriptable Objects. The first challenge that came about was not being able to reference the templated base class directly to check for subtypes, requiring each templated class to have a base class it inherits from, name appended with Base to avoid confusion.
However, this was just the tip of the iceberg, as I still needed to find the references on GameObjects in the scene, Prefabs in assets, and worst of all GameObjects in not open scenes. To get into this problem I started by creating a function which gets all the references in a GameObject. Luckily I was able to iterate over all the serialized fields of the attached components to the GameObject, checking each field to see if it was an object reference, and if that reference’s type matched any of the Scriptable Object types I had created.
With this it was fairly simple to load all prefabs from assets and check them all by passing them to the function, then getting all references in the scene was done by finding all objects in the scene and checking if they were of type GameObject before doing the same.
Then with the slightly easier parts done, I had to find the references in all scenes, even those closed. To do this the only method I found was sadly quite inelegant, I had to find all assets of type scene in the assets folder, then open all the scenes before finding all the game objects in them like before, this would be a fairly slow function especially as projects get bigger, so I aim for it to only happen once and then keep track of updates to scenes and prefabs by hooking into Unity’s relevant call-backs.
Realistically all the reference tracking code is not particularly fast and needs a deeper look into the workings of Unity to properly improve it and ensure it’s operating better, but getting it working at all was a large undertaking that caused me to learn a lot about how Unity’s editor works.
Code snippets below showcasing some mentioned code
