<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] Embedded languages, object persistance... ack. --> <!--X-From-R13: X Q Znjerapr <pynjNxnatn.ah> --> <!--X-Date: Sat, 01 Jan 2000 11:03:20 -0800 --> <!--X-Message-Id: E124To3-0005zF-00#dingo,kanga.nu --> <!--X-Content-Type: text/plain --> <!--X-Reference: 000c01bf51db$81f3f600$f6088d18#busy1,on.wave.home.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: [MUD-Dev] Embedded languages, object persistance... ack.</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw#kanga,nu"> </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="msg00003.html">Previous</a> | <a href="msg00005.html">Next</a> ] Thread: [ <a href="msg00012.html">Previous</a> | <a href="msg00046.html">Next</a> ] Index: [ <A HREF="author.html#00004">Author</A> | <A HREF="#00004">Date</A> | <A HREF="thread.html#00004">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: [MUD-Dev] Embedded languages, object persistance... ack.</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>: Re: [MUD-Dev] Embedded languages, object persistance... ack. </LI> <LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#kanga,nu">claw#kanga,nu</A>></LI> <LI><em>Date</em>: Sat, 01 Jan 2000 11:03:15 -0800</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 Wed, 29 Dec 1999 01:03:00 -0800 Joe Kingry <jkingry#uwaterloo,ca> wrote: > I want a mud server on which I can change the code online of say a > skill, a spell or something else. I understand that this is the > purpose of having an embedded language that runs "on top of" the > mud's driver. i.e. MUF for MUQ, Python for AR3 etc. What you are talking about we commonly call "runtime morphism", which is just the ability to edit the object heirarchy at runtime, and to have the effects of those changes appear during the same runtime (there may be a delay) without an interruption in service. However the use of an internal scripting language in a MUD is rarely driven by the need to support runtime morphism More often the driving factors are things like ease and rapidity of world development and suitability for non-programmer users/players. Adding runtime morphism is not necessarily an automatic or trivial task once you have an internal scripting language. Consider a deep object heirarchy, where a large number of objects which are in common use in the game all inherit from a common shared object. What happens if I come along and edit the methods and/or attributes on that shared object? What happens if I totally redefine it? What happens to all the objects that descend from it? What happens to the commands people have or are issuing which affect the child objects? What happens if the changes cause mass breakages such that few to no objects actually work any more? For me some of the driving reasons behind internal languages are Rapid Application Development (implementing the game world or world features), suitability for non-professional programmer use, ability to tailor to world building versus general programming problems, ease of extending the language in "interesting" directions, and so forth. > So in general I know this code is to be compiled since you don't > want to be executing "scripts", but is this code an object? and > then is the byte-code stored? ack.. I'm confused. Not so fast. The majority of MUD servers out there with internal scripting languages don't actually have an internal Virtual machine (VM) to which they byte compile their internal scripting languages (eg the Tiny-* clan). Having a VM and building a byte code compiler can significantly increase performance, but it is also a non-trivial programming task that many have foundered on. More simply: Language design is not easy and is very easy to get wrong. This is why many of the new rash of MUD servers are (very intelligently) avoiding this problem entirely and using the Java VM and then using Java, JPython, or similar to produce the appropriate byte codes. There area certain trade-offs of course. Your ability to redefine and tailor the language to your task at hand is gone, your selection of possible languages to use is heavily limited (especially for us by non-programmers), etc. Another distinction which needs to be made here (which most of the object oriented servers fail to do) is between a class definition and an object. A class definition describes and defines how something would be and would work if it existed. It _defines_ something, it doesn't actually create one of those things. An object is an "instance" of a class. It is a created example of the class definition. Why is this important? In systems which make a distinction between classes and objects, you can compile the class definitions and store the results with with class, and then merely have the various object instances refer to that definition to access their defining code. You can also build different systems to handle class definitions than you use to handle objects, tailoring each system to handle its data type (class or objects) best and not the other. However, most current MUD servers do not define the difference between a class definition and an object instance. They are one and the same. (eg MOO, ColdC, etc). What this means is that an object usually also defines its class. Often programmers for such systems try and install an artificial distinction by only doing programming (class definitions) in objects that they never actually use anywhere, and just inheriting children from those object when they want to create intantiations (ie the objects players actually use). Not making the distinction makes things simultaneously a little messier and a little easier in implementing the system. You now have only one type of thing to deal with (objects), but you now also have to deal with a mess of class heirarchies amd objected heirarchies which are intermingled. Depending on how you approach things, the difference can be large or quite small. Now as to how the bytecode is actually stored, there are lots of ways, if you think about the bytecode really is just another data stream associated with a class or an object. You could even do something as simple as: class class_definition { attribute *attrs; method *methods; byte-code compiled; }; and keep them all together, and handle them all together in whatever your persistence system is. > Here, I'll try to demonstrate what I little I think I know from > MUSH type enviroments. A MUSH allows you to create an > object. Great. This object is unique and persistent. Ie. it will > be there when you get back if you so desire. You can assign code > to execute based upon certain defined actions on the object, or > you can create a new action for this object. Going by this model > then, does that mean every single object in these "new" muds is a > class and is inherited from a previous object? But then it's > executed how? See the above dinstinction between classes and objects. MUSHes fail to make that distinction and thus every object has the potential to both be an object _and_ a class definition for other objects and classes. Yes, it is kind of confusing if you come from a strict OO background. As mar as execution is concerned (which only ever properly occurs for objects, not classes), that occurs by having something call one of the methods on that object: class X { void poke () { print "Hello there!"; } } Object Y is an instance of class X. You then have something call Y.poke () to invoke and run that code. > I think I have my object/class/code/driver concepts all muddled. That's really easy to do with most MUD server implementations. > -doesn't require me to learn it's "own custom embedded > language"... Realise that no matter what language it uses, for someone it will require learning a whole new language as they won't know it. Doesn't really matter if its Java, Python, NetREXX, or whatever. The advantage with chosing a generic programming language here is that your audience of people who do know it increases, and they have some chance of being able to exploit that skill elsewhere as well. Note however that once you have a language chosen, the real learning pain is in your class heirarchy -- which is expressly NOT portable and NOT leveragable to other systems. > -somehow allows for security and access levels while coding > -somehow allows for an event type system This is a bitch and a minefield. You are caught right in the middle of usability requirements on the one hand, and the need to keep things secure on the other. > Muq seems to have most of these except for MUF, I got tired of > programming backwards ;). I'm no fan of RPN either (or lisp for that matter). > Then there is Momoko, it uses Java which would be great, but I'm > not quite sure how to go about things and if it insists on having > everything in memory or not and file management etc and i'm > unclear if every unique object is it's own class on a persistent > system. I haven't looked at Momoko in any detail yet. Would someone care to point out MUD-Dev to the authors? -- J C Lawrence Home: claw#kanga,nu ----------(*) Other: coder#kanga,nu --=| A man is as sane as he is dangerous to his environment |=-- _______________________________________________ MUD-Dev maillist - 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> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00046" HREF="msg00046.html">Re: [MUD-Dev] Embedded languages, object persistance... ack.</A></strong> <ul compact><li><em>From:</em> "Jay Carlson" <nop#mitre,org></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00003.html">Re: [MUD-Dev] Admins as Mortals twist</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00005.html">Re: [MUD-Dev] Storing tokens with flex & bison</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00012.html">[MUD-Dev] Muq update</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00046.html">Re: [MUD-Dev] Embedded languages, object persistance... ack.</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00004"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00004"><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: [MUD-Dev] OS Inspiration</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00021" HREF="msg00021.html">Re: [MUD-Dev] OS Inspiration</A></strong>, Greg Miller <a href="mailto:gmiller#classic-games,com">gmiller#classic-games,com</a>, Sun 02 Jan 2000, 17:26 GMT <UL> <LI><strong><A NAME="00119" HREF="msg00119.html">META: List goals (was Re: [MUD-Dev] OS Inspiration)</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Tue 18 Jan 2000, 08:35 GMT </LI> </UL> </LI> </ul> </LI> <LI><strong><A NAME="00013" HREF="msg00013.html">[MUD-Dev] JavaWorld: Build an object database</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Sat 01 Jan 2000, 20:51 GMT <LI><strong><A NAME="00012" HREF="msg00012.html">[MUD-Dev] Muq update</A></strong>, Cynbe ru Taren <a href="mailto:cynbe#muq,org">cynbe#muq,org</a>, Sat 01 Jan 2000, 20:14 GMT <LI><strong><A NAME="00004" HREF="msg00004.html">Re: [MUD-Dev] Embedded languages, object persistance... ack.</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Sat 01 Jan 2000, 19:03 GMT <UL> <LI><strong><A NAME="00046" HREF="msg00046.html">Re: [MUD-Dev] Embedded languages, object persistance... ack.</A></strong>, Jay Carlson <a href="mailto:nop#mitre,org">nop#mitre,org</a>, Tue 04 Jan 2000, 01:28 GMT </LI> </UL> <UL> <li><Possible follow-up(s)><br> <LI><strong><A NAME="00043" HREF="msg00043.html">Re: [MUD-Dev] Embedded languages, object persistance... ack.</A></strong>, Jay Carlson <a href="mailto:nop#mitre,org">nop#mitre,org</a>, Mon 03 Jan 2000, 20:25 GMT <UL> <LI><strong><A NAME="00124" HREF="msg00124.html">Re: [MUD-Dev] Embedded languages, object persistance... ack.</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Tue 18 Jan 2000, 09:17 GMT <UL> <LI><strong><A NAME="00137" HREF="msg00137.html">Re: [MUD-Dev] Embedded languages, object persistance... ack.</A></strong>, icecube <a href="mailto:icecube#ihug,co.nz">icecube#ihug,co.nz</a>, Tue 18 Jan 2000, 20:52 GMT </LI> </UL> </LI> </UL> </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>