Resets and repops (a really short post)

claw at null.net claw at null.net
Thu Mar 27 12:31:23 CET 1997


On 24/03/97 at 10:38 PM, Nathan Yospe <yospe at hawaii.edu> said: >On
Mon, 24 Mar 1997 claw at null.net wrote:
>:On 21/03/97 at 11:09 AM, Nathan Yospe <yospe at hawaii.edu> said: >On
>:Wed, 19 Mar 1997 claw at null.net wrote:
>:>:On 18/03/97 at 10:00 AM, Adam Wiggins <nightfall at inficad.com> said: 
:>:><Chris Gray:>

>Different philosophies. I'm doing this partly as practice for the
>GURU thing. Erm. I'm it now, for that. The other guys decided
>manifold theories and other meaningless math was more their line...
>Dan (he's lurking here) Mazeau will be joining me eventually on that
>project. The point there, though, is that GURU is an experiment in a
>mass player interaction in a rather detailed and vast world. I can't
>afford to have the entire world running... not with 10,000 players
>and several million "rooms", where a room is the distance a player
>can walk in about a minute... this is the goal for GURU.

Funny thing is, without the metrics (rooms, one minute), I have almost
he same goals except that I demand that the entire game be animated,
players or no players.

>Yeah... I guess the focus makes a difference too. I tend to have more
>passive scenarios... there is a definate plot, self renewing. Well...
>different philosophies..

I basically avoided the plot viewpoint as I have no control over what
other builders do, I've never seen it done well (multiple
order/solution path intersections (and that's with a background as a
paid writer (SF&F, mostly short stories))) and I don't think its
suited to a MUD world which is in a constant state of development and
change (ie user's changes permanently afffect the world for all
players).

>:Again, depends on implementation.  I allow a player to place a geas
>:on a mobile, essentially allowing the player to order the mobile to
>:follow a course of action in fair certainty that it will.  (Spoofs
>:are wonderful here -- they sit on the mobile and trigger on external
>:events to insert forged events into the mobile's stream to make the
>:mobile do what they want)

>Hmm. I wonder how your spoofs compare to my filters.

A spoof is an object that stands inplace of another object.  Its
easier to explain with a diagram:


    ObjectA and ObjectB exist.
    ObjectA spoofs ObjectB.
      ObjectB is cloned to ObjectC.
      ObjectA creates a new object (the spoof) with the same ObjectID
        as ObjectB.

  The replacement ObjectA above is the spoof.  The reason it is so
  powerful is that none of the rest of the system has any evidence it
  happened, and the spoof contains a "generic method" which passes
  method calls thru to the clone ObjectC, possibly after extra
  processing.  The results of such a method call can also be
  post-processed before returning the value to the original caller.
  The result is that the spoof is able to add, alter, or subtract
  features from ObjectB without ever directly affecting ObjectC or 
  giving ObjectC (was B) any clue that its been spoofed.

  Deleting a spoof is a matter of deleting the spoof object, followed
  by copying the cloned original (ObjectC above) back to the original
  ObjectID (ObjectB above), and then deleting ObjectC.

Clear?

>Depends on the setup. At the moment, it should be capable of handling
>Clement... I test ran it on Robert Forward's "Dragon's Egg". 

That's the water world with the discussion of Roche points isn't it? 
Neat.

>Neutron
>star surface. 

Whoops.  Wrong one.  The Roech point one was Dragonfly something...

>Essentially, I define a physical object in terms of its
>properties, likewise a location object, and the interactions of the
>above are defined in the base class functionality. All classes must
>be derived from these, or independant of the "real world" or
>supportive of something of the above.

Capiche.  So its all built into the server at that point.

>:>...I would have a generic
>:>shopkeeper, and a set of pick and choose features, which would be
>:>applied to the generic shopkeeper randomly by his predecessor upon
>:>death, and scheduled for an appearance at some later date.
...
>:
>:I can do this (haven't) by having a data blob passed down from the
>:original event:
...
>Same dif. The players will never know.

The difference is that the now-dead mobile can pre-determine the
characteristics of the to-be-created mobile.  That can be rather
useful.  Kill the shopkeeper too often and his replacements become
increasingly twitchy.

>:>I can see how this would be nice. Damnit, now you got me thinking
>:>of scrapping my Event system and rewriting. Don't do that! *grin*

>:I'm really really really sorry.  I promise to do it again.

>Right. You wouldn't do that to me, would you? (Preps a return salvo
>of inspirational material)

Of course not.  Every time.  <Busy assembling script to auto blast
entire MUD archive to list for every new idea submitted>

>:Because my memory image is so fluid (everything resides on disk) I
>:haven't looked much at using in-memory compression.  I do reference
>:count and fold strings tho, and the whole DB cache with the
>:requested, modified-but-not-committed, committed, etc states, along
>:with the interested party lists is pretty tight.

