Resets and repops
Nathan Yospe
yospe at hawaii.edu
Fri Mar 21 12:53:27 CET 1997
On Thu, 20 Mar 1997 claw at null.net wrote:
:On 19/03/97 at 01:53 PM, Nathan Yospe <yospe at hawaii.edu> said: >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>
:
:>In other words, no player body stealing, and no
:>disruption of complex evolutionary AIs.
:
:Awwwww. Body stealing is *so* much fun.
*grin* Aw, well. It could be implemented, of course...
:>> 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?
:
: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.
:>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...
:
:Interesting. We had quite a bit of discussion on the old list
:regarding anonymous groups. I suspect with your system they would be a
:doddle. This relates quite well to few posts from the old list (for
:the new chaps here, clawrenc at xsvr1.cup.hp.com is an old email address
:of mine):
:
:--<cut>--
:From: "Chris Lawrence" <clawrenc at xsvr1.cup.hp.com>
:Date: Thu, 26 Sep 1996 12:06:45 -0700
:
:
:> From: Orion Henry <ohenry at sdcc10.ucsd.edu>
:
:[...deletia...]
:> > > > Oh yeah, I hate that. We have several levels of command
:> > > > verification, so you can specify that you need two functioning hands
:> > > > to do this certain command, or two functioning arms, or a be able to
:> > > > walk and have sight, or be able to talk...etc etc. This is great,
:> > > > from many standpoints, and quite easy to implement. Thus when your
:> > > > hands are both severed, you can hug someone, but you can't pick
:> > > > anything up or open doors.
:> > >
:> > > Possible problem: All of the above more or less fails when the mody
:> > > is an amorphous amoeboid blob.
:>
:> Actually, not at all. I'd be quite confused if the blob shook my
:> hand.
:
:Why?
:
: The blob extrudes a pseudopod!
: The blob's pseudopod globs on to your hand! Ewwww! Blech!
: The blob shakes your hand!
: The blob farts in your general direction.
: You smell of elderberries.
I remember this. If you recall, I have a shapeshifting species available
for play. The limiting factor is the difficulty inherent in reconstructing
a skeletal system for this species. Thus, you could quite easilly have a
Slipt (the aforementioned species) form an extra pair of arms... of
course, coordination might become a problem. A Slipt can manage four limbs
optimally. After that, each limb being actively used incurs a coordination
penalty.
:> Anyways, we don't try to model things that don't make sense
:> or wouldn't/couldn't exist in nature. A "blob" would either be
:> organic (thus combat with it is quite simple) or magical. In either
:> case it doesn't bother me that it be a little different, nor that it
:> can't open doors/shake hands/nod its head.
:
:Sure the blob can open doors, shake a head or hands (or three heads
:and twenty hands, simultaneously) -- it just keeps extruding new body
:parts, heads, hands, legs, whatever.
Exactly.
:The thing to me is that the blob can mold parts of its body into any
:form (forgery, impersonation, localised creation of limbs and other
:features, etc), and that it can more or less squeeze thru a hole of
:any size. Standard attacks with edged weapons fail as, while they do
:physically cut the body, the severed portions then reunite with the
:main body, more or less undamaged. Want the blob to look like a man?
:With great effort it can mold its body into a humanoid shape, walk on
:two legs, and even forge vocal cords to attempt human-style speech.
:Want better? Have the blob pour its body into a suit of plate armour
:(or a really well fitting Italian suit) and animate that.
*grin* Right. Of course, a blob might not be as strong as a human in that
suit of armor.
:[...deletia...]
:--<cut>--
:
:and from the same digest:
:
:--<cut>--
:From: "Chris Lawrence" <clawrenc at xsvr1.cup.hp.com>
:Date: Thu, 26 Sep 1996 12:48:18 -0700
:Subject: Combat rethought?
:
:Re: limb based damage, combat, bodies etc.
:
:[...deletia...]
:
:Not quite. Its probably easier to start from the bottom up however,
:rather than addressing just this point. My fledgeling idea is to have
:a body type object contain a compound list, where each node on the
:list represents a body segment, and any particulars on that body
:segment (stats etc). The body type object then inherits from a numher
:of body segment objects, each of which adds body component types to
:the body type object. The body segment object types map to the nodes
:on the body segment list, allowing them to be interpretted. The body
:type object then also inherits from a base body object which contains
:the base methods used to assemble and manipulate bodies in general.
:
:The base body object primarily defines a broad range of virtual
:methods. Things like CanManipulateSmallObjects(),
:CanDoXXXXSimpleThing() etc. It is then up to the body object to
:fulfill/define those virtual methods on the basis of the body segment
:parents, and the nodes currently defined on the body segment list.
:
:A character or mobile object would then inherit from one of these body
:type objects to define what type of body this thing had.
:
:Thus there could be troll body type objects, human body type objects,
:etc. The blob body type object gets a little more interesting in that
:its body segment list is highly dynamic (what pseudopods has it
:extruded at any one instant?). The definitions for the virtual methods
:off the base body object would then have to either scan the current
:segment list to determine current capabilities, or even grow a new
:segment, changing the segment list, to fulfill a request.
:
:The necessity for virtual functions underneath this is to allow the
:base body object to define a generic API (eg all the CanDoXXXAction()
:methods) which all body type objects must then adhere to. The reason
:for making them virtual is the old one -- it forces the body
:programmer to actually define those methods for that body type.
:
:[...deletia...]
:
:Given a segment list as above, and an inbound damage message (for
:instance) could have its value spread across the various body
:segments. The body segments would then react as per their defining
:object parents. Ugly, but perhaps workable, especially given that I
:can have the base body object require that all body type objects
:satisfy a given API for the capabilities of their body, thus allowing
:all other verbs and objects to have a simple method of checking what a
:given body can do.
:
:> > > 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.
:--<cut>--
:
:and getting back to anonymous groups:
:
:--<cut>--
:From: "Chris Lawrence" <clawrenc at xsvr1.cup.hp.com>
:Date: Thu, 26 Sep 1996 13:17:30 -0700
:Subject: Re: Realism vs. Playability (Was: Muds w/o boring stock
:races!)
:
:> From: Wout Mertens <Wout.Mertens at rug.ac.be>
:> Travis S Casey (casey at xi.cs.fsu.edu) wrote:
:
:> > 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.
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.
: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.
:> From: "Chris Lawrence" <clawrenc at 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>--
Of course, lumping things by name is quite fun... it assumes that name
(short desc, whatever) implies appearance, so that nature is not known,
but appearance is.
: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've got the second, still working out parts of the first. A lot of my
ideas started here, though, in one form or another.
: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.
:>> 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.
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.
:>> (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).
I have three levels of this, I suppose... The Player, the Character, and
the set of Items that compose the Body. Players are a little farther from
Characters than your character is from your body, and Characters are a bit
more tightly bound to their Bodies than yours. Its not too dissimilar,
though, on the whole.
: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.
: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.
Likewise for my own, at least in theory. As discussed at an earlier date,
I have several types of Character AIs. Some are essentially Players, some
are lower level, some are root level stimulus response sequences.
: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?)
Yeah, that's a pretty accurate description.
: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.
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.)
:>> 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?
No, that is correct. I was refering to Singularity 2, the MUd, and not
Physmud++, the base, which could (hopefully) be easilly adapted to any
well defined system of "natural" laws. Most of this adaption would be in
the base Physical class... if Mana were made a feature of the Physical
class, and possibly of the Location class... and the rules were well
defined (IE, mana transfer, regeneration, etc) the system should function
quite well. User programming, it seems, would be a decent model for
magery. (Anyone here ever read Rick Cook's wizardry series?)
: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).
An interesting system.... not sure if I could do that with my engine.
:System-wide consistant behaviour on one side, and endless flexibility
:on the other. Both have advantages.
Yeah.
:>> 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.
Ah. I guess the difference is, the core lib would have to be recompiled to
actually violate the physical laws... and they would simply be new laws...
but I don't allow Players to code anything for their Characters that they
could not do themselves with their Characters using an outside scripting
language interfaced to their telnet client.
:>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.
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.
:>> 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?
Embarrassment.
:>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
:
Hmmm. Well, Maybe, yes.
:
:>> cf the original Gods system. You can find a passable description in
:>> Bartle's original MUD survey.
:>
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ 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
More information about the mud-dev-archive
mailing list