Items features 2

This is a upgrade of the item feature design previously described here.
In the first version, every item property was encoded in a list of features. I mentioned such features as ‘mapcell’ which contains the type of map cell on which the item works. The example for this feature was a fishing pole, which produce fishes when you are on a water cell.

But what if I want an item with several features, each one with different conditions ? Example :
a sword called Sting which has three features :
– can be weared on ‘main hand’ slot
– gives you 1d6 attack bonus when used as a weapon (only when weared)
– produce blue light (only when there are orcs nearby)

Using the previous system, this would lead to the following features :
– feature “wear” body_slot “main hand”
– feature “attack” damage “1d6”
– feature “light” range 5 color 200 200 255
– feature “near_creature” type “orc” range 15

Ok, everything is here but how can the engine use all this ?? Do we have to wear the sword to produce the light ? Do we need to be near an orc to wear it ? This is a total mess.

The issue is that “near_creature” is not a feature, but a feature condition.

Thus, using a new structure for item type definitions :
item type
allows more flexibility in the item design.

I will give some examples using the following format for the items.dat file (this is not exactly the actual items.dat format in TCOD) :
ITEM_DEF := item_type “name” { FEATURE_DEF }
CONDITION_DEF != condition “name” { PARAM_LIST }

For Sting, we have :
item_type “Sting” {
feature “wear” { BODY_PART “hand” }
feature “attack” { DAMAGE “1d6” condition “when_wear” {} }
feature “light” { RANGE 5 COLOR 200 200 255
condition “near_creature” { CREATURE_TYPE “orc” RANGE 10 }

Note that we now distinguish the wear feature (ability of an item to be wear on a specific body slot) and the wear condition (necessity to be weared to activate another feature). Of course, you can only use the condition “when_wear” on items that already have the feature “wear”.

And for our fishing pole :
item_type “Fishing Pole” {
feature “produce” { ITEM_TYPE “fish” condition “when_oncell” { CELL_TYPE “water” } }

A torch :
item_type “Torch” {
feature “onoff” {}
feature “light” { RANGE 5 COLOR 255 200 0 condition “when_on” {} }

3 comments so far

Add Your Comment
  1. The “produce” feature for the fishing rod should have an PRODUCEAT parameter which would be set to inventory. I would also add two more conditions (can you add more than one condition?) which is somehow difficult to handle: you should only get a fish if you have a bait in your inventory and if you roll a succesfull fishing-skill die. The last condition is maybe complicated to realize because the die you roll is relative to a non-constant number… After you performed the fishing skill a bait is to be removed from the inventory but how’d you do that? Either make add a remove item feature with the condition “has-fished” or you could make features execute other features.

    Which leads me to another question: is the produce feature executed every time you’re near water? I think it sould rather have the feature can be used which will execute another feature (the “execute” feature) when you ‘u’se the item.

    One last problem I can see: having conditions like “when_on”, “when_oncell” or “when_wear” will be hard to handle (or rather very slow to handle – checking every condtition for every entity takes a lot of time) if you leave them conditions. If these conditions are triggers that will execute the feature they are attached on this will get easier but needs more hardcoding (triggers tend to spread all over my sourcecode but that’s maybe the way I’m realizing them).

    Still watching your game tensely,
    Christopher Brandt

  2. From a gameplay point of view, we can handle the bait with a standard items property : the durability. Each time you use the fishing pole, its durability decreases. Once it reaches 0, the fishing pole breaks and disappear from your inventory. You have to get another (instead of getting bait). Having actually baits is still possible, but would need more features, more conditions for more or less the same result (from a gameplay point of view).

    Skills, as features, are hardcoded. I’ll probably need to add a skill parameter to the feature class. I didn’t need it for now (I have not implemented the fishing pole yet!)

    Features are not ‘executed’. They are items properties that are used by the engine. For example, when you attack a creature, the engine looks for items that have the ‘attack’ feature enabled. Here, ‘enabled’ means that all features conditions are true.

    The inventory panel has a generic ‘use’ function. When you use an item, the engine looks for features on this item. If it finds the ‘wear’ feature, it equip the item in its body slot. If it finds the ‘produce’ feature, it check that the feature is activated (for the fishing pole, that you are on a water cell) and produce the item. I can add a skill roll here if there is a skill mentioned on the feature.

    Yes, when_xxx conditions may take some cpu to handle, but they are not checked for every item every frame. Each feature works differently. Generally, a specific feature is checked on every item of the player inventory when the player does a specific action. The most cpu consuming process is the lighting process which has to check every item on the visible part of the map to see if it produces light. But this is only a 60×40 map. I’m not worried about performance, most computers can handle this. As one of my teacher used to say :
    – step one : make something that WORKS…
    – step two : make it fast !

  3. Ah okay. That’s an interesting way to handle item properties. My attempt is that I have some general properties which don’t really need something like features (for weapons eg.: stat-modifiers, damage, weight etc.) everything special can be added using events. Each item may have certain triggers like: onAttack, beforeHit, beforeDamage, afterDamage, onDestroy and some more. The events executed may do anything. It’s some more hardcoding in the first place, but once you have event-code done, you won’t need to hardcode new “features”, you just create some (really easy to write) events. It’s another attempt and I like yours as well.