<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: Quotes from Marcus Ranum --> <!--X-From-R13: @nguna T Kbfcr <lbfcrNunjnvv.rqh> --> <!--X-Date: Fri, 26 Jun 1998 19:57:20 -0700 --> <!--X-Message-Id: Pine.GSO.3.95q.980626160611.4577A-100000@uhunix2 --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199806262204.PAA06931#under,engr.sgi.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: Quotes from Marcus Ranum</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:yospe#hawaii,edu"> </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="msg01230.html">Previous</a> | <a href="msg01232.html">Next</a> ] Thread: [ <a href="msg01226.html">Previous</a> | <a href="msg01215.html">Next</a> ] Index: [ <A HREF="author.html#01231">Author</A> | <A HREF="#01231">Date</A> | <A HREF="thread.html#01231">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: Quotes from Marcus Ranum</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Re: Quotes from Marcus Ranum</LI> <LI><em>From</em>: Nathan F Yospe <<A HREF="mailto:yospe#hawaii,edu">yospe#hawaii,edu</A>></LI> <LI><em>Date</em>: Fri, 26 Jun 1998 16:56:25 -1000</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</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 Fri, 26 Jun 1998, J C Lawrence wrote: :> Nathan Yospe's model (which has been partially admpted by a few :>others) is compute heavy as he dynamically simulates fragments of the :>world by computing its current state by extrapolation from the last :>time it was fully generated (almost no fixed data definitions, only :>fixed formulae and an axiomatic base of laws of physics). :How has it worked out in practice? I suppose I should answer this. In practice, I don't know. Experimentally, it has advantages and drawbacks. An advantage is that the primary limit on capacity is the number of active users. A disadvantage is that CPU usage is the most intensive bottleneck, and clever caching mechanisms can only go so far. I'm thinking of experimenting with G3 chips... a dual G3 Rhapsody server might be just the thing for a local server node's host. I've found that - The optimum timespan for switching between the deterministic and probabalistic update methods seems to be about 10 minutes. Under 10 minutes results in the cost of probabilistic evaluation being higher than the cost of calculating every event in those ten minutes sequentially when reactivated. - The optimum timespan for switching between probabilistic and contextual update methods seems to be about 35 minutes, but contextual updates look a little fishy if performed in an area that has been visited in the past 36 hours. Therefore, the benifits of contextual updates (which use trends for a from-base update on the basis of a modifier table, and a fudge factor) are not realized for a couple of days. I finally settled on four days, at which point only a pedantic player has any right to expect the grass to be trodden in an exact spot, as opposed to a vague trail... there's no way a player can guarantee that someone else didn't come by and move that rock, et al. - The majority of situations can be handled without resolving any detail beyond the most general until a player requests greater detail. If I have a balloon with a picture on it, the details of the picture will be stored as a key to a client to server data request. These details will *not* be fed to the client unless the client requests them. The client will present a "balloon with a picture on it" unless greater detail is noticable (IE, the player is close to the balloon) or the player pays attention to the balloon. Detail requests are originated by the client in all cases. The server will happily never serve optical information seperate from spacial data to a client handling a blind or sightless (alien) character. Likewise, there is no thermal data passed unless specified by client (no, these are not all case-by-case transactions, most are stored serverside until the client modifies them, with a sort of agent-for-the-client class acting on the client's behalf), and no tactile data when the client has not sent a request, or made contact. (I've given thought to restricted information, but, I figure if they want to hack for more info, let them. A little incentive to the programmers out there.) The beauty of it is, if there is no request from the client, a lot of this stuff remains unresolved. I call it lazy instantiation. The world only exists where you are aware of it. All the rest is just potential. - My inheritance structure, which is key to the lazy allocation scemes, needs to be placed into a better DB design. I hate databases! Damn, I'm not looking forward to writing the replacement for my (too slow to resolve) DB. (The DB as it exists is transparently in memory or on disk... which means a frightfully large in memory ref table, sort of like 68k mac handles, but a bit slower to resolve.) - I can generate worlds far vaster than anything that currently exists. I have given thought to hosting each stellar system on a seperate sever process, and hosting one to 50 server processes on any given machine. Some of these stellar systems are rather dull, and a bunch of systems with no habitable planets could be jammed on one machine. - I can easilly transport things between one server process and another. I have to handle a bit of overhead each time when every base object on one server is present on the next. Numbers must be maintained from one server to the next. I handle this by assuming I will never have more than 4000 servers, and snagging the first 12 unused bits (out of 58) for a server ID. If I ever end up with more servers than that, I'll have to overhaul everything and switch to 128 bit longs. :P It is possible to inherit from an object that originated on another server. Non-generalized objects are broken by category, and have the first 96 "server IDs". The search method is optimized (yeah, right... but that's what my design docs claim) for those 96 first, then the local server ID, then all others. - object clusters do not make permanent inheritable copies of themselves in the database unless inherited from, at which point, they do copy and reserve an ID. Object clusters function as temporary object types. All objects are clusters. An object will resolve into clusters of finer granularity on sufficient investigation, using dynamic resolution, until it becomes a random association of componant substance (with impurities). This should never actually happen. The entire server is one object cluster. It should also never have to be called upon for investigation directly, as there is no parent location to call it. I have found that most objects are treated in terms of clusters of approximately 1 to 500 primary objects. A primary object is an instance of something grabbed from the database and inserted into the gameworld. A character, chair, or book might be a primary object. A primary object of a (filled) bookshelf would have generic books in it, but a cluster of 500 individual primary objects (books) and 1 primary object (bookshelf) would have books of some significance. The contents would have to be individually entered, or the client would get a resolved set of giberish on pages. I have no idea if a builder would do a thing like that... but it could be done, at high cost in memory allocation. Builders will have to be doled out limited memory resources. - how does it work out in practice? I don't know. In experiment, it has a tremendous amount to offer... and costs like hell. -- Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech) (Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept. yospe#hawaii.edu nyospe#premier.mhpcc.af.mil <A HREF="http://www2.hawaii.edu/~yospe/">http://www2.hawaii.edu/~yospe/</A> </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="01226" HREF="msg01226.html">[MUD-Dev] Quotes from Marcus Ranum</A></STRONG> <UL><LI><EM>From:</EM> J C Lawrence <claw#under,engr.sgi.com></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg01230.html">[MUD-Dev] Re: Levelless MUDs</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg01232.html">[MUD-Dev] Re: Multi-Server games</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg01226.html">[MUD-Dev] Quotes from Marcus Ranum</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg01215.html">[MUD-Dev] Re: Suggested theme</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#01231"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#01231"><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>[MUD-Dev] Re: the why of online worlds</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="01238" HREF="msg01238.html">[MUD-Dev] Re: the why of online worlds</A></strong>, Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Mon 29 Jun 1998, 05:10 GMT </LI> </ul> </LI> <LI><strong><A NAME="01236" HREF="msg01236.html">[MUD-Dev] Re: what's fun?</A></strong>, Richard Bartle <a href="mailto:76703.3042#compuserve,com">76703.3042#compuserve,com</a>, Sun 28 Jun 1998, 10:21 GMT <LI><strong><A NAME="01235" HREF="msg01235.html">[MUD-Dev] Re: Quotes from Marcus Ranum</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sat 27 Jun 1998, 19:46 GMT <LI><strong><A NAME="01226" HREF="msg01226.html">[MUD-Dev] Quotes from Marcus Ranum</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 26 Jun 1998, 22:05 GMT <UL> <LI><strong><A NAME="01231" HREF="msg01231.html">[MUD-Dev] Re: Quotes from Marcus Ranum</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sat 27 Jun 1998, 02:57 GMT </LI> </UL> </LI> <LI><strong><A NAME="01215" HREF="msg01215.html">[MUD-Dev] Re: Suggested theme</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Fri 26 Jun 1998, 14:45 GMT <LI><strong><A NAME="01209" HREF="msg01209.html">[MUD-Dev] Thread implementations...</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 26 Jun 1998, 06:15 GMT <LI><strong><A NAME="01208" HREF="msg01208.html">[MUD-Dev] I/O Event Handling Under Linux by Richard Gooch</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 26 Jun 1998, 06:05 GMT <UL> <LI><strong><A NAME="01216" HREF="msg01216.html">[MUD-Dev] Re: I/O Event Handling Under Linux by Richard Gooch</A></strong>, s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Fri 26 Jun 1998, 16:45 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>