Resets and repops (a really short post)

[Nathan Yospe]

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:>
:
:>: Built in rumour systems
:>
:>Macroscopic approximation, if you must have it. This allows a rumor
:>to traverse a dead area with no CPU burn, and when a Player finally
:>encounters the Rumor, he/she will have no clue whether it propogated
:>live or not. 
:
:For me there are two problems here:
:
:  1) It assumes that Players (or their equivalants) are the only items
:which define "interesting" in the server's world.  ie the reactions of
:internal systems to the rumour is insignificant, or can be entirely
:predicted and constructed as of any later time.  I presume this is
:centered about your concept that the universe should be
:auto-predicted/auto-generated and not maintained in real time.

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.

:  2) It requires that rumours be managed by a centralised control
:which precludes localised specialised rumour processing without the
:HQ's implicit knowledge.  (eg accellerated rumour decay, mutation,
:direction of spread, interest content, probability of delivery, etc) 
:It also precluded (well, makes more difficult at least), localised
:inconsistant rumour systems which are not part of the global rumour
:system.

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'm not real comfortable with either point.  For me MUD worlds are a
:question of accidental ongoing unforseen synergy and going the route
:of auto-generating areas as of time-predicted states just loses that.
:
:Its not that your magic system encourages players to hoard dead rats,
:its that dead rats discourage most rumour mongers from visiting you
:(aversion to dead, aversion to rats), and thus you can better conceal
:the fact that you are running a rat breeding/slaughter factory above a
:pool of TC's which feed mana to your highly unstable hoard of super
:magical objects.  Hang on!  You're not supposed to be breeding rats! 
:Why not?  Rats will eat dead TC's.  TC's will eat dead rats.  Ensure a
:fairly steady food supply (divert a stream?) and voila!  You have one
:huge mana factory.  Best of all there's no external mana leakage to
:make your area appear on mana flow detectors.
:
:Its compleatly unplannable for -- but its the sort of thing players
:(or at least players like me) would and will do.

*nod* Whereas, in my system, the game has provided far more worrisome
things than this... but GURU is going to be a lot freer, so...

:>:  Newspapers
:>
:>Er... how does this differ from rumors?
:
:They're codified and accuracy of transmission is guaranteed.  (eg the
:rumour starting in one town is "Bob died from a fall.", but mutates
:into "There was a horrible murder!" by the next town, whereas a
:newspaper guarantees that its content will not alter with travel)

Ah. But conceptually the same... They are both transmitting objects.
Diseases, rumors, whatever. Newspapers might or might not be transmitting,
now that I think about it, in a game with no electronic communication.

:>:  OBE (Out of Body Experience)
:>
:>OBE would, by definition, have a manifest Player controlled bodyless
:>Character. Sounds perfectly susceptible to the normal rules to me. 
:
:Depends on your implementation.  For me it doesn't.  I merely create
:an object in the visited location and re-route all IO received by the
:object to the player.  As such its compleatly transparent to the
:traveller, and almost compleatly undetectable to the contents of the
:visited room (they can watch the room's inventory, and so detect it).

I have a class IOSocket. An IOSocket can hold any GenericIO. The IOSocket
need not be a Character. If it holds a Player, r any other qualified
GenericIO, it triggers the room. Several of the qualified GenericIOs are
filters for Players and Characters.

:To handle the body aspects, the remote object is also a spoof on the
:player's body (it just as a different location).  Thus all
:commands/events directed to the remote object which would normally
:affect, affect the "home" body instead.
:
:Its a lot cheaper doing it this way than forging a fake remote
:character.  (Tho now I think of it, ghosts might be a neat idea).

Hmmm. I guess it might be... still, I make it quite hard to get out of
one's body. And a lot of the OOB objects are not created, simply activated
and relocated.

:>:Scrying
:>
:>Again, this would create a local Player controlled bodyless Character
:>manifestation, and adhere to the rules.
:
:Same as above except I don't bother with a spoof (not needed, scrying
:is concious), and allow control of the cry location/tracking.

Hmmm. Well, personal preferences again. I like to keep implementations
absolutely consistant.

:>:  High altitude overview (for those with 3D)
:>
:>Occupied Areas get slow refreshes even in unoccupied Rooms. Anything
:>covered by line of sight from a Player is operating full speed. 
:
:Accepted.  A problem can result in an area which is in sight from
:above (say a cavern with a hole into the roof to outside), being state
:dependant on an area which is always out-of-sight from above (the
:water flowing thru the cavern is dependant on hundreds of activities
:further up and down stream).  Now Bubba on his Pern dragon teleports
:to a position at 10,000' from which he can look into the hole in the
:cavern roof.

