Item Upgrades

There are many ways to upgrade an item:

Parent/Child Item Definitions

This is the recommended approach if you have a simple upgrading system where upgradable items have a finite and linear upgrade path. By finite and linear path means items which upgrade with the same result each time. Example : Sword -> Sword +1 -> Sword +2 -> Sword +3. With this approach you can have one Item Definition for each sword: Sword, Sword +1, Sword +2, Sword +3.

The Item Definitions can then be linked with a parent/child relationship. This allows you to inherit attribute values of the parent which can then be overridden or modified for each definition. This is a great way to say “Sword +2 must always have 20% more attack than Sword +1”

A new Item Definition attribute called Upgrade of type Item Definition should then be created. This will allow you to link the Item Definition upgrades in order. If needed a UpgradeRequirements attribute of a custom type could be created. This attribute would decide when you are allowed to upgrade your item.

A custom script would then be necessary in order to get the upgrade requirements and check if the upgrade is valid. If it is valid the item can then be replaced by the new one using the Upgrade Item Definition attribute.

This approach is fairly simple and offers a good solution for those who want an item upgrade system that is easily manageable. Note that it is a trade off with scalability, as this approach does not scale well once you reach hundreds of upgradable items with many upgrades each.

Item Definitions and Item Attributes

This approach is recommended if you have an simple item upgrade dependencies and few upgradable items. 

This approach uses Item attributes to define the Item Definition array/list that the item can be upgraded to. As an example imagine that you have a Sword with 3 attack and a Sword+1 which has 5 attack. The Item Definition “Sword” could be created with the string[] attribute UpgradeName and int[] attribute UpgradeAttack.  The item should then have two int attributes called Attack and Level.

Within a new script you can check the item level to know if the item can be upgraded. If the item can be upgraded the item’s Level attribute should be increased. The the Item Definition’s UpgradeName and UpgradeAttack can then be fetched to replace the item’s name and attack values.

Upgrade Items and Upgradable Items with Slots

This is the approach that is used in the demo. That does not mean it is the best approach for all cases. This approach consists of two parts. Upgradable items and Upgrade items. Upgradeable items are items which can hold other items in an array called Slots. These slots can be populated with items categorized as Upgrade items. This allows you to create one upgrade item that can be used to upgrade any upgradable item.

A base value needs to be added to the Item Definition and this value is recomputed each time the item is upgraded. A new attribute called Slots with type ItemAmounts should then be added to the Item Definition on the upgradeable item. This stores the items that the item can be upgraded to. A new script should then be created which knows how each upgrade will affect an upgrable item of the Item Category. When the item is upgraded the correct upgradable item can be selected based on the base value on the ItemDefinition and the upgrade items that are contained within the Slots attribute.

In the demo scene the “Boost upgrade” upgrades “Weapons” and “Armors” items differently. It will increase teh Attack attribute on the Weapon items and increase the Defense attribute on the Armors items.

This approach is very flexible and scalable though it requires a more complex script compared to the two previous solutions.

Crafting

This approach is different compared to the others. It uses Crafting Recipes as a base for upgrades. With the crafting system you create a list of generic ingredients and have a custom Crafting Processor which follows different logic depending on the ingredients provided. You could have a recipe called “Weapon Upgrade” which is defined using Item Categories as 1 Weapon + 5 Materials. Your Crafting Processor would take items that fit that description (for example, 1 Sword + 2 Iron + 3 Bronze). It could then compute the swords upgraded attack value using the rarity and compatibility of the materials as parameter. The same Crafting Recipe and Crafting Processor can be used to upgrade any weapons

This approach is most appropriate for very complex systems and as it requires more code than the other solutions. It is recommended for intermediate level programmers.

Which workflow is the best?

There is no workflow that is better than the other. They all have their advantages and disadvantages. The workflow that you should choose should depend on the desired structure of your inventory. You can also mix and match the approaches to take advantage of their strengths.