From ojw at iprimus.com.au Sun Dec 2 13:37:36 2001
From: ojw at iprimus.com.au (Oliver White)
Date: Sat Apr 5 19:46:40 2003
Subject: [WF-Scripting] Eidetic Temlates for Mason Data
Message-ID: <3C0993F0.4060904@iprimus.com.au>
Well finally! I've got my first ever atlas program running.
I've discussed the data format for mason with several key developers,
and got some excellent advice. I think the way we should do things is to
represent each table as a list of atlas objects of type
Atlas::Message::Object::MapType.
Each object will represent a row in the table, and will be served up by
eidetic as an Atlas XML file, to be loaded into Stage on start-up by the
rims that need them. Demitar has cited security issues as the reason why
we should go for rim based loading as opposed to client connection based
loading.
So, what do I need from the entity team? Simply come up with an eidetic
template to serve XML - a sample atlas map object is in order:
This would correspond to something like this in SQL:
CREATE TABLE FUR_TYPES
(
NAME CHAR(50),
COLOUR CHAR(50),
DENSITY NUMERIC(10,3),
HAIRS_PER_CM INTEGER(10)
);
This should cover the vast majority of data. Note that in addition to
strings, floats and integers, we can also have maps and lists within
objects. I don't see how you would need that when representing single
tables as atlas objects, but by all means give me a nudge if you need it
and I'll come up with some templates.
Sorry this has taken so long, it's certainly been a learning experience
for me, and at the very least I've found a few bugs in atlas which Al
Riddoch has fix up for me.
From here I'll be working with the stage team to develop the RIMs to
load this data and run a game world.
Cheers!
--
Oli White
From bryce at neptune.net Sat Dec 1 23:48:09 2001
From: bryce at neptune.net (Bryce Harrington)
Date: Sat Apr 5 19:46:40 2003
Subject: [WF-Scripting] Re: [WF-General] Eidetic Temlates for Mason Data
In-Reply-To: <3C0993F0.4060904@iprimus.com.au>
Message-ID:
On Sun, 2 Dec 2001, Oliver White wrote:
> Well finally! I've got my first ever atlas program running.
Congrats!
> So, what do I need from the entity team? Simply come up with an eidetic
> template to serve XML - a sample atlas map object is in order:
>
>
Looks like, I suspect:
> This would correspond to something like this in SQL:
>
> CREATE TABLE FUR_TYPES
> (
> NAME CHAR(50),
> COLOUR CHAR(50),
> DENSITY NUMERIC(10,3),
> HAIRS_PER_CM INTEGER(10)
> );
>
> This should cover the vast majority of data. Note that in addition to
> strings, floats and integers, we can also have maps and lists within
> objects. I don't see how you would need that when representing single
> tables as atlas objects, but by all means give me a nudge if you need it
> and I'll come up with some templates.
I am guessing that with mason we may not need anything with more than
the basic types, but that'd only be a guess.
It feels like we're "missing some syntax" here, but I'll be happy if
this is all we need to know.
> From here I'll be working with the stage team to develop the RIMs to
> load this data and run a game world.
>
Cyphesis-C++ is probably the more logical place to start, but ok.
Thanks again, cy!
Bryce
From ojw at iprimus.com.au Sun Dec 23 14:58:51 2001
From: ojw at iprimus.com.au (Oliver White)
Date: Sat Apr 5 19:46:40 2003
Subject: [WF-Scripting] Thoughts on a transformation RIM.
Message-ID:
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