17. Unreal Engine and Java server – how to equip items with inventory

In this post we will have a look at what implementation I’ve put in place for equipping items.

This post is extension for Chapter 13 – creating MMO inventory with Java, which made a base inventory/items implementation.

YouTube for this post can be found here:

The Java server code can be found here.

The high level design of implementation:

Please note that this is not exactly the representation of what is built, but a close approximation. The reason is because I am using NoSQL therefore I don’t have the same exact associations.

Also, the Weapon, Legs, etc. and WeaponSlot, HelmSlot, etc. are not db models but rather Java objects. Java knows to extend the DB models to those types based off the category field. This allows us to use the tags in different ways depending on what the object is.

Let’s talk about reasons for each piece and how it works.

Item design

The item is unique item piece created by game designers. There will be many types of items, such as weapons, shields, helms, consumables, etc. The types are determined by category. In Java you’re able to distinguish the object type based on this category and use the correct class to work with it.

Items have Tags which are basically a mapping of properties. This allows you to not statically define your parameters. For instance you can have properties with:

• damage: 50 (for weapon)
• defense: 25 (for armor)
• healing: 300 (for potion)

and notice how you’re now able to place ANY of these properties inside tags, and determined by the category field you can use them as desired.

This is a powerful polymorphic technique which allows you to build scalable objects – sort of making it future-proof.

Item Instance

Item instance is a unique instance for the item. This is not essential in some games, but if you plan to have any features that may have item modifiers, then you will need this or something similar (e.g. you could have a unique identifier on character item).

For example, if you want to have a system where you can ‘sharpen your weapon’ or apply a buff to it, you want to only apply it to a certain instance of the item, not globally.

Furthermore, its to ensure the same item reference is used when you keep the item in your inventory, drop it or trade it with players.

Dropped Items

This object contains:

• dropped item ID
• location of the item that’s dropped
• item instance (containing the actual item that’s dropped )
• updated at, which is important for cleaning the items

There is another potential improvement that we need to make, which is to add belongs to field. Generally after items are dropped, only the player that the item belongs to can pick it up.

I will look to add this in future.

Character Item

Character Item is essentially the items that the player has in their inventory. It has a location field which specifies the location of the item in their inventory. Its linked to the ItemInstance object but as we’re using NoSQL, I am just copying that object across for faster reads.

Inventory

This is the inventory that the user has. It’s mainly a collection of the CharacterItem objects, but it also contains some fields such as max size for the inventory, gold, and the character name that it belongs to.

Rather than having a separate table for the Character Items, since I am using NoSQL, its just a nested document inside this table. This would speed up reads.

Equipped Items

This part is fairly important.

You could just have equipped field on your item instance, which may be fine for some games.

I explicitly made this equipped items field because there can be some more complex logic behind equipping items.

For example, you can have a 2h weapon that requires both slots, the weapon slot and the shield slot.

In those cases, you should have some easy to use model to classify that behavior. FYI I have not yet implemented such behavior, but I am creating a system design to support it.

Again similar to Items, we have a category field which defines the slot types.

This is useful for validations, for example you cannot have two helmets equipped. So you search for slot types of particular category and unequip them.

Testing

For this episode I will test it using Postman.

If you’d like to try this out yourself, I created a file: resources/items/create-items.txt with the items that I create using Postman requests.

I also added the postman collections to resources/postman/Item.postman_collection.json

So in order to test this, we will:

• create base items
• generate player inventory
• spawn items
• pickup items
• get inventory
• equip items from inventory
• get equipped items
• un-equip items from inventory

1. Create base items – use the create-items.txt file and the create items API call to populate some base items.

2. Generate player inventory – when you create a player this will happen by default, but here we did not go through registration so we will generate inventory on the fly.

3. Spawn some items – we generated some items in step 1, lets take a couple of those IDs and spawn them, IDs [500, 600, 700] which will be a small axe, wooden buckler and leather belt.

4. Pickup the items – you can do this by scrolling down in the response object from Spawn Item or use the Get nearby items request. You’re after the droppedItemId from there, to insert into pickup item request.

5. If you picked up the items successfully, then get inventory call will return the three items that you’ve collected.

6. Equipping items from inventory – you do this by copying the itemInstanceId field from the items that you have in the inventory. Paste them into the equip item request object. Do this for all three items.

7. Getting equipped items – this should show the three items that you’ve picked up AND equipped now.

8. Finally let’s un-equip some items to complete the testing. You do this again with the item instance ID. I’ve made the un-equip endpoint return the inventory object in-case that’s useful for the game engine. I will potentially be modifying this as per requirements when integrating this with Unreal Engine.

Conclusion

We’ve now got a relatively useful inventory module built up in this project. In the next post I will look to integrate this with Unreal Engine for a live demo.

There will be potential modifications for the response objects to satisfy the UI requirements.

Also note that there are many ways to build these systems and you have to choose the tradeoffs that make sense.