[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

98: Re: Resets and repops

[Full Header] [Plain Text]
From: Nathan Yospe <yospe@hawaii.edu>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 20 Mar 1997 09:07:16 -1000
References: [1]
Organization: Kanga.Nu
On Wed, 19 Mar 1997, Jon A. Lambert wrote:

:> From: Nathan Yospe <yospe@hawaii.edu>
:> :On 17/03/97 at 12:17 PM, "Jon A. Lambert" <jlsysinc@ix.netcom.com> said:
:> :>I heartily agree with your sentiments.  I am attempting something
:> :>similar. I treat most NPCs identically to characters.  The subsystems
:> :>that NPCs run issue commands to an input buffer.  In like fashion, the
:> :>players' input buffers are written to by the network process. 
:> 
:> The problem here is that you get the same overhead on an NPC as on a PC,
:> with the interpreter, but twice, as you have to create the NPC commands
:in
:> the first place.
:
:You are correct in this first instance, interpreter overhead is the same on
:an
:NPC as a PC.   The script that issues NPC commands requires very little
:interpretation.  The overhead does in fact occur primarily in the command
:parser.
: 
:> I do allow for this in my own system, but I also have
:> lower level command access for both PCs and NPCs, and in general, PCs
:tend
:> to use the command buffer more, NPCs the lower level access. 
:
:This is interesting, I have thought of black-boxing low level routines so
:they 
:can easily be integrated in higher level scripts.  You then come up with
:two
:levels of user-programming.  Your more sophisticated mud-programmers
:creating these lower-level routines and your less sophisticated users
:accessing
:these at a more abstracted level.  

I have about four levels of programming. The lowest level requires a
restart of the MUD, though it has the nice advantage of being runnable
from within the MUD, contrary to Dikus (I have an emacs/pico/vi access
pipe for top level imms, and failed bootup protection, bringing up the
last viable mud core when there is a failed bootup, but not the mass of
areas, etc.) This is, of course, the C++ access layer. The middle levels
are integrated into the same language, which allows both low level (yes,
blackboxed) calls to C++ objects and indistinguishable calls to objects
designed in the lower middle level usage of the language. (Think library
vs application writers in C++) The highest level language is the scripting
language provided to animate Characters, usable for NPCs and PCs... a
quest writer could use this for all of his quest NPCs, and a Player could
use this for a script to keep his Character alive when he goes LD.

:> :>I have attempted to balance this by programming some
:> :>NPCs to be "marshalls" for other NPCs or controllers of city/town
:> :>subsystems.  Thus not all NPC scripts are  active and consuming
:resources
:> :>all the time.  For instance city guard captains are  programmed to
:issue
:> :>patrol orders and attack orders to their charges.  An interesting side 
:> :>affect is that by taking out a "marshall" or subsystem controller, a
:>   ^e?
:> :>great amount of chaos  ensues until a replacement NPC is found.  
:> 
:> :Cute.  I like this.
:> 
:> Hmmm. I tend to like everything remotely active to be completely active,
:> thinking for itself to a greater or lesser extent.
:
:I agree with this, the type of activity I refer to occurs whether or not
:players are
:present.  The individual tactical activity occurs when players are present.

Hmmm. I use macroscopic event prediction to account for whatever happens
while an Area is Playerless. Then again, I've got a background in chaos
mathematics, thermodynamics, nanotech... I tend to think that way anyway.

:> *grin* I modeled a bit of that into my graphical project... I like it
:too,
:> and hope someone will eventually run such a world with a Physmud++
:base...
:> I certainly provided enough support for that, and for alternative
:physical
:> models... nonetheless, any consistant model will create a better mud,
:> whatever the model may be.
:> 
:I would be pleasantly surprised.  I suspected that my model to be
:inconsistent with 
:a model based on real physics.  My world is round with a hole in the
:middle.  Water
:flows into one hole and out of the other.  It is suspended in aether.  The
:sun is exactly 
:30 miles in diameter and is in fact a flat golden disc that descends and
:ascends into the 
:hole.   The stars are in fact fixed in the firmament of the heavens.  The
:amount of aether 
:present in an object determines its attraction or repulsion to earth.      

Actually quite easy to model. Aether I have done before (For a lark, I
modeled Terry Pratchett's Discworld in one simulation... where light is
only barely faster (sometimes slower) than sound, and the world rests on
the backs of four elephants riding on the shell of a giant space turtle.)
Your universe is quite well defined... The forces, as I see them, are
Mass/World attraction, Aether/World repulsion.... I could use these, and a
proper balance of mass and Aether for your sun, to model the celestial
motion of the sun. The fixed stars are not a problem at all (I never
bothered to unfix the stars for Singularity 2.... as I never even coded
them in.) Water behavior sounds natural... if we have any sort of spin to
the world, I could give Aether a polarization value, and water would
simply be responding to the pseudo magnetic properties of the Aether
field.

:> :>They demand sacrifices, quests and generally participate in mortal
:> :>affairs.  As such they are roleplayed by whomever is granted with the
:> :>responsibility.  With this in mind, I have done away with my
:solar/lunar
:> :>timer events and have assigned maintenance and execution of these
:events
:> :>to the Apollo NPC's and Artemis NPC's subsystems. 
:> 
:> Quite nice. How do you model the Deiatic charis
:> 
:What does this mean?  I am intimately familiar with Homer,Hessiod, the five
:playwrights 
:and Plato, although only in English translation.  

Attraction of the gods... the ability of a god to force attraction from
any mortal. Kind of a touchy issue.

:> Linking scheduling is quite simple in my system, partly because I had to
:> allow for the distorted physics of the region around a black hole, the
:> effects of time dialation, and simpler matters such as different
:planetary
:> systems, differing gravitational fields, free fall localities, fluid
:> environments... I think I could link in a "gods" system fairly easilly.
:> The whole point of Physmud++ is that it can model any, _any_ set of laws
:> to the universe.
:
:Even if these laws are consistent in their inconsistency?  I think part of
:the
:charm of such an environment is that it can conveniently match with
:observed 
:behavior and be believable in context.  I keep thinking of the scene in
:Monty
:Python's Holy Grail where a discussion about how to determine whether the
:lady in question was a witch.  Can such ridiculous observable behavior
:occur
:in your physical model.  Is the lady, lighter or heavier than a duck?  In
:my model
:there would be ample observable evidence to support the lighter than a duck
:theory, since if the lady be a witch she would have a good deal of aether
:within.
:Thus she would readily be repelled by the earth, more so than a duck. ;-)

Sounds like what I would expect from your Aether/Mass model. Yes, the
Aether laden witch would be lighter, potentially, than a duck. I want to
see an overly enchanted sword lift its owner into the heavens.

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

> Actually, there is another way... make the separate objects for > > the armor, then write code which allows them to be referred to > > as if they were a unit. Such code could be useful in other > > situations as well. > > I was thinking of doing that, too. Eg a swarm of bees, a pack of wolves, > (You can give the intelligence to that container) and bulk objects: water, > coins, etc. It's actually a container for one type of thing. (Have to > remember about differing between an actual container and a bulking > container... Can't just go and inherit an object list if I only need a > count). Ahh, bulking container! I hadn't thought of a name for my folding/merging/splitting water objects. Good one. 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. 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... > From: "Chris Lawrence" <clawrenc@xsvr1.cup.hp.com> > > Largely I agree with Casey here. I think the real solution is to define > > a general handling for composite objects, such that they can be > > manipulated as one. This helps handle the age-old problem of: > > > > > i > > You have 20 balloons. > > > drop balloons > > The balloon flies away. > > The balloon flies away. > > ...etc > > > > How to do it? I have no idea as yet. > > What do you think of the container approach? It works, except for the case of some of the ballons being/acting differently: > i You have 20 balloons. > drop balloons The balloon flies away. The balloon suddenly turns into a ghost, shrieks at you, and flies away. The balloon bursts noisily as you release the string! BANG! The balloon falls with a THUD! Obviously a lead balloon. Tbe balloon flies away with a WHEEEEEEEE of leaking gas. The balloon shivers and bobs beside you, seeming lonely. ...etc. [...deletia...] --<cut>-- Interestingly enough the above was going on while we were also discussing R*-Trees and user-assigned naming schema. It just keeps on coming around -- not that I still have any decent workable idea of how to do anonymous groups, or component bodies. 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). >> What I don't do is bind player characters or non-player objects to >> using the parsed command line. Any object may directly call any >> method, with any set of arguments, on any other object. Of course >> it is then up to the receiving object's security criteria as to how >> and if it accepts the call (stolen straight from COOL). As such the >> automation code for mobiles >Very few of my objects can be called at all by anything outside of >the Environmental Nuance And Balance/Localized Event State (don't >blame me, one of my friends is an acronym freak and suggested the >above when I attempted to describe the enables system.) What this >means is that my system cannot be commanded to act, except by proxy >or programmed response. Everything is based on the ability of every >object to REact. This means that every object has a set of reactions >to poll through for various impulses, but does not have to react to >any specific impulse. (Though, for example, gravity is a very >persuasive impulse, with a reaction that cannot, in the current >version, be overridden, merely countermanded.) 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. >> (that's all a mobile is: a normal object with an event chain that >> causes state changes in the mobile) can directly call the relevant >> methods to affect the subject mobile, or it can lodge command >> strings to be parsed into a direct method call (which in truth is >> just another method call with the command as an argument). >For me, a Character is an object capable of taking commands (from the >Player, AI, etc) and delivering impulses to associated Item >components. (Sort of a nervous system representation) If you recall I virtualised bodies from characters. Thus I have "characters" which a user or mobile controller connects to, and which more or less equate to "soul" or "personality". A character object can in turn connect to and control multiple body objects. The bodies conversely are strictly physical affairs -- indentical to the standard concept of a body (lump of meat/metal/etc). 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. Actually the command source for player controlled bodies/characters and mobile controlled is even identical. A player command comes in as an event which does nothing but translate the command into a method call on an object. It then logs _that_ method call as a new event and exits. The only difference for mobile animation is that each mobile event will log a successor event which could be a command to be parsed and handled as above, or a direct method call. In the end, its all the same. What I don't have is your concept of globbed bodies, ie a body composed of a hierarchy of loosely associated and grouped objects which conform to a unified presentation, but are capable of acting and reacting independantly. (Am I correct for your system?) I could sort of fake something like that thru really really nasty inheritance trees (inherit from all the appropriate parents to plop body compnentes together (ie an arm parent, a leg parent etc)), but devil take it if that's a solution I'd put my name to. >> Part of the neat aspect of this is that I expect players to augment >> themselves and their character objects with home-grown, purchased, >> stolen, or otherwise acquired code to implement various neat >> features. Earlier discussion focussed on the Combat Packages aspect >> of this (more or less intelligent user-written combat AI libraries), >> but I can also see it happening with socials, naming cards (objects >> which auto-register/de-register names on the recipient), mana >> factories/sinks, :etc. > >Hmm. Of course, having made my world highly dependent on real world >physics, none of this is relevant to me... From what you've written earlier, I suspect a more accurate description would be that your system defines a base set of operational laws for objects and their reactions (gravity, solidity, mass, density, size, etc for a "normal" universe) and then allows objects to manipulate within that externally enforced framework. As such you have an externally enforced framework within which everything else must happen in a logically consistant manner (per the framework). No? Conversely I allow any sort of object/class to be defined, with the only requirement being that the state of any object must be logically consistant with its individual history of messages received and sent (ie event history). System-wide consistant behaviour on one side, and endless flexibility on the other. Both have advantages. >> BYOC takes a whole new meaning. >Heh. As opposed to my system: BYOI - bring your own intelligence. A >player cannot write code to violate physics, but there is nothing to >prevent AI writing, though the AI will have the same limits as a >player... merely, possibly, faster reflexes. Whithout the base law violation requirement, this is pretty synonymous with my system and encouragement of player/object augmentation thru Combat Packages, Magic Filters, etc. >I expect and encourage >players to write AIs for whatever they feel an AI could handle better >than they could... then rate builder's products on how much Player AI >is used in the builder's zone. Certainly ups the creativity factor... >and since the rating factors into how many mortality points a builder >can gain (which make the difference in terms of reincarnation, as >well as purchasing more builder resources, creating new Characters, >etc...) for an area, builders vie for the most complex Area AIs and >challenges. 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. >> Hehn. I took a classic (for me) tack, and decided to ignore the >> problem on the basis that it would invalidate the server both for >> simulation work, and because addressing it would cause any unrelated >> synergy across the MUD world to dissappear (eg rumours of events in >> areas not populated with players would no longer propagate, which >> would cause remote reactions to their rumours (cf watchers, spoofs >> and triggers) to no longer occurr). > >This, for me, can be handled completely by the update factors... and >I could never run a simulation without a TuringAI controlling at >least one Character in the simulation region, and TuringAIs trigger >action the same as Players. TuringAIs are designed to convince >Players that they are Players, thus upping the apparent Player >density... and forcing people to look alive, lest they be mistaken >for a poorly designed TuringAI. There is a penalty for being mistook? >Hmmm. I tend to like everything remotely active to be completely >active, thinking for itself to a greater or lesser extent. Similarly. However the marshal concept allows a central repository to >> cf the original Gods system. You can find a passable description in >> Bartle's original MUD survey. > >Uh... what survey would this be? I thought I posted it before: ftp://ftp.parc.xerox.com/pub/MOO/papers/mudreport.txt ftp://ftp.parc.xerox.com/pub/MOO/papers/mudreport.ps ftp://ftp.parc.xerox.com/pub/MOO/papers/mudreport.ps.Z depending on preferred flavour. -- J C Lawrence Internet: claw@null.net ----------(*) Internet: coder@ibm.net ...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...