Hmm. I never have areas that are dependant on each other, as each area
represents a distinct world... I guess that's a diff in the def of "area"

:>:Indirect viewing ("typical" magic eye objects, or your clairvoyance).
:>
:>Again, creates a manifest bodyless Player controlled Character
:
:There are two Magic Eyes.  Each one allows a player or mobile to look
:thru it to see everything the other matching MT sees.  One is sitting
:lost in the grass by the side of a well travvelled path.  The other is
:located in the lost Dungeons where the Goblin King is planning his
:next assault.  

Ah. OK. Transmitters, another IOSocket. With some kind of filter in it.

:>object. :  Remotely controlled/possessed mobiles.
:>
:>Sounds like a Player controlled Character to me.
:
: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.

:>:  'Bots.
:>
:>Player controlled.
:
:Actually the most useful 'bots are player independant.  See earlier
:discussion.

Yeah, misconcept of what a 'bot was. Still not too bad.

:>:This is of course all pretty well MUDLib stuff, but I think it
:>:should be accounted for.  I'm a big fan of automated rumour systems
:>:with built-in local reactions to parsed rumours for one.  
:>
:>I don't mind any of this stuff, but not a thing above has violated my
:>system, and I think all of it could be implemented in Physmud++
:>without a recompile.
:
:I'm a little curious here.  How do you define a phsyical law system to
:your server?  Is it capable of auto-predicting say Clement's "Mission
:into Gravity", from base laws?  Could you handle PK Dick's (Or was it
:Farmer?) "The Man in Black" (a single character is responsible for the
:iterative translation of a universe of chaotic physical laws into a
:single law system)?  I'm trying to get some feel for the method of
:your scoping here.

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". Neutron star
surface. 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.

:>:-- When an object changes state such that a new state should be
:>:achieved some time in the future, then that object logs an event to
:>:that effect.  (Standard example: mobile is killed, and needs to be
:>:replaced in some form)
:
:>Agreed.
:
:>:-- The event that is logged is actually a fairly simple:   :
:>:1) At XXX time check conditions if the new state is
:>:allowable/logically consistant.  
:
:>Ah. Not bad. Often, the logged event is to create a new instance at a
:>future date, but with a few distinct and unique characteristics. For
:>example, were I to implement a fantasy, and desire the new shopkeeper
:>to replace the old scenario, 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:
:
:  Bubba Shopkeeper dies.
:  Logs reincarnate check event with attached data blob XXX.
:  Reincarnate event runs, checks out OK
:  Instantiate event logged with attached data blob XXX.
:  Instantiate event runs, parses data blob for preferred paramaters 
:    for new instantiation.
:
:At the moment I allow the instantiation event to figure out its own
:thing.    

Same dif. The players will never know.

:>:Its this randomity factor
:>:that prevents the known repop times.  Instead its now: Whoozis will
:>:start thinking about repopping in 15 minutes, with a 0.5%
:>probability :of actually repopping in any given minute after the 15
:>minutes are up :(so could be right on 15 minutes, or could be 6 days
:>from now).
:
:>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)

:>:3) If no, and if the re-instatement is still "possible", relog the
:>:same event as in #1 but for a yet future time.
:
:>I do have "delay" scheduling.
:?  

Reschedule the event if impossible at execution time  by n seconds.

