Mason Item Creation System - Early Design Document

NOTE: Some ideas about how the Item System should be implemented have changed since this document.

Document History


Introduction

Many computer-RPG players have over the years frowned at the lack of depth, xx and attention to real detail in most (all) commercial RPGs. Consider basic actions that anyone could come up with, like: Making a simple axe using a wooden stick, a sharp rock, and a piece of string. Then use our newly made axe to chop down trees, wield as a weapon in combat, or simply sell it to someone less creative :-). This is the attention to detail I want when I'm playing computer-RPGs, and this is what we're going to give you (and ourselves) with Mason!

Shortly summed, the Mason Item Creation System (MICS) will let you put "anything" together, and then later let you take it apart and even reuse the components. The only limitations will be in the game's item database (or so we hope :-).


Goals and Requirements

The MICS should structurally be kept as simple as possible, implementing only a few atomic operations. Instead, high-level operations will be accomplished by using a scripting system that builds more complex commands using several atomic operations. These atomic operations will mainly cover the following actions:

Furthermore Items can be created from different Materials, and they inherit their initial properties from that Material (density, hitpoints, hardness, durability, look etc). Materials can also be combined in similar matter, allowing for hybrids like bronze, brass, steel a.s.o.


Definitions:

Just to avoid any misunderstandings, here is a quick explanation of the terms that are used throughout this paper:



Concept:

