# Need insight on item system

I have made an item database that takes keyed values from a database script then assigns them to an item class, then stores that item class in a List variable.

This works fine but I have come across something that I see as potentially troublesome. For every unique effect, I have to make another keyed value and apply it to all the existing collections in the database.

I want to make it such that an item can hold only 6 special values(physical damage, magical damage, armor, heal, etc) but with this method, I don't know how to tell the script which value goes to which special effect.

Below is a template item from the database file. I use GRFON for this. See how I have written down all the possible damage types but for special values, I made 7 only with 6 of them being generic. The damage types can easily be assigned but when it comes to the special values, I have a hard time assigning magnitudes to special effects.

{
iD: 0
name: Template
category: Null
type: Null
subtype: Null
values: {
physical: 0, magical: 0, hot: 0, cold: 0, electric: 0, dark: 0 }
specialvals: {
spMag1: 0, spMag2: 0, spMag3: 0, spMag4: 0, spMag5: 0, spMag6: 0, spDuration: 0 }
special: none .
properties: {
mass: 0, durability: 0, maxdurability: 0, charge: 0, maxcharge: 0, accuracy: 0, useRate: 0, reloadRate: 0, range: 0 }
description: This is a template item.
equippable: 0
usable: 0
stackable: 0
maxStacks: 1
count: 0
rarity: 0
price: 0
uID: template
}

• Do I see it correctly that the specialvals.spMag1, specialvals.spMag2 etc. attributes mean something different for different items and what exactly they mean depends on the type of subtype of the item? Feb 2 '18 at 12:46
• Yes, I gave them generic names because they don't represent one fixed effect unlike the damage types. Feb 2 '18 at 13:00

Having variables in data structures which mean different things in different contexts is an anti-pattern. It easily leads to a lot of confusion.

What you could do instead is to store these in a list of key-value pairs.

The JSON representation would look like that in JSON:

specialvals: [
{ key: "fireaura_range", value: 30 },
{ key: "fireaura_duration", value: 10 },
{ key: "radioactivity", value: 10 },
{ key: "considered_contraband_during_smuggling_quest", value: 1 },
{ key: "tastefulness_in_soup_receipt", value: -590 },
]


On the C# layer, you would either represent this with a Dictionary<String, Int32>.

When your item database is an SQL database, then these special values would be stored in a database table separated from the items table with 3 columns ItemID, key and value with the primary key being ItemId and key.

A completely different approach would be a component-based architecture.

Instead of trying to represent every possible item functionality in one class, you create a bunch of "component" classes and each item can have any number of these classes.

   components: [
{ type: "aura_damage",
element: "fire",
range: 30,
duration, 10 },
{ type: "soup_ingredient",
taste: "salty",
value: -590 },
{ type: "smuggling_quest_contraband",
illegality: 500 }
]


Your item would then have a list of components with 4 entries. Each entry would be a different class which inherits from a Component base class and has the variables applicable for that type.

• I am aware of that but I figured it would make my database very large as I add more items. Is there no way to effectively(without having to make additional scripts) have some generic values used in different contexts based on the item? Feb 2 '18 at 13:20
• @Aeiou I don't see how that would make your database "very large". It's not that much larger than what you already have now. The problem with generic values which mean different things based on the item is maintainability. In a year from now you won't remember anymore which variable means what for what item. Feb 2 '18 at 13:24
• Can you elaborate on your second approach? I don't see how I can recycle code in the second method. Feb 2 '18 at 14:00
• @Aeiou Different components are used by completely different game features, so there would not be much opportunity for code reuse. If you do have any code duplication between components, you would extract that to a common base class for those components. Feb 2 '18 at 14:51