[WF-Scripting] Thoughts on a transformation RIM.

[Oliver White]

Well I've finally got a day to myself, and I thought I might share some ideas 
I have about implementing Mason and future games in Stage. I'm not as active 
in mason game design as some, but I understand that a major theme of the game 
is to be able to change the world around you. I'd like to focus on this idea 
of transformation as a basis for a ruleset module for stage. 

Change is the one thing that makes life interesting, and so too will it be 
the feature of any game that is interesting in the long term. I guess the 
philosophy goes that you never cross the same river twice.

In stage terms, transformation is something that changes entities into one or 
more other entities, with properties differing from the original entity. 
Let's take one scenario:

=====================================================

THE GEMCUTTER

Vanitus is a gemcutter character played by Ralph. The character entity 
representing Vanitus has a bit of data associated with it, including a number 
of skills taken from the Circe ruleset. One of these skills, funnily enough, 
is a gem-cutting skill. Vanitus has come into contact with a shady character 
called Devnion and has aquired an uncut diamond. Devnion has offered Vanitus 
a cut (scuse the pun) of the profits, in exchange for an application of his 
skill. Vanitus grabs his gem cutting tools and sets to work creating a fine, 
faceted stone.

Ralph peforms a series of mouseclicks in Morgate, which sends an atlas 
operation to the server like so:

SKILL_APPLICATION("GEMCUTTING", "ENTITY-020349", "LOW");

The server then performs the following actions:

1) Checks that GEMCUTTING is applicable to the entity specified.

2) Checks that Vanitus is in posession of the correct tools.

3) Ties the Vanitus entity to the activity of gemcutting for 3 hours, the 
lowest period of time to take to perform this gem cutting (he's a bit wary of 
this Devnion and just wants to get his money and be rid of the suspect). 
Vanitus will stay cutting the gem until this time is up, or Ralph gets bored 
and sends a new action to the server (or possibly until he is attacked and 
his server-side reflexes take over).

4) Given the time period and Vanitus' skill level, the rough gem entity is 
replaced by a large, low quality gem entity.

A fight then ensues, over the quality of the gem and Vanitus is forced to 
flee in fear of the law. Squatters take over the building and bury the corpse 
of Devnion in the cellar.

=====================================================

This explains a little of how player interaction can change a world. 
Circumstance can also cause transformation - fire can change wood into 
charcoal. Natural forces like fire, weathering and so forth can be thought of 
as an application of a skill of the world itself. So, when a mage casts a 
fireball at a gemcutter, after discovering he stole and damaged a magic stone 
of hers, a fire force is applied to a nearby tree. The server then does the 
following:

1) Sends an atlas object to the transformation RIM -

FORCE_APPLICATION("FIRE", "ENTITY-004991", "HIGH);

2) The rim checks the tree for the opposing element - water.

3) The tree is dry as tinder, and it's entity is gradually replaced by a pile 
of charcoal over the next 2 hours.

Vanitus escapes with singed hair and runs into the forest

=====================================================

Now, not all skills and forces will involve transformation, but we want to 
encapsulate transformation and reuse it in other game systems. Obviously we 
need to dispatch only certain force and skill application entities to the 
transformation RIM, so pegasus needs to make sure they get to the right 
destination.

The rim is responsible for taking the application request and determining the 
outcome. This may involve determining the material and shape of the entity in 
question, the physical environment of the entity, and the qualities of the 
applicant character or world embodyment.

That covers the scope of the RIM. There are a couple of design considerations 
for pegasus as a whole, though. I'm suggesting that RIMs collaborate by 
putting atlas operations on the in-queue of other RIMs. This may not be the 
most efficient way to handle internal server communications. If you have any 
other ideas about optimising internal communications, let us know. Pegasus' 
dispatch mechanism may also need some work.

The transformation RIM will use data extracted from Eidetic as XML/Atlas 
files, to describe skills, materials and shapes. Some of this data may need 
to be shared with other rims, so there are still future considerations for 
our data model. I've done only a little preliminary work in this direction, 
as I've discussed with bryce.

Thats about all I've got so far, but it's a good step towards implementing a 
full-featured RPG engine. I'd recommend folks think about what other 
encapsulations might be useful.

Thanks for listening,

Oliver White