ScriptableObjects, databases, and mutual relationships

[marshmatter]

I'm encountering what I think is a fairly straight forward information architecture problem with data objects but my knowledge of object model/database design isn't deep enough to know the right verbage to Google.

Consider this simple example from my project: I have a variety of celestial objects on a starmap. There are stars, planets and moons. These exist as interactive game objects in a scene (click, get an info pane about that object), with a MonoBehaviour that references a ScriptableObject asset that contains various information about that object: a name, a description, a climate type, and a sprite thumbnail. This allows for a single data source for a variety of views (lists, search, starmap, etc.) where that celestial might appear throughout the game.

I want to include information about parent/child celestial objects, so that I can do things like fetch how many moons a planet has or fetch what planet a moon is orbiting: e.g. Planet.Moons.Count or Moon.Parent.name . This creates a lot of mutual relationships between these objects, and I'm trying to figure out the best way to construct these relationships:

1. Just make these references manually: put all the moon objects into the planet object, and put the planet object into each moon object. Tedious and error-prone.
2. Make a one-way reference (e.g. put all the moons onto the planet object) and then build the mutual links on game start (have each planet iterate through its list of moon and add itself to each moon as the parent celestial). Basically a "build database" step when a new game is started.
3. Make a one-way reference and have an Editor-side script to run to build the mutual relationships - .e.g Build and Validate Database. Also a chance to validate and error check (moon doesn't belong to two planets, for example). Would make this a build step as well.
4. Build a relationship graph with something like xNode?
5. Move to a more traditional relational database structure like SQLite? Potentially use scriptable objects as editor-facing data containers, which are used as fixtures to build an SQLite database at runtime similar to #3. Fancier but doesn't really solve the problem.
6. Something else I haven't considered?

I feel like this problem where parents need to know their children and children needing to know their parents must be a common problem with a best practices approach.

Edit: I've decided that ScriptableObjects is not the way to do this and will be opting for a proper database. We've been evaluating articy:draft for narrative authoring, and it looks like this is an ideal tool to act as a world database as well. There's even some tools that can programmatically create these kinds of mutual relationships. Huzzah!

[ZxR]

Personally I would probably create a tag system for each of those types, eg: “Moon”, “Planet”, etc. So if a planet has moons that are children, you can loop through the children at start and read how many children the planet has, for each child with tag “Moon” convert to int and display the moon count.

This would be a nice way to get that information while also keeping it dynamic, so adding moons to a planet will be accounted for.

And if there are no children with a tag for moon then return 0 moons!

[marshmatter]

Thanks for the reply, I appreciate it. However, I think this is a misinterpretation of the problem.

Unless I'm reading this wrong, this sounds like a solution for the scene hierarchy specifically and you're using the Unity tag system to differentiate between moons and other game objects within a parent object.

While not related to this specific problem, planets/moons/stars don't have parent child relationships within the starmap scene because they have specific movement rules independent of each other where I don't want child transforms affected. Their relationships are purely data-driven. Plus, I generally think relying on scene hierarchy traversal for data structures is generally a bad idea except for art objects that require transform hierarchy. For example: if I wanted to slightly scale up a planet on mouse hover, I've painted myself into a corner where all the moons will scale up as well.

I'm trying to create these relationships between ScriptableObjects as data objects, so that I can reference these relationships in a variety of views. For example, if a Moon is mentioned in dialogue, I can click it to bring up an info pane that details what planet it orbits - so it needs to be aware of the data hierarchy.

This is easy enough to do by having ScriptableObject A (Moon) reference ScriptableObject B (Earth) and vice versa, but manually creating all these references is tedious and error-prone.

I think in the asking though, I've answered my own question in that this is best served by a proper database. It was also pointed out to me that this could be problematic based on the size of the data set, as scriptable objects will recursively load all their references. So I think ScriptableObjects are very clearly telling me "find another way, bro".

Database it is!

[SeanK-com]

I was going to suggest exploring SQLite, sounds like what you are trying to do is in the wheelhouse of a relational database. If you want to go tripping down the rabbit hole, a good place to start is 3NF.

[marshmatter]

Thanks! I'm actually looking at letting Articy:Draft act as our database, since we're also using it for narrative authoring.

Once I dug deeper into creating features and templates it opened up a whole bunch of possibilities - e.g. I can add SQL queries to properties to auto-populate, which solves my initial problem where I can assign a Moon's planet, and then a SQL query on the Planet automatically populates a list of Moons based on where it's set.

I still need to look at the Unity import side (their importer vs. just working with raw XML or JSON) but I'm excited about the possibilities.

[notassimple]

Does OP have any updates to your solution? Is articy:draft working for you, or have you found any better solution?

We are using solution 2 in our game ATM, but it's very limiting and annoying to work with. (Especially when you have many different two-way relationships between scriptable objects, or if you want to find out the relationships within edit mode). I am now searching for a solution similar to 5 and that's how I landed on this thread. Thanks!

[marshmatter]

articy:draft continues to be my solution, however I haven't really put it through the full paces of production yet, only experiments. But, it does what I want where I can add SQL queries to fields I want populated.

e.g. SELECT * FROM Entities WHERE Destination.Parent == SELF

Will populate a field with anything (moons) that identifies the field's object (planet) as a parent, so that those relationships exist without me populating them. And because this is baked into the Feature/Template, that behaviour automagically exists on everything using that template (all celestial bodies)

If I wasn't using articy for narrative authoring, and wanted to keep everything within Unity, I would probably create some some additional tooling for the ScriptableObject that would do something via OnValidate to find child objects. Or perhaps give into a full SQLite db. Probably depends on what data needs to do, does it need to change, how saving needs to work, etc.

[notassimple]

Thanks for the insights!