Item Framework

Lark

Active Adventurer
MSC Developer
MSR Developer
Lead MSR Developer
Dec 30, 2009
55
39
Oregon
While I'm waiting on my wife's hand surgery, I thought I'd post some insight on how the item system is currently framed:

Base Item <-- Item Instance <--> World/Inventory Item

Base Item: These are data for your standard MS:C item. Each one only contains data and has a small memory footprint. Features:
- Name (e.g., "Volcano Sword")
- Type (Defined by Tags, like "2H", "Sword", "Fire", etc.)
- Mass
- Value, in gold
- Max Stack Size (default: 1)
- Abilities (Slash, Charge1=PowerSlash, Charge2=FireSlash)
- Description/Flavor Text
- Pointer to (unloaded) 2D Icon, client-only
- Pointer to (unloaded) 3D Mesh
- These pointers dynamically load assets only when needed, and are unloaded when done. Example: Another player logs in with a Crossbow equipped, so your client loads the Mesh for their character. When they log out and no other players have a Crossbow, it is unloaded and Garbage Collected/deleted after some time. This allows for large item variety, if desired.

Item Instance: Data about each spawned Base Item (in Inventory and/or World), owned by the server. Each one has a small memory footprint, but there could be thousands on a server (each NPC or Player could have dozens/hundreds of items). Features:
- Exists in a Character/NPC/Container inventory or directly on a spawned World item
- Pointer to the Base Item
- Pointer to a spawned World Item, if one exists.
- Unique ID (prevents duplication, in theory)
- Owner ID (Player or NPC)
- Stats/Abilities/EXP unique to this item (Currently not implemented, but planned... See below).
- NOTE: Players do not control/modify this data; the server does. If you want to Drop an item, you send a Request to the server, and if valid, the server will Drop your item. The only exceptions would be in single-player, or your own (listen)server.
- NOTE 2: My idea for Items is: They can be leveled and evolve unique stats/abilities tied to your Character, but if you drop/trade it, only the Base Item will exist for another Player. You can also use one 1H item in each hand, or quick-use potions and 1H spells if holding a 2H item.

World Item: The 3D mesh visible in the World, whether equipped or by itself. Features:
- Pointer to its unique Item Instance data.
- Mesh is Async-loaded from the Base Item

Inventory Item: The 2D icon/UI widget representing the item in a storage container (includes Equipped, Trade, Loot, etc). Features:
- Pointer to its unique Item Instance data
- Icon is Async-loaded from the Base Item.
- Only exists on the client as a Player UI/HUD widget. The logic behind moving items between containers is handled by the server, but the widgets themselves are owned by the client.

Summary:
- All Base Item data exists on all clients/servers
- All Item Instance data is owned by the server. Each client only knows about their own items and spawned/equipped World Items.
- World Items are the 3D items owned by the server and visible to all clients
- Inventory Items are the 2D UI widgets owned by the client to display item information and allow the client to request actions from the server.

Ideas/Suggestions for changes are welcome. It should be noted that the Item Instance class isn't even needed, but since the Items poll was split on RNG items/mods, I at least supported the potential feature.
 
Last edited:

Thothie

Administrator
Staff member
Administrator
Moderator
Lead MSC Developer
MSC Developer
Apr 8, 2005
16,212
268
lost
Been while since I commented on any of these, but I'd suggest making most item data simple string tables, so you can tweak the types and properties at any time without having to change the whole struct (or at least have a dynamic string table for "additional data"). Makes for very dynamic items you can tack any number of properties onto as needed. Downside is character file size, of course, and the overhead of searching through a string for a specific property, by its literal name, rather than an index/enum or pointer, is suboptimal, but ya may find that extra bit of overhead worth it down the line. (Certainly would have made our lives easier - only recently added the ability to add one full string to items that saves with them.)

Might also wanna routue your description/flavor text to a language file with tags, along with any other text in game, so anyone can translate it. Was a shame we didn't keep using the Half-Life function for that, but alas, didn't have a method to pull language tags from the titles.txt file in the script system.

Also remind her to keep her hand inside the vehicle at all times. ;)
 

Lark

Active Adventurer
MSC Developer
MSR Developer
Lead MSR Developer
Dec 30, 2009
55
39
Oregon
Good news @Thothie , I've been following Unreal's standard for text localization. FName is used for Identifiers only and doesn't need to be localized. FText is used for _ALL_ text displayed to Players - including the text you might have seen in the Item Stats widgets in the recent video I posted - and is linked with a Key to a row in a Data Table (basically an Excel file) that can have columns added to translate to any language. FString is only used mostly for debug messages and some formatting.

Basically, each Item Instance takes values from the Base Item, tacks on its own instanced values, and creates FTexts that are updated only when values change. These strings are what the UI displays when looking at/hovering over an item.

FName IDs could be an issue later... Unreal makes it easy to serialize and use strings as IDs, but I want to avoid using strings as the primary key for a large database if I can.

As for the Tags: I haven't finished setting it up this way, but I plan to have Tags point to an FText value (that can be translated) prior to being displayed to the user. Thanks for the tip though, I might forego tags in favor of some kinda indexed const FText.
 
Last edited:

Jelly

Adventurer
MSC Developer
RiP
Nov 25, 2005
1,892
8
28
You are here --> X
I like the idea and abstractions between item instances and base items. Great idea to keep a reference to the item instance on the widgets and gameobjects. That way you can do things like special frames around icons of highlevel items or special shaders. I like it!
 

Jelly

Adventurer
MSC Developer
RiP
Nov 25, 2005
1,892
8
28
You are here --> X
Question about abilities:
So items can have abilities, but how will the architecture for that work? Something similar to how it is layed out for items? With base abilities and ability instances, to allow for reuse with different modifiers, perhaps based on level or stats of item or player?
 

Lark

Active Adventurer
MSC Developer
MSR Developer
Lead MSR Developer
Dec 30, 2009
55
39
Oregon
Question about abilities:
So items can have abilities, but how will the architecture for that work? Something similar to how it is layed out for items? With base abilities and ability instances, to allow for reuse with different modifiers, perhaps based on level or stats of item or player?
I've attached a direct screenshot of how I currently have the BaseItems set up, and ItemInstance could also have instanced Abilities that can be added, but that's the par I haven't implemented yet. It wouldn't be that hard to add, though.

EDIT: Apologies Jelly, I read your question wrong. I could probably set up Abilities in a similar fashion, but no, right now they are set up as static Abilities. I would actually like to set them up kinda like Morrowind, where you can create your own spells/spell effects/enchantments (although not limited to just spells).

Untitled.png
 
Last edited:
Top