:>:The clever stuff comes of course in the recreating of the state,
:>:which is where I finally followed ChrisG's tack <nod> and split my
:>:object model into class objects (which must be unique, and may
:>:inherit from multiple parents), and instances (which must inherit
:>:from a single class object, and need not be unique).  FWIW the
:>:driving gain for moving to this split was standardised ctors and
:>:dtors for object instantiation.
:
:>My OLC object vs instance model.... and there are other advantages...
:
:Close to.  Chris Gray described this way back before your list, except
:that he AFAIR splits it down to having objects store individual
:methods, and "objects" in the MUD world sense are then collections of
:tiny single method/attribute objects into an "intelligent" whole.  (I
:don't go that far)

Hmmm.

:>modification of an OLC object, however, under my system, does not
:>change any of the instances... quite. Lazy copy model, which means
:>somewhere out there will be floating a copy of the original
:>characteristics, until the last copy of them is destroyed... 
:
:Ahh, here changing the base code for a class object causes every
:dependant child to rebuild their inheritance trees the next time they
:are touched/loaded.  (Lazy rebuild?)  Touch a root object and the
:whole MUD will re-orient like a fifteen tonne charging rhinocerous
:doing a 360 on a dime.
:
:This of course can be thought of as a Good Thing, or a very Bad Thing.

I did it the way I did as a deliberate choice. Could have gone the other
way. Of course, part of the base is hardcode.. a lot of it, actually...
so there is only so much base modification you can do. Restructuring a
virtual class would affect all of its descendents... but changing an OLC
object's desc won't change those of its instances.

:>...so if
:>you modify, say, an OLC version's description, the String will cut
:>loose and bindto one of the instances... if that instance dies, it
:>will bind to another, and so forth. Certainly saves on the String
:>overheads. 
:
: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.

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

:>Incidentally, I
:>have explained my system to allow a Player to experience an
:>Occurance, the results of which are permanent to that Player, and
:>that Player alone, haven't I? 
:
:On the old list only, and then during its final death throes.  It
:would probably be a good idea to go over it again.

I can go into more detail if anyone is interested.

:>Things like blowing up a complex or
:>triggering a thermonuclear detonation can be coded to become a part
:>of that Player's history, and that Area will forever after be a
:>destroyed complex or glass lined crater to that Player's
:>Characters... and anyone else that is introduced to the aftermath.
:
: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.

:The thing that bugs me about it is:
:
:Bubba and Boffo (two RL players) are stting side by side in their dorm
:room, MUDding on PhyMUD++.  
:  
:  Bubba:  Hot diggity!  I just nuked the collosseum!
:  Boffo:  Oh wow!  Lemme see!  I'll be there in a sec.  
:  (sound of frantic typing)
:  Boffo:  Hang on!  I just walked into the colloseum and its fine!
:  Bubba:  But I jut nuked it!  See!  Look at my screen...

Well, yes, there is that. On the other hand, if there is no RL
interaction, you get Boffo looking like a liar, until he brings Bubba in
to it in the game.. at which point it becomes a part of Bubba's history
too. Confusing at times, but better tahn any of the alternatives for my
needs.

:>:Aside:  
:>:
:>:At the moment I've been intending to make the TrashCollectors (cf
:>:earlier discussion with ChrisG on removing waste objects) do this as
:>:a side effect of their normal rounds.  The base purpose of the TC's
:>:are to accellerate object decomposition, and provide an amusing
:>:(cheap) target and toy for users.
:>:
:>:Essentially the TC's would wander the land in slightly overwhelming
:>:numbers, finding and collecting any loose odd objects that happen to
:>:be laying about (eg torches, dropped EQ, weapons, newly programmed
:>:and abandoned user objects etc).  How the TC's handle that junk
:>:comes in a number of flavours:
:
:>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.

:>:-- If the object is small they pick it up and continue on. -- If a
:>:larger object they englobe the object and decay it and any carried
:>:objects at an accellerated pace.  Once the object(s) have
:>:destructed, the TC will move on, having grown slightly.  This
:>:process produces considerable mana. 
:>-- If the object is too large to
:>:englobe, it will suck its own thumb and grow until it is large
:>:enough to englobe the object(s).  Once the object(s) have
:>:destructed, the TC will split into multiple new TC's .  This process
:>:consumes considerable mana.  Should there be insufficient local
:>:mana, the TC consumes the mana, dies, and scatters a spore for each
:>:unborn TC.   
:>:-- If the object is a TC corpse, the TC will eat it and
:>:grow by a factor smaller than the size of the TC eaten.  There is no
:>:net mana change. 
:>:-- If the object is another TC, a small percentage
:>:of the time one TC will eat the other, and both will die, producing
:>:four TC spores in the process. 
:>:-- If the object is in some way
:>:special/wanted the TC picks up the object, drops anything else it is
:>:carrying, and attempts to convey it back to a (special
:>:characteristic specific) dumping group.  (This makes TC's preferred
:>:hunting targets for players)  A carrying TC will produce significant
:>:mana in each room it passes thru. 
:>:-- The TC will spoof the object
:>:found, and disappear.  The action of the spoof is to speed the delay
:>:of the object, and to drop a TC spore (that will grown into a new
:>:TC) into a percentage of rooms it passes thru which don't contain
:>:TC's or TC spores.  In the mean time the base object continues to
:>:behave as normal until it destructs.  There is no net mana effect.
:>-- If the object is a TC spore, the TC will eat the spore and 
:>:increment the count of the number of spores it will release when 
:>:it dies.
:
:>Intersting. Extremely complex. Very interesting. Can't imagine how
:>hard to program that's gonna be.
:
:Not that tough to code.  I'd estimate an afternoon.  The nice bit is
:that each of the above "feetures" is self contained.  The only thing
:that really varies is when its invoked.  Ergo: TC enters location,
:checks local inventory of objects, generates random value, enters
:switch/case of possible handlers, invokes handler.  Everything from
:there is a transparent bolt-on.

