<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: Resets and repops --> <!--X-From-R13: pynjNahyy.arg --> <!--X-Date: from tacitus.globecomm.net [207.51.48.7] by mx3.ibm.net id 858901625.22434-1 Thu Mar 20 23:47:05 1997 --> <!--X-Message-Id: 3331cdbe3d9d002#msgSFO01,schwab.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199703190418.EAA98913#out2,ibm.net --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: Resets and repops</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw#null,net"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00155.html">Previous</a> | <a href="msg00157.html">Next</a> ] Thread: [ <a href="msg00154.html">Previous</a> | <a href="msg00157.html">Next</a> ] Index: [ <A HREF="author.html#00158">Author</A> | <A HREF="#00158">Date</A> | <A HREF="thread.html#00158">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: Resets and repops</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI> <LI><em>Subject</em>: Re: Resets and repops</LI> <LI><em>From</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI> <LI><em>Date</em>: Wed, 19 Mar 97 12:07:01 -0800</LI> <LI><em>Reply-to</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On 18/03/97 at 10:00 AM, Adam Wiggins <nightfall#inficad,com> said: ><Chris Gray:> >> [Much good example deleted - the famous 23rd platoon bites it.] >> ...When I came upon similar situations, where >> I wanted to replenish some monsters or prizes, what I did was to simply >> store the time that the last set had been "used up". Then, if a player >> character (I explicitly chose to not have NPC's trigger such things) >> enters the area, and the time is sufficiently later, then I will >> regenerate the stuff just before the player enters the location. So, >> there are small resets, but nothing global, and only when "needed". I >> like this way of doing it. >Not bad; my only problem with this is that if there's any sort of >mechanisms by which the player can learn about their world without >actually going places, this starts to break down. The most obvious >example is the spell locate object. Other good candidates: Built in rumour systems Newspapers OBE (Out of Body Experience) Scrying High altitude overview (for those with 3D) Indirect viewing ("typical" magic eye objects, or your clairvoyance). Remotely controlled/possessed mobiles. Demon riders on mobiles. 'Bots. 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. >But I guess I like to avoid >doing things this way (that is, triggered by players) because it's >pretty tricky to avoid slip-ups like I describe above. Using the >brute force method tends to be easier all around and works more >consistantly. Having said that... It also allows having your server run simulations. >This is one of my main problems with repops. (Hey, guys, it's been >29 minutes since we left zone X, which means it's gonna pop in the >next minute) While this area was been gutted when I reworked my object model a while ago (again), the way it is supposed to work for me: -- 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) -- The event that is logged is actually a fairly simple: 1) At XXX time check conditions if the new state is allowable/logically consistant. 2) If so, log a new event which attempts to create that state. Give this second event a low order probability of execution (this means that exactly when the event will ripen is uncertain, possibly within seconds or as long as months from then). 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). 3) If no, and if the re-instatement is still "possible", relog the same event as in #1 but for a yet future time. 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. Getting back to recreating the state and taking the resurrected mobile example, the secondary event would create a new instance of the base <whatever> mobile type. The type's ctor would initialise it appropriately, and (one hopes) would appropriately randomise the attributes so as to be different from the dearly departed. A nice side effect of the naming schema (user assigned names) and objectID handling (all instances have guaranteed unique never-reassigned ObjectID's) is that any user-assigned names given to the dead mobile will still be orphaned, and not refer to the new instance. Thusly you could have a mobile ctor which creates a baby/child and launches an event stream which slowly "grows" the mobile from infancy to old age and decrepitude, with any deaths along the way just leading to the (semi-) randomly timed creation of new infants to take up the progression. 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").. 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: -- 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. 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. >> In all things, though, you have to balance the benefit actually seen by >> the players against the implementation effort. If the players can't really >> tell the difference, then I'd say don't bother. However, if you do >> everything gradually, so that rumours float around, news articles appear >> in local papers, troop movements can be observed, both directly and >> indirectly, then I'd say go for it. But then, if all of that stuff is >> there, you obviously already have a very detailed MUD! 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. >...Dwarven guards, when they get disarmed >or their left vambrace chewed up, have to go down to the armory and >get fitted for a new one. Of course, things in the armory don't just >appear there - they are made by the dwarven smiths. Naturally _they_ >can't just make weapons and armor from thin air, they need the ore >brought up to them from the mines. The miners of course, need >tools...etc etc. You get into coding a full economy -- a thing rife with positive and negative feedback loops (cf Palace's early economy mishaps and happy accidents). Its something I don't think I'd even attempt. What I think would be easier, and provide a LOT more fun, is to implement independant economies with their own internal methods of production and consumption which are not dependant on other economies. 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. 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). 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. The nice thing about this sort of system is that it becomes self balancing. Opportunities for mana consumption exceed mana production, so the system always runs starved (try to run it fat and you get positive feedback). While there can be synergy between the mana economy and other economies, even positive and negative feedback (again cf Palace and the guns and coins), you don't get the direct causal dependancies where the stonemason can't build castles because the lumberyard has no wood because the robbers robbed the bank so the woodsman can't get paid for the trees he cut, and the elves can't sell their silks anymore anyway (no money), and now pro0hibit all tree cutting. -- J C Lawrence Internet: claw#null,net ----------(*) Internet: coder#ibm,net ...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00155.html">Garbage Collector</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00157.html">Re: Resets and repops</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00154.html">Re: Resets and repops</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00157.html">Re: Resets and repops</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00158"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00158"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>Re: Resets and repops</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00150" HREF="msg00150.html">Re: Resets and repops</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 20 Mar 1997, 13:23 GMT </LI> <LI><strong><A NAME="00151" HREF="msg00151.html">Re: Resets and repops</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 20 Mar 1997, 14:40 GMT </LI> <LI><strong><A NAME="00153" HREF="msg00153.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Fri 21 Mar 1997, 02:57 GMT </LI> <LI><strong><A NAME="00154" HREF="msg00154.html">Re: Resets and repops</A></strong>, Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Fri 21 Mar 1997, 03:03 GMT </LI> <LI><strong><A NAME="00158" HREF="msg00158.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Fri 21 Mar 1997, 07:47 GMT </LI> <LI><strong><A NAME="00157" HREF="msg00157.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Fri 21 Mar 1997, 09:33 GMT </LI> <LI><strong><A NAME="00159" HREF="msg00159.html">Re: Resets and repops</A></strong>, Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Fri 21 Mar 1997, 14:25 GMT </LI> <LI><strong><A NAME="00161" HREF="msg00161.html">Re: Resets and repops</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Fri 21 Mar 1997, 23:49 GMT </LI> <LI><strong><A NAME="00162" HREF="msg00162.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Sat 22 Mar 1997, 00:56 GMT </LI> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>