Item support about open-builder HOT 3 OPEN

I have been thinking about how to represent items for a little bit, and I think I have a pretty good idea for an item/inventory system that will be both flexible and powerful. If things about this design aren't clear please let me know and I can work on clarifying and possibly draw out a diagram that outlines the main classes and their interactions. I am working on my Technical Communications skills in general, so I would appreciate any feedback either way. Anyways, onto my actual idea ...

Overview

• Generic Item Class
• Contains a list of Attribute/Component Pointers
• Every behavior different items will need will have a Attribute/Component to hold data about that behavior.
  • I.e. Durability Attribute, Placeable Attribute, Tool Type (Pickaxes mine stone faster), Placeable Block (Voxel Items from the list above), Item does extra damage to enemies, etc.
• Lua creates the list of items in the game. These are then stored in an items Data Structure on the Server
• When a client loads the game, the server sends over a serialized list of these items.
  • Schema could look something like the ItemData Schema below.
• Advantage of using the Attributes is that it makes it easier to add new functionality.
  • For example, if we want to add a display for durability left on a tool, the code that already renders the items would now just have to do a check while looping through each item to see if that item has the durability attribute and if it does render a durability bar.
• Each client would have their own Inventory that just consists of a list of ItemStacks (similar to minecraft).
• Each ItemStack would consist of an id (which corresponds to the master list sent over by the server) as well as a map from ComponentType to ComponentData *. This allows us to keep info that is related to a specific component like a Durability, so DurabilityData would be derived from ComponentData and just have a max durability variable as well as current durability variable in it. Only components that have state would need to have a corresponding ComponentData
• I have several ideas for syncing inventory data. Firstly, when a client loads into the game, the server would send the whole inventory to the player.
  • To update a players inventory, the server could do one of several things
    1. Send the entire serialized player inventory every time there is a change.
    2. Only send the players inventory back to them when they try to make an invalid request.
    3. Only ever send changes/diffs.
• I have written a Inventory Schema below.

Synchronizing Data

Since Open-Builder is a networked, multiplayer game, I made sure to think about how we can serialize the both the items that a server is using as well as the inventory of a player.

The following schemas are json-like objects that are meant to show the structure of how we could send the data.

Inventory Schema:

[
   {
      ItemId: id,
      ItemCount: numItems,
      AttributesData:
      [
         {
            AttributeType: type,
            ConstructorArg1: arg1 (These args are dependent on the AttributeType),
            ConstructorArg2: arg2,
            ...
            ConstructorArgN: argN,
         }
      ]
   },
   {
      ItemId: id,
      ItemCount: numItems,
      AttributesData:
      [
         {
            AttributeType: type,
            ConstructorArg1: arg1 (These args are dependent on the AttributeType),
            ConstructorArg2: arg2,
            ...
            ConstructorArgN: argN,
         }
      ]
   },
   {
      ItemId: 0 (Means that there is no item in this slot)
   }
]

Item Schema

{
   ItemName: “name”,
   ItemId: id,
   ItemTexture: ??? (not quite sure how we want to do this)
   Attributes:
   [
      {
         AtrributeType: type (Probably just a number (enum) that uniquely identifies which derived Attribute this is),
         ConstructorArg1: arg1,
         ConstructorArg2: arg2,
         ...
         ConstructorArgN: argN
      },
      {
         AtrributeType: type (Probably just a number (enum) that uniquely identifies which derived Attribute this is),
         ConstructorArg1: arg1,
         ConstructorArg2: arg2,
         ...
         ConstructorArgN: argN
      }
   ]
}

from open-builder.

In terms of a technical post, I think this is really well and neatly laid out, so that's all good :)

For the ideas posted, it's really good. Love the idea of having items keeping a list of attributes, like as you said that would be very scalable. Also like how you thought about ways the sort of "base data" is separated from the individual item data.

Only thing I can really think of is if there is a way to define attributes in the Lua code itself, but that might be complicating things a bit too much so the current ideas are perfectly fine.

So as far as I can tell this is what we have so far in terms of data, using all caps to show the different struct/schema more clear

ITEM - defines the data associated with a type of item, as well as a list of ITEM ATTRIBUTE

ITEM STACK - Contains an Id for an ITEM, the amount in this stack, and a list of ITEM ATTRIBUTE DATA, corresponding to the ITEM ATTRIBUTE list of the ITEM

INVENTORY - Managed list of ITEM STACK, could also be used to store things like the items in chest, etc

ITEM ATTRIBUTE - Contains info about a property of the item, such as it has durability etc

ITEM ATTRIBUTE DATA - Metadata about an attribute of an invidvial ITEMSTACK, such as how much durability is left in it, etc

Have a flight to catch soon so not sure if managed to list everything, please let me know if I did, but the ideas you have posted are looking great so far :)

Thanks!

from open-builder.

It seems like you summarized what I said pretty well!

I don't have a lot of experience with Lua, but my initial thought is that there would be a specific script that is run when the server starts up that defines the items. I am not too familiar with Lua, but I would think the script to define the items would look something like this (written in Python syntax because I am more familiar with Python):

def defineItems():
    items = ItemList()
    sword = Item("texture_file.png")
    sword.addAttribute("DamageModifier", 10) # add a DamageModifier Attribute with the value 10
    items.addItem(sword)
    return items

Defining all of these things in Lua could get overly verbose, so we could also define them in some file in a standardized format then have Lua read the input from the file. The addAttribute function should basically just call a factory function that returns an Attribute/Component pointer.

from open-builder.