Ah, OK... Right. The problem is, I keep forgetting how your mana works..
as a storable quantum.

:>:Once a TC has grown past a specified size, or if it successfully
:>:consumes more than X objects, it will split into two otherwise
:>:identical TC's.  A TC in normal operation (moving, whatever),
:>:continually and slowly produces mana.  However, very high mana
:>:levels are quickly fatal to TC's _unless_ they find an object to
:>:englobe.
:
:>:TC's have a set (short) lifespan.  They are born from spores, grow
:>:on objects found, move quickly, and produce spores when they die. 
:>:As far as resets are concerned, should a TC find an object with a
:>:reset() method, with a set RESET_ME flag, the TC will call the
:>:reset() method a percentage of the time (percentage depending on age
:>:of requested reset, plus object-specific fudge factor).
:>:
:>:A TC spore will consume all mana in its area.  The rate of
:>:development of a TC spore is porportional to the rate of mana
:>:consumption.  Should their be no mana, the spore will lay dormant.
:
:>Hmmm. Wierd world you have going here. *grin*
:
:Yup.  They way I see it, I only need to maintain enough reference and
:duplication with the real (ie non-MUD) world to allow users to have
:some chance of understanding and predictably handling what is going on
:in the MUD world.  Its a question of ensuring there are enough shared
:referrants to be playable, 
:
:Its sort of the opposite viewpoint really.  Rather than attempting to
:make the MUD more "real", I'm working to make the MUD only as "real"
:as it has to be to be playable, but absolutely no more.  The real
:fight then is to make the MUD *internally* consistant.  I want to see
:a MUD which obeys its own world rules rather than attempting to be a
:pale imitation of a dreamed reality.

*nod* Well, as part of the purpose of Singularity (and by association,
Singularity 2) is to promote education of physics... Physmud++ is not so
constrained, but Sing2 _has_ to be realistic, physically.

:>:This way to do this is to implement base systems which automagically
:>:generate rumours/news events etc, which are then carried about and
:>:reacted to by mobiles, and communicated to players etc.  Once you
:>:have a base, automatic rumour system (one that requires no
:>:supporting code in other objects) most of the rest should pretty
:>:well come for free.
:
:>I've created a class derived from my Communication class that
:>essentially does this. It spawns, splits, mutates, decays and jumps
:>from Character to Character. When it jumps to a PC, it causes the
:>previous holder to tell the rumor to the PC. It cannot live on non
:>sapients, and certain personalities will also kill it. PCs can spread
:>rumors by typing "tell <name> about <something from the rumor key>"
:>IE, if the PC had recieved the rumor with the message 'The ugly old
:>man tells you, "Hey, buddy, did you hear about the king's daughter
:>and the horse trainer?"', you can later type "tell uffoogu about the
:>king's daughter" and it will autotell the rumor for you.
:
:Neat.

Thanks.

