I've been working with a piece of code for a crafting-heavy project the last few days. My idea was simple at first, to make a really generic system for item creation. I wrote four recipes for crafting the four basic tools, and they were all hard-coded.

As I looked at the completed code, I was struck with a really stupid idea. Why should any item be hard-coded? Items themselves are without any really special behavior. They all work off a basic set of rules, so why should these be properties of individual items?

So I set out to make a template-based item crafting engine.

It works by creating an XML-like file for each item. These files currently have very little information in them, just "reactions".

When one item is used with another, it reads the reaction section of the data file for the main item. If there is a reaction in that file, it passes the reaction to the handler, then derives all the important information.

Steps of the Reaction:

Step 1: Find the CD [REACTION] in the file: main.type
Step 2: Find the CD secondary.type in the file.
Step 3: Read two values from the CD stream: skill, and DC.
Step 4: Grab the skill found in the stream from the global skill list, and pass the file, items, and player off to the react proc of that skill.
Step 5: Form a list of items in the [REQUIRE] cd
Step 7: Run through the required items in the list, determine if the player posesses all of the items in the list.
Step 8: Determine success or failure based on the DC value we grabbed from step 3.
Step 9: Change the CD to SUCCESS or FAILURE. Now CD to CONSUME. Create a list from the CONSUME CD within success or failure.
Step 10: Run through the CONSUME list, and remove the items from the player's inventory.
Step 11: CD to CREATE, and create items from this stream. Each item is then put into the inventory of the player.
Step 12: CD to MESSAGE and output the buffer to the player as a message.

Item reactions are very simple right now. I currently have about three or four more features to add.

Right now, I haven't fleshed out a material system, so items don't track what materials they were made of. I plan to add materials to the system soon.

I also haven't figured out a way to do "incomplete" constructions without chaining together multiple items with file definitions.

This is important, because currently, it pulls everything out of your inventory on its own. This means that you can't pick which items go into the construction. I'd like to see it possible to add items to a stack, and then begin construction when the stack is complete.

I'd also like a way to add multiple ways to make something. For instance, I'd like to see meta-ingredients. I can list [wood] instead of wood/pine. That way, any type of wood would work. Or even, an OR sort of list where items can be made out of either metal or wood, and it will change certain properties of the finished product. For instance, a wooden fishing hook giving a -2 to the fishing_bonus variable of a fishing rod, while a metal fishing hook would have a +0.

I'm also currently removing all "types" and making an itype variable that works similar to a path, but will allow for multiple-inheritance of properties. Datums handle items, and work more similar to classes, while object instances represent item instances. This way, I can afford to do some more interesting things, such as an item that inherits all the functions of an /item/container class, the functions of a /item/weapon/sword class, and the functions of a /item/armor/shield class.

I think I'll make a post about pseudo-multi-inheritance next week, when I've got more work done on the system.