When creating a database it is important to organize your objects and attributes thoughtfully. The descriptions below give an idea for how you should setup your database.
The most common attributes which are sometimes predefined in the UI Item View Modules or other components in the system can be found here.
The item category will define what your item can and cannot do. Examples of categories could be Equippable, Consumable, or One Handed. The categories can be nested with multiple parents the items that are part of a category will inherit all the properties from all the parent categories.
Mutability & Uniqueness
Categories also define if their direct items are mutable and unique. Mutability defines if an item can have its attribute values changed at runtime
Unique defines if the item will try to stack together when possible. Note that mutable items that are common (not unique) will keep the attribute values of the pre-existing item when stacked.
Examples for mutable/unique categories:
- Immutable & Common: Any items that do not change once created. The same item reference will be used for all items with the item definition as long as they have the same attribute values. Examples include a Materials category for items like Wood, Rope and Steel.
- Mutable & Unique: For items that should be considered unique. Unique in the sense that two items of with the same item definition won’t have the same reference or ID. Since the items are mutable their attributes can be changed at runtime, changing the attribute of one item will not change attributes for another as each item is unique. Examples include a Sword category with items like Iron Sword and Great Sword.
- Immutable & Unique: Functions the same as Immutable & Common but items won’t stack in the default Item Collection. Examples include a “Key Item” category for items such as Map, Boss Key, and Chest Key.
- Mutable & Common: Similar to Mutable & Unique except that when an item is added to a collection it will try to stack on top of an existing item with the same item definition. This is a good option when for equippable items that require mutability to be equipped yet does not need to be unique. Examples include a Grenade category for item like Flash Grenade and Frag Grenade.
Mutability and Uniqueness only affects items that are directly under that category.
When defining your attributes it is important to place them in the correct collection. There are three options:
- Item Category Attributes: Attributes that relate the category directly. Examples include a Category Icon. All item definitions and items within a category will share that same attribute value.
- Item Definition Attributes: Attributes that will be shared by all items within the same item definition. Any attribute that will not change at runtime should be set here. Examples include a Icon such that each item with the same item definition can have their own icon.
- Item Attributes: Attributes that may change at runtime. These are specific to the item itself. Meaning two items with the same item definition could have different values for the same attribute. Examples include a Durability attribute that decreases for each strike of a weapon.
At runtime you may want to change the attribute value, such as to increase the attack value of the weapon. One solution may be to increase the attack attribute, but it may be better to replace the item by a new one.
As an example your database could have item definitions: Sword, Sword +1, Sword +2. When you upgrade a Sword it gets replaced by Sword +1 item. This allows you to keep the item attribute values separated for each weapon behavior. Item definitions can be used to implement this structure cleanly with the parent system. With a parent structure of Sword -> Sword +1 -> Sword +2, all attribute values will be inherited by the child item definition.
The Sword category is Mutable and Unique. In the demo a sword can be upgraded by attaching “upgrade” items to it. This means that each sword must be unique and mutable. Mutable is required so you can change the attack and “upgrade” items at runtime. Unique prevents the sword from stacking with the same item definition.
As shown in the screenshot the sword category has two category attributes:
- CategoryIcon is inherited from the Viewable category. This attribute defines the icon that should be shown in the editor.
- AnimatedID is inherited from the Animated category. This is used to know what animation to use when attack with a sword. All items in that category will animate the same way.
The item definition attribute are specific to each item definition, therefore each item definition in this category can have their own values for the defined attributes. Notice BaseAttack is part of the item definition. This value will not be able to change at runtime.
Only Attack and Slots will be able to change a runtime and therefore they are the only ones added as item attributes. Attack uses the modify variant to copy the BaseAttack value by default. This value can then be changed at runtime.
The Material category is Immutable and Common. It is Immutable because it has no attributes that need to change value at runtime. And Common because material items need to stack automatically.
The only category attribute is the CategoryIcon.
All the other attributes are set as item definition attributes.
There is no need for item attributes since all material item definitions will have a single item each.