[WF-General] Rules Team Resurrection
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
* A list of skills for Mason, with skill difficulty level and other
attributes (based on the skill system developed by Aglanor
* 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).
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
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).
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