Dev Log: Gerbil Peril!
Let’s break down some of the core design concepts that went into the development of Gerbil Peril! Some original concepts (such as Game Events and ScriptableObject asset utility) is courtesy of this post from Schell Games.
Going into the project, an important core principle was to decouple scene references. A very effective way to achieve this is by leveraging ScriptableObjects.
Prefabs and objects within scenes, while basic building blocks of any Unity project, are unable to directly reference prefabs or objects within other scenes. Generally this is not a problem, but when building modular systems, the need to link scripting features across scenes becomes more and more apparent. In past projects I have worked on, what bridges the gap between scenes is normally a Singleton, one script that gathers all references between scenes and allow scripts to communicate directly with each other via the Singleton.
While this approach makes things convenient on a more programmatic level, it does create a big dependency issue if not structured carefully. The blog post mentioned above goes into greater detail for why this is the case. To circumvent this potential issue, let’s first remind ourselves about what problem it is we are trying to solve. Cross-scene object dependencies. With that in mind, ScriptableObjects are a perfect fit to solve this issue. Let’s take a look at one of the components that solve one part of the dependency issue : Game Events
At their core, Game Events are ScriptableObjects. This means they cannot be added into scenes directly. So we need some component that links the functionality of ScriptableObjects to the scenes that require them. The GameEventListener component does exactly that for our Game Events.
Game Events work like messengers. Whenever something of interest happens, it tells all components that have subscribed to it that something has happened. For example, say we have a Game Event called Player Is Happy. Whenever something happens in the game that would make the player happy, the Game Event can let all components linked to it know that the player has become happy, including components from other scenes.
In previous projects I have worked on, this same effect was achieved by creating what’s known as delegates and events, but as mentioned previously, Singletons arose from using this approach. What could go wrong from time to time is if we try to test a component in isolation, we would not be able to do so without first having the Singleton present in the scene. The bigger the Singleton got over the project life cycle, the harder it was to test any single component that had a dependency on said Singleton. It is therefore no surprise that I quickly picked up this approach to event handling and have been happy with the results thus far.
Another useful ScriptableObject component is the Scene Set (original concept by Fredrik Ludvigsen). Normally, loading scenes within Unity requires string literals or number indices (according to the project build settings), which can create a slight dependency issue. If the scene files are renamed, deleted, or moved within the project build settings, we can encounter errors. This can especially be a problem if a renamed scene has a completely different name than before it was renamed. Fortunately, Scene Sets solves this issue by directly referencing the scene files themselves.
Scene Sets also lend themselves very well with Game Events, allowing scenes to be loaded and unloaded whenever something of interest happens in a game. For example, when the player walks into the entrance of a cave, we can load the Cave scene.
There are various other simpler components implemented within Gerbil Peril!, such as AnimationReference, IntReference, PersistentOption. Each of these are ScriptableObjects, aimed at making cross-scene referencing of components easier and as bug free as possible during the development cycle.
