<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] RP=MUSH/PG=MUD --> <!--X-From-R13: pnyvonaNqnexybpx.pbz (Qnyvona Fverfvnf Rnexybpx) --> <!--X-Date: from scipio.globecomm.net [207.51.48.12] by in3.ibm.net id 866927796.50732-1 Sat Jun 21 21:16:36 1997 CUT --> <!--X-Message-Id: 33ad365e.412609#relay,mnsinc.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199706210253.TAA22051#user2,inficad.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: [MUD-Dev] RP=MUSH/PG=MUD</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:caliban#darklock,com"> </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="msg01409.html">Previous</a> | <a href="msg01411.html">Next</a> ] Thread: [ <a href="msg01450.html">Previous</a> | <a href="msg01561.html">Next</a> ] Index: [ <A HREF="author.html#01410">Author</A> | <A HREF="#01410">Date</A> | <A HREF="thread.html#01410">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: [MUD-Dev] RP=MUSH/PG=MUD</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] RP=MUSH/PG=MUD</LI> <LI><em>From</em>: <A HREF="mailto:caliban#darklock,com">caliban#darklock,com</A> (Caliban Tiresias Darklock)</LI> <LI><em>Date</em>: Sat, 21 Jun 1997 21:18:10 GMT</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, 20 Jun 1997 20:18:49 PST8PDT, Adam Wiggins <nightfall#inficad,com> wrote: >[Caliban:] >> 'here we have a group of servers that does this part well, and here we >> have a group that does that part well, so why not look at the >> possibility of doing something that combines the natural strengths of >> the two types, a sort of hybrid server?' > >*nod*..this is what I desire, and I think most folks think that this >is a Good Thing(tm) too. However, there seem to be large disagreements >of what the 'good' parts of any given server (or, more signifigantly, >game type) are. A lot of effort appears to be directed at locating the good algorithms and internal representations of the object model, rather than the high-level things which make a good game. What I'm looking at here is the general idea that people prefer certain things; we never seem to discuss the actual end-result, but the idea of how to represent a specific effect. I think in any system, there are several things that need to be handled, but rather than looking around and going "Let's use the socket code from Diku and the builder code from Mordor and the commands from TinyMUX and the database structure from Cold" -- which of course would be like using all the leftovers you have that aren't moldy to make a casserole -- let's look at what *makes* these things good (and I'm not saying any of the above are necessarily the best examples available), and see if we can't come up with something that would be as good or better. >We're always talking about this _sort_ of thing, I think, but it's >usually in very general terms rather than in terms of actual >functionality you want to lift wholesale from a certain server. No, no, no, that's not what I'm proposing! I'm proposing that we look at what works, and use it as a guide -- with the aim being to take the good parts, see why they're good, and try to put them together into something better. There will of course be modifications, because there's nothing out there that's *perfect*; more to the point, what I'm looking at is the possibility that if we assume the people using the server know absolutely nothing about anything, how can we best provide them with something intuitive and easy to use? This means that none of the admins, imms, imps, gods, wizards, or whatever you call them have any preconception about how the MUD ought to work; let's assume they would spend a lot of time posting messages to mailing lists asking how to do very very simple things, and try to answer those questions in the documentation and help. Let's try to make a server that takes next to no effort to install, run, and use, and free up these people to actually improve the game itself by adding new spells and classes and races and let them do all of it without having to recompile or reimplement anything at all. >As you've said, any hybrid worth its beans would have to be from-scratch, >forgoing a lot of the assumptions and setup things that have kept >existing servers from heading this way. If we operate from the assumption that no one is going to need to bring a database or area in from any other server, and leave any desired conversion utilities to standalone programs designed by people who need to do that sort of thing... that could free up our ability to define what really needs to be in the server. If we work from the idea of making the player happy, rather than the builder and the programmer, then we could possibly come out of this with something really great that's long overdue. >> There's a lot of talk here about internals, and next to no talk about >> what finally ends up on the screen when a user logs on. The user is > >It depends. I recall Wout's list being a lot less technical, but maybe >I just wasn't paying very close attention. About 6 months ago the >list went *very* technical and I didn't post for quite a while; it's >actually gotten quite a bit better with the recent influx of so many new >people. It's not the question of technical versus nontechnical; it's more a question of directed effort. The server developer is obviously concerned more with the code that runs the server than he is with the command set it results in. We end up with an interface and command structure that happens almost as a side effect. >Depends. I'm not interested in making my game accessable to a wide number >of users. I *am* interested in making it more playable, fun, and enthralling >for the users that I am targeting (namely, those who like to play the same >kinds of games I do). One thing my parter and I have always paid very >close attention to is making sure everything works in an intuative way. But the question is whether you're allowing new people who WOULD like to play these same kinds of games an appropriate opportunity to learn the game. No game is going to make *everyone* happy, but to create an interface targeted at people with a specific area of knowledge can unfairly lock out some very promising players. A related problem area is the all-too-common lack of documentation in servers; as should be evident in this post, I have four major problems with the majority of servers available. 1. Lack of documentation. 2. Nonintuitive command structure. 3. Complex and difficult building interface. 4. Lack of system flexibility. What all of this comes down to, in my opinion, is a lack of proper planning and design. I think what happens is that the developer has a really cool idea, and just jumps in and starts writing code. (I've been guilty of this myself.) When he hits a snag, he ducks and weaves around the problem. At the end of the process, there's this huge mess of code that could have been a lot better; and it's so tightly integrated, the problems are now difficult if not impossible to fix. It's been mentioned on this list before that the planning phase and the documentation phase just aren't fun. I think that's a good point, but I also think that we have a large enough community that we could possibly get the planning done in a sort of open forum, even before the code is actually being written. If we create something that has clear and compelling advantages, then people will *want* to write to the standard, and it won't be a question of my project and his project. If we build a set of 'desirable' server qualities, and put forth a little work here and there toward implementing those qualities, we can end up with a project that really doesn't *belong* to anyone. It would be something that is a property of the community, like it should be. It would reflect the wants, needs, and opinions of the people who are actually expected to use it. >Even the most intelligent and experienced gamer will be turned away if he >can't figure out how to interact with the game. Ours is particularly >bad since the game world is so open-ended (no easy-to-define goals from >the moment you start playing) and so complex (no simple list of special-case >rules as with a pen and paper RPG). I think complexity is something we should be trying to minimise. The more complicated the game gets, the harder it is to add a new feature or enhance an existing one. Tight integration for speed and power is a good thing until you want to build on it; there's no place to slot your changes and concepts in, and when you try to shift things around, you break things that you thought weren't even related. One of the things I've been looking at is trying to separate the four sections of the server I mentioned previously on this list; basically, setting them up so there is a very simple API in between them and anything that conforms to that API can replace a section. Sort of like FOSSIL drivers for serial interfaces; a FOSSIL driver abstracted the serial communications required for a program into a simple interrupt-driven API which nearly anyone could support. Any DOS programmer could learn the API in a matter of minutes, and add serial support to an application with a few hours of work. I think we could do the same general thing with a MUD, allowing someone to easily plug a new command set or builder interface or programming language or server core into the game. In other words, we could make it modular, with any and all of the modules interchangeable within their own function set. Working to this sort of standard would allow us to write whatever weird and wonderful things we want, with the assurance that as long as it conforms to the API it's going to work well with other pieces. Furthermore, if someone has a great plan for a new command structure, he wouldn't have to go reinvent the wheel by building the server core that handles network communications. He could build just the module he has a great idea for, and be confident that it's going to be linked to a working additional set of interfaces. This separation of function would also allow a programmer to quickly isolate any problems to a specific module, improving debugging. If someone keeps getting booted form the server, the problem could not possibly be in the command structure or programming language, it must be somewhere in the server core. If we provide an effective debugging model, we could make even the location and repair of bugs effectively a no-brainer. If we could cooperate on a project of this type, and set aside the 'X sucks Y rules' sort of thing, I don't really see that it would hurt anything. It may help; there are probably a lot of people out there who could improve their own designs just by watching the thread. Even if we don't actually build a server, we can still have an impact on server buillders, whether it might be the design of a full server based on what we come up with, or just a few modifications to a design in progress to reflect something we said that was considered a Good Idea. I certainly don't see that a discussion of the matter could have any detrimental effect. -+[caliban#darklock,com]+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I am here to grind your eyes harder into the miasmic bile of life; to show you the truth and the beauty in the whisper of steel on silk and the crimson scent of blood as it rises to meet the caress of a blade. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+[<A HREF="http://www.darklock.com/]+-">http://www.darklock.com/]+-</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="01561" HREF="msg01561.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong> <ul compact><li><em>From:</em> clawrenc#cup,hp.com</li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="01395" HREF="msg01395.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></STRONG> <UL><LI><EM>From:</EM> Adam Wiggins <nightfall#inficad,com></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg01409.html">Integrating PK</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg01411.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg01450.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg01561.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#01410"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#01410"><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] RP=MUSH/PG=MUD</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="01443" HREF="msg01443.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, Adam Wiggins <a href="mailto:nightfall#user1,inficad.com">nightfall#user1,inficad.com</a>, Mon 23 Jun 1997, 10:43 GMT <LI><strong><A NAME="01447" HREF="msg01447.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, Jeff Kesselman <a href="mailto:jeffk#tenetwork,com">jeffk#tenetwork,com</a>, Mon 23 Jun 1997, 11:51 GMT </LI> <LI><strong><A NAME="01448" HREF="msg01448.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 23 Jun 1997, 12:03 GMT <LI><strong><A NAME="01450" HREF="msg01450.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, Jeff Kesselman <a href="mailto:jeffk#tenetwork,com">jeffk#tenetwork,com</a>, Mon 23 Jun 1997, 12:18 GMT </LI> </LI> </LI> </ul> </ul> </ul> </ul> <LI><strong><A NAME="01410" HREF="msg01410.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Sun 22 Jun 1997, 04:16 GMT <UL> <LI><strong><A NAME="01561" HREF="msg01561.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Sat 28 Jun 1997, 03:30 GMT </LI> </UL> </LI> <LI><strong><A NAME="01506" HREF="msg01506.html">Re: [MUD-Dev] Meta</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Thu 26 Jun 1997, 07:57 GMT </LI> </ul> <LI><strong><A NAME="01500" HREF="msg01500.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Thu 26 Jun 1997, 02:33 GMT <UL> <LI><strong><A NAME="01531" HREF="msg01531.html">Re: [MUD-Dev] RP=MUSH/PG=MUD</A></strong>, Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Thu 26 Jun 1997, 16:14 GMT </LI> </UL> </LI> </ul> </ul> </ul> </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>