Hi! Ivan is here again. I am the Team Leader, Project Manager, and Senior Developer on our game Return to Divinity. Today, I would like to tell you about the refactoring of the item/inventory system for Return to Divinity.

In my previous devlog from last week, I shared the design of the inventory system. In response to my post, my connection Jazmine Chargualaf shared with me the Working with Data in Unreal Engine 5 presentation by Jack Condon. It highlighted various tools Unreal Engine 5 provides for handling data and impressed me so much that I decided to refactor the existing item implementation.

The motivation behind the refactoring was to proactively facilitate working with items for the future stages of development, where having a simple interface for adjusting item stats (and tracking their changes) would be a great time saver.

Overviewing changes

What the designs were:

• Item is a self-contained UObject.
• The catalog of items the trader may offer is defined in a custom GameInstance (which lives "above" the in-game level and persists from application start to application end).
• TraderActor has a list of offered items generated based on the catalog specified in the abovementioned game instance.

What the designs have become:

• Item data is contained in a special structure; the item asset is now an item data wrapper and a Data Asset subclass.
• TraderActor's catalog of items is now specified in TraderActor. No dependency on GameInstance.

Reasons and Benefits

Separating Item Data from Item Asset, and the upgrade from UObject into Data Asset

First, having item data separate from item assets allows the developers to change how the item data is represented without changing what an item actually is. Simply put, I can change the facade however I want without affecting the core. It is like you dressing differently for different occasions but remaining essentially the same human being.

Second, even though presenting items as UObject assets is a valid way, it is logistically inconvenient: every item is essentially a sub-archetype of items, and to get the item data, you would need to create an instance of that archetype with its default data. Even though Unreal Engine has a convenient function UClass::GetDefaultObject() for this exact purpose, I would much prefer to have direct and easy access to item data - because those item assets are meant to be concrete instances in the first place, not archetypes.

Data Assets act as concrete instances rather than archetypes when you work with them, which allows me as a developer to reference the data I need directly.

Furthermore, Unreal Engine has a built-in feature for tracking changes to Data Assets (which allegedly also works with UObjects, too, but it did not support our kind of items).

TraderActor

1. The ability to specify the catalog of offered items in the trader actor itself allows the customization of that catalog for every trader in the game. Keeping that catalog in the GameInstance object, which would persist through the entire game, would not allow for that customization.
2. There are no reasons for the trader item catalog to be stored in GameInstance. The dependency is unfounded.

Conclusion

Have we added new features to the game? Not necessarily, but refactoring is not about adding features: it is about making their implementation more stable and easier to work with. These changes will save designers time when they are creating and tweaking items later in Alpha and Beta.

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