By Miguel Guzmán Miranda

With design and comments by:

Damien McGinnes

Draft Edition – Version 0.0.1 – October 2002

Copyright 2002 Miguel Guzmán Miranda

Published under the GNU Free Documentation License


This whitepaper is intended to define an action system to use in Worldforge games. Specifically, it is adecuate for its implementation as RIM modules, because each action can be seen as a response to an Atlas event.


The action system needs to interact with the Character System by Hans Häggström .

The character system should use the Skill System by Miguel Guzman to determine the specific skill to use for an action.


Actions are atomic processes in the game world.

Seen as a black box from outside the Action System, Actions have the following properties:

- trigger: what triggers an Action. When the trigger condition is set, an action occurs.

- inputs: the inputs an action can have. Action inputs are numeric in nature, and whenever possible, in scientific magnitudes.

- outputs: the outputs an action can have. Action outputs are numeric in nature, and whenever possible, in scientific magnitudes.

About numeric, realistic magnitudes for outputs: traditionally in RPG systems actions have two possible outputs: success and failure. Depending on the complexity of the system it could have degrees of successes and failures, but these were or quite simple (like critical successes and botches) or left to the master criteria.

This is a simplification we do not need. When performing actions, we don't need to roll dice. We calculate, based on mathematical formulae and random seeds, numerical outputs that relate to real-world magnitudes.

Examples: when orienteering, we can directly output the direction, in degrees from North, that the player believes to be the actual North. When lockpicking, we can output the time it takes to open a lock. When shooting an arrow, we can output the exact direction vector and power the arrows has when fired.

About randomness: the character system and specifically the skill system have no randomness asociated. That means, you either know a thing or you don't know. When performing some skill is where randomness from environment is taken into account, thus:

All the randomness in a game action is provided by the action.

The next item is a sample action that accomplish these goals:

1 - as it is a simple action, it will serve to illustrate this philosophy.

2 - as an easy action, should be very easy to implement.

3 - it is player-triggered, so should be easy to test.

2 - it is a common action and has a game value (it's useful for a player) so it is worthy of implementation.

Sample Action: Orientation

Description: the action of orientation represents the character intention to determine where a specific direction (North

by default) is.

Client behavior: in the client the player can hit a key to orientate north, or click a mouse button in the automap to orientate in the direction between its current position and that point. When the client receives a response from the server, it shows a spot or a compass pointing in that direction.

Trustable?: no. There's no way to assure that the client does not always know where north is, because it knows the map media. (Thus, this one could be a client-implemented skill, except for lgging the usage of it and increasing the player skill in it).

Server behavior: the server receives an "atlas orientation request" from a player. It asks the RIM orientation rule to calculate a response, and it sends that response as an "atlas orientation request".

Action definition:

- trigger: - player action

- input: - player ability to calculate direction ([1,100], unitless)

- optional: environment difficulty to orientation ([1,100], unitless)

- output: - direction from real North (or current player facing) where player believes his destination is ([-180,180], degrees)

- experience: experience points for the character ([0+], experience points)

- optional: time it takes to the player to calculate the orientation ([0+], milliseconds)

Action behavior:

We design this action behavior having in mind that the player can have a margin of error of 180º in both directions if his skill is null (he can end pointing to the opposite) and that his error margin is 0º if his skill is 100 or more and enviroment factors are not taken into account.

So, without environment factors we could have something like:

Error margin = 180(1 - ability/100)

With ability 100 error is null, with ability 0 error is 180º.

If this player's ability is 50% then we have a 90º error in both directions.

When the error margin is calculated, then the action picks up a random number between (-error,+error), for instance a number between -90 and 90 (i.e. get random(-1,1)*errormargin).

That number, in degrees, is what should be added to North or real direction to get the player calculated direction. This is the number the RIM module returns to STAGE and what stage returns in the "atlas action orientation response". The client gets this number of degrees and adds or substracts it for the real number and points the player in that direction graphically.

The action also should output experience to the character system, and could output the time it takes for the player to orientate (which should also go in the "atlas action orientation response").

Note that this example is very simple and not very accurate, the formula for instance is linear and this is not realistic, a character with ability 50 in orientation should be able to get a very accurate response on a sunny day or clear night, and not being able to pick east instead of north. But it serves as an example.

A more accurate formula would be:

errormargin = 180(1 - sqrt(ability/100)) [if ability>=100, errormargin=0 ]

Some numbers with this formula:

ability: 0 error: 180

ability: 10 error: 180(1 - 0.316) = 123.12 improv: 56.88

ability: 20 error: 180(1 - 0.447) = 99.50 improv: 23.62

ability: 30 error: 180(1 - 0.548) = 81.41 improv: 18.09

ability: 40 error: 180(1 - 0.633) = 66.16 improv: 15.25

ability: 50 error: 180(1 - 0.707) = 52.72 improv: 13.44

ability: 60 error: 180(1 - 0.775) = 40.57 improv: 12.15

ability: 70 error: 180(1 - 0.837) = 29.40 improv: 11.17

ability: 80 error: 180(1 - 0.894) = 19.00 improv: 10.40

ability: 90 error: 180(1 - 0.949) = 9.24 improv: 9.76

ability: 100 error: 180(1 - 1) = 0.00 improv: 9.24

(TODO: include a nice graphic)

You can see here that the error reduces considerably with the skill, and that whith higher skills, though the return diminishes (first derivate negative) the results are pretty good. Also, you can see that the first ability improvements reduce considerably the error, as would happen in real life.

From this point onwards it's a matter of toying with different mathematical models to find a compromise between complexity and realism.