On Mon, 24 Mar 1997 claw@null.net wrote:
:On 21/03/97 at 12:53 PM, Nathan Yospe <yospe@hawaii.edu> said: >On
:Thu, 20 Mar 1997 claw@null.net wrote:
:
:>:>That's interesting... you use a free user programming system,
:>:>though, don't you?
:>:
:>:Yup, altho that can be easily disabled/limited. As each object and
:>:each method on each object metes its own security (who is allowed to
:>:call with with what arguments), its *really* easy to bind the object
:>:creation/programming methods with a more restrictive security level.
:>:And then of course there are little things like quota systems,
:>:automatic object recycling, timed object lifespans, etc for the less
:>:draconian chaps.
:
:>Hmmm. But nothing to enforce literary consistancy.
:
:True, but once you allow any form of free programming, that's history.
:Heck, even standard monolithic non-user-programmable games with teams
:of vigilant admins can't manage that one.
*grin* Well, what we have here is a challenge. Lets see... I'm writing a
scratch codebase. Aspect one covered. I'm a decent author. (Eventually,
books by one Anthony Aspe are gonna start wandering into your part of the
world. That's me.) I might or might not have the stamina to write an
entire world. Probably not, but I can set the mood for the whole damn
thing.
:>:> > > Also, "fitted" equipment works in nicely with the limbs list.
:>:
:>:Arrrrghhh! This could get very ugly, quickly with the above.
:
:>I'm currently tangling with this problem.
:
:It is an ugly one indeed.
I may settle on a rough/perfect fit model.
:>:I was also
:>:thinking of doing a very similar idea for swarm bodies (eg the body
:>:consists of thousands of barely intelligent insects which en masse
:>:have great intelligence and can manipulate objects via joint action
:>:(thousands of bees descend on the boulder, and all buzzing mightily,
:>:lift it away!). In the swarm body case however the player would
:>:split off sections off his main body and send them off on seperate
:>:paths.
:
:>Now this is seriously cool. And quite possible, too. I'll have to
:>allow a player species based on the swarm concept at some point.
:
:For me it was a direct extension of allowing a single character to
:simultaneously control multiple bodies (side effect of body stealing).
:Once I had that the instant thought was: "Well, if he can control two
:or three bodies, say his own, and a couple mobiles or whatever, why
:can't he control a few thousand bodies? Say a couple hundred thousand
:bees blitzkrieging the Fortress Of Impenetrable Custard"...
:
:Ooops. And thus it started.
I had a species that was a swarming body. I just rewrote them to take
advantage fo the new swarm mind capacity of the code. Of course, the swarm
is made of particulate gas, and is not actually made of individual
creatures, but rather clusters of creatures... its a rough model.
:>:A point I'm not resolved on is how to handle component differences
:>:in the group object. Yes its a pack of wolves, but all of those
:>:wolves are unique in various ways (some wear collars as escaped sled
:>:dogs, some have scars, one is the leader, male/female, young/old
:>:etc). It gets more obvious when 20 players get their troll
:>:characters together. Even if they are manipulated as a unit, Does a
:>:watcher see a mob of trolls, or does he see:
:>:
:>: A troll with red hair.
:>: A troll with green hair.
:>: A troll with bulbous eyes and foot long boogers.
:>: A troll ...you get the idea...
:
:>Hmmm. If these trolls are all individuals based on the same basic
:>troll, or if there are more than six of them, in my system, they get
:>"bulked" together. See my earlier posts about fighting an army.
:
:What I'd like is something like:
:
: > l
: There is a group of trolls here.
: Something catches your eye: one of the trolls is Bubba!
Hmmm. Well, I could extend the distinguished recognition code. The army
post, if you recall, added as an afterthought that there was an officer
among the troups.
:Along with all the other standard vations on group size,
:recognisability, etc. I actually suspect that it can't be handled
:gracefully from a textual interface without getting very deep into NL
:and persona prediction. Graphical may well be the way to solve the
:area -- as long as all those bodies out there are somewhat visually
:unique.
The end question is, "what's too much?"
:>:I suspect that the real problem is that I implicitly do not support
:>:compound types in the internal language. (Well, nothing more
:>:complex than typeless lists/arrays). If I supported complex types
:>:which allowed full objects to be used as components, this would be a
:>:LOT easier -- its just that doing that opens up a huge nest of worms
:>:(incompleat objects, missing dependancies, etc).
:
:>Hmm. Obviously, we catalogue things differently.
:
:True, but I'm not sure why you comment that. ??
Because I didn't follow a word of your previous paragraph. Compound types?
Complex types, I think, is something along the lines of my 'parts' system.
But what is a typeless list or array? Isn't that getting a little extreme?
Then again, you did say that _any_ command could be applied to any object.
The implications of that had never quite sunk in.
:>:Why have the objects poll? Why not have the events which provoke
:>:reactions in the object be handled by an event processor within the
:>:objects? No more polling.
:
:>Not that kind of polling. An Event triggers reactions in every object
:>present, whether they be null or not. The objects poll, in the sense
:>of request a response, their potential responses with the Impulse.
:>The response, if any, is scheduled on the Event queue.
:
:How do you handle remote reactions then? cf the old scenario of
:Kastle Krak and the Elven Forest. Even the Cystalline Tree almost
:fits.
I just posted something to r.g.m.diku about this in the loop driven vs
event driven thread. I've got three layers of event queues: global, area,
room, with internal threads in each queue. Remote reactions are going to
be in the area or global queue, of course... but, getting deeper into the
question... we're going to have to get really deep into the Impulse system
here.
:Lessee, I'll dig up an old quote on the scenario:
:
:--<cut>--
:I'll see if I can't remember the scenario that originally took me on
:this route. Do note that this is a fairly complex set that I used as
:a proof-case for a whole chunk of ideas, with spoofing etc just one of
:the results.
:
:
: The GreatGodGooGoo has a number of holy relics.
: Each relic has a non-magical base state, and a magical awakened
: state.
Not sure what the application of the magical/non magical part is, but
awakened would mean that a global condition would be logged. Conditions,
at any scope, are responsible for static Impulses.
: If more than three of GGGG's relics are simultaneously awakened,
: the GGGG does nasty things.
Awakening a relic triggers a check/increment/create on a global condition
object tracking the GGGG relics. A condition of 3 generates an Impulse to
GGGG at this point. This condition object is not used by the base classes,
so affects nothing but GGGG.
: 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.
Seems straightforward enough. Create a state shift of the bearer making
bearer's composition something heatproof and extremely hot. That's it, the
internal laws of the game handle the rest. Maybe create an affect object
to mark the changes and an unscheduled event for reversion to be scheduled
"immediate" by the removal or sleeping of the stone.
: Relic #2 is the Horn of the GGGG, which awakens only while it is
: blown and then reverts to the base state.
Extremely simple. Increments the condition object, triggering the object's
check, then decrements it, doing nothing.
: 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.
OK, GGGG awaking generates a "check for sword of GGGG" event immediate.
Likewise, the sword awakening generates a check for GGGG. Followed by a
check for MW. Um. #2, happening as soon as detection is possible, really
depends on how detection is accomplished. It could take the form of a
search probe looking for the MW, that would be manageable. Or check every
two seconds, though I would refuse to allow the area to be activated in
the intrest of CPU preservation... unless there were no active proxies
involved... #3 is easy enough.
: 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.
That's what I was afraid of... the MW is gonna be in this thing, so if it
leaves, it has got to send out a broadcast... an impulse. The sword has a
trap set for that impulse. Of course, there is no default global action
impulse for using an exit... but the exit for that sack has been
programmed with one, because it has a special property. Also the entrance.
: 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,
: out works.
WL has the property of broadcast blocking. It has been programmed to block
any global state broadcasts that have been defined as "magical". The
question is whether the awakening is sensed when the awakened object
leaves the protection of the WL. The two possibilities require utterly
different implementations of the state object. (I used the awakening =pulse method, so an object awakened in the lair is safe even after
leaving, so long as it does not sleep and reawaken. The sleep event is
prevented from decrementing by the crippled scheduling.)
: There is a Magic Cloak.
: Anyone wearing the MC appears to be the MW (more than the real
: MW (ie gets preferentially attacked)).
That sounds simple enough to code. Just a matter of changing their ref ID.
And of placing a program on the MC to make any calls to it check with the
cloak.
: Anyone carrying the MC appears to be the GGGG (non-preferentially).
Same deal, but with the cloak interpreting the checks the other way.
:Base rule: Any effect on any object must be programmable without
:source access to any other objects.
By my system's definitions, no source access to the objects. The global
condition object is a standard feature to the game, and is not a real
object.
:Challenge: Program the above, following the base rule.
:
:Now code the old sceptre/Castle Krak/Elven forest scenario, with the
:WL as part of Castle Krak, following the above rule.
No clue.
:--<cut>--
:
:The base principle regarding the above for your implementation is;
:How do you handle remote effects from a very localised event?
Those "localized" events were nothing of the sort. Each one did something
out of the ordinary, and would register global states. Of course, this is
all academic, as anything requiring global states in Singularity 2 (as
opposed to Physmud++) is suspect for violations of the base laws, as is
clearly the case with your example. But the code support is there. (So
what are the global conditions there for? Symmetry. I have reasonable uses
for local (room) and regional (area) conditions.... and since there is
symmetry everywhere else, the global conditions got put in. Lucky for the
ridiculous (by Sing2's laws) situation proposed.
:>:Outside of that the basic object model is fairly simple. Every
:>:object may accept or refuse any method call. All objects are
:>:required to respond in one of those two manners. A method call is
:>:synonymous with an event from the target object's perspecitive.
:>:From the caller's perspective it is merely a component
:>:transaction/event for the event :it is processing.
:
:>I guess this is an implementation difference. I like my
:>Impulse/Reaction alternative to method calls, if only because it
:>allows a greater degree of low level universal rules control.
:
:cf Bloodstone from Bartle's document. For the web weary I'll quote
:(excuse the formatting, I can't be bothered to re-wrap it):
<considerably more detail than I would ever bother with in the desc of a
flower, but similar concept to Physmud++>
: Mobiles were to have artificial intelligence (AI). Because of
:the way bodies were made up of parts, it was possible to get eg. a
:broken arm in a fight. A mobile might be able to figure out it needed
:a splint, and proceed to make one. Getting this alone to work as a
:general principle would be worth a PhD in AI...
That's a bit much to swollow. Not the splint... the AI part.
: Everything was interlinked. If bricks were removed from a
:wall, it might collapse, bringing the rest of the building down.
:Small-scale actions could have large-scale effects. There are,
:however, well known problems in the AI field of object representation
:concerning this kind of activity. Either the programmer has to list
:explicitly all effects of players' actions (which is difficult and
:tedious) or the game's interpreter can figure it all out on-the-fly as
:it happens. This latter approach, where there are a set of physical
:laws that are applied to everything that has moved after a command has
:been executed, is workable but vulnerable; there can be long delays as
:effects are propagated throughout the universe being modelled, and
:some effects may take considerable time to dampen down and disappear.
:Pulling a petal off a flower may seem innocuous, but if it makes you
:weigh just enough that the snow bridge upon which you're standing
:collapses, and this in turn starts an avalanche, there can be
:wide-scale devastation that is almost impossible to sort out.
Not hard at all, actually. And taking up less CPU than the poll of a Diku
through a handful of rooms. And _that_ is why I have a lot of sleeping
threads. Because of those types of avalanche effects. Though... well...
there are more probably causes than a flower petal, which I would never
allow to be coded (too much RAM for too little result) or some picked up
object (remember, if you pick it up off of the bridge, nothing has
changed)... jumping up and down might do it, though. The thing is, is we
are not talking a 100% random system.
: Bloodstone had a 25,000 word dictionary; this was quite a
:feat, but the authors never made apparent which words were actually
:functional and which were merely ignored. It is quite difficult to
:think of even 1,000 words that could feasibly be of use in a MUA.
:Again, Bloodstone appeared to be going for overkill in an effort to
:impress potential customers.
Um. OK.
: Bloodstone was envisaged as a game of life, yet there lay its
:central problem: it had no gameplay to speak of. It was a simulation
:to incredible depth, but there wasn't really much that players could
:do, it was too open-ended. Even given the extravagant claims its
:publicists made, it probably could have been forgiven all but that.
This is more a failing of the mentality of mud design at the time. A
simulation can add massively to gameplay exactly because of the avalanche
effect described earlier. Bubba ticked you off, and you know Bubba is
going to be crossing that bridge on his way home, so you start weakening
its foundation, until it cannot support more than a coule hundred pounds.
Then you hide a small cart full of nice knives just out of sight (almost)
on Bubba's side of the bridge. Of course, the cart is cheap, but the
knives are... actually tin, with rocks under the third layer. You get the
idea.
: Bloodstone was a grand concept, but doomed to failure. Its
:reliance on compositionality ensured that it would be stuck in a
:morass of intricate inter-
:relations between its components unless it sacrificed some of its
:depth (and thus some of its claim to originality). Some application of
:AI techniques may have alleviated the problem (eg. lazy evaluation -
:expand a rose object from a template only when it is actually in use),
:but the best approach would probably have been to represent objects at
:a higher level of abstraction. In the end, depth is useless unless
:there's a reason for it. Bloodstone's depth didn't pass this "so
:what?" test.
Well, they did go a little too far. Detail is not the objective. Laws that
can make a universe behave predicatbly, to allow unpredicted results from
clever players, is. I want the guy who thinks to put a grenade in a roller
skate and roll it down the tunnel to be able to do exactly that.
:--<cut>--
:
:>Ugh. No, I use a nervous system of sorts, with Impulses being passed
:>along the limbs and into the body, to wherever the Character is
:>stationed within the body. (In the head, for humans, etc..) Also, for
:>example, shock can be passed as an Impulse, allowing a Character to
:>be killed by pain, or some such. (but also creating a flinch
:>reaction, etc, which is really nice.)
:
:What causes the flinch to pull the hand off a hot plate as vs an
:undirected body jerk reaction that leaves the hand there?
The fact that the flinch is interpreted at every joint as a 'tighten'
reaction, exactly like the human nervous system. The closer the joint, the
stronger the response... and the hand pulls away.
:>:Cute. What discourages me from such a tack is that it requires
:>:public admin judgement calls which can (and will be) the subject of
:>:controversy by "slighted" builders.
:
:>Well, thats true as far as the literary rating and so forth, but not
:>the AI practicality factor... its pretty much an impartial measure of
:>how much the area makes Players think when they play it. See my post
:>to rec.games.mud.admin, etc... I think. Or maybe it was
:>rec.games.mud.diku.
:
:Unforunately I don't have newsgroup access right now -- and driving
:DejaNews when you don't have an exact idea of what you're looking for
:is a bear. Would you repost here?
Soon as I track it down. I've been meaning to get a sweep of my own posts
out of dejanews.
:>:>...and forcing people to look alive, lest they be
:>:>mistaken for a poorly designed TuringAI.
:>:
:>:There is a penalty for being mistook?
:
:>Embarrassment.
:
:Oh dear! You thought I was a mobile? I shall have to kill you I'm
:afraid. Please stand still and don't struggle too much old chap.
:I'll try and make this painless.
To which the clever TuringAI (which hides its own nature by challenging
yours) replies, "Kill me?! That's it. You're really asking for it, punk."
and pulls out a _very_ nasty looking self targetting deadman switched
flamethrower. *grin* And that is a real TuringAI I designed. Haven't
tested the sucker yet, mind you.
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe@hawaii.edu