<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: Resets and repops --> <!--X-From-R13: pynjNahyy.arg --> <!--X-Date: from fabius.globecomm.net [207.51.48.6] by mx01.ny.us.ibm.net id 859484107.80391-1 Thu Mar 27 17:35:07 1997 --> <!--X-Message-Id: 333aafdd19a2002#msgSFO01,schwab.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199703222353.XAA133532#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="msg00234.html">Previous</a> | <a href="msg00236.html">Next</a> ] Thread: [ <a href="msg00233.html">Previous</a> | <a href="msg00240.html">Next</a> ] Index: [ <A HREF="author.html#00235">Author</A> | <A HREF="#00235">Date</A> | <A HREF="thread.html#00235">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>: Thu, 27 Mar 97 08:54:48 -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 22/03/97 at 12:20 PM, cg#ami-cg,GraySage.Edmonton.AB.CA (Chris Gray) said: >But isn't it a bit unrealistic to be able to do that? I was thinking >about this stuff this morning, and it occurs to me that one of the >things I would want to do is to be careful about identification. In >my system all database entries have a unique ID. I would use that as >a handle for things. You can put a name for it into your private >symbol table. Then, you can refer to it, unambiguously, by that name. >So, the 'scry' for me, would end up not using 'elven archwizard', but >some made-up name by which this player refers to the NPC. Such a name >can only be made when you have some other unambiguous way of >referencing the archwizard, such as by being in the same room as him >and doing the naming. So, having this link to the elven archwizard >can be considered enough to keep that NPC active. If you don't have >some kind of unambiguous reference like that, then the above command >seems to me to require some sort of scan of the entire world, in >order to find something that meets that description. Now, you may >want to allow that, but for most uses, I think an unambiguous >reference would be preferable. There's a problem with this view: Some names are unique (or at least very limited) due to their adjectival tags, not their nouns. The "elven archwizard" can be such a case, especially if the game only allows one to exist at any moment. Consider the scenario I posted a while ago concerning the Orcs, the breeder Orcs, the variant production of breeder/worker/fighter/noble Orcs by the breeders dependant on population density, mortality rate, and invasion status, and more importantly, the competition by the noble Orcs to become King Orc (with the guarantee that there is only ever one KO). Thusly: The "King Orc" as a tag always uniquely identifies a single Orc, or is unable to indentify any Orc (ie the KO is recently killed and the nobles are fighting for kingship). Given even a loosely educated player, they will know of the existance of a "King Orc", even if they have never met the chap. As such, doing a "scry king orc" or similar becomes a reasonable command. They know he exists, they don't know where, but they hope they can locate him on the basis of his uniqueness. The problem this presents to a MUD server is whether or not you maintain a global namespace for such tags (especially such fluid tags), and if not, how you proceed with the search. (What if the KO is located in a hidden/unknowable location?) >I don't have a >gut feel for the speed of a 100% in-memory MUD, since mine has a disk >based DB with lots of caching, but what I've observed is that DB >access is the big bottleneck. Ergo: You need a bigger cache. >ChrisL, what have you observed on this? Cache size is critical. My attempt in general is to make the cache large enough that I can keep the entire working set of the MUD at any instant in memory -- where working set is defined as comprised of any object which has been accessed within the last 20 seconds or so (it gets better when you can start hitting multiple minutes). Yup, its memory expensive -- but its cheaper than everything in-RAM. Yup, it looks like I will be going back to a three level cache. >If a system is 100% in-memory, then links from one entity to another >can be just pointers, but with a disk-based system that's harder. For me every object has a guaranteed unique ObjectID (guaranteed for the entire life of that database). As such inter-object references merely become ObjectID's. Reference speed is of course slower. This is one of the reasons there was so much interest on the list last year in persistant stores, and specifically Texas with its Pointer Swizzling, and Object Store (commercial, rather similar in principle to Texas). It is an area I intend to revisit. I still have a very ugly nagging feeling that all the work I've been putting into the DB layer lately (adding native transactions and rollbacks) will be wasted once I find or write a decent persistant store and see how much better a solution that is. >Do >any of you convert DB-refs to pointers on the fly when objects are >loaded? Not quite. I have a layer that sits immediately over the DB cache and handles all the tracking of the requested objects, interested party lists etc. That layer attempts to short-circuit references between objects which are already in cache, but frankly, the current short circuit is more expensive than the lookup would be. >The world complexities we've been talking about would seem to require >100's or 1000's of active NPC's. My original target was single digit millions of active objects, where an active object is defined as any object which has an ongoing event stream. My current revised view is hundreds of thousands of active objects on a < US$3,000 machine. Note: I haven't even attempted anything over a thousand or so (almost all duplicate) on my already extremely over committed machine. >Also, the code being discussed is a >lot more complex than what I'm currently running. Is my system just >hopelessly slow, or is there something wrong with my assumptions >here? >I guess I can barely imaging this kind of thing working with a 100% >in-memory system, running 100% native code (i.e. very little >scripting or whatever you want to call it). That's exactly what MOO and almost all Tiny-* MUDs do, and some of them have databases measuring up in the scores of Megs. (Have a look at the last LambdaMOO dump some time) >Mine is 0% true in-memory >and 100% scripting (fairly efficient scripting language, however), so >maybe this is why I'm slow. Comments? Without running a profiler over the code, I can't really comment. However I would immediately suspect your cache management along with any blocking you do on disk IO. >:Amusing. Could even toss player notes onto a given memory, thus: : >:> note silke this asshole tried to steal my hat! ... >...Is it >realistic to provide this kind of aid in the game? Handy, yes. This >is one of the reasons why I would like to go to a 100% 3D graphic >game. You can then avoid a lot of the stuff that is needed in text >games and simply leave things like noticing, remembering, etc. up to >the human player. You don't have to come up with text descriptions >dependent on the local conditions - >you just display the world according to those local conditions, and >the visual acuity of the player if you want, and let the player sort >it all out. Much more realistic. Is it playable, though? The probme here is ensuring that all your character's graphics are reasonably unique. Most 3D games build bodies from stock libraries (here a leg, there a leg, throw in an arm or two, a torso, one of three colours of hair etc) which leaves the resultant bodies all looking very much the same. cf Meridian59 and its name tag haloes for all the characters. Its a *LOT* cheaper than having 500 unique bodies. >I *really* like it when unexpected, but consistent, things happen. Too >bad that in my simple system, it has only sorta happened once. Sniff! Yeah, but this is a funny world we've got here, where ideas and potential often count for more than what's actually done with them. Set up a system where your players *can* do some neat things, and lord knows they may well just stick to endlessly killing fidos. Set up the system so tht nothing is flexible, and some user will come along and figure out how to program it... Them's the breaks. -- 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="msg00234.html">Re: Mixture</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00236.html">Mixture</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00233.html">Re: Resets and repops</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00240.html">Re: Resets and repops</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00235"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00235"><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="00224" HREF="msg00224.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Thu 27 Mar 1997, 07:24 GMT </LI> <LI><strong><A NAME="00229" HREF="msg00229.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Thu 27 Mar 1997, 17:06 GMT </LI> <LI><strong><A NAME="00232" HREF="msg00232.html">Re: Resets and repops</A></strong>, Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Thu 27 Mar 1997, 19:35 GMT </LI> <LI><strong><A NAME="00233" HREF="msg00233.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>, Thu 27 Mar 1997, 23:50 GMT </LI> <LI><strong><A NAME="00235" HREF="msg00235.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Fri 28 Mar 1997, 01:35 GMT </LI> <LI><strong><A NAME="00240" HREF="msg00240.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Fri 28 Mar 1997, 04:25 GMT </LI> <LI><strong><A NAME="00245" HREF="msg00245.html">Re: Resets and repops</A></strong>, Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Fri 28 Mar 1997, 13:58 GMT </LI> <LI><strong><A NAME="00246" HREF="msg00246.html">Re: Resets and repops</A></strong>, Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Fri 28 Mar 1997, 14:07 GMT </LI> <LI><strong><A NAME="00247" HREF="msg00247.html">Re: Resets and repops</A></strong>, Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Fri 28 Mar 1997, 14:11 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>