The basic operations that we want to be able to do on anything (that makes sense), will be described below.

  • Some items (typically raw materials) can be split into several similar items, each of smaller size than their parent.

  • Examples: Sawing a tree trunk at its middle, will leave us with two tree trunks, each with half the size of the original tree trunk. Hitting a big lump of iron ore with a sledgehammer, will leave us with several (random number) little lumps or iron ore.

  • Most items can be shaped into several different shapes, leaving us with an item of the same material, but a different shape.

  • Examples: Using a knife on a piece of wood, could give us an axe handle (plus possible some biproducts like sawdust), but it's still the same piece of wood. Using the knife again on the axe handle, could give us a knife handle (plus some more sawdust).

  • Multiple items can be combined into one item, replacing the original items. This process is fundamentally irreversible. (But can still be destroyed though)

  • Examples: []

  • Multiple items can be attached into a binding, leaving each of the attached items intact. This process is reversible.

  • Examples: Attaching an axehandle with an axehead, will give us a complete axe. Attaching a rock with a string, could give us a throwing sling.

  • A binding can be detached, leaving the binding's separate items. These items can ofcourse have changed while bound. (Received damage etc.)

  • Examples: Detaching the axehandle from an axe, will leave us with an axehandle and an axehead. Detaching the string from a sling, will leave us with a rock and a string.


    Material Creation:

    Not quite yet.. . . . .


    Item Creation:

    Primitive Items are created by supplying the item type and a Material. Note that the material must be legal for the item. Lets explain it with an example:

    Scenario: The Lumberjack John has a tool belt containing a knife, and is carrying a saw. John wants to make himself a staff and an axe, he has an old axehead in his backpack. On the plains outside John's cottage, there is one little birch, and one little oak.

    After having completed his wooden staff, John starts thinking. "I really should have used the hardest type of wood (oak) to create the axehandle; the softer birch would've made a sufficient staff."

    To make this actually work, we compare the bounding box property of the the source item to the destination item. The destination must be of smaller size than the source. Then we check if Source->Material is a legal material for the destination item type. When performing these shape operations, the source item's properties are of course 'inherited' to the destination item.

    We'll also need some kind of smart Complex Items structure, so that when we try to attach the axehead to the handle, the complex item database will tell us that the result is an axe. Eg. if our Complex Item structures looked like this:

    Complex Item 1:

    We would search for the complex item with both (and only) AxeHandle and AxeHead as it's children, thus finding the Axe complex item. The search would of course have to be restricted by some kind of groups, so that when eg. one of the elements belong to the tool category, we don't go about searching through plants and building blocks etc.




    Atomic Operations (low-level operations)

    Item Shape( sourceItem, destinationItemType )

    The shape operation takes the sourceItem's properties and material type, and uses them to create a new item of type destinationItemType. We will have a acceptedMaterialTree that defines acceptable material types for all item types, this will also include groups (eg. group:wooden, type:oak). This operation returns an item of destinationItemType, with sourceItem's properties.


    Item[] Cut( sourceItem, plane, amount )

    The cut operation clones a sourceItem into amount+1 items and then adjusts the size/volume properties of all items. It may or may not invoke shape on each of the spawned items, depending on the plane cut in, and the number of cuts. Eg. For a wooden log: shape( Log(oak), yz, 4 ) will return 5 logs each of less 'length' than the source, whereas shape( Log(oak), zx, 5 ) will return 6 tree planks each of same 'length' and 'depth as the source, but with less width.
    NOTE: Since this operation depends on the atomic operation shape, it doesn't technically qualify as an atomic operation. Hence it should probably be moved into the 'medium-level' section.


    Item Combine( item1, item2 )

    The combine operation irreversibly combines 1..n primitive items, into a new primitive item. If the source items are made of different materials, the new item will have a material that is a mixture of all the source materials. This operation will invoke "Material->combine( item1.material, item2.material )" to get the returned item's material, but will use item1 and item2's properties.
    NOTE.1: The Material->Combine() might not be allowed, which also means that the item combination is not allowed.
    NOTE.2: Atomic Combine will probably only combine 2 items, but a high-level operation will automate the process of combining n items.


    Binding Attach( item1, item2 )

    The attach command will attach 1..n items into a new binding, none of the source items will be affected by the initial process. This process is fully reversible. The binding structure will probably have a few modifier properties.
    NOTE.1: Atomic Attach will probably only combine 2 items, but a high-level operation will automate the process of combining n items. NOTE.2: Bindings can also be attached.


    (void) Detach( binding )

    The detach operation dissolves a binding, deleting the binding structure afterwards.
    NOTE.1: If Atomic Attach is restricted to 2 items (see above), Atomic Detach will only detach two items. If so a high-level operation will automate process.


    (void) Put( sourceItem, destination )

    The put operation puts the sourceItem in/on the destination. Item Group/Tag and Item Size are factors deciding if the put is valid. Eg. Put( hammer, toolbox ) valid because hammer is smaller than the toolbox. Put( shirt, self ) valid because shirt is tagged wearable.


    Item[] Destroy( sourceItem, cause )

    The destroy operation destroys the sourceItem and (possibly) returns remnants. The cause of the destruction determines which remnants (if any) are left. Cause may be magic, heat, cold, impact...


    Item Specific Operations (medium-level operations)

    Pre Idea

    Most (as many as possible) operations should belong to groups, but items may have unique operations.
    Item tree: Items will have tag bits, allowing them filter allowed operations,
    and be part of multiple groups.

    +-------------ROOT--------------+ | | | | | | USEABLE WIELDABLE WEARABLE Rock Sword Trousers Mug Knife Sweater Axe Hat Scythe Shoes Mace Socks Spear Pants Shovel Vest Hammer Steel Knuckles

    Example: Groups are 'UPPER', items are 'lower'

    Since the Scythe and Hammer are very inefficient at piercing, we tag unset their PIERCE tag. Since the Steel Knuckles can be worn on the hand, we tag it as Wearable, and because of its shape, we untag its PIERCE and SLASH tag.

    +---------+---ROOT--------------+ | | Take | | | Put | | | Drop | | | Throw | | | | | | | | +-----+ | | | | USEABLE WIELDABLE WEARABLE Slash Wear Pierce Bash | Scythe:Harvest <= Defined item Knife:Carve <= unique operations Shovel:Dig <=

    The result of this idea example is this:
  • Any of the items above may be Taken, Put (on the ground, in a container), Dropped, or Thrown
  • All the items defined wieldable may be used to Slash, Bash and Pierce, except the Scythe and the Hammer, which may not be pierced with, and the Steel Knuckles, which may not Slash or Pierce .
  • In addition to the above, the Scythe may be used to harvest, the Knife may be used to Carve, and the Shovel may be used to Dig.
  • The Steel Knuckles may be Worn because they're tagged wearable.


    Command List:

    Work in progress, some defined categories would make things easier. Commands that are (nearly) unique (like Scythe:Harvest) are not listed here.

    General commands: All

      Take
      Put
      Drop
      Throw
      (Steal)

    Wieldable commands: Weapons, Tools.

      Slash
      Bash
      Chop
      Cut
      Pierce
      Carve
      Dig
      Hammer

    Wearable commands: Clothes, Jewelry.

      Wear


    Scripted Operations (high-level operations)

    Pre Idea

    Currently working with Scripting for high-level operations, and Recipe system for ingame scripts.
    THOUGHT: Using Python for Script/Recipe and communicate with 'lower levels' over the Atlas protocol ??




    Document History

    Date Version Author Changes
    2000-10-24
    0.0.1

    Torbjørn Lædre
    Initial Document
    2000-10-25
    0.0.2

    Torbjørn Lædre
    Atomic operations laid out. Item Creation ideas listed.
    2000-10-29
    0.0.3

    Torbjørn Lædre
    Scrapped one item shaping approach, added a new approach. Updated details. More details on operations added.

    Associated operations tree:
      Groups are 'UPPER', operations are 'lower'