>Hmmm. An utterly different model here. I don't understand half of
>what you just said.

Ahh, its time for a refresher course in my lockless database model --
the old Compare&Commit business:

>:>:Handling minor details like closing opened doors, re-locking
>:>:chests, and resetting traps and the like is similarly handled,
>:>:with the secondary event either doing it directly ("A sudden
>:>:strangely cold breeze slams the dtor shut"), to the animation and
>:>:trekking of a work-horse mobile to the door/trap/whatever to reset
>:>:it "manually" (cf MirrorWorlds "man in a white lab coat")..

>:>Ugh. Lets just have it happen when no one is looking.  

>:As pointed out earlier on this thread, the problem is that an object
>:in a well travelled location (ie constant player traffic) will never
>:reset.  While this may be a Good Thing on the face of it, there
>:should be an automated system to retrieve the object to allow the
>:reset.

>Ah. I try to discourage high trafic areas with resets. I prefer non
>reset mothods in high pop areas, preferably organic and evolutionary.

How about a key item for an area being removed and dropped in a
heavily travelled room?

>:Which presents a very interestingly fluid aspect to time.  Were I to
>:do this I could see having mobiles set up to edit character's
>:timelines for a fee, adding or deleting event histories to allow
>:travel to different time tracks.
>:
>:(Always the rebel)

>Heh. Time pirates and time police. This could get fun.

Thought you'd like that one.

>:>So far sounds like Midgaard janitors.
>:
>:Accursed insult!  Die foul fiend!  Begone loathsome malingerer! 
>:<<Like Midgaard indeed!  Ha!  The bloody nerve>>

>*laugh* OK, I appologize.

<mutter>

You may guess from this that while I'm was impressed with the early
LP's (back when Lars was on the ball (even if I dind't like playing
them)), since then, well, I'm not so impressed.

<sniff>  <bloody foreigners>

>:>Hmmm. A possibility: enchant an opponent's sword to destroy it?  

>:Yup!  Especially if you know there's not enough mana about to
>:support the enchantment, which is likely, considering that your
>:spell soaked up a bunch of mana to create the effect.

>Hmmm. A very, _very_ interesting world. One with little sense in it,
>but fun.

Ahh, not quite!  The goal is for the world to make total sense, and to
be entirely logically predictable and consistant within its framework
and base axioms.  However, the goal is also for that framework and
those base axioms to bear little relation to the real world's
framework and axioms.

Thus there is a sense, possibly a looney sense, but a self-consistant,
predictable, manipulatable almost algebraic sense at that.

>:>Or inconvenience the enemy, at the least. 
>:
>:The true test of a battle:
>:
>:  UggUgg slashes at you with his Sword of Instant Beheading and
>:    minor discomfort!
>:  > cast soakhole on uggugg
>:  You cast the dreaded mana eater soakhole on UggUgg!
>:  UggUgg sneezes and buries your in green snot!
>:  Your armour suddenly dissappears!  
>:  Your spell of magical summon protection fails!
>:  Your spell of magical sight fails!
>:  UggUgg's Nose Ring of Killer Snot dissappears!
>:  UggUgg's Belt of Gas Containment dissappears!  Phew!
>:  UggUgg's dagger of wart removal dissappears!
>:  > cast create mana
>:  You create 5,000 units of mana!
>:  Your mana stores are now empty.
>:  >cast $my_protections
>:  You are now magically potected from summons.
>:  You can now see all magically hidden objects.
>:  UggUgg thows a blade of painful castration at you!
>:  > jump!
>:  You leap mightily.
>:  The blade misses!  You are still a baritone.
>:  > attack uggugg with spear
>:  You ram UggUgg through with the spear of Icy Death!
>:  UggUgg now has the flu and looks a bit watery about the eyes. 
>:  UggUgg picks up a rock.
>:  UggUgg bases you with a rock!  Ouch!  That hurt!
>:  > throw TC at uggugg
>:  You throw the charmed trash collector at UggUgg.
>:  The TC englobes UggUgg!
>:  UggUgg gives you the Sword of Instant Beheading and minor
>:    discomfort.
>:  UggUgg gives you the Boots of Mighty Chilblains,
>:  UggUgg gives you the Goggles of Big Farts.
>:  UggUgg gives you Super Nose Hair Puller.
>:  The TC has eaten everything UggUgg was carrying!  Yech! 
>:  UggUgg is naked!
>:  Your spell of magical summon protection fails!
>:  Your spell of magical sight fails!
>:  Your spell of magical tummy tuck fails!
>:  Your spell of power voice fails!
>:  Your spell of land control fails!
>:  Your spell of bowel control fails!  
>:  Your spell of toe cheese protection fails!
>:  > stat spells
>:  You have no spells.
>:  > stat mana
>:  There is no mana here.
>:  > strangle uggugg
>:  You wrap your hands about UggUgg's neck and begin to squeeze!
>:  UggUgg prays to the Great God GooGoo!
>:  GooGoo mana blesses the area!  
>:  There is a LOT of mana here!  You skin prickles!
>:  > i
>:  You have a mana shielding sack
>:  > l in sack
>:  There are 5,000,000 TC spores in the sack.
>:  >empty sack on UggUgg
>:  The spores eat all the mana!
>:  There are 5,000,000 TC's here!  Wow.
>:  All the mana is gone!  
>:  ...
>:
>:The real weapons now are mana attacks.  But then woe be the chap who
>:sneaks in with a non-magical bodkin and pricks the battling mages in
>:the arse while they mana fight.  He might just win the war.

