Resets and repops (a really short post)

[Nathan Yospe]

On Thu, 27 Mar 1997 claw at null.net wrote:

: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.

The definition of "room" aboive is just a convenience. But the system
behind the GURU, as originally designed, seems to be what Physmud++ is
drifting at a rapidly accelerating pace toward, only diff is Physmud++ is
text.

:>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).

You too? Seriously? I publish under the name Anthony Aspe. Managed a
couple of short stories included in anthologies (Chud, Dead Water in Del
Ray's (I think, that was a few years back) new authors series) and have a
couple of SF&F books being testmarketed. However, I don't find anything
about it unsuited. Tricky as hell... requires some serious mental
gymnastics, and all areas undergo pretty severe review. Most of the world
is just a stage, and... well, you have to be careful. The story is only in
the extended scale, the long view. Anything must be allowed in the
microcosms that make that long view up. I call it scripted free will, and
I have been pulling the wool over the eyes of players in P&P games I run
for many years with practiced application of this technique. They are free
to do anything they want... and the tale will unfold around them, whether
or not they choose to play the role of one of the heroes.

:>: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?

Semi. What happens to B if it was, for example, a player controlled object
that got changed in the period of being spoofed?

:>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.

Er, no. That's 'Rocheworld' (originally 'Flight of the Dragonfly')

:>Neutron
:>star surface. 
:
:Whoops.  Wrong one.  The Roech point one was Dragonfly something...

Right. Hal Clememnt is OK, but by far my favorite hard science authors
are, in order, McMurey(sp?) (Murder in the Solid State), Forward (above),
and Sheffield (Cold as Ice, Between the Strokes of Night, etc). My own
writing tends to be a little to heavy for my own tastes. (I like to curl
up with a good Pratchett discworld book or a bit of Asprin.) In any case,
I've always thought a MUD written with the space operatic scope of Star
Wars but the science of Forward or Sheffield could really be something.
And seeing as how no one else is going to do it... now, if I wasn't also
planning to release the codebase, it would be easier.

:>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.

Yeah. The server locks down the physical laws. I don't figure there is
reason to provide support for alteration of fundamental laws without a
recompile.

:>:>...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.

Ah, true. There are many extensions to this, leading into evolution and
self balancing mobs.

:>:>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>

Aaaahhh!!! Duck and cover!!!

:>: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:

Hmmm. I'll go back through my old mail.

:>:>: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?

Ummm. And sitting there? Can't be all that key, then, can it? There is
always the "vanish the moment the room is empty" or the "quietly vanish if
not referenced (looked at included) for n seconds" or the favorite decay
method. Of course, at this point, a key element might actually signal some
AI driven mobile to come pick it up in a reasonable fashion. Or something.
Dunno. Seems rather improbable, in any case.

:>: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.

Yeah. Of course, I'm not going to provide the code for it... if the
players want it, they can do it themselves. (How? Easy... move them into
the proper timeline with an overridden move... one that specifies
timeline. This will set their timeline to the new one. Programmable.
Expensive as all hell, if done right.)

:>:>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>

*chuckle* Personally, I was never impressed with any of my early MUDs.
I just liked the social atmosphere. Then again, I got into them from a
background of already having written a few local network puzzle games, and
even though I didn't know how _attrocious_ the code itself actually was,
even back then I realized that I could do better. The LPs were too slow
and the Dikus too crude. It never struck me that the Dikus remained crude
because of poor initial design concept, and the LPs remained slow because
of a flawed design concept (IMO) of writing bad code in a crude language
(yes, I despise LPC almost as much as QuakeC) on top of a bloated
driver/server. Yes, runtime loading is nice (but I've finally got runtime
loading wrappers done for Solaris, Irix, HPUX, NeXTSTEP, and NT... dunno
how to add OS/2, Linux, or BSD, and MacOS is impossible. (Rhapsody will
use the same architecture for runtime binding of new code as NeXTSTEP))
but there is little else to impress about LPs. No threads support, no
support for adding tree types, no support for event evaluation, and the
drivers I've seen are not programmed to be maintainable. Dikus are a lost
cause. MOOs are similar, for the most part, to LP in problems. I've been
unable to find a single existing solution that I like.

:>:>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.

That's logic, not sense. *grin*

:>: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.

*nod*

:>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.

I love strategy too... but in my opinion, few life or death battles are
run like chess games. Of, there is a lot of strategy in setting up for a
confrontation, in preparing... in directing a battle of forty or fifty
players on each side... but when it comes to the crunch, you don't have
_time_ to strategize. My battles rarely last more than 10 seconds. Unless
someone is sniping on both sides. And no large weapons get used. Its not a
matter of no support for strategy.. the truth is, improvision gets you
killed... and battleground strategies... chess games... are fancy names
for improvising.

:>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.

Yes, but how much of a challenge is that in your games? The whole point in
my game (this one, at least) is that sitting still, building defenses, is
a lost cause. The enemy isfar too powerful, and determined to eradicate
you. The only hope lies in taking the battle to the enemy, which means,
really, that you will be avoiding fights in hostile territory with enemies
unafraid to die.

:>:>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.  

Yeah, I know. But I never got around to reading it. Franky, I was an early
Berserker fan, and got burned out by that.

:>: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?

Michael Hohensee (michael at mainstream.com/aemud at geocities.com)
Shall I do the honors?

:>The Saphire guy? He seems bright.
:
:Have not noticed him.  Go for it.

Tatt (quest at newl.com)

:>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?

Trying to track him down.

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

Greg Munt <greg at uni-corn.demon.co.uk>

:>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.

Not sure of either of their addresses. I'll send out invites soon as I get
those.

:>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".

Alright, I'll send out invites to the three above who's addresses I know.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu