In Progress: Item Definition Data Files - Rules and Function

[GlyphGryph]

Some of you may be aware that I’m trying to gut our current item system and replace it entirely.

Basically, this is going to serve as my working reference repository while I do so. Suggestions are appreciated, and hopefully this post will describe the latest form of item_templates (the things actual in game items are built from, and what’s actually defined in this file)

The structure is pretty basic right now, and doesn’t have all (or even most) of the attributes it will need to work with the game yet. I expect that to change in the near future. Also, it’s in JSON, because that is the file format we’ll be using.

[  { "key": "UNIQUE_KEY_VALUE", // This string represents an items unique identifier. Additional definitions with the same key will be ignored. No spaces.
    "name": "Item Name", // The name
    "description" : "This is a a generic item. It is glorious." // Don't worry about adding newlines for display purposes, I'm going to let my rendering code figure that out."
    "weight": 10, // The  weight
    "volume": 4, // The volume
    "variations": [ {  // You can swap out a set of values for a different set of values without creating a new item. Right now, just for name and description.
      "odds": 200,  // The odds, in hundredths of a percent, that this variation will replace the default. This is a 2% chance.
      "name": "Alternate Item Name" //The value to be changed if this variation is selected.
    },{
      "odds": 50,  // The odds, in hundredths of a percent, that this variation will replace the default. This is a .5% chance.
      "name": "Super-Brand Alternate Item Name" //The value to be changed if this variation is selected.
      "description": "This is the best damned generic object you've ever seen."
    }
]

I do hope on generalizing the code for handling “alternates”, my current implementation is a wee bit lacking. I think it will do a lot to add flavour to common objects, but far more importantly, it will do a lot to enable completely NEW types of objects: Things like notes or journals, for example.

They could all have the same item key, meaning there’s a chance for any of them to spawn, and you only have to add one entry, but adding additional potential contents for those journals suddenly becomes trivial.

[theShaikan]

Veeery nice. This should make longer descriptions more fun to write… I kind of go overboard, dropping lore and explanations on top of outward description and the code does not quite agree with me usually. Is this also going to be taking care of lines going too long before adding a break, no matter the viewport size?

[Shoes]

Will it be easy to add new properties? It seems like it. For example, eventually I would like to break down “warmth” into “heat retention” and “wind resistance”. Doing that now would require me adding a new property to every single item, and most of them would have “0”.

I suppose in the same vein, would every single thing have to be declared? If I have pants or something, I won’t have to declare that they suck at cutting zombies.

[GlyphGryph]

There will be defaults for most of these values, so items will still be created the values aren’t used or aren’t appropriate, but I feel you want something a bit more than that - sort of the ability to swap in different ‘default sets’ in a way? Like be able to say:
“default_stats: GENERIC_CLOTHING”, and it would pull all the base stats from there, and you’d right in the exceptions?
In this case, I imagine GENERIC_CLOTHING would end up being an actual item in it’s own right, just never used in the game. And I’d probably allow the use of any previously defined item (there’d be a file you could put generic items in to make sure they get defined first).

Alternately, I could have it calculate sensible defaults off existing stats, like material, weight, and size or other tags. Have it end up a bit more emergent.

I could even combine the two. So you could create:

item_defaults.json
{key:“GENERIC_CLOTHING”,
name: “A piece of clothing”,
material: “COTTON”,
encumbrance: 1,
worn_on: “TORSO”,
cut_resistance: 1
}

items.json
{key: “SHIRT”,
default_stats: “GENERIC_CLOTHING”,
name: “A plain shirt”,
volume: 3,
weight: 2,
worn_on: “TORSO”
}

Damage of resulting template ends up being based on weight, volume, material and gives “bashing: 0.5” and “bashing_resistance: 0.5”

Is that the sort of thing you’d be looking for?

[GlyphGryph]

Another addition, this time to help out with crafting recipe. I’m going to introduce the “item_group”: tag, which will have an “ITEM_GROUP” or [“ITEM_GROUP”, quality#] value assigned. I’m not yet sure how this will be implemented - a separate grouped-by-item-group data structure, or a method for the normal collection, BUT the important use of this will be for item abilities. No longer will you have to list out individual items for crafting, and new items will be added to the crafting group automatically if you tag them right.

The benefits of such a system are obvious.

You’ll also note the introduction of a “quality” value. While some item groups will doubtlessly ignore this value (the default will be 1), this may come into play for various crafting recipes. The details are still being hashed out, but there are a few possible ways this can go. Expect one or more of:
Quality Requirements for more complex recipes - Your pen knife may be good enough to carve a simply spear, but may simply be ineffective for cutting wood into 2x4s.
Time to craft/construct increased - A simple rock may work as a hammer in almost all circumstances, but it certainly won’t be as efficient. Meanwhile, a butchers knife will make much quicker work of a zombie corpse than a pen knife. (Not technically crafting, but we could easily use the new values)
Success chance modified - A high quality tool means less slippage and more precision - a real needle may simply be easier to sew with than a primitive bone one.

Combined with the (hopefully) eventual introduction of real item durability mechanics, I think this will do a lot a distinguish high quality industrial tools from primitive ones, giving primitive characters the ABILITY to do everything on their own (and the consequent price that can engender) while still leaving an incentive for braving the dangers of town and doing a bit of scavenging.

Ultimately, though, all of that stuff is beyond the scope of what I’m doing right now. What I’m doing will simply make that /possible/. Like the item variation, we’ll see how it actually shakes out once it starts interacting with other elements.

As far as actual progress goes…
I’ve been working at this simultaneously from both ends pretty much. I’ve got a “new” system reading in the items and building them correctly, and I’m reworking the existing code to support the kind of system I’m envisioning. I’ve still got a way to go, though. While “Part (a) Replacement System” is finished with step one, “Part (b) Destroy Enums, Replace with Maps” is still a work in progress, thanks to the dastardly presence of the dreaded C++ Macro.

Once that’s done, I can begin actually tying the two systems together and hopefully have something demonstratable. It will probably be another week or two before then, though, and then another week or two beyond that (at least) for this to actually be finished. I use the term finished loosely, as this isn’t taking into account any of the OTHER numerous item-related changes being implemented. What I’m trying to say is, don’t expect this in the next version. But it’s still, at the moment, totally happening.