Dynamic Databases: From Idea to Implementation (Part 2)

Sonya Rivers
5 min readSep 30, 2019

--

My last update for ArcLight’s dynamic database system left off finishing the foundation of the Dialogue Database for storing and retrieving dialogue snippets from the SQLite tables as references to a serialized JSON text file. Recently, I’ve been able to expand this SQLite database system to also include our Quest system, a shallow Player Inventory system, and a basic Player Stats table for tracking the player’s experience.

As a group, we decided that these backend systems would need to be compartmentalized so that they do not interfere with one another and they must also be able to communicate with each other through their database connections to send and retrieve data from each other as needed. In essence, we needed a compartmentalized hierarchy of how the database would be divided into tables, with no single table having higher priority than the other.

We also decided that there would need to be a base Interaction script that functioned as an interface class and a base Item script that functioned as an abstract class for all interactable items to inherit from. This functionality allows all interactable objects the player comes into contact with, such as loot, NPCs, or other quest items, to have a base Interact() and CleanUp() method. The Interact() method triggers the interaction to begin, and the CleanUp() method triggers the interaction to end and all relative data to be updated in the backend system.

Hierarchy of inheritance for the Interactable Interface

Based on these parameters, this is the design for the backend system that I was able to come up with:

The compartmentalized organization of all SQLite Database Manager Scripts

The SQLite Database dictates the flow of data to and from this backend system. Each of the pillars of interactive data management systems — the Dialogue Manager, Quest Manager, Skill Tree Manager, and Player Inventory Manager — all have their own connections to the data powerhouse that is the SQLite Database. The Quest Manager has the unique ability to cross-reference the Dialogue, Skill Tree, and Player Inventory tables but this is a read-only permission connection. All data is written via each component manager’s individual SQLite connections to prevent the overwriting of data from multiple sources, which leads to data entry errors.

From the player’s perspective, the player will interact with a scriptable object in 3D world space. This object will have an I-Interactable script attached to it, which will classify its interaction type. Depending on the interaction type (Dialogue, Combat, Item, etc), the Interact() method will be called and the new player data will begin to be written as a serialized object. Once the interaction has been marked as complete the CleanUp() method is called by the event system. In the CleanUp() method, the finalized player event data will be formatted specifically for JSON serialization, then passed as a JSON file to its relative manager script, then from the manager to the SQLite Database. The database is then populated with file paths to the serialized JSON data. These JSON file paths can be reopened by their system manager(s) in order to parse the data back into strings recognizable to the human eye.

Luckily, Unity has its own built-in JSON serialization tool that works very well with Unity’s Scriptable Objects. This lovely pairing of JSON serialization and Scriptable Objects allows the entire team to make quick edits in the SQLite Database subsystems without getting into the nitty-gritty code or worrying about whether or not their edits will “break” any systems.

This means that any team member — without prior knowledge of how our backend system is designed and functions in the codebase — can come into Unity, create their own Dialogue Scriptable Object, and attach that object to a Dialogue Trigger I-Interactable Object in 3D world space so that the player can interact with it.

Example clip of creating a “Safety Dance” dialogue interaction from a scriptable object

One might ask, “Why use a Scriptable Object and a database? Isn’t that overkill?”. The answer is yes and no.

Yes, it would be possible to only use Scriptable Objects and have persistent data for static objects that aren’t dependent on the player’s actions, such as static NPCs or signpost objects. However, for dynamic objects that are going to be saved and loaded at runtime, such as the Player Inventory, choice-driven Dialogue, Player Stats, and Quest data, these objects require a little extra care in their storage and organization; otherwise, you will lose data between play sessions, and nobody wants that! In other words — No, Scriptable Objects are not a one-stop-shop solution for managing gameplay data, especially persistent data between opening and closing each game session in a final build.

With this in mind, the best option is a coupling of Scriptable Objects for static scene objects and serialized JSON dynamic objects that are saved and loaded as JSON object files from the database’s organized directory.

It’s easier to think of each I-Interactable GameObject interaction as a barcode scanner sequence. The object to be scanned is a 3D-space GameObject, the sticker is a Scriptable Object attached to the 3D GameObject, the barcode image on the sticker is the JSON serialized file, and the barcode number below the sticker is the database table entry that saves and loads the file under its unique ID. Lastly, the I-Interactable script functions as the scanner as this 3D serialized object interacts with the player in world space.

Hopefully, this outline of ArcLight’s Dynamic Database system is helpful for explaining some of the higher mysteries of backend scripting in Unity. For my next objective, I plan on finishing the Quest system’s event-driven data processing. Right now it has many placeholders from debugging, but since our team has finished the storyboard for our first quest it’s time to plug real data into the backend of the quest system. I will also be working with Zared on developing the UI interaction scripting so that it is not only beautiful but also fully functional and supported by all backend systems.

Stay tuned for the next ArcLight update! As always, your feedback and support are much appreciated!

--

--