[WF-General] Rules Team Resurrection

HansHäggström hans.haggstrom at helsinki.fi
Tue Apr 8 17:53:26 PDT 2003


It's time to resurrect the WorldForge Rules Team!

We will meet on irc.worldforge.org, in the #rules channel.
The initial suggestion for the meeting time is
Sunday 2003-04-13, at 19:00-21:00 GMT.

Below are the current mission statement of the rules team,
the meeting agenda, a battleplan, and some notes.

Rules Team Mission

The Rules team is needed by both the Media and Server teams,
to provide more detailed requirements and content for Mason.

The role of the rules team is also to bridge the chasm between
game developers (our "target customer group") and our servers.
In addition to helping to get Mason done, the Rules team is
establishing procedures and tools that makes it easier to go from
game requirements to an actual implementation of the game using
the WorldForge framework.

The rules team will start working on detailed Mason content, namely:

* Descriptions for a set of specialized rule modules, each providing
   some aspect of the functionality needed for Mason, and defining
   some archetype interfaces it uses / provides.

* A list of item types (entities) in Mason, with attributes and default
   attribute values.

* A list of skills for Mason, with skill difficulty level and other
   attributes (based on the skill system developed by Aglanor
   and others).

* A list of actions available to characters (and creatures to some
   extent), and descriptions of what skills they use, what parameters
   they take, their duration, energy usage, and the effects they have
   (defined  using the rule modules described earlier).

Meeting Agenda

1. Introduction  - Where and how are we -- the Rules Team -- needed?

2. Recollection  - What item, skill, action, and rule module lists and
                    definitions do we have currently?
                    What parts can we reuse?

3. Rule Overview - Agree about how detailed the rule modules should be,
                    what kind of information we need for them,
                    and work out some example ones to give us some
                    concrete idea about what a Rule Module is.

                    Perhaps a Metabolism rule module would be a good
                    start, providing interfaces for Digesters and
                    Edibles - the former being capable of digesting
                    the latter.  Edible would provide some attributes
                    about its nutrient value.

4. Format        - Agree about some format to use for representing
                    groups of archetypes -- for example some
                    tab separated table, with certain column headers.
                    Some prototypes for this could be good to work
                    out in advance of the meeting.

5. Work division - Brave volunteers agree on things to do for the
                    next meeting.  Some items using the archetypes
                    defined in step 3 could be a good goal -- for
                    example some of the edible food items in Mason.

6. Schedule next meeting


1. First some outline of the required modules, entities, skills,
    and actions could be good to have.  Just something general to
    provide a ground for detailed lists and definitions.

2. We need to agree on a simple format for presenting archetypes.
    Archetype attributes have many properties too (such as name, type,
    visibility, default value, and perhaps standard deviation and/or
    range for default value).
    Usually we have a scenario of many archetypes inheriting a common
    parent (such as a list of creatures inheriting a Creature archetype),
    and only redefining the default values (and ranges/deviations) for
    different attributes.

3. Work could proceed by selecting some simple rule modules to
    define, creating archetype interfaces they provide,
    and the set of attributes the interfaces contain.

4. We can now start creating various item archetypes inheriting from
    an Entity archetype and implementing various interfaces provided by
    the rule modules.  In parallel, we can work on skill definitions
    and action definitions, and the remaining rule modules.

    This work includes creating and updating an inheritance tree that
    minimizes the effort needed to create new archetypes.
    Basically there should be archetypes for different categories of
    things, providing mostly sensible default parameters
    (for example LivingCreature, Character, Animal, Plant, etc).

5. As new rule modules get defined or existing ones changed, there
    might be need to update existing archetypes (for example, adding a
    Fire rule module providing a Flammable interface, and making
    PhysicalEntity (or some kind of root archetype) implement it, may
    require tuning the flammability of different items (even if the Fire
    Module may use a material attribute to determine a basic

On Archetypes and Interfaces

Multiple inheritance will not be used among archetypes,
instead a Java like single inheritance with optional
implemented interfaces system will be used
(see "Archetypes and Interfaces" bookmark in #stage).

An interface is basically an archetype definition without
default values for attributes.  An archetype can
inherit (extend) zero or one other archetype, and implement
zero or more archetype interfaces.
An archetype that implements a specific interface is
required to contain the attributes declared in the interface.

Also note that archetypes can only contain attributes,
no methods (at least not currently).

Miscelaneous Notes

As an initial idea, I suggest exploring the possibility of using
spreadsheet programs such as Excel or Gnumeric for editing
the lists, and creating a script for exporting tab separated column
files to some suitable input for the servers.  This would allow us
to get quickly up and running, and have a simple common format
to edit in CVS.

Current Atlas Entities have the following attributes:
id, name, desc, bbox, position, mass, location (container), contents.

It would be good if we could express both items, skills, and actions
as archetypes, as they all have attributes that we want to edit in much
the same way (archetype inheritance might not be needed among
skills and actions that much though).
For this purpose, we could use a basic object model with a
RootArchetype at the top, containing only id (and perhaps name & desc?)
attributes, and inherit Entity, Skill, and Action archetypes from it.
This way we could use similar tools and scripts to work with them.

Hans Häggström (zzorn)

More information about the General mailing list