[MUD-Dev] Object and class heirarchies -- are they really necessary?
J C Lawrence
claw at cp.net
Wed Mar 22 15:14:27 New Zealand Daylight Time 2000
On Wed, 22 Mar 2000 01:01:33 -0500
Phillip Lenhardt <philen at funky.monkey.org> wrote:
> On Tue, Mar 21, 2000 at 03:57:25PM -0800, J C Lawrence wrote:
>> True. That was one of the sources of the design requirement for
>> Murkle that features must be programmable without requiring
>> source access to any other objects.
> No matter how many times I read this design requirement--and it
> has been many: I have read and reread nearly every thread in the
> archive in which it appears--I always come to the conclusion that
> it is either tautological or trivially false. Since both those
> conclusions seem unlikely candidates for what you mean, I was
> wondering if you could clarify.
Aye, the wording is not the best. A better statement:
In order to program any feature in the game source level access
must not be required to any other pre-existent objects in the game
that are not the direct recipients of the feature. Ie. If a
feature is going to _directly_ affect only objects X, Y, and Z, then
those are the ONLY objects that should need to be accessed.
Even that's not so great. There were a variety of scenarios used to
develop the basic concepts:
The Elven Forest, Castle Krak and the Sceptre scenario
When the King's sceptre is in the Elven Forest magic ceases to
work in Castle Krak. ie all previously exstant magical results
in the castle fail. If Bubba was magically invisible, he is no
When the sceptre is no longer in the Elven Forest, magic works
in Castle Krak.
Any transition of the sceptre in or out of the Elven forest
transitions the state as appropriate. eg if the sceptre enters
the forest and Bubba was magically invisible in the castle,
voila! He's visible. If Boffo was flying, he falls. If Bernie
was magically strong, he's now weak. If Buzz was magically
disguised, he's now back to normal. If Thrud was weiling the
Sword of Doom, well we's waving a bit of base iron about now.
The magic sack as in the GGGG ceases to function, and teleports
cease to work as do all other new spells... You get the idea.
Now, just to prevent you special casing the magic calls to go check we
had the relics of the Great God GooGoo and the Magic Sack. Ohh, what
the crap, I might as well post the entire scenario (it was what was
used to develop and exercise my spoof and watcher models):
Relics of the Great God GooGoo and the Magic Sack of Hiding
The GreatGodGooGoo has a number of holy relics.
Each relic has a non-magical base state, and a magical awakened
If more than three of GGGG's relics are simultaneously awakened,
the GGGG does nasty things.
Relic #1 is a stone which awakens into the Gem of GGGG.
The gem turns its bearer into a FireGod only for so long as he
carries the gem.
The FireGod is very hot. Food cooks when in his presence, metals
get painfully hot, and candles melt.
Other players near the FireGod are slowly damaged by the heat.
Relic #2 is the Horn of the GGGG, which awakens only while it is
blown and then reverts to the base state.
Relic #3 is a sword which awakens to the sword of GGGG.
The sword has interesting properties when awakened:
1) If the GGGG is awake (three relics etc), the the sword
teleports to GGGG.
2) If it can detect the MistWraithe it magically teleports to the
MW and begins attacking him.
3) If it is carried by a FireGod, then the sword is destroyed.
#1 happens as soon as the GGGG is awake, and the sword can
detect him and it can teleport.
#2 happens as soon as it can detect the MW and can teleport.
#1 has priority over #2, and #2 has priority over #3.
There is a Magic Sack of Hiding.
Anything in the MSH is hidden from the rest of the game. No
magical effects can either enter of leave the MSH. Players, and
the MW can enter the MSH.
There is a Wizards Lair.
Any magical effects, such as an awakening, occuring in the WL are
hidden from the rest of the game. No magical effects or spells
can enter the WL, but they can all leave the WL. ie in fails,
There is a Magic Cloak.
Anyone wearing the MC appears to be the MW (more than the real
MW (ie gets preferentially attacked)).
Anyone carrying the MC appears to be the GGGG (non-preferentially).
Bubba and the Crystalling Tree scenario:
The actual scenario was called "Bubba and the Crystalline Tree", and
dealt fairly simply with our friend Bubba who managed to climb a
crystalline tree. This was no mean feat as Bubba is a very heavy chap
whose weight *should* break the tree, dropping bubba to the ground.
The scenario is:
-- Bubba is in the Crystalline Tree.
-- Bubba has some sort of state changing effect which lessens his
weight such that the tree does not break. Typical examples are: he is
holding on to a large number of helium balloons, he is enchanted to be
-- Bubba now changes his weight value. This could be by letting go of
the balloons, picking up another object, receiving a "heavy" spell,
having his "light" spell wear off, having one of the objects he is
carrying receive or lose a heavy/light spell, having one of the
objects he is carrying chage its weight for any other reason etc.
-- Having the tree respond appropriately to Bubba's weight change.
> I read your design requirement either as:
> "Any object must be able to affect any other object without
> changing that other object."
Without requiring that other object's explicit support (in the form
of its source) to implement the feature.
Taking the ElvenForest/CastleKrak/Sceptre scenario, the problem is
You have a world in which already exist magical objects, the Elven
Forest, and Castle Krak. You have to implement the feature set
described in the above scenario (magic working/not_working) without
in any way touching the source code for any of the magic objects,
the Elven Forest, or Castle Krak. You can however edit the source
for the Sceptre (as that object id directly involved), and create
any number of new objects as part of yuor process.
Now notice, you can't rewrite your magic code to check for the
toggle flag! That's touching the source of an object that is not
directly involved. You also can't have the ElvenForest or
CastleKrak notice when the sceptre is or is not inside their bounds
for the same reason. _ALL_ the functionality must be accomplished
via edits to the sceptre object, or via the creation of new objects
(possibly dynamically at runtime).
Following similar constraints for the other scenarios gets more
interesting. The reason however for the design constraint is to
ensure that __arbitrary__user__programmers__ can accomplish features
in their world without ncecessarily requiring write access to
objects they don't own or otherwise have access to.
Its the other side of usability in a game comprosed of very tight
multi-user object-level security restrictions. Remember that the
base purpose of Murkle is/was:
Murkle is intended to serve worlds where the players can create
virtual realities, and then enforce those realities on each other.
A post which discusses some of the spoof and related areas with
Shawn Halpenny is at the URL below. Just plug in keywords from the
above into the search engine at Kanga.Nu to find the rest:
J C Lawrence Internet: claw at kanga.nu
----------(*) Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev