Resets and repops

[Nathan Yospe]

On Tue, 18 Mar 1997 claw at null.net wrote:

:On 17/03/97 at 12:17 PM, "Jon A. Lambert" <jlsysinc at 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. 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. Nonetheless,
PC reflexes, for example, take advantage of low level access, adn some
people will undoubtably use the high level access when programming NPC
behavior. My PCs and NPCs are not different classes... there is a single
tag with enumerated values Player/AI/Comp Control/Switched Out for the
four basic states of behavior. Imms cannot enable anything but their own
bodies and Comp Control bodies... In other words, no player body stealing,
and no disruption of complex evolutionary AIs.

:I don't distinguish between any sort of objects, be they rooms, mobiles,
:dumb objects, or players.  They're all the same, all do the same things,
:and outside  of the IO going to a connection object for players, all run
:exactly the same  code.

That's interesting... you use a free user programming system, though,
don't you? My Characters are not physically there... they are sort of a
core for a creature to be built around, out of Item components... an Item
is simply a composite of Item components with no Character mind behind it.
I guess this is partly a result of my limb component system... any Item
component, capable of being a full fledged Item in its own right, has a
set of Types it inherits behaviors and characteristics from, many of which
are precoded in binary form, but which can be added to by internal
programming. As such, you can program a Character, but you can also
specifically program its arm to be, say, a cybernetic cannon with special
targetting...

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

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

: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 teh 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, but my codebase certainly doesn't
forbid it, should an admin of some less scientific version decide to make,
for example, programming equivalent to spell design/learning/casting.
Again, this would require some interesting constraints on programming...
making the programs cost the programmers big time in some manner...

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

:>I also agree with the concept that NPC activity continues in areas/zones
:>that players are not present in.  There can be significant overhead
:>involved with this. 

: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. The less
desirable Players get kind of weeded out by these things. In any case, the
overhead on the system, if I ran _everything_ would be far too great.
Better to run a handful of Areas where the Players are... it also keeps
track of where people go quite well.

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

:>In a related vein, I was inspired by Nathan's description of his
:>implementation of the physical laws of the universe to do something not
:>altogether dissimilar in my server.  While Nathan's model seems highly
:>appropriate to a real world with real laws of physics, my world's physics
:>are entirely subject to the whims of the gods.  I don't believe in
:>physics, I believe in divine intervention. (*grin*) It was my original
:>intention that all immortals/deities actually be THAT.  They  can be
:>player/administrator run and can be used literally as gods. My immortal
:>pantheon is very similar to the greek mythos albeit with different names.

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

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

:> It may be that Apollo might wish to delay the sunrise to allow a favored
:>player to gain  advantage in an early morning attack or Artemis decides
:>that an eclipse would be  appropriate to auger a significant event.  With
:>the NPC always "playing", it is possible for them to respond in an
:>automated way to sacrifices, prayers and quests. There are many other
:>possibilities, as I decide which dieties' subsystems control which  mud
:>events.

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.

:cf the original Gods system.  You can find a passable description in
:Bartle's original MUD survey.

Uh... what survey would this be?

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            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