Hi! I am Ivan, Return to Divinity's Team Leader, Project Manager, and Senior Developer. Today, I wanted to highlight the technical design of the item inventory, why it is designed this way and what are the benefits of this particular implementation approach.

I. Problem

We as a team have agreed that introducing items with passive status effects that can be purchased for gold gained in combat will help add meaningful progression into the game. The question is now, what would that look like in code?

Any good building starts with concrete plans about what this building will be used for. Software is no exception: a sensible and convenient software architecture can be built only if we define some conditions for which it is used. With the abovementioned items, we know that:

• Items will stay with the squad until the end of the run, i.e. until the game is lost or won. Inventory clears on game start and game end.
• Every item can have an associated status effect (increase squad damage, speed, etc.)
• The only way to get items is to buy them from the Trader for gold

II. Solution

With the problem defined, we can think about our solution. As usual in my blogs, let's start with the architecture.

II.1. Architecture

- InventoryItem is the representation of an item in an inventory. It has its basic item info like ItemName, GoldCost, and Description as well as a list of passive InventoryItemEffects. InventoryItem does not do anything itself and is a mere information container.

- InventoryItemEffect describes a particular passive effect an item can have. InventoryItemEffect provides a list of possible status effects that the game designer can pick from and then contains variables that would be relevant to this effect. Any special variables that are not directly related to this effect would be hidden. Similar to InventoryItem, InventoryItemEffect is merely an information container; it is up to game systems to account for the presence of the effect on an item.

- InventoryManager is a system that will control all the inventory changes. It is already implemented in its basic form for using Health Potions.

- DivinityGameInstance is a special persistent object that exists from application start to application end, and one of the few objects that do not change on level transition. That is the place where our inventory information will be stored to ensure it stays intact as the squad travels through encounters.

II.2. Use scenarios of the inventory

The visualization below describes the major use cases for the inventory in our game.

II.3. Advantages

There are several advantages to the chosen technical implementation of inventory, items, and item effects:

1. Modularity of item effects (which are extracted as their own information structure) enables game designers to create a library of status effects that could later be swapped or modified at will.
2. Representing associated passive status effects as a list creates a simple way for game designers to give one item several simple effects should they choose to.
3. Caching (mentioned in the second attachment) sums of similar item effects drastically cuts down on calculations.

Why does caching matter?

Imagine the following example: the squad has 7 items that may or may not increase the damage Heroes deal to enemies. On every attack, the game rules system will have to look into the inventory and walk through the 7 items, check for each whether it affects the damage dealt, and account for that effect if true.

Multiple heroes may execute an attack in just one second. Then, there are also enemies, and their damage may also be moderated by the items in the squad inventory. All of a sudden, there is a potential for the inventory to be checked several hundreds of times every single second, even though the items themselves did not change.

Now, if we cached (saved) those sums for each effect, we could simply retrieve the cached value of, say, the dealt damage modifier, and use it when calculating damage. We would not even need to check what items the inventory has in it to know what total impact they have. And whenever the inventory is updated - which would likely happen outside of a battle - we would simply refresh the cached values.

Conclusion

That was the overview of the inventory system I designed for our game Return to Divinity. I hope you found it insightful, and I thank you for your time.

Best,
Ivan Shyika
Team Leader, Project Manager, and Senior Developer of Good Faith Team