Hi all,

I´m currently working on a little 2D "explorer game" in Unity and do have some problems with the item database.

First I created a simple XML Database in which I stored things like ItemValue, ItemDescription.....and also the Path to the specific prefab. Because I wanted to manage my Database only in one place, I started to build a Custom Editor and used Scriptable Objects to represent my desired Item Hierarchy.

At this point I learned a lot about Unity´s crappy serialization system and how you have to do "big" workarounds to save your Database without any restriction like "No support for custom null classes, no support for polymorphism....) .

I started to realize that I have to setup my own little "system" to get the job done but I can´t get my head around the whole thing.

1) Lets say I have the raw data representation of my Items (ItemID, ItemDescription, ItemValue e.g) saved  in a .json or .yaml file, how do I map the "raw data" to the visual part of the item (in game)?

    Should I create the Items dynamically (e.g create some factorys for diffrent item types and build them in code)?

    Should I rewrite my "custom editor" to create acutal  prefabs and save the path to my desired item like I did in the XML thing?

    Is there an best practice for this kind of problem in Unity?

Kind regards,

You probably do want some sort of factory, yeah. For example, your database might include a field like "InGame Prefab Name", which your factory can use to look up the relevant object to Instantiate. Your factory itself might just be a MonoBehavior with an array of prefabs, and you can iterate through them at runtime to find them by name.

Something you didn't mention, but which is important to think about, is to have a clear understanding about the difference between an item instance and an item type (also known as an item definition, or an item archetype, or similar). For example, you might have 1 row or definition for the type, which has the basic properties, the name of the prefab to be used, etc - but that doesn't tell you where you might find instances of that object in the game. That would probably be in a different table entirely, or handled via a different system (e.g. a 'spawn' system), which creates item instances in the world given an item type and a position.

Hi Kylotan,

thanks for your reply.

At the moment I have an abstract class called "BaseItem" which serves as the base of all evil.

The classes Consumable, Obstacle and Material inherit from the root class. 

All items share some base information like ItemID, ItemName, ItemDescription, ItemValue, QuestItem and the child classes have some extra functions, extra fields ect...

Now I can use JSONUtility or the YAMLDotNet Library to de/serialize all that stuff and create objects in code. If Iuse the .json format I could go further and use MongoDB to manage all that stuff (for example).

But thats only the "definition" of the items and the way I save them on the disk.

Now imagine I load my Database in some sort of data structure when the game starts which gives me the possibility to iterate through all my items at runtime or do other fancy stuff.

The next step could be an abstract Item Factory. 

If I want to spawn a mushroom  I could say  "Hey Consumable Factory, create some nice mushrooms for me".

Then the spawn system can get some sort of notification to spawn that shit at position X/Y.

Now I try to ask my question in a diffrent way:

Should I create the prefabs for each Item manually and save only the paths into my database so that I can do something like this:

Instantiate(Ressources.Load<SomeType>(SomeType.prefabPath)) OR

Should I create the "game objects" dynamically with some sort of factory like:

Okay Consumable Factory, I need a mushroom and a mushroom needs a Rigidbody2D, a BoxCollider and a SpriteRenderer.

I would recommend that you create the prefabs manually, assign them into some object in the inspector, and use that object at run time to look up the prefabs that you want to spawn. Resources.Load is not a good system to use, generally.

You don't need to construct the object component-by-component; the Unity prefab system exists entirely so you don't have to do that.

Hey Kylotan thanks for your reply and sorry for my absence!!!

I think something is wrong with my brain or with Unity.

It´s true, Unity´s Prefab System exists to hold the recipes for specific entities but I can hardly believe that adding thousands of prefabs to a GameObject is the right way.

Many developers from which I have read the dev. log used databases like MongoDB, SQLLite, CouchDB or what ever to store their data...so there must be a way or a pattern to associate the metadata from  my  items (damage, defense, special effects...) with specific prefabs/objects in Unity.

The only way I can think of to achieving this is to create the prefab through a custom editor and save all paths into my item and serialize it or create a component system and add only a "prefab component" to items which need a visual representation (and save all relevant infos in this specific component)

Would this be a valid option too?

Firstly, most single player games don't have thousands of item types, so the problem of scale you mention never comes up. They might have a few hundred, but it's not a hardship to add them to a game object one by one, any more than it would be a hardship to add them to a database one by one.

Secondly, developers that are using MongoDB or CouchDB for their data are typically working on online games. You don't use this for client-side data because you aren't going to ship an instance of Mongo with your game! Nor are clients going to connect to a shared database. When working on a persistent online game the database is made necessary by other constraints, and given that they already have a database connected, it can make sense to extend that usage to include storing their object types. But again, that is for online server-side data, not for client-side data. (If you have some specific articles you've seen, feel free to link them and we can discuss what they're doing.)

