<!-- MHonArc v2.4.4 --> <!--X-Subject: RE: [MUD-Dev] Object and class heirarchies -- are they really necessary? --> <!--X-From-R13: @nguna T Kbfcr <lbfcrNunjnvv.rqh> --> <!--X-Date: Tue, 21 Mar 2000 17:59:01 -0800 --> <!--X-Message-Id: Pine.GSO.4.21.0003211455300.2035-100000@uhunix2 --> <!--X-Content-Type: text/plain --> <!--X-Reference: 11A17AA2B9EAD111BCEA00A0C9B4179303D6E44A#molach,origin.ea.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, RE: [MUD-Dev] Object and class heirarchies -- are they really </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="msg00684.html">Previous</a> | <a href="msg00686.html">Next</a> ] Thread: [ <a href="msg00682.html">Previous</a> | <a href="msg00686.html">Next</a> ] Index: [ <A HREF="author.html#00685">Author</A> | <A HREF="#00685">Date</A> | <A HREF="thread.html#00685">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</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>'" <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI> <LI><em>Subject</em>: RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</LI> <LI><em>From</em>: Nathan F Yospe <<A HREF="mailto:yospe#hawaii,edu">yospe#hawaii,edu</A>></LI> <LI><em>Date</em>: Tue, 21 Mar 2000 15:52:15 -1000</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#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 Tue, 21 Mar 2000, Koster, Raph wrote: :> My favourite benefit of this approach is the same one that e.g. Diku :> has over most LPMuds... that you nail down in the implementation of :> the single physical class the entireity of the feature set... and as :> a consequence, all physical objects are guaranteed to respond sanely :> to a known set of actions. :This is what I referred to as the great strength of Dikus--they are :template-based muds. The template constrains, but only insofar as the data :set that the template provides. If you can expand the template and supply :default values to objects that have not been manually updated with new data, :then your constraints pretty much go away without having to subclass new :object types, etc. Funny thing - the first version of Physmud - the one I had running as a text mud - was actually a port of a set of worlds written for a modified Diku to a more flexible custom engine with a file interpreter that read Dike format. I've still got the last version - which I still play with from time to time, and still plan on finishing eventually - but occasionally I start to get fed up by the limits currently present. I never thought I'd say this, but I miss the quick-feature-add of putting another field or two into a text file, giving it a default, and editing in the value on a test object/thing. Now, I do the same thing, but I have to work in the global physics of the feature before I can activate it, and test it for consistancy... Dikus are nice, because Dikus are simplistic. Still... I use a global base for all physical objects, one for processes, and one for relationships. Inheritance from these is dynamic; the source code doesn't have a clue what the object heirarchy is. Processes cover verbs, continuous behaviors, triggered/scheduled actions, etc... There is inheritance for processes. All inheritance is potentially MI, but some MI will not lead to results - inheriting from two complex objects will not create a hybrid mutant - no chair-dogs that try to be both - because a complex object is instantiatable, and objects derived from multiple instantiatable objects are considered bad and not loadable. Objects can be *assembled* from multiple complex objects, by linking them using relationships. An object must be made complex to be instantiated or used in an assembly. Processes are also complex/basic and can be assembled using relationships. Relationships specify dimensional, temporal, or complex connectivity, and can be coded... This means that, if I wanted to create a new attribute for all physical objects, I could easilly do so... but a builder could not. Fortunately, attributes for physical objects are very narrow in focus. They include parametizable things like mass, energy, material, state, temperature, life (sorry, I know, but that's how I did it), shape, dimensions, density, density gradient, velocity, position, orientation... All of which are interdependent, and some of which are complex themselves. A new material is a bitch to design, having hundreds of parameters, quite a few of which are variable by state. Materials can contain binding to a process, but not to a spacial relationship. Life no longer does anything significant, as there is a subclass of physical called "alive", bound to processes like replication, reaction, and proaction... all of which have subprocesses implementing specific behaviors. If I wanted to add a new physical attribute, I could... and I could make the base processes take it into account... but I can't control the exact results of this change... and I certainly can't test it in a limited scope. And that's just for behavior. Interface is a whole different can of worms. How do I describe the attribute to a player, if at all? There's a client - theoretically - that needs to be able to interpret direct (as opposed to consequential) manifestations of the new attribute. I remember adding a new set of fields describing locomotive behaviour for objects - if an object moved under its own power, it could describe that behavior, or use a default - and I can't think how I'd do this now. I'd say the current design is better - the client describes the locomotive behaviour out of a lexical database it has updated from the server when the new process in question is added - but you can't make a tigger bounce and flounce and pounce, unless you derive a special version of a hopping locomotion process (one exists for pogo sticks, or things of that nature, already) with those descriptions... which would really mess with the NLP neural net's lexicon. And building objects is a pain. I'm using a skeletal gui based assembler. :> So though in theory, with competent and _disciplined_ developers, the :> LPMud can be everything a Diku can and then some, in practice there's :> no question which code base I prefer to be a player in. Since Skotos :> uses DGD, an LP driver, we must attempt to conjure up this discipline :> largely through our world implementation (and developer interface). :cf my LP vs Diku posting from ages ago, it's in the archives and also on my :website. Key point is near the end, and is equally applicable to your :approach: "The name of the game in Dikus really has to be making the :templates they load more flexible"... in other words, for your approach, :providing an architecture to your superclass so that your methods can easily :be added to, expanded on, and customized in greater detail... :<A HREF="http://www.legendmud.org/raph/gaming/index.html">http://www.legendmud.org/raph/gaming/index.html</A> As I said, I did that once... the end result was a form of SGML that had a separate program for converting Diku files to a subset... and mobprogs to a different file, to be updated by hand. Now the question is, if I turned my codebase and development environment loose, would it hold up against the undisciplined builders' efforts? If someone tries to write a process that behaves in a way out of keeping with the existing resources and process attributes, it won't work - but I imagine some abuses will, and where there's something hackable... -- Nathan F. Yospe - Born in the year of the tiger, riding it forever after <A HREF="http://www2.hawaii.edu/~yospe">http://www2.hawaii.edu/~yospe</A> nathan.yospe#isearch,com yospe#hawaii,edu Don't mind me, I'm just insane... there's someone else here in my brain. _______________________________________________ MUD-Dev mailing list MUD-Dev#kanga,nu <A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</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="00682" HREF="msg00682.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></STRONG> <UL><LI><EM>From:</EM> "Koster, Raph" <rkoster#origin,ea.com></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00684.html">Re: [MUD-Dev] better usage through mechanics [from: CGDC dinner]</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00686.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00682.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00686.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00685"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00685"><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] Debugging techniques</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00810" HREF="msg00810.html">[MUD-Dev] Debugging techniques</A></strong>, adam <a href="mailto:adam#treyarch,com">adam#treyarch,com</a>, Fri 31 Mar 2000, 20:57 GMT </LI> </ul> <LI><strong><A NAME="00765" HREF="msg00765.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Phillip Lenhardt <a href="mailto:philen#funky,monkey.org">philen#funky,monkey.org</a>, Tue 28 Mar 2000, 21:34 GMT </LI> </ul> </ul> <LI><strong><A NAME="00677" HREF="msg00677.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Dr Richard A. Bartle <a href="mailto:richard#mud,co.uk">richard#mud,co.uk</a>, Tue 21 Mar 2000, 21:45 GMT </LI> <LI><strong><A NAME="00682" HREF="msg00682.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Wed 22 Mar 2000, 00:25 GMT <UL> <LI><strong><A NAME="00685" HREF="msg00685.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Wed 22 Mar 2000, 01:59 GMT </LI> </UL> </LI> <LI><strong><A NAME="00686" HREF="msg00686.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Draymoor <a href="mailto:fibhufky#erols,com">fibhufky#erols,com</a>, Wed 22 Mar 2000, 02:33 GMT </LI> <LI><strong><A NAME="00687" HREF="msg00687.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Draymoor <a href="mailto:fibhufky#erols,com">fibhufky#erols,com</a>, Wed 22 Mar 2000, 03:53 GMT </LI> <LI><strong><A NAME="00756" HREF="msg00756.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Brian Ashburn <a href="mailto:BAshburn#us-south,net">BAshburn#us-south,net</a>, Tue 28 Mar 2000, 20:18 GMT </LI> <LI><strong><A NAME="00782" HREF="msg00782.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, cg <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Wed 29 Mar 2000, 02:38 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>