Discussion Best Practices - Data Structures for "Market" System

Hi all,

I've been coding for a while but generally new to Unity. I'm in some very early planning phases of building a dream game of mine and had some questions about how best to approach a few things.

Problem Statement:
I want to build a market system into the game. This market would allow players in different places to put things into a global market place for sale or to buy. I'm unsure the best data structure or object to use to do this.

My initial research in the documentation led me to think I would need a Scriptable Object to store some structure that would track all of this. My web-dev part of me would just make a database table, but that doesn't seem to be a good option for games due to poor performance. Do I just make a new class for items and then store a hashmap of those? Having trouble getting google to give me a clear answer on this one so any insight is appreciated.

Thanks in advance!

 

Don't confuse the strategy you use with the tactical objects you use.

In Unity I would never reach for an actual "database" unless I had actual "database-y" queries to do. When I say "database" below I mean "some repository of data."

This is my pre-made store / inventory / character selection screen blurb:

These things (character customization, inventories, shop systems) are fairly tricky hairy beasts, definitely deep in advanced coding territory. They contain elements of:

- a database of items that you may possibly possess / equip
- a database of the items that you actually possess / equip currently
- perhaps another database of your "storage" area at home base?
- persistence of this information to storage between game runs
- presentation of the inventory to the user (may have to scale and grow, overlay parts, clothing, etc)
- interaction with items in the inventory or on the character or in the home base storage area
- interaction with the world to get items in and out
- dependence on asset definition (images, etc.) for presentation

Just the design choices of an inventory system can have a lot of complicating confounding issues, such as:

- can you have multiple items? Is there a limit?
- if there is an item limit, what is it? Total count? Weight? Size? Something else?
- are those items shown individually or do they stack?
- are coins / gems stacked but other stuff isn't stacked?
- do items have detailed data shown (durability, rarity, damage, etc.)?
- can users combine items to make new items? How? Limits? Results? Messages of success/failure?
- can users substantially modify items with other things like spells, gems, sockets, etc.?
- does a worn-out item (shovel) become something else (like a stick) when the item wears out fully?
- etc.

Your best bet is probably to write down exactly what you want feature-wise. It may be useful to get very familiar with an existing game so you have an actual example of each feature in action.

Once you have decided a baseline design, fully work through two or three different inventory tutorials on Youtube, perhaps even for the game example you have chosen above.

Or... do like I like to do: just jump in and make it up as you go. It is SOFT-ware after all... evolve it as you go!

Breaking down a large problem such as inventory:

https://forum.unity.com/threads/weapon-inventory-and-how-to-script-weapons.1046236/#post-6769558