:>:eg  Mana comes in two forms, +ve and -ve.  Mana is required to do
:>:magic (sign dependant on magic used).  Magical objects have a mana
:>:sign (-ve or +ve), and consume mana of that sign, thus slowing or
:>:stopping their decay.  Magical objects react to opposite sign mana
:>:by accellerating their decay.  Should a magical object find no mana
:>:to consume they decay VERY quickly (no mana is worse than bad mana).
:>:TC's and a few other objects produce mana (always in matched +ve
:>:and -ve pairs) at various rates.  Mana flows like a liquid thru
:>:rooms and spaces, attempting to have no two locations adjacent with
:>:different mana levels.  
:
:>Cool!
:
:Thanks.
:
:>:What's this mean?  Magical objects have a definite life span.  Don't
:>:feed them enough mana and they destruct.  The more magical objects
:>:you have together, the more quickly your local area becomes mana
:>:depleted (mana flows slowly) and the more quickly they decay.  Get
:>:sufficient highly powered magical objects together and they'll all
:>:destruct within seconds.  Keep only one or a few magical objects,
:>:and they'll survive on the local mana.  Want lots of magical items? 
:>:Better keep them all right beside a major mana producer (eg a farm
:>:of TC's you continuously feed trash).  
:
:>I like this! Consistant laws! (Which means it can be implemented in
:>Physmud++!!)
:
:>:Magic fights also become travelling affairs.  No-one can afford to
:>:stand still -- they run out of mana.  Then again, manage to locate
:>:yourself by a major mana producer, and you have a huge advantage. :
:>:You sure as heck won't find any super powered over-armed magical
:>:users or mobiles wandering about -- they may have the Spear of Icy
:>:Death, the Greaves Of Incredible Footwork, the Magical Nose Ring Of
:>:Killer Snot, and the Goggles Of All Making All Tits Bigger, but
:>:unless they work their butts off keeping them fed enough mana, six
:>:steps later they'll all turn to dust.
:
:>Love your item names. 
:
:Yeah, and those are the toned down versions.  I've had some rather
:interesting days of late.  
:
:"That kill3r snot is a gnarly c00l w3apon dood."
:
:<<Of course some prefer the googgles>>
:
:>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.

:>Or inconvenience the enemy, at the least. 
:
:The true test of a battle:
:
:  UggUgg slashes at you with his Sword of Instant Beheading 
:  and minor discomfort!
:  > cast soakhole on uggugg
:  You cast the dreaded mana eater soakhole on UggUgg!
:  UggUgg sneezes and buries your in green snot!
:  Your armour suddenly dissappears!  
:  Your spell of magical summon protection fails!
:  Your spell of magical sight fails!
:  UggUgg's Nose Ring of Killer Snot dissappears!
:  UggUgg's Belt of Gas Containment dissappears!  Phew!
:  UggUgg's dagger of wart removal dissappears!
:  > cast create mana
:  You create 5,000 units of mana!
:  Your mana stores are now empty.
:  >cast $my_protections
:  You are now magically potected from summons.
:  You can now see all magically hidden objects.
:  UggUgg thows a blade of painful castration at you!
:  > jump!
:  You leap mightily.
:  The blade misses!  You are still a baritone.
:  > attack uggugg with spear
:  You ram UggUgg through with the spear of Icy Death!
:  UggUgg now has the flu and looks a bit watery about the eyes.
:  UggUgg picks up a rock.
:  UggUgg bases you with a rock!  Ouch!  That hurt!
:  > throw TC at uggugg
:  You throw the charmed trash collector at UggUgg.
:  The TC englobes UggUgg!
:  UggUgg gives you the Sword of Instant Beheading and minor
:discomfort.
:  UggUgg gives you the Boots of Mighty Chilblains,
:  UggUgg gives you the Goggles of Big Farts.
:  UggUgg gives you Super Nose Hair Puller.
:  The TC has eaten everything UggUgg was carrying!  Yech!
:  UggUgg is naked!
:  Your spell of magical summon protection fails!
:  Your spell of magical sight fails!
:  Your spell of magical tummy tuck fails!
:  Your spell of power voice fails!
:  Your spell of land control fails!
:  Your spell of bowel control fails!  
:  Your spell of toe cheese protection fails!
:  > stat spells
:  You have no spells.
:  > stat mana
:  There is no mana here.
:  > strangle uggugg
:  You wrap your hands about UggUgg's neck and begin to squeeze!
:  UggUgg prays to the Great God GooGoo!
:  GooGoo mana blesses the area!  
:  There is a LOT of mana here!  You skin prickles!
:  > i
:  You have a mana shielding sack
:  > l in sack
:  There are 5,000,000 TC spores in the sack.
:  >empty sack on UggUgg
:  The spores eat all the mana!
:  There are 5,000,000 TC's here!  Wow.
:  All the mana is gone!  
:  ...
:
: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! 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. 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.

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

:>That could be cool... an
:>overenchanted sword that must feed off of magical prey constantly, or
:>drain its owner dry. 
:
:Easy enough to do -- just have magical prey eat mana by adding it to
:their inventory (up to a set level, and from there on destroy it).

Sounds good.

:>I can just see it.... here, unicorn, unicorn,
:>unicorn.... my sword really wants to make your acquaintance!
:
:cf The Book Of Swords, SoulBiter etc.

Not something I've read.

:>I have to say, you guys create universes every bit as cool as my own.
:>And killer bases for those universes. No wonder the newsgroups have
:>decayed so much... we keep sapping out the talent.
:
: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.
That AEMud chap might be nice. The Saphire guy? He seems bright. I'm going
to extend an invite to Robin Carey (the NetServe guy) when he gets his new
account. Not sure who Engberg is. Hollebeek seems a good thinker. Munt?
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. Still, the
brightest ideas I've seen on the NGs have mostly come from people on this
list.

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

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