>Fun battle system! 

Actually I wrote that off the top of my head.  Were it a log of a real
battle for me, every step would be riddled with suggested combat
scripts, interactive editing, blow/counter-blow responses etc.

It is hopefully however, at least in character and flow, somewhat the
way I would hope a battle might go.

>I've already given the list a taste of my
>system... a different type of strategy, with a lot of dodges, mad
>dashes, tossed explosives, ducks behind cover... a little more
>intense in that sense, but with less of your clever strategy. 

As you may guess from my compleat Gordon R Dickson collection, and
signed mint set of the Dorsai quadrilogy, I'm a fan of strategy.  I
really like the idea of changing combat from a spontaneous blast of
chaotic violence, to something that is prepared for and launched as a
series of predicted set pieces.  Its no longer a penis waving question
of who has the biggest weapon, but who has the best application of
their available attacks and defenses in regard to that particular
foe's similar set.  Yet again, EQ is driven down in significance, and
the importance of the point of application of the EQ is raised.

>The
>clever strategy in my game tends to get overriden by sheer terror and
>action. Not that there is no strategy.. just that most of it involves
>not getting into the fights in the first place.

I suspect that will be a common choice in my games.

>:>Or
>:>would it drain from you by proximity? 
>:
>:Both really.  The objects don't care where the mana comes from.

>Can you direct an object's prefered source?

I guess I could....Hurm.  It would require re-working a whole bunch of
crap, but its possible.  Not sure of a clear advantage tho.  It seems
easier to create a new economy (not mana based) which is source
dependant, have the object a member of that economy, and then drag the
mana aspect in as a side effect (eg: after transaction in new economy,
also grab mana from same transaction).

>:cf The Book Of Swords, SoulBiter etc.

>Not something I've read.

Fred Saberhagen.  

>:There are still some out there.  I'd love to get people like Stephan
>:White, Greg Hudson, David Engberg, Hollenbeek (sp?), Reese, etc in
>:here at some point.  Even that AEMud chap, and as long as I don't
>:have to tolerate the NT line, the MUNT fellow.

>Yeah... I'd rather not have Reese in the list.. he's got a good mind,
>but very little tolerance for people who don't agree with him to the
>letter. 

Yeah.  He can be a pain.  I'd intend to keep him on a very short rope
until he got the idea of biting his keyboard.

>That AEMud chap might be nice. 

I don't have an address handy.  Why don't you send him an invitation?

>The Saphire guy? He seems bright.

Have not noticed him.  Go for it.

>I'm going to extend an invite to Robin Carey (the NetServe
>guy) when he gets his new account. 


Good.

> Not sure who Engberg is. 

Original author of Interlude (very neat LISP-ish server), now into
JAVA MUD development.  (I'd love to get him in here)

>Hollebeek
>seems a good thinker. 

Again, I don't have a address.  Bounce an invitation his way please?

>Munt? 

Oh, lessee: http://www.incite.com/users/clay/munt/  

>Then there is Shawn Halpenny, a diku
>coder who has ripped out everything to the same degree I have
>(meaning that there is 0% of the original diku code left) and has
>some nice ideas regarding event scheduling. 

Toss him in here.  I'd also like to get Ola Forsheim.

>Still, the brightest
>ideas I've seen on the NGs have mostly come from people on this list.

We've got a good group here, assembled over some time with some
decently smart cookies.  I want to be creful not to lose that, but I
also don't want to see the list die from familiarity (everybody knows
what everybody else has to say).

Note: One of the invitation messages, or auto-reply messages lists the
subscription address as mud-dev-admin at secant.com.

THAT IS WRONG!  THERE IS NO SUCH ADDRESS.

The correct subscription address is mud-dev-admin at null.net.  Just drop
a message there with a subject line of "subscribe".

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...





More information about the mud-dev-archive mailing list