SQLite, however, can be a good solution for client-side data. It makes a lot of sense for multiplayer games when you maybe have an SQL database on the server and you can get some benefits from having a very similar table structure on the client, allowing you to share identifiers and maybe some code. If you don't have the server, these benefits disappear, so you have to consider whether SQLite gives you anything useful. In the case of Unity, the answer is often no. Unity's serialisation system and prefabs already give you a decent interface for adding, editing, and storing your game data in the editor.

What is the reason you have for wanting to define your item properties separately from the Unity data? Is it a multiplayer game? Do you have a separate tool that you'd prefer to use? You can export that data in whatever form you like but ultimately you're going to want a process of matching up Unity prefabs to item properties and that's where a name=>prefab database comes in, whether that is an array of Gameobjects or a wrapper around Resources.Load or access within an AssetBundle or similar. Even if you had an SQLite DB locally which contains your object data, you still need a routine that finds the prefabs accordingly, and then, most likely, injects the information from the database into the in-game objects. Often that is more complex than just defining the data in Unity directly!

On 17.8.2017 at 11:14 AM, Kylotan said:

What is the reason you have for wanting to define your item properties separately from the Unity data? Is it a multiplayer game? Do you have a separate tool that you'd prefer to use? You can export that data in whatever form you like but ultimately you're going to want a process of matching up Unity prefabs to item properties and that's where a name=>prefab database comes in, whether that is an array of Gameobjects or a wrapper around Resources.Load or access within an AssetBundle or similar. Even if you had an SQLite DB locally which contains your object data, you still need a routine that finds the prefabs accordingly, and then, most likely, injects the information from the database into the in-game objects. Often that is more complex than just defining the data in Unity directly!

Because Unitys serialization system sucks as hell. In my opinion it is not really possible to write object oriented C# Scripts when Unity is not be able to serialize custom classes/generics without hacking something together like there is no morning. Therefor it shouldn´t be more complex then writing my own system especially when there are libraries like Json.NET which has very cool features for JSON serialization.

But no matter which system I use, the 

Quote

a routine that finds the prefabs accordingly, and then, most likely, injects the information from the database into the in-game objects

make me some headache because I don´t know how to connect the "raw data" with the prefabs/gameobjects properly.

Maybe my english is to bad to express my exact problem.

**Edit

https://feedback.unity3d.com/suggestions/serialization-of-polymorphic-dat

Some inspiration from other developers

Unity's serialisation has problems, sure. But there's one thing it can do quite easily, and that's represent simple tables of data - which is pretty much exactly what you'd have with an external database.

To be fair serialising generics is a hard problem in most languages. I don't think UE4 can do a great job of it either. This is very separate from your data model, where the concept of generics does not (or at least should not) exist.

I already explained how to connect the raw data with the game objects, so if that doesn't work for you, you will have to tell us why not, then we can suggest a different approach.

As a reminder, the process can be quite simple:

• Option 1: a gameobject with a list of prefabs, which you populate via the Inspector in the editor. You can iterate through them and pick the right one out by name. These names are stored in your item data. (e.g. {"name": "Sword", "Weight": 10, "Prefab": "Sword123"} )
• Option 2: prefabs stuffed into a Resources directory. You take the name from your item data and get the prefab via Resources.Load. You probably want to use a filename instead of some other name.

None of this particularly cares about how you choose to store your item data - you seem determined to use an external data format or database, and that is your choice, but as long as you include some sort of identifier to look up a prefab, there should be no problem.

15 minutes ago, SongOfDurin said:

Maybe my english is to bad to express my exact problem.

Sprichst du Deutsch? Dein Englisch ist gut (im Gegensatz zu mein Deutsch), doch dein Problem ist unklar...

Ja ich spreche Deutsch :).

I think I mentioned your Option 2 in one of my last posts 

Quote

The only way I can think of to achieving this is to create the prefab through a custom editor and save all paths into my item and serialize it 

With this approach I should be able to centralize my Prefab/Item creation. Then I could use my "item name" or "item id" as the key value and access the prefab over the prefab path in my specific item. But it seems really odd to do this.

As I started with Unity I programmed a custom editor and used Scriptable Objects for my class hierarchie. The bad thing about this was the fact that I had to save every Item Instance as an asset to my "asset database" and after I switched my base class to an abstract base class I got a big surprise: It roasted my whole database. While researching this stuff I decided to to avoid as much as possible because with other serialization technics I get the same resul, with much less effort.