<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] common server design --> <!--X-From-R13: ptNnzv-pt.UenlEntr.Sqzbagba.OP.QO (Quevf Uenl) --> <!--X-Date: from scipio.globecomm.net [207.51.48.12] by in1.ibm.net id 867290424.47654-1 Thu Jun 26 02:00:24 1997 CUT --> <!--X-Message-Id: 9706260222.86ek@ami-cg.GraySage.Edmonton.AB.CA --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: [MUD-Dev] common server design</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA"> </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="msg01508.html">Previous</a> | <a href="msg01510.html">Next</a> ] Thread: [ <a href="msg01621.html">Previous</a> | <a href="msg01521.html">Next</a> ] Index: [ <A HREF="author.html#01509">Author</A> | <A HREF="#01509">Date</A> | <A HREF="thread.html#01509">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: [MUD-Dev] common server design</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: [MUD-Dev] common server design</LI> <LI><em>From</em>: <A HREF="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</A> (Chris Gray)</LI> <LI><em>Date</em>: Wed, 25 Jun 97 19:22:34 MST</LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> [Caliban:] :> To a certain extent, yes. But, the facilities available in the server :> will influence what make sense in designing the way in which things like :> rooms, objects, commands, etc. are put together. : :However, this also results in the commands being fitted to the server :instead of :the user. The user has to use the commands, so the user should be the :primary :concern in designing a command structure. I have to disagree. User input is important, yes, but you cannot ignore the realities of implementation. Some ideas are just plain not workable, regardless of what uninformed users might think. :> Doing that stuff while ignoring what the server is like is bound to run into :> troubles. : :That viewpoint basically hammers a fundamental theory of object-oriented :programming, which is that no part of the program should rely upon any :knowledge :or assumptions regarding the rest of the program. If OOP is appropriate :for a :MUD server, then OOD should also be appropriate. You design each object :within :the four groups mentioned previously (user interface, command interface, :network :interface, and game system) as though anything whatsoever could be :interacting :with it. Sorry, I don't see your point here. Can you rephase? :> If you :> have a concept of separate "exits" (I don't), then any support in the :> server for them should be considered, and vice versa. : :If you have no concept of anything, the server must by necessity support :an :intuitive and understandable method of describing in an effective :fashion :something that the developer would never in a million years have thought :of. :It's the 'intuitive and understandable' parts which bog down some :servers. "Intuitive and understandable" are so subjective that they can easily lose all value as evaluators. As you say below, the concensus (hah!) of a group of people is generally of more value, so long as that group has enough background to be aware of most of the issues. The opinion of a large group of uninformed/inexperienced people is often not worth much. :> You can't do the :> two completely separately, since the base of the scenario is dependent :> on the server and what it does well. : :I expect the server to have a very broad but well-defined goal, which is :to run :text-based multiplayer online games that are easy to interact with. :Given that :goal, certain types of games (Quake, chess, connect four, poker, :scrabble, word :search puzzles, crosswords, etc.) won't really be appropriate. Neither :will some :potential applications (operating systems, device drivers, compilers). :While I :am sure some weirdo somewhere is going to complain he can't use RPC in :his :mobprogs, I don't think that necessarily means we need that in the :server. I think you have to have a more strongly defined goal than that. What appears to happen a lot, at least from what I've gathered from folks on this list, is that people with lots of experience with MUDs (I'm not counting myself here, since I have almost no experience with MUDs outside of my own) have thought about what they find wrong with current servers, and have set out to try alternative stuff in the hopes that it will serve better. This is much more like research than it is like deliberate commercial development. I think a lot of input from the user point of view would be valuable, but not directly applicable to the core of a server (I always tend to think of a server as being fully programmable, so that the distance from its core to user commands is quite large). The value of all of that user input is in how to build upon the core to attain the selected portion of the user goals. Trying to exactly match any given set of requests from inexperienced users sounds like a recipe for failure to me. Paying attention to the requests is valuable, but following them exactly isn't. :> Certainly, but I think it is unwise to equate "cool" with "useful". In :> real life, the best way to do something may not be cool at all. : :If you're trying to create something cool, then the best way to do it is :by :definition something cool. QED. There will obviously be some limitations :and :restrictions the final server inherits -- try to be everything to :everyone, and :you end up nothing to nobody -- but I'm really hoping we can create :something :that will flatten the learning curve without overly diminishing the :power. In :my opinion, that's pretty cool *and* pretty useful. You may disagree, of :course, :since that's your prerogative. I guess it depends on how you think of "cool". Achieving an affect that appears cool to its users can be done by entirely non-cool internal techniques. And vice-versa, unfortunately. Again, what is cool will vary from user to user, too. :Another point might be that there is a lot of useful crap out there, :too. Think :of the most horrendous misfeature of a server you have ever seen in your :life :(no, I don't have anything in mind, but I'm sure it's not hard for you :to come up :with one) and I can almost guarantee that someone out there is using it :for something. If nothing else, *you're* using it as an example. ;) Well, given my almost total lack of experience with other MUD systems, some things I've seen so far that really didn't appeal are: - silly inheritance in LP that results in sillyness like 3K rooms that are minimally different from one another - ridiculous scripts in Mush that look like line noise victims - poor command parsing in many MUDs (it isn't hard to add a little bit of support for extras words, punctuation, etc.!) - whatever... :The willingness of people to believe that my example of a pathologically :bad :command line for a game server was a *recommendation* pretty much :demonstrates :people's expectation that a game server's command syntax will be :unusable and :cryptic. In my case it arises from my belief there are a lot of hackers out there who will implement whatever seems easiest at the time, with little or no thought of future expansion. To me, such systems seem to be things that have mutated and sprouted cancers, rather than things that have grown properly with adequate resources. A good designer has to step back from time to time and ask if what is happening is good, and then be willing to redo stuff if it isn't good. Too many people hacking on MUD servers do not do that, and it shows. (Not that I'm claiming that I would never resist change!) This arises mainly from the lack of external input, I think; :there are :things I find intuitive, and things other people find intuitive. Since I :am a :longtime gamer, experienced programmer, and network administrator... :chances are :I would find something 'intuitive' where many other people would find it :just :plain confusing. I might, for example, think that a good syntax for :making some :object inherit another objects properties is by using a command like : : create child uses parent : :But someone else could look at this and get confused. Obviously, the :Java people :among us will likely think this is perfectly logical, although an :argument could :certainly be made for 'extends' instead of 'uses'. Someone else might :prefer to :have the commands separated -- for example, 'create child' and 'link :child parent'. Other people will of course have different ideas. But the :problem with :both approaches is that it isn't really descriptive of the parent/child :relationship, and doesn't spring to mind instantly when trying to make :one :object the same as another object. I wouldn't have any problem with that sort of distinction. My solution would be to accept any of the keywords that people are likely to use (or use none at all, and rely on position). The things I have problems with are excess use of hard-to-type punctuation characters and escape mechanisms. (Background: I also immensely dislike the syntax of things like shell scripts, nroff/troff, some of the perl stuff, etc.) :Which is why I like the idea of getting together in a sort of round :table :discussion about what makes a game server's command interface good or :bad, and :how it could be made better. That way, even if the discussion goes :straight to hell and degenerates into flamage, we see some other :people's opinions. We should :all at least get one or two ideas from this sort of discussion, since :even when :someone just says 'a command like X sucks' you might think of a way to :fix it or :a new command that doesn't suck. Question: are we talking about the user input in general to MUDs, or are we just talking about some building commands and ignoring the more common stuff? I've been assuming we're talking about everything. Got any specific suggestions you'd like to start the discussion process with? Here is one from me: (using pseudo-BNF type stuff) Don't use page <who> '=' '"' message Instead, use page <who> <message> where <message> is the rest of the input line Given that the builder commands in my MUD are part of the scenario and not the server, I can likely throw together stuff to try them fairly quickly (assuming I'm not deep in something else, of course!). The problem is more likely to be in the basic concepts in building. As I said, I have no such thing as "exits" as separate entities, and I also have no concept of "objnums" or anything like that. The latter just doesn't make any sense in my system. When you build a room via a command, as in: build room new north indoors in Chris's new room you get a new room that is linked to the north of the room you are currently in. You can then move to it and decorate it, change its connections to other places, add entry/exit restrictions, etc. You can also give it a symbol in a symbol table, for later reference. Oh, the above is parsed according to: <generic command: build, alias @> <build command: room, alias r> <room building command: new> <direction to build in: north, alias n> <room type: indoors> <room name: "in Chris's new room"> This isn't super user friendly, but after a bit of practice isn't bad - most people will have more trouble remembering the various room types (which just controls what generic room they inherit from), than in remembering the pieces of the command. Would it be more user friendly to have keywords for all the pieces, and default values, so that users could use, e.g.: @r new type indoors dir n or, if you like typing punctuation: @r new type=indoors dir=n ? -- Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA </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="01533" HREF="msg01533.html">noise</A></strong> <ul compact><li><em>From:</em> alexo#bigfoot,com (Alex Oren)</li></ul> <li><strong><A NAME="01530" HREF="msg01530.html">Re: [MUD-Dev] common server design</A></strong> <ul compact><li><em>From:</em> caliban#darklock,com (Caliban Tiresias Darklock)</li></ul> <li><strong><A NAME="01521" HREF="msg01521.html">Re: [MUD-Dev] common server design</A></strong> <ul compact><li><em>From:</em> Jeff Kesselman <jeffk#tenetwork,com></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg01508.html">Levels and XP</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg01510.html">Re: [MUD-Dev] "short" Introductory Message (fwd)</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg01621.html">Re: [MUD-Dev] common server design</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg01521.html">Re: [MUD-Dev] common server design</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#01509"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#01509"><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] common server design</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <LI><strong><A NAME="01616" HREF="msg01616.html">Re: [MUD-Dev] common server design</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Tue 01 Jul 1997, 05:55 GMT </LI> </ul> <LI><strong><A NAME="01472" HREF="msg01472.html">Re: [MUD-Dev] common server design</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 24 Jun 1997, 13:03 GMT <UL> <LI><strong><A NAME="01478" HREF="msg01478.html">Re: [MUD-Dev] common server design</A></strong>, Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Wed 25 Jun 1997, 03:48 GMT <UL> <LI><strong><A NAME="01621" HREF="msg01621.html">Re: [MUD-Dev] common server design</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Tue 01 Jul 1997, 07:38 GMT </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="01509" HREF="msg01509.html">Re: [MUD-Dev] common server design</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Thu 26 Jun 1997, 09:00 GMT <UL> <LI><strong><A NAME="01521" HREF="msg01521.html">Re: [MUD-Dev] common server design</A></strong>, Jeff Kesselman <a href="mailto:jeffk#tenetwork,com">jeffk#tenetwork,com</a>, Thu 26 Jun 1997, 13:57 GMT </LI> <LI><strong><A NAME="01530" HREF="msg01530.html">Re: [MUD-Dev] common server design</A></strong>, Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Thu 26 Jun 1997, 16:09 GMT </LI> <LI><strong><A NAME="01533" HREF="msg01533.html">noise</A></strong>, Alex Oren <a href="mailto:alexo#bigfoot,com">alexo#bigfoot,com</a>, Thu 26 Jun 1997, 16:49 GMT </LI> </UL> </LI> <LI><strong><A NAME="01518" HREF="msg01518.html">Re: [MUD-Dev] common server design</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 26 Jun 1997, 12:00 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>