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

nu.kanga.list.mud-dev

82: Re: Resets and repops

[Full Header] [Plain Text]
From: claw@null.net
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 18 Mar 97 08:42:39 -0800
References: [1]
Organization: Kanga.Nu
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. 

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.

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

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.

BYOC takes a whole new meaning.

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

>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
>great amount of chaos  ensues until a replacement NPC is found.  

Cute.  I like this.

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

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

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


om the mines. The miners of course, need tools...etc etc. If a player broke down a door, it wouldn't ever "reset" - the dwarven repair crew would shop up and patch it up. This is totaly awesome as far as I'm concerned, but implementing it would be no small chore. I think the main problem would just be balance - if the mithril vein down in the mines suddenly runs dry, the dwarven keep is thrown into chaos as their entire economy breaks down for two weeks. While this is the intended result, it would be easy to have this happening _all_ the time. (Economies are a delicate thing, especially when they involve as few people as you'd normally find in given zone, say 100 dwarves.) I'm hoping that builders that have the motivation to do this can code individual mob scripts to do this sort of thing, but I'm still planning to have the game "fudge" it a bit (having herbs just appear in the healer's chest, for example) in order to make balance less of a nightmare.