From csus.edu!csulb.edu!hammer.uoregon.edu!news1.mpcs.com!nntp.primenet.com!howland.erols.net!math.ohio-state.edu!news.physics.uiowa.edu!nntp.ksu.edu!news.cis.okstate.edu!jds Tue Dec 3 07:58:25 1996 Path: csus.edu!csulb.edu!hammer.uoregon.edu!news1.mpcs.com!nntp.primenet.com!howland.erols.net!math.ohio-state.edu!news.physics.uiowa.edu!nntp.ksu.edu!news.cis.okstate.edu!jds From: jds@math.okstate.edu (Jennifer "Moira" Smith) Newsgroups: rec.games.mud.announce,rec.games.mud.misc,news.answers,rec.answers Subject: [rec.games.mud]: FAQ #1/3: MUDs and MUDding Supersedes: Followup-To: rec.games.mud.misc Date: 16 Nov 1996 07:00:03 GMT Organization: Oklahoma State University, Stillwater OK Lines: 629 Approved: news-answers-request@MIT.Edu,rgm-announce-request@theurgy.digex.net Expires: 14 Dec 1996 07:00:02 GMT Message-ID: Reply-To: jds@math.okstate.edu NNTP-Posting-Host: littlewood.math.okstate.edu Summary: basic info on muds Keywords: muds aber lp tiny muck mush moo uber unter diku smug muse mage Originator: jds@littlewood.math.okstate.edu Xref: csus.edu rec.games.mud.announce:2601 rec.games.mud.misc:24302 news.answers:87456 rec.answers:25588 Archive-name: games/mud-faq/part1 FREQUENTLY ASKED QUESTIONS: Basic Information about MUDs and MUDding This is part 1 in a 3 part series of FAQs. $Id: mudfaq-p1.html,v 1.6 1996/10/28 16:51:43 jds Exp jds $ _Disclaimer:_ This document may be seen to be biased towards TinyMUDs. This is because the maintainer mainly plays those types of servers, not because she thinks they are inherently better or worse than other types of servers. However, this document is meant to be generalized and useful for all MUDdom, and so corrections and contributions are always welcome. Welcome to the world of MUDding! Table of Contents * FAQ #1: Basic Information about MUDs and MUDding + General Information o 1.1. What is a MUD? o 1.2. What different kinds of MUDs are there? o 1.3. Where are MUDs located? o 1.4. I paid money for my account! MUDding is a right, isn't it? o 1.5. How do I connect to a MUD? o 1.6. What is a client program? o 1.7. Now that I'm connected, what do I do? o 1.8. Why not just dive in? o 1.9. What password should I use for my MUD character? o 1.10. What's the easiest way to annoy a veteran MUD user? o 1.11. What's the easiest way to be a mean veteran MUD user? o 1.12. What should I _not_ do in terms of player interaction? o 1.13. Is MUDding a game, or an extension of real life with gamelike qualities? o 1.14. What common commands are used on MUDs? o 1.15. I know what's going on now! What's next? o 1.16. Who should I ask for help? o 1.17. What if I'm completely confused and am casting about for a rope in a vast, churning wilderness of chaos and utter incomprehension? o 1.18. What USENET newgroups are devoted to MUDs? o 1.19. Are there any MUD URLs? o 1.20. How do I start my own MUD? + Glossary o 1.21. What was the first MUD? o 1.22. What is a bot? o 1.23. What's a clueless newbie? o 1.24. What is a cyborg? o 1.25. What's a dino? o 1.26. What is a flame? o 1.27. What is a furry? o 1.28. What is OOC/IC? o 1.29. What is a log? o 1.30. What is Maving? o 1.31. What is net lag? o 1.32. What's player killing? o 1.33. What is spam? o 1.34. What is TinySex? o 1.35. What is a 'Wizard' or 'God'? * FAQ #2: MUD Clients and Servers + Client Information o 2.1. What is a client? o 2.2. Where do I get clients? o 2.3. What operating systems do clients run on? o 2.4. Is there anything wrong with running a client? o 2.5. What different clients are available? [Client List] + Glossary of Client terms + Server Information o 2.6. What is a server? o 2.7. Where do I get servers? o 2.8. What operating systems to servers run on? o 2.9. Is there anything wrong with running a server? o 2.10. What different servers are available? [Server List] + General Information o 2.11. What do I do if my client/server won't compile? o 2.12. Should I read the documentation of whatever client or server I select? o 2.13. What is FTP, and how do I use it? * FAQ #3: Basic Information on RWHO and mudwho + 3.1. What is RWHO? + 3.2. How Does It All Work? + 3.3. Where Can I Get This Stuff? + 3.4. Where Are Some RWHO Servers? General Information _1.1. What is a MUD?_ A MUD (Multiple User Dimension, Multiple User Dungeon, or Multiple User Dialogue) is a computer program which users can log into and explore. Each user takes control of a computerized persona/avatar/incarnation/character. You can walk around, chat with other characters, explore dangerous monster-infested areas, solve puzzles, and even create your very own rooms, descriptions and items. You can also get lost or confused if you jump right in, so be sure to read this document before starting. For a nice anecdote about the origin of the name, I quote Richard Bartle, co-author of the first MUD: [...] I am WELL aware what "MUD" stands for, and maybe once every 2 months have to tell someone. The "D" does stand for "Dungeon", but not because the original MUD (which I co-wrote) had a dungeon in it; rather it was because there was a hacked-up version of Zork doing the rounds at the time, which bore the name "Dungeon". We thought that this program would act as the archetype for single-player adventure games, so we called our game "Multi-User Dungeon" in an effort to convey some feeling of what the program did. As it happened, the genre was promptly called "Adventure games" after the Colossal Caves game "Adventure", so we were wrong in that respect. By then, though, we had our acronym. _1.2. What different kinds of MUDs are there?_ You'll notice the disclaimer on this FAQ mentions _TinyMUD._ That's one common type of MUD, but there are many different types of MUDs out there. The _Tiny-_ and _Teeny-_ family of MUDs are usually more _social_ in orientation; the players on those MUDs tend to gather, chat, meet friends, make jokes, and discuss all kinds of things. The _LP-_ family of MUDs, including _Diku_ and _AberMUD_, are usually based on roleplaying adventure games; the players on those MUDs tend to run around in groups or alone killing monsters, solving puzzles, and gaining experience in the quest to become a wizard. There are still other types of MUDs, such as _MOOs_, _UnterMUDs_, and so forth. Each type has its own unique style, and players are rarely forced to stick to one type of playing - there's no rule that says an _LPMUD_ _must_ be a combat-oriented MUD, or that a _TinyMUSH_ _must not_ be a combat-oriented MUD. We suggest that you experiment around with several different types of MUDs to see what you find is the most interesting. If there's one thing MUDdom has, it's variety. You may wish to check out the LPMud FAQ, posted to the rec.games.mud.lp newsgroup periodically by George Reese. _1.3. Where are MUDs located?_ Several different services provide lists of currently-running MUDs. One of the best is the MUD Connector, reachable at http://www.mudconnect.com/. You can also get mailed a current list of muds by mailing to mudlist@merlyn.punk.net with SUBSCRIBE as the subject. MUDs are run on many fine computers across the world. To play, all you have to do is telnet to the MUD's Internet Protocol Port, and you're in business. Some MUDs have a policy called registration to cut down on abuse of privileges; you might have to send mail to the administrator of the MUD in order to obtain a character. It's important to note that MUDs are _not_ a right, and your access is granted out of trust. People usually have to pay to use processing time on the large, expensive computers which MUDs often run on, and you're being given a special deal. Which brings us to another point: MUDs can't really be run on anything less than a largish workstation (currently), so they're usually on academic or corporate workhorse machines. _1.4. I paid money for my account! MUDding is a right, isn't it?_ Don't believe that for a second. When you paid money to your school's computer department for an account, you entered into a contract with that department. Most schools have a well written Computer Policy document, that will detail exactly what you have rights to. Most schools classify MUD as a game, and games as non-essentials. Therefore, if your school decides to shut off all games, or disallow you to telnet out to play muds, you're stuck. Don't try to get around it; they'll find you. Instead, try to talk to the Powers That Be, and see why they did what they did. They may have very good reasons for it (such as limited resource that really need to be dedicated to schoolwork). _1.5. How do I connect to a MUD?_ There are several ways to hook yourself up to a MUD's internet port. First, you can use telnet once you find out the MUD's network address and port number. If, for instance, we knew that ChupsMUD was at the network address pickle.cs.umsst.edu at port 4201, we could type: (on most systems, including UNIX) telnet pickle.cs.umsst.edu 4201 (or, on some VMS systems) telnet pickle.cs.ummst.edu/port=4201 and we'd be ready for action. If we get back an error saying something like _host unknown_, we'd want to do the same thing, only using the machine's internet number address, like this: telnet 127.0.0.1 4201. If you're using straight telnet on a VMS system, you might have to make sure that your terminal has _newlines_ turned on. If it doesn't, the mud's output will get spewed across the screen in a most ugly fashion. Your second option is to scout out the many fine client programs which exist for the sole purpose of providing a friendly and useful front end to MUDs. (See _client_, below.) _1.6. What is a client program?_ Telnet is a rather ugly way to connect to most muds, since it doesn't do any fancy text wrapping, and if someone says something while you're typing out a line, it will make a mess out of your line, making it hard to see what you're typing and hard to keep track of what's going on in the mud. A client program is simply another program you use instead of telnet to connect to a mud. Clients also provide useful things such as macros and the ability to gag or highlight certain mud output. Clients are available for anonymous ftp from several sites. See the Frequently Asked Questions posting #2 for more information about clients. _1.7. Now that I'm connected, what do I do?_ Once you connect, find out what the deal is with respect to you getting a character. Some MUDs allow you to create your own, and others require you to send off for one via email. If you have to send off for one, send one e-mail request and cool your heels. MUDding will be around forever, no need to rush it. But let's say you've now gotten a character, and you're connected up, and things are starting to get interesting. At this point, you should do what is probably least intuitive: type _help_, read the instructions and directions, and understand them. Then, type _news_, read the information, and understand it. Then (yes, we know, we know... it'll be fun, soon!) practice using the commands given to you until you think you've got a good enough grip to be able to start in on exploring, questing, socializing, or whatever else tunes your engine. _1.8. Why not just dive in?_ Some people are easily annoyed when other people clearly have no idea what they are doing, even if they were recently in that position themselves. It'll be much easier for you to cope without some fella saying things you don't understand to you and possibly killing you. _However_, many MUD players are helpful, and asking them, "excuse me, are you busy? I'm a brand new player, and I have a question," will often work just fine. _1.9. What password should I use for my MUD character?_ You should pick a password just as you do for any computer account. Use a word, or better yet, a phrase or anagram, that isn't obvious. Don't, for instance, use the same name as your character, or your own first name, or your girl/boyfriend's name. And never never use the same password as the one on your computer account. Most MUDs prevent people from getting the passwords from within the mud, and most encrypt the password when it's store in the database files. However, there is nothing preventing the MUD's owner from modifying the code to dump the passwords to a file, along with other information such as the host you connected from. Using this information, an evil MUD admin could probably figure out your login name and get into your account easily. It's also not a good idea to use the same password on different MUDs, since if your password gets out on one MUD, all your MUD characters have been compromised. This is _especially_ important for MUD Wizards and Gods. Use the auto-login feature of your client, if it has one, and protect the file containing the login information against reading by others. This story comes from Alec Muffett, author of Crack and maintainer of the alt.security FAQ. aem@aberystwyth.ac.uk: The best story I have is of a student friend of mine (call him Bob) who spent his industrial year at a major computer manufacturing company. In his holidays, Bob would come back to college and play AberMUD on my system. Part of Bob's job at the company involved systems management, and the company was very hot on security, so all the passwords were random strings of letters, with no sensible order. It was imperative that the passwords were secure (this involved writing the random passwords down and locking them in big, heavy duty safes). One day, on a whim, I fed the MUD persona file passwords into Crack as a dictionary (the passwords were stored plaintext) and then ran Crack on our systems password file. A few student accounts came up, but nothing special. I told the students concerned to change their passwords - that was the end of it. Being the lazy guy I am, I forgot to remove the passwords from the Crack dictionary, and when I posted the next version to USENET, the words went too. It went to the comp.sources.misc moderator, came back over USENET, and eventually wound up at Bob's company. Round trip: ~10,000 miles. Being a cool kinda student sysadmin dude, Bob ran the new version of Crack when it arrived. When it immediately churned out the root password on his machine, he damn near fainted... The moral of this story is: never use the same password in two different places, and especially on untrusted systems (like MUDs). _1.10. What's the easiest way to annoy a veteran MUD user?_ Demand something. Whine. Follow them around. Page or tell them over and over after they've asked you to stop. In combat MUDs, steal from corpses of things they just killed. _1.11. What's the easiest way to be a mean veteran MUD user?_ Don't give help to the new players. Kill them, ignore them, shout "get a description" at them. These are the best ways to kill off MUDding in general, actually. _1.12. What should I _not_ do in terms of player interaction?_ You shouldn't do anything that you wouldn't do in real life, even if the world is a fantasy world. The important thing to remember is that it's the fantasy world of possibly hundreds of people, and not just yours in particular. There's a human being on the other side of each and every wire! Always remember that you may meet these other people some day, and they may break your nose. People who treat others badly gradually build up bad reputations and eventually receive the NO FUN Stamp of Disapproval. The jury is still out on whether MUDding is "just a game" or "an extension of real life with gamelike qualities," but either way, treat it with care. _1.13. Is MUDding a game, or an extension of real life with gamelike qualities?_ It's up to you. Some jaded cynics like to laugh at idealists who think it's partially for real, but we personally think they're not playing it right. Certainly the hack-'n-slash stuff is only a game, but the social aspects may well be less so. _1.14. What common commands are used on MUDs?_ Most MUDS have a core of commands which players use to move around and interact with each other. For instance, there are commands for interacting with other players, like _say_ (or sometimes _"_), and other commands like _look_, _go_, etc. In TinyMUD, there are commands like _home_ (which always places you in your home -- remember that), _:_ (pose -- try it), etc., which allow you to do stuff inside the database. Commands prefixed by a _@_ (generally) allow you to change the database! Commands like _@describe_, _@create_, _@name_, _@dig_ and _@link_ allow you to expand the universe, change it, or even, perhaps, _@destroy_ it, under certain conditions. In LPMUDs, none of those apply; in order to edit the universe, you have to attain Wizardhood or be the God of the MUD. Whatever the case, these building commands are beyond the scope of this little sheet -- find the documentation for whatever MUD you're playing with and consume it avidly. Most MUDs have documentation on-line, although better documentation can be gotten via ftp from other sites. Ask around, or try looking on ftp.tcp.com, or ftp.math.okstate.edu in /pub/muds/misc. _1.15. I know what's going on now! What's next?_ Now is the time when you should be most careful. Within reason, don't be afraid to ask questions of other players. _1.16. Who should I ask for help?_ Wizards (see the glossary section) are usually helpful; if you know a wizard to be a wizard, then you can usually ask them a question or two. Make sure they're not busy first. Also, players who have been logged on for a long time (which you can check using the _WHO_ command) are often helpful, as they are usually the veterans who've seen it all before. In combat MUDs, asking relatively high level characters is usually the way to find things out. _1.17. What if I'm completely confused and am casting about for a rope in a vast, churning wilderness of chaos and utter incomprehension?_ Ask a friend to help you. Don't post anything in any newsgroup. Just take it slow, one step at a time, smoothing over the things you don't understand by reading manuals (i.e. man telnet), asking local help, or trying to find people who use MUDs who are at your site. _1.18. What USENET newgroups are devoted to MUDs?_ There are several USENET newsgroups associated with MUDs. The first (and least used) is alt.mud. When it got popular, the newsgroup rec.games.mud was then created, and when it got too noisy and chaotic, a few new groups were split off of the main one (rec.games.mud is no longer a real newsgroup - all of its volume went to rec.games.mud.misc). The current newsgroups are: rec.games.mud.admin Postings pertaining to the administrative side of MUDs. rec.games.mud.announce moderated group, where announcements of MUDs opening, closing, moving, partying, etc are posted. rec.games.mud.diku Postings pertaining to DikuMUDs. rec.games.mud.lp Postings pertaining to LPMUDs. rec.games.mud.misc Miscellaneous postings. rec.games.mud.tiny Postings pertaining to the Tiny* family of MUDs. If you feel you must post something to USENET, please do it in the group where it best belongs - no posts about TinyMUSH in the Diku group, no questions about an LPMUD in the Tiny group, etc. _1.19. Are there any MUD URLs?_ Several; a good start is Lydia Leong's MUD Resource Collection (http://www.cis.upenn.edu/~lwl/mudinfo.html). Also try the Aragorn server (http://aragorn.uio.no/). If you know of any that you'd like to see included here, let me know. _1.20. How do I start my own MUD?_ First, you need to pick a server. You'll have to figure out how to compile it, get it running, and you'll need to know how to _keep_ it running, which usually involves some programming skills, generally in C, and a good deal of time. Of course, you also need to be well versed in the ways and commands of that particular MUD server, and you'll probably need help running the place from a few of your friends. Don't forget that you'll have to have a machine to run it on, and the resources with which to run it. Most MUDs use anywhere from 5 to 90 megs of disk space, and memory usage can be anything from 1 to 35 megs. A good rule of thumb is to first ask around for specifics on that server; average muds need around 25 megs of disk space for everything, and about 10 megs of memory, although the exact numbers vary widely. _NOTE:_If you don't _explicitly own_ the machine you're thinking about right now, you had better get the permission of the machine owner before you bring up a MUD on his computer. MUDs are not extremely processing- consumptive, but they do use up some computing power. You wouldn't want people plugging in their appliances into the outlets of your home without your permission or knowledge, would you? Glossary of MUD Terms _1.21. What was the first MUD?_ MUD1, written by Richard Bartle and Roy Trubshaw, back in 1979-80, is generally accepted as the first MUD. Sceptre was developed independently about the same time as MUD1, and so has influenced some mud servers since then. TinyMUD Original, the first of the Tiny- family of muds, was written in August 1989. A more complete chronology of MUDs is being gathered - a good starting place is http://www.ccs.neu.edu/home/lpb/muddex.html. _1.22. What is a bot?_ A bot is a computer program which logs into a MUD and pretends to be a human being. Some of them, like Julia, are pretty clever -- legend has it that Julia's fooled people into believing that she's human. Others have less functionality. The most common bot program is the Maas-Neotek model. _1.23. What's a clueless newbie?_ A newbie is someone who has only recently begun to participate in some kind of activity. When we're born, we're all life newbies until we get experience under our belts (or diapers, whatever). You're a clueless newbie until you've got the hang of MUDding, basically. _1.24. What is a cyborg?_ A cyborg is defined as 'part man, part machine.' In the MUD world, this means that your client is doing some of the work for you. For instance, you can set up many clients to automatically greet anyone entering the room. You can also set up clients to respond to certain phrases (or _triggers_). Of course, this can have disastrous consequences. If Player_A sets his client up to say hi every time Player_B says hi, and Player_B does likewise, their clients will frantically scream hi at each other over and over until they manage to escape. Needless to say, runaway automation is very heavily frowned upon by anyone who sees it. If you program your client to do anything special, first make sure that it cannot go berserk and overload the MUD. _1.25. What's a dino?_ A dino is someone that has been around for a very long time (cf. _dinosaur_). These people tend to reminisce nostalgically about dead or nonexistent MUDs which were especially fun or interesting. _1.26. What is a flame?_ Flaming is when someone shouts at another person in a vain attempt to convince them that whatever that other person said or believes in is unconditionally wrong or stupid. Avoid getting into flame wars, and if flamed, laugh it off or ask someone else what you did wrong. _1.27. What is a furry?_ A furry is an anthropomorphic intelligent animal. If you've ever seen Zoo-bilee Zoo on The Learning Channel, you know what I mean. Furries are not unique to MUDdom - they originated in comics, and can usually be found at comic or animation conventions and the like. Generally, any MUD character which has fur and is cute is deemed a furry. Most furries hang out on FurryMUCK, naturally. _1.28. What is OOC/IC?_ On many role-playing MUDs, you may see these terms quite often. The stand for Out-Of-Character and In-Character, respectively. They're used by players to note when they're really roleplaying, or not. _1.29. What is a log?_ Certain client programs allow logs to be kept of the screen. A time- worn and somewhat unfriendly trick is to entice someone into having TinySex with you, log the proceedings, and post them to rec.games.mud.* and have a good laugh at the other person's expense. Logs are useful for recording interesting or useful information or conversations, as well. _1.30. What is Maving?_ Mav is an old TinyMUDder who sometimes accidentally left a colon on the front of a whisper, thus directing private messages to the whole room. The meaning of the verb has changed to include making any say/whisper/page/pose typing confusion. _1.31. What is net lag?_ The Internet (the network which connects your computer to mine) is made up of thousands of interconnected networks. Between your computer and the computer which houses the MUD, there may be up to 30 gateways and links connecting them over serial lines, high-speed modems, leased lines, satellite uplinks, etc. If one of these gateways or lines crashes, is suddenly overloaded, or gets routing confused, you may notice a long time of lag time between your imput and the MUD's reception of that input. Computers which are nearer to the computer running the MUD are less susceptible to netlag. Another source of lag is if the computer which hosts the MUD is overloaded. When netlag happens, it is best to just patiently wait for it to pass. _1.32. What's player killing?_ The answer to this question varies widely. On most combat-oriented MUDs, such as LPMUD and Diku, player killing is taken quite seriously. On others, it's encouraged. On most TinyMUDs, as there is little to no combat system, player killing is sometimes employed as a means of showing irritation at another player, or merely to show emphasis of something said (usually, it means "and I really mean it!"). It's best to find out the rules of the MUD you're on, and play by them. Obviously, this _really_ means character killing, not player killing - there haven't been any cases of homicidal maniacs killing MUDDers for using up all the terminals, yet. _1.33. What is spam?_ Spamming, derived from a famous Monty Python sketch, is the flooding of appropriate media with information (such as repeated very long _say_ commands). Unintentional spamming, such as what happens when you walk away from your computer screen for a few minutes, then return to find several screenfuls of text waiting to scroll by, is just a source of irritation. Intentional spamming, such as when you repeat very long _say_ commands many times, or quote /usr/dict/words at someone, is usually frowned on, and can get you in trouble with the MUD administration. _1.34. What is TinySex?_ TinySex is the act of performing MUD actions to imitate having sex with another character, usually consentually, sometimes with one hand on the keyboard, sometimes with two. Basically, it's speed-writing interactive erotica. Realize that the other party is not obligated to be anything like he/she says, and in fact may be playing a joke on you (see log, above). _1.35. What is a 'Wizard' or 'God'?_ Gods are the administrators who own the database. In most MUDs, Wizards are barely distinguishable from Gods - they're just barely one step down from the God of the MUD. An LPMUD Wizard is a player who has won the game, and is now able to create new sections of the game. Wizards are very powerful, but they don't have the right to do whatever they want to you; they must still follow their own set of rules, or face the wrath of the Gods. Gods can do whatever they want to whomever they want whenever they want - it's their MUD. If you don't like how a God acts or lets his Wizards act toward the players, your best recourse is to simply stop playing that MUD, and play another. There are frequently different "levels" of Wizards or adminstrative types; each MUD is different, so be sure to check to see how the local hierarchy operates. A more appropriate name for wizards would probably be _Janitor_, since they tend to have to put up with responsibilities and difficulties (for free) that nobody else would be expected to handle. Remember, they're human beings on the other side of the wire. Respect them for their generosity. _________________________________________________________________ This posting has been generated as a public service, but is still copyrighted 1996 by Jennifer Smith. If you have any suggestions, questions, additions, comments or criticisms concerning this posting, contact Jennifer Smith, aka Moira (jds@math.okstate.edu). Other Frequently Asked Questions (FAQ) postings contain information dealing with clients, servers, RWHO, and FTP sites. While these items aren't necessary, they are quite useful. I'd also like to thank cthonics (felixg@coop.com) for his help in writing these FAQs, ashne and Satoria for their help, and everyone else for helpful comments and suggestions. Thanks again to Alec Muffett (aem@aberystwyth.ac.uk) of alt.security. The most recent versions of these FAQs are archived on ftp.math.okstate.edu in pub/muds/misc/mud-faq, plus on rtfm.mit.edu in the news.answers archives. HTML-ized versions are available at URL http://www.math.okstate.edu/~jds/mudfaqs.html. Have fun! - Moira _________________________________________________________________ Jennifer Smith / jds@math.okstate.edu -- Jennifer Smith jds@math.okstate.edu On MUDs: Moira, etc. | But still I fear and still Here, have a clue. Take two, they're small. | I dare not Laugh at the Madman. From csus.edu!csulb.edu!hammer.uoregon.edu!news1.mpcs.com!nntp.primenet.com!howland.erols.net!math.ohio-state.edu!news.physics.uiowa.edu!nntp.ksu.edu!news.cis.okstate.edu!jds Tue Dec 3 07:58:26 1996 Path: csus.edu!csulb.edu!hammer.uoregon.edu!news1.mpcs.com!nntp.primenet.com!howland.erols.net!math.ohio-state.edu!news.physics.uiowa.edu!nntp.ksu.edu!news.cis.okstate.edu!jds From: jds@math.okstate.edu (Jennifer "Moira" Smith) Newsgroups: rec.games.mud.announce,rec.games.mud.misc,news.answers,rec.answers Subject: [rec.games.mud]: FAQ #2/3: MUD Clients and Servers Supersedes: Followup-To: rec.games.mud.misc Date: 16 Nov 1996 07:00:04 GMT Organization: Oklahoma State University, Stillwater OK Lines: 1149 Approved: news-answers-request@MIT.Edu,rgm-announce-request@theurgy.digex.net Expires: 14 Dec 1996 07:00:02 GMT Message-ID: References: Reply-To: jds@math.okstate.edu NNTP-Posting-Host: littlewood.math.okstate.edu Summary: mud clients and servers, descriptions and locations of source Keywords: muds clients servers ftp Originator: jds@littlewood.math.okstate.edu Xref: csus.edu rec.games.mud.announce:2602 rec.games.mud.misc:24303 news.answers:87457 rec.answers:25589 Archive-name: games/mud-faq/part2 FREQUENTLY ASKED QUESTIONS: MUD Clients and Servers This is part 2 in a 3 part series of FAQs. $Id: mudfaq-p2.html,v 1.7 1996/10/28 16:51:43 jds Exp jds $ _Disclaimer:_This document may be seen to be biased towards TinyMUDs. This is because the maintainer mainly plays those types of servers, not because she thinks they are inherently better or worse than other types of servers. However, this document is meant to be generalized and useful for all MUDdom, and so corrections and contributions are always welcome. Table of Contents * Client Information + 2.1. What is a client? + 2.2. Where do I get clients? + 2.3. What operating systems do clients run on? + 2.4. Is there anything wrong with running a client? + 2.5. What different clients are available? [Client List] * Glossary of Client terms * Server Information + 2.6. What is a server? + 2.7. Where do I get servers? + 2.8. What operating systems to servers run on? + 2.9. Is there anything wrong with running a server? + 2.10. What different servers are available? [Server List] * General Information + 2.11. What do I do if my client/server won't compile? + 2.12. Should I read the documentation of whatever client or server I select? + 2.13. What is FTP, and how do I use it? Client Information _2.1. What is a client?_ Clients are programs, usually written in C, that connect up to servers. Telnet is one such client program. Many clients written for MUDs have special added bonus features through which they filter the output; most, for instance, separate your input line from the output lines and wraps words after 80 columns. Some also have a macro- writing capability which allows the user to execute several commands with just a few keypresses. Some allow you to highlight output coming from certain players or suppress it altogether. Still other clients make the sometimes tedious task of building new areas a breeze. _2.2. Where do I get clients?_ Listed below is a list of clients, and a site or two where they can be ftped from. If the site is down, your best bet is to ask around. In general, ftp.tcp.com and ftp.math.okstate.edu are good places to look. Directions for how to ftp and unarchive clients are at the end of this FAQ. _2.3. What operating systems do clients run on?_ Most use some variant of Unix, either BSD or SysV. Some run under VMS with either MultiNet or Wollongong networking, and there's also one for IBM VM. There are, of course, many new clients for Macintoshes and for PCs running Winsock. _2.4. Is there anything wrong with running a client?_ Not usually. Clients can be large when compiled, especially if they have lots of nifty features. They don't take up much CPU time at all. It is recommended that you ask your friendly systems administrator or other machine-responsible person if it's okay for you to install one on the system, if only for the reason that someone else might already have done so, and you might be able to save space by sharing with them. If there's a no games policy at your site, don't try to sneak by it with a client -- their activities are easily detectable. Be good. _2.5. What different clients are available?_ Here's a reasonably accurate listing of available clients. Please note that I have not tested each of these, and they're not guaranteed to work for you. If your favorite client isn't listed here, please drop a short note describing the client's features and where it can be ftp'd from to jds@math.okstate.edu. You may also be interested in John Daub's page of Macintosh mud resources, at http://www.eden.com/~hsoi/mud/. The following clients are detailed below. Directions for how to ftp and unarchive clients and servers can be found at the end of this FAQ. _Unix Clients_ TinyTalk, TinyFugue, TclTT, VT, LPTalk, SayWat, PMF, TinTin, TinTin++, TUsh, LPmudr, Muddle _Emacs Clients_ MUD.el, TinyTalk.el, LPmud.el, CLPmud.el, MyMud.el _VMS Clients_ tfVMS, TINT, TINTw, DINK, FooTalk _PC Winsock Clients_ VWMud, WinWorld, MUTT, MudWin, MUDSock, Pueblo, zMUD, AvPlay, GMUD, VTW, MUSHClient, Phoca, SimpleMU, WinTin, NTTinTin _Macintosh Clients_ MUDDweller, Mudling, MacMOOSE _Misc Clients_ REXXTALK, RXLPTalk, MUDCaller, BSXMUD Clients _________________________________________________________________ Unix Clients TinyTalk Runs on BSD or SysV. Latest version is 1.1.7GEW. Designed primarily for TinyMUD-style muds. Features include line editing, command history, hiliting (whispers, pages, and users), gag, auto-login, simple macros, logging, and cyberportals. ftp.math.okstate.edu:/pub/muds/clients/UnixClients parcftp.xerox.com:/pub/MOO/clients ftp.tcp.com:/pub/mud/Clients TinyFugue Runs on BSD, SysV, and OS/2. Latest version is 3.5alpha10. Commonly known as 'tf'. Designed primarily for TinyMUD-style muds, although will run on LPMUDs and Dikus. Features include regexp hilites and gags, auto-login, macros, line editing, screen mode, triggers, cyberportals, logging, file and command uploading, shells, and multiple connects. ftp.math.okstate.edu:/pub/muds/clients/UnixClients ftp.tcp.com:/pub/mud/Clients TclTT Runs on BSD. Latest version is 0.9. Designed primarily for TinyMUD-style muds. Features include regexp hilites, regexp gags, logging, auto-login, partial file uploading, triggers, and programmability. ftp.white.toronto.edu:/pub/muds/tcltt ftp.math.okstate.edu:/pub/muds/clients/UnixClients VT Runs on BSD or SysV. Latest version is 2.15. Useable for all types of muds. Features include a C-like extension language (VTC) and a simple windowing system. Also see VTW below. ftp.math.okstate.edu:/pub/muds/clients/UnixClients ftp.tcp.com:/pub/mud/Clients LPTalk Runs on BSD or SysV. Latest version is 1.2.1. Designed primarily for LPMUDs. Features include hiliting, gags, auto-login, simple macros, logging. ftp.math.okstate.edu:/pub/muds/clients/UnixClients SayWat Runs on BSD. Latest version is 0.30beta. Designed primarily for TinyMUD-style muds. Features include regexp hilites, regexp gags, macros, triggers, logging, cyberportals, rudimentary xterm support, command line history, multiple connects, and file uploading. ftp.math.okstate.edu:/pub/muds/clients/UnixClients PMF Runs on BSD. Latest version is 1.13.1. Usable for both LPMUDs and TinyMUD-style muds. Features include line editing, auto-login, macros, triggers, gags, logging, file uploads, an X-window interface, and ability to do Sparc sounds. ftp.lysator.liu.se:/pub/lpmud/clients ftp.math.okstate.edu:/pub/muds/clients/UnixClients TinTin Runs on BSD. Latest version is 2.0. Designed primarily for Dikus. Features include macros, triggers, tick-counter features, and multiple connects. ftp.math.okstate.edu:/pub/muds/clients/UnixClients TinTin++ Runs on BSD or SysV. Latest version is 1.5pl6. Derived and improved from TinTin. Additional features include variables, faster triggers, and a split screen mode. ftp.princeton.edu:/pub/tintin++/dist ftp.math.okstate.edu:/pub/muds/clients/UnixClients TUsh Runs on BSD or SysV. Latest version is 1.74. Features include hiliting, triggers, aliasing, history buffer, and screen mode. ftp.math.okstate.edu:/pub/muds/clients/UnixClients LPmudr Runs on BSD or SysV. Latest version is 2.7. Designed primarily for LPMUDs. Features include line editing, command history, auto-login and logging. ftp.math.okstate.edu:/pub/muds/clients/UnixClients Muddle Runs on BSD, SysV, NeXT Mach, Irix, Win95, and WinNT. Latest version is 2.0. Written for use with the Mordor server. Features include multiple logins, triggers, and some programming capabilities. parker.bio.uci.edu:/pub/mordor http://moria.bio.uci.edu Emacs Clients MUD.el Runs on GNU Emacs. Usable for TinyMUD-style muds, LPMUDs, and MOOs. Features include auto-login, macros, logging, cyberportals, screen mode, and it is programmable. parcftp.xerox.com:/pub/MOO/clients ftp.math.okstate.edu:/pub/muds/clients/UnixClients TinyTalk.el Runs on GNU Emacs. Latest version is 0.5. Designed primarily for TinyMUD-style muds. Features include auto-login, macros, logging, screen mode, and it is programmable. ftp.tcp.com(128.95.10.106):/pub/mud/Clients ftp.math.okstate.edu:/pub/muds/clients/UnixClients LPmud.el Runs on GNU Emacs. Designed primarily for LPMUDs. Features include macros, triggers, file uploading, logging, screen mode, and it is programmable. ftp.lysator.liu.se:/pub/lpmud/clients ftp.math.okstate.edu:/pub/muds/clients/UnixClients CLPmud.el Runs on GNU Emacs. Designed primarily for LPMUDs. Similar to LPmud.el, but with the added capability for remote file retrieval, editing in emacs, and saving, for LPMud wizards. mizar.docs.uu.se:/pub/lpmud MyMud.el Runs on GNU Emacs. Latest version is 1.31. Designed primarily for LPMUDs and Dikus. Features include screen mode, auto-login, macros, triggers, autonavigator, and it is programmable. ftp.math.okstate.edu:/pub/muds/clients/UnixClients ftp.tcp.com:/pub/mud/Clients VMS Clients tfVMS VMS version of TinyFugue (see above). Uses Wollongong networking. Latest version is 1.0b2. ftp.math.okstate.edu:/pub/muds/clients/VMSClients TINT Runs on VMS with MultiNet networking. Latest version is 2.2. Designed primarily for TinyMUD-style muds. Features include hiliting (whispers, pages, users), gags, file uploading, simple macros, screen mode. See also TINTw. ftp.math.okstate.edu:/pub/muds/clients/VMSClients TINTw Runs on VMS with Wollongong networking. See TINT. ftp.math.okstate.edu:/pub/muds/clients/VMSClients ftp.tcp.com:/pub/mud/Clients DINK Runs on VMS with either Wollongong or MultiNet networking. Similar to TINT. No longer supported by the author. ftp.math.okstate.edu:/pub/muds/clients/VMSClients ftp.tcp.com:/pub/mud/Clients FooTalk Runs on VMS with MultiNet networking and BSD Unix. Primarily designed for TinyMUD-style muds. Features include screen mode, and it is programmable. See RispTalk below. ftp.math.okstate.edu:/pub/muds/clients/VMSClients ftp.math.okstate.edu:/pub/muds/clients/UnixClients PC Winsock Clients VWMud Runs on Windows 3.1 and above using Winsock. Latest version is 1.20. A 32-bit version is now available, version 2.0. Features include ANSI color, macros, triggers, and more. http://www.computek.net/public/vaughan papa.indstate.edu:/winsock-l/mud ftp.microserve.com:/pub/msdos/winsock WinWorld Runs on MS Windows using Winsock. Latest version is 0.4d. Features include auto-login, multiple connects, command history, logging, and more. ftp.mgl.ca:/pub/winworld papa.indstate.edu:/winsock-l/mud MUTT Runs on MS Windows using Winsock. Latest version is 01i. Name stands for Multi-User Trivial Terminal. Features include scripting, multiple connects, triggers, macros, logging, etc. ftp.graphcomp.com:/msw/mutt papa.indstate.edu:/winsock-l/mud MudWin Runs on MS Windows using Winsock. Latest version is 1.06. Features include command history, simple macros, and logging. ftp.microserve.com:/pub/msdos/winsock papa.indstate.edu:/winsock-l/mud MUDSock Runs on MS Windows using Winsock. Works mainly with TinyMUCK, but should work with other MUDs. Still in beta. wings.network.com:/pub/mosaic/ http://www.umn.edu/nlhome/m279/fayxx001 Pueblo Runs on MS Windows95 and Windows/NT using Winsock. Latest version is 1.0. Features full support for interactive hypertext (IHTML), ANSI, 3D graphics (VRML), 2D graphics (GIF and JPEG), audio (MIDI and WAV). Brings up a complete hierarchy of active MUDs. Features include logging, command history, line editing, auto-login, and simple macros. http://www.chaco.com/pueblo/ zMUD Runs on MS Windows95 using Winsock. Latest version is 4.22. Based on ideas from TinTin++. Features include macros, triggers, multiple-connects, logging, command history, and more. http://www.trail.com/~zugg/zmud.html AvPlay Runs on MS Windows using Winsock. Latest version is 4.21. Designed for the DikuMUD Avalon, but should be able to run on most muds. Features macros, triggers, logging, command history, colors, etc. ftp.avalon.co.uk:/AvPlay_Windows/ GMUD aka Generic MUD client. Runs on MS Windows 3.1 with Win32s, or on Windows NT or Windows 95, with Winsock. Latest version is 1.9b. Features triggers, macros, logging, multiple connects, and more. papa.indstate.edu:/winsock-l/mud VTW Based on VT 2.15 for Unix. Runs on MS Windows with Win32s, Windows NT or Windows 95 with Winsock. Latest version is 1.1 beta. http://ezlink.com/~tekhedd MUSHClient Runs on Win95 or WinNT, or Win3.x with Win32s, with Winsock. Latest version is 1.04. Designed for TinyMUSHes, but will work on all types of muds. Features include an MDI interface, multiple connects, auto-login, triggers, macros, hilites, command history and editing, logging, and much more. connexus.apana.org.au:/pub/pennmush pennmush.tinymush.org:/pub/PennMUSH/Win32Binaries Phoca Runs on Windows 3.1 and above with Winsock. Latest version is 1.0. Fairly feature-free, unless you buy the commercial version. ftp.phocat.com:/pub/phoca ftp.cts.com:/pub/farallon http://www.phocat.com/phoca/phoca.html SimpleMU Runs on Windows 3.1 and above with Winsock. Latest version is 1.53b. Designed for TinyMUSHes. Features include ANSI color, multiple connects, auto-login, triggers, macros, hilites, command history and editing, logging, quoting off-line @mail and more. http://www.rahul.net/galen/simple.html WinTin Port of TinTin-III to MS Windows 3.1x. Works only with some Winsock TCP/IP stacks (specifically, it DOES work with Microsoft's tcp-ip32, but does not work with Trumpet). ftp.cs.cmu.edu:/afs/cs/user/johnmil/ftp NTTinTin Port of TinTin-III to Windows NT with Winsock. ftp.cs.cmu.edu:/afs/cs/user/johnmil/ftp Macintosh Clients MUDDweller Runs on any Macintosh. Latest version is 1.2. Connects to a MUD through either the communications toolbox or by MacTCP. Usable for both LPMUDs and TinyMUD-style muds. Current features include multiple connections, a command history and a built-in MTP client for LPMUDs. rudolf.ethz.ch:/pub/mud mac.archive.umich.edu:/mac/util/comm ftp.tcp.com:/pub/mud/Clients Mudling Runs on any Macintosh. Latest version is 0.9b26. Features include multiple connections, triggers, macros, command line history, separate input and output windows, and a rudimentary mapping system. imv.aau.dk:/pub/Mudling ftp.math.okstate.edu:/pub/muds/clients/misc MacMOOSE Runs on Macintoshes using MacTCP. Latest version is 2.0a3. Designed to make it easier to program MOOs and MOOSEs. ftp.media.mit.edu:pub/asb/MacMOOSE/ http://asb.www.media.mit.edu/people/asb/MacMOOSE/. Misc Clients REXXTALK Runs on IBM VM. Latest version is 2.1. Designed primarily for TinyMUD-style muds. Features include screen mode, logging, macros, triggers, hilites, gags, and auto-login. Allows some IBM VM programs to be run while connected to a foreign host, such as TELL and MAIL. ftp.math.okstate.edu:/pub/muds/clients/misc RXLPTalk Runs on IBM VM, and anything that uses REXX. Partially derivative of REXXTALK. Latest version is 6.0. Designed for use with LPMuds. Features include hilites, gags, logging, macros, and multiple connects. eenuix.ee.usm.maine.edu:/pub/virtreality/mainframe ftp.math.okstate.edu:/pub/muds/clients/misc MUDCaller Runs under MSDOS. Latest version is 2.50. Requires an Ethernet card, and uses the Crynwr Packet drivers. Does NOT work with a modem. (If you telnet in MSDOS, you can probably use this.) Features include multiple connections, triggers, command-line history, scrollback, logging, macros, and separate input and output windows. ftp.tcp.com:/pub/mud/Clients ftp.math.okstate.edu:/pub/muds/clients/misc oak.oakland.edu:/pub/msdos/pktdrvr BSXMUD Clients These clients run on various platforms, and allow the user to be able to see the graphics produced by BSXMUDs. BSXMUDs are generally LPMUDs (but not necessarily) who have been hacked to enable the sending of polygon graphics coordinates to BSXclients, thus letting you play a graphic MUD instead of just a text-based one. For Amiga: modem or TCP/IP - AmigaBSXClient2_2.lha For PC: requires a modem - msclient.lzh AND x00v124.zip For X11: sources, version 3.2 - bsxclient3_8c.tar.Z For Sun4: binary - client.sparc.tar.Z Also available are programs to custom-draw your own graphics for a BSXMUD: - muddraw.tar.gz, bsxdraw.zoo ftp.lysator.liu.se:pub/lpmud/bsx ftp.math.okstate.edu:/pub/muds/BSXstuff _________________________________________________________________ Glossary of Client Terms Auto-login Automatically logs into the game for you. Hiliting Allows boldface or other emphasis to be applied to some text. Often allowed on particular types of output (e.g. whispers), or particular players. "Regexp" means that UNIX-style regular expressions can be used to select text to hilite. Gag Allows some text to be suppressed. The choice of what to suppress is often similar to hiliting (players or regular expressions). Macros Allows new commands to be defined. How complex a macro can be varies greatly between clients; check the documentation for details. Logging Allows output from the MUD to be recorded in a file. Cyberportals Supports special MUD features which can automatically reconnect you to another MUD server. Screen Mode Supports some sort of screen mode (beyond just scrolling your output off the top of the screen) on some terminals. The exact support varies. Triggers Supports events which happen when certain actions on the MUD occur (e.g. waving when a player enters the room). (This can nearly always be trivially done on programmable clients, even if it isn't built in.) Programmable Supports some sort of client-local programming. Read the documentation. Some of these clients are more featured than others, and some require a fair degree of computer literacy. TinyTalk and TinyFugue are among the easiest to learn for unix systems; Tcltt and VT are more professional. Caveat Emptor. Since many MUDders write their own clients, this list can never be complete. As above, ask around. _________________________________________________________________ Server Information _2.6. What is a server?_ A server is a program which accepts connections, receives data, mulls it over, and sends out some output. In the MUD world, the server keeps track of the database, the current players, the rules, and sometimes the time (or the _heartbeat_). Servers are usually very large C programs which maintain a small-to-enormous database of the objects, rooms, players and miscellany of the MUD. _2.7. Where do I get servers?_ Below (see question 2.10)there is a list of different types of servers, complete with ftp sites on which they can be found. Be aware that this list is far from complete, as new servers pop up constantly, and the existing ones are still being developed. _2.8. What operating systems to servers run on?_ Most servers require some form of UNIX, be it BSD or SysV. A few servers are being ported to VMS nowadays, and there are a few which have versions for MS-DOS and Amigas. _2.9. Is there anything wrong with running a server?_ Because of their size and their constant computational activities, servers can be extremely CPU-intensive and can even be crippling to any other work done on that computer. Even if they're not CPU-intensive, most MUDs can take up a fair amount of disk space - anywhere from 10 to 90 megs, which could impact the other users on the machine. Do not ever run a MUD server on a machine illicitly or without express permission from the person responsible for the machine. Many universities and companies have strict policies about that sort of behavior which you don't want to cross. Of course, people who don't know any better start up illicit MUDs all the time. Apart from the possibility of losing all your work and energy to one press of a sysadmin's finger, there's no harm done to the player. But we must stress: running a MUD where you shouldn't can get you into a whole new world of hurt. Don't take the chance, it's not worth it. _2.10. What different servers are available?_ There are probably as many MUD server types as there are MUDs. Since everyone has their own opinions as to what MUDs should be like, and since the server source can be edited, most MUDs have site-specific fixtures in them. However, there are a few main protoMUDs (also called 'vanilla versions' because they haven't been 'flavored' yet). Note that this list is not complete, and that it may contain errors in fact or judgement, but is deemed pretty much right as of this writing. Corrections/additions to jds@math.okstate.edu are welcomed. There are essentially three groups of muds: * Combat-oriented MUDs (LP/Diku/etc, originally) * Social-oriented MUDs (TinyMUD & its descendants, etc) * Miscellaneous (mixture of the above, or hard to classify) The majority of the muds in the miscellaneous category are not combat-oriented muds at all, and indeed many take after TinyMUD in most things. However, as these muds are not a direct derivative of the original TinyMUD code, I've stuck them in their own category. The authors listed for each server are very probably not the people currently working on that code. To find out who's currently in charge of the code, either ftp the latest version and look for a README file, or ask around. A note on the term _combat-oriented_: this generally means that combat is an inherent part of the culture of the mud. A flight-simulator could be called a combat-oriented game, just as truely as your typical shoot-em-up game could be. A _social-oriented_ mud has a different focus, one dependent either on roleplaying social interactions (which MAY include combat!), or on not roleplaying at all, but merely talking with friends or other such benign things. It should be emphasized that simply because a given server is listed in the combat-oriented area, it does not necessarily follow that it _must_ be a combat-oriented MUD. Most servers are fairly flexible, and can be used for social and combat uses alike, as well as for business and education. These categories are getting rather dated, and may be changed at some point in the future for ones that make more sense. Detailed listings of the following servers are below. Directions for how to ftp and unarchive servers can be found at the end of this FAQ. Combat-Oriented MUDs MUD, AberMUD, LPMUD, DGD, DikuMUD, YAMA, UriMUD, Ogham, CircleMUD, AmigaMUD, Realms Social-Oriented MUDs TinyMUD, TinyMUCK v1.*, TinyMUSH, PennMUSH, AlloyMUSH, TinyMUCK v2.*, TinyMUSE, TinyMAGE, MUG, TeenyMUD, TinyMUX Misc MUDs UberMUD, MOO, LambdaMOO, SMUG, UnterMUD, Mordor, COOLMUD _________________________________________________________________ Combat-Oriented MUDs MUD The original, by Richard Bartle and Roy Trubshaw, written back in 1978. An advanced version of MUD1 is now running on CompuServe under the name of "British Legends". The only MUD2 still running is at Iplay Online at iplay.interplay.com. Source generally not available. AberMUD One of the first adventure-based MUDs. Players cannot build. In later versions, a class system was added, and wizards can build onto the database. It's named after the university at which it was written, Aberystwyth. Latest version is 5.21.5. Supports all the usual in combat game design, including BSX graphics and MudWHO. Not too big, and it will run under BSD and SYSV. Amiga TCP/IP support now included. Author, contact address, and mailing list address is A.Cox@swan.ac.uk. sunacm.swan.ac.uk:/pub/misc/AberMUD5/SOURCE LPMUD The most popular combat-oriented MUD. Players cannot build. Be warned, though: LPMUD servers version 3.* themselves are very generic - all of the universe rules and so forth are written in a separate module, called the mudlib. Most LPMUDs running are written to be some sort of combat system, which is why I've classified them here, but they don't have to be! Wizards can build onto the database, by means of an object-oriented C-like internal language called LP-C. It's named after its primary author, Lars Pensj|. Latest version is 3.2, aka Amylaar. Fairly stable, and size varies from medium to large. Driver (server) versions seem to have split into several main variants, not counting possible mudlibs (databases) available. Amylaar, CD, and MudOS are the current favorites. For further information, email to amylaar@meolyon.hanse.de. There is a port of 3.1.2 for Amigas, called amud, now included in LPMUD v3.2. For further information email to mateese@ibr.cs.tu-bs.de. See the rec.games.mud.lp FAQ for more info. ftp.lysator.liu.se:/pub/lpmud ftp.cd.chalmers.se:/pub/lpmud/cdlib ftp.tu-bs.de:/pub/games/lpmud ftp.ccs.neu.edu:/pub/mud/drivers/mudos There is a port of 3.1.2 for MSDOS, that requires at least a '386 to run. It accepts connections from serial ports. ftp.ccs.neu.edu:/pub/mud/drivers/lpmud/msdos DGD Written by Felix Croes. A reimplementation from scratch of the LPMUD server. It is disk-based, and thus uses less memory. It's also smaller and lacks many of the features of the other LPMUD servers, though it is capable of simulating most of those features in LPC. Many DGDs are simulating an LP, but there are several MUDs that now use DGD to simulate a MOO variant. The name stands for Dworkin's Generic Driver. Stable. Has been ported to the Atari ST, Commodore Amiga, Macintosh, Windows NT, and Windows 95. ftp.lysator.liu.se:/pub/lpmud/drivers/dgd ftp.ccs.neu.edu:/pub/mud/servers/dgd DikuMUD Newer than LPMud, and gaining in popularity. Almost identical from the players' point of view. Uses a guild system instead of a straight class system. Wizards can add on to the database, but there is no programming language, as in LP. It's named after the university at which it was written, Datalogisk Institut Koebenhavns Universitet (Dept. of Datalogy, University of Copenhagen). coyote.cs.wmich.edu:/pub/Games/DikuMUD Some Diku mud variants (Merc 2.2 and Envy 2.0) have been ported to Windows 95 and Windows NT. ftp.netcom.com:/pub/jw/jwo YAMA PC mud writing system, using waterloo wattcp. Runs on a 640K PC/XT or better. Runs best with about a 1Mb ram disk, but is fine without. A separate windows version (yamaw) runs under windows and allows you to run a mud on a 286 or higher without taking over the machine. sunacm.swan.ac.uk:/pub/misc/YAMA UriMUD Developed from an LPMud2.4.5, the code structure is very similar. Features include better speed, flexibility, stronger LPC, and the ability to handle multiple mudlibs under one parser. Latest version is 2.5. urimud.isp.net:/urimud/src Ogham From the players' point of view, similar to LPMUD. No programming language or database, as server and mudlib compile together to form a single binary executable. Latest version is 2.5.0. ftp.ccs.neu.edu:/pub/mud/servers/ogham ftp.math.okstate.edu:/pub/muds/servers CircleMUD Derivative of DikuMUD Gamma v0.0. Developed by Jeremy Elson (jelson@cs.jhu.edu). Less buggy and tighter code all in all. Latest version is 2.20. ftp.cs.jhu.edu:/pub/CircleMUD sunsite.unc.edu:/pub/Linux/games/muds ftp.math.okstate.edu:/pub/muds/servers AmigaMUD Written by scratch for Commodore Amiga computers. Includes custom client which supports graphics and sound. Disk based, fast programming language, standard scenario including built-in mail and bboards. Obtained from the Aminet ftp sites. ftp.wustl.edu:/pub/aminet/game/role/AMClnt.lha, AMSrv.lha Realms Written by Andy Baillie for Amiga systems. Primarily combat based with races and classes. There are some social commands but not that many. The database may be modified both online and offline. It is disk based and uses caching to allow it to run on less powerful machines. Contact realms@babylon5.demon.co.uk for more information. _________________________________________________________________ TinyMUD-style MUDs TinyMUD The first, and archetypical, socially-oriented MUD. It was inspired by and looks like the old VMS game Monster, by Rich Skrenta. Players can explore and build, with the basic @dig, @create, @open, @link, @unlink, @lock commands. Players cannot teleport, and couldn't use @chown or set things DARK until later versions. Recycling didn't exist till the later versions, either. It's called 'Tiny' because it is - compared to the combat-oriented MUDs. Original code written by Jim Aspnes. Last known version is 1.5.5. Not terribly big, and quite stable. ftp.math.okstate.edu:/pub/muds/servers primerd.prime.com:/pub/games/mud/tinymud There is a PC port of TinyMUD, along with some extra code. It accepts connections from serial ports. ftp.tcp.com:/pub/mud/TinyMUD There is a modified version of TinyMUD called PRISM, that works for PCs, Atari STs, and most Unixes. It also comes with a internal BSX client for MSDOS. lister.cc.ic.ac.uk:/pub/prism TinyMUCK v1.* The first derivative from TinyMUD. Identical to TinyMUD, except that it added the concept of moveable exits, called @actions. Also introduced the JUMP_OK flag, which allows players to use @teleport, and @recycle, which TinyMUD later added. Its name, MUCK, is derived from MUD, and means nothing in particular. Original code written by Stephen White. Latest stable verion is 1.2.c&r, which brought TinyMUCKv1 up to date with later TinyMUD things. Not terribly big. ftp.math.okstate.edu:/pub/muds/servers TinyMUSH The second derivative from TinyMUD. Also identical to TinyMUD, with the addition of a very primitive script-like language. Introduced JUMP_OK like TinyMUCK, and has recycling, except it is called @destroy. Also introduced the concept of PUPPETs, and other objects that can listen. In later versions the script language was extended greatly, adding math functions and many database functions. In the latest major version, 2.0, it's gone to a disk-basing system as well. Its name, MUSH, stands for Multi-User Shared Hallucination. Original code written by Larry Foard. The latest non- disk-based version is PennMUSH (see below) 1.6.5, which is quite similar to 2.* from the user's point of view. Both the disk-based version and the non-disk-based version are being developed at the same time. TinyMUSH is more efficient in some ways than TinyMUD, but winds up being larger because of programmed objects. Version 2.* in general uses less memory but a great deal more disk space. TinyMUSH 2.* and PennMUSH 1.5* both run under BSD and SysV. Most recent version of TinyMUSH is 2.2.1. ftp.tinymush.org:/pub/mud/tinymush ftp.cis.upenn.edu:/pub/lwl primerd.prime.com:/pub/games/mud/tinymush ftp.tcp.com:/pub/mud/TinyMUSH There's also a port of 2.0.8p10 to Macintosh, currently at version 0.6.0b1. TinyMUSH/Mac 0.6.0b1 resides at http://www.metamage.com/mush/ PennMUSH See TinyMUSH above. PennMUSH is a non-disk-based version of TinyMUSH, and is quite similar from the user's point of view. The latest version is 1.6.5, and will run under both BSD and SysV Unix. pennmush.tinymush.org:/pub/PennMUSH/Source ftp.math.okstate.edu:/pub/muds/servers There's also a port of 1.6.0 to Windows 95 and Windows NT. Both executables and source are available for download. pennmush.tinymush.org:/pub/PennMUSH/Win32Binaries AlloyMUSH AlloyMUSH is based on an early beta of TinyMUSH 2.2. It has added ANSI color, zones, powers, building functions, debug output redirection, and more. Latest version is 1.1p1. http://www.cris.com/~jmcgrew/mush ftp.tinymush.org:/pub/mud/tinymush/src/alloy TinyMUCK v2.* TinyMUCKv1.* with a programming language added. The language, MUF (multiple user forth), is only accessible to people with the MUCKER flag. Changed the rules of the JUMP_OK flag somewhat, to where it's nice and confusing now. MUF is very powerful, and can do just about anything a wizard can. Original version 2.* code written by Lachesis. Latest version is 2.3b, with several varieties (FBMUCK and DaemonMUCK 0.14 the most common). The name doesn't mean anything. Can be quite large, especially with many programs. Mostly stable. ftp.tcp.com:/pub/mud/TinyMUCK TinyMUSE A derivative of TinyMUSH. Many more script-language extensions and flags. Reintroduced a class system, a-la combat-oriented MUDs. The name stands for Multi-User Simulation Environment. Latest version is 1.9f3. Fairly stable. mcmuse.mc.maricopa.edu:/muse/server eeunix.ee.usm.maine.edu:/pub/virtreality/servers/Tiny.servers/T inyMUSE TinyMAGE The bastard son of TinyMUSH and TinyMUCK. It combines some of MUSH's concepts (such as puppets, @adesc/@asucc, several programming functions, and a few flags) with TinyMUCK2.x. Interesting idea, really busted code. The name doesn't mean anything. Latest version is 1.1.2. ftp.tcp.com:/pub/mud/TinyMAGE MUG Derivative of TinyMUD 1.4.1. It's name stands for Multi-User Game. Powerful but awkward programming language, which is an extension of the user language; primitive notion of Puppets; inheritance; sane variable/property matching; arrays and dictionaries in hardcode. Somewhat non-standard and buggy in a few places. Requires gcc.2.4.5 or greater (or other good C++ compiler) to compile. Available by e-mail from wizard@cs.man.ac.uk; development site is UglyMUG (wyrm.compsoc.man.ac.uk 6239). TeenyMUD Originally a TinyMUD clone, written from scratch, with its main feature being that it was disk based. Original code written by Andrew Molitor. Now closer to a TinyMUSH, with some TinyMUCK influences. Latest version is 2.0.4betap3. Fairly small, and mostly stable. ftp.teleport.com:/pub/vendors/downsj fido.econ.arizona.edu:/pub/teeny ftp.tinymus.org:/pub/mud/teenymud TinyMUX Derivative of TinyMUSH 2.2. Mostly reverse-compatible with both TinyMUSH and PennMUSH, it brings out some of the features of each, including some code from MUSE, and much original and refined code. Latest version is 1.0p6. ranger.range.orst.edu:/pub/cota/source _________________________________________________________________ Miscellaneous UberMUD The first MUD where the universe rules are written totally in the internal programming language, U. The language is very C/pascal-like. The permissions system is tricky, and writing up every universe rule (commands and all) without having big security holes is a pain. But it's one of the most flexible muds in existance. Great for writing up neat toys. It's also disk-based. Original code written by Marcus J Ranum. Latest version is 1.13. Small in memory, but can eat up disk space. Quite stable. decuac.dec.com:/pub/mud ftp.white.toronto.edu:/pub/muds/uber ftp.math.okstate.edu:/pub/muds/servers MOO An Object-Oriented MUD. Unfortunately, the first few versions weren't fully object oriented. Later versions fixed that problem. There is a C-like internal programming language, and it can be a bit tricky. Original code written by Stephen White. Last version is 2.0a. NO KNOWN SITE LambdaMOO An offshoot of MOO. Added more functionality, many new features, and a great deal more stability, in a general rewrite of the code. This is the only version of MOO that is still being developed, originally by Pavel Curtis, and now by Erik Ostrom. Latest production release is version is 1.7.9p2. Latest version is 1.8.0p5. The current production release of LambdaMOO is 1.8.0p5. parcftp.xerox.com:/pub/MOO SMUG Also known as TinyMUD v2.0. It has an internal programming language, and it does have some inheritance. Surprisingly similar to MOO in some ways. SMUG stands for Small Multi User Game. Original code written by Jim Aspnes. ftp.tcp.com:/pub/mud/Smug UnterMUD A network-oriented MUD. It's disk-based, with a variety of db layers to choose from. An UnterMUD can connect directly to other UnterMUDs, and players can carry stuff with them when they tour the Unterverse. This can be a bit baffling to a new user, admittedly, but those people already familiar with the old cyberportals and how they work (invented way back with the original TinyMUD) will adjust to the new real cyberportals easily. There is both a primitive scripting language and much of the U language from UberMUD built in, as well as a combat system that can be compiled in if wanted. The parsing can be a bit odd, especially if you're used to the TinyMUD-style parser. Unter is also the only MUD that can run under BSD Unix, SysVr4 Unix, and VMS with MultiNet networking, with little to no hacking. Original code written by Marcus J Ranum. Latest version is 2.1. Small in memory, but can eat up a lot of disk space. ftp.math.okstate.edu:/pub/muds/servers decuac.dec.com:/pub/mud ftp.tcp.com:pub/mud/UnterMUD Mordor Most like a DikuMUD, with a built-in combat system, along with many choices for class and race, but not guild-based. Some "social-mud" features included as well. Also features online database editing as well as an offline db editor. Latest version is 3.0. Runs on BSD Unix, SysV Unix, NeXT Mach, IRIX, and WinNT & Win95. Written by Brett Vickers & Brooke Paul. Also comes with a custom client, Muddle. parker.bio.uci.edu:/pub/mordor http://moria.bio.uci.edu/ COOLMUD A distributed, object-oriented, programmable MUD server. Written by Stephen White. http://www.csclub.uwaterloo.ca/u/sfwhite/coolftp/ Note: just because we say something's available doesn't mean we have it. Please don't ask us; ask around for ftp sites that might have them, or try looking on ftp.tcp.com or ftp.math.okstate.edu. _________________________________________________________________ General Information _2.11. What do I do if my client/server won't compile?_ Your first best bet is to check out the documentation and see if someone is listed as 'supporting' (i.e. generally responsible for) the program. If they are, send them a short, well-written e-mail note explaining your hardware and software completely as well as a transcript of the error. Do not post to the internet unless all other realistic options have been considered and taken -- generally speaking, most readers will not be interested in your dilemma and may get upset that you're wasting their time. Since MUDs have probably been compiled on every single platform since the Cyber 3000, there's a good chance that asking around the subculture will get you the answers you crave. Do not mail me. I probably won't know. _2.12. Should I read the documentation of whatever client or server I select?_ Yes. _2.13. What is FTP, and how do I use it?_ FTP stands for File Transfer Protocol, and is a way of copying files between networked computers. The best way to learn about ftp is to get the FTP FAQ, by emailing mail-server@rtfm.mit.edu with send usenet/news.answers/ftp-list/faq in the body of the message. Not all ftps are alike, but here's a sample session on a unix system: % ftp ftp.math.okstate.edu Connected to ftp.math.okstate.edu. 220 ftp.math.okstate.edu FTP server (SunOS 4.1) ready. Name (ftp.math.okstate.edu:jds): ftp <-- use 'ftp' as your login 331 Guest login ok, send ident as password. Password: <-- use your email addr as pwd 230 Guest login ok, access restrictions apply. ftp> cd pub/muds/clients <-- how to change directories 250 CWD command successful. ftp> dir <-- ls also works 200 PORT command successful. 150 ASCII data connection for /bin/ls (139.78.112.6,4011) (0 bytes). total 2310 -rw-r--r-- 1 4002 4002 34340 Feb 6 1992 amigaclient.lzh ...etc etc... -rw-r--r-- 1 4002 4002 43093 Dec 13 1991 tinytalk.117.shar.Z 226 ASCII Transfer complete. 2631 bytes received in 0.7 seconds (3.6 Kbytes/s) ftp> bin <-- VERY IMPORTANT! binary transfers 200 Type set to I. ftp> get tinytalk.117.shar.Z <-- get filename 200 PORT command successful. 150 ASCII data connection for tinytalk.117.shar.Z (139.78.112.6,4012) (43093 bytes). 226 ASCII Transfer complete. local: tinytalk.117.shar.Z remote: tinytalk.117.shar.Z 43336 bytes received in 0.28 seconds (1.5e+02 Kbytes/s) ftp> bye <-- how to quit ftp 221 Goodbye. % Now that you've successfully ftped a file, you must unarchive it. There are many ways of archiving files; so many that they couldn't possibly all be listed here. In general, though, if a file ends in: .Z uncompress filename .z gunzip filename .gz gunzip filename .tar tar -xvf filename .shar sh filename .zip unzip filename Generally, once you've unarchived your client or server, you must still compile it. This varies widely depending on the system you're on and the particular client or server. Your best bet is to look for a README or INSTALLATION file or something equally obvious, and then if you're still unsure, ask someone locally to help you out. If you are connecting directly to the Internet from your PC running Windows, or a Macintosh, you have it much simpler. Just use a FTP client (WS_FTP or CuteFTP for Windows) to connect to whichever server and download whichever client you want. For PC systems, look in this FAQ for clients which say they use Winsock. _________________________________________________________________ This posting has been generated as a public service, but is still copyrighted 1996 by Jennifer Smith. If you have any suggestions, questions, additions, comments or criticisms concerning this posting, contact Jennifer Smith, aka Moira (jds@math.okstate.edu). Other Frequently Asked Questions (FAQ) postings contain information on MUDs, MUDding, and RWHO. While these items aren't necessary, they are quite useful. I'd also like to thank cthonics (felixg@coop.com) for his help in writing these FAQs, IronThoughts and Tarrant for their help, and everyone else for helpful comments and suggestions. Last but not least, a special thanks goes out to Richard Bartle, for getting MUDs started in the first place. The most recent versions of these FAQs are archived on ftp.math.okstate.edu in pub/muds/misc/mud-faq, plus on rtfm.mit.edu in the news.answers archives. HTML-ized versions are available at URL http://www.math.okstate.edu/~jds/mudfaqs.html. Have fun! - Moira _________________________________________________________________ Jennifer Smith / jds@math.okstate.edu -- Jennifer Smith jds@math.okstate.edu On MUDs: Moira, etc. | But still I fear and still Here, have a clue. Take two, they're small. | I dare not Laugh at the Madman. From csus.edu!csulb.edu!hammer.uoregon.edu!news1.mpcs.com!nntp.primenet.com!howland.erols.net!math.ohio-state.edu!news.physics.uiowa.edu!nntp.ksu.edu!news.cis.okstate.edu!jds Tue Dec 3 07:58:27 1996 Path: csus.edu!csulb.edu!hammer.uoregon.edu!news1.mpcs.com!nntp.primenet.com!howland.erols.net!math.ohio-state.edu!news.physics.uiowa.edu!nntp.ksu.edu!news.cis.okstate.edu!jds From: jds@math.okstate.edu (Jennifer "Moira" Smith) Newsgroups: rec.games.mud.announce,rec.games.mud.misc,news.answers,rec.answers Subject: [rec.games.mud]: FAQ #3/3: RWHO and "mudwho" Supersedes: Followup-To: rec.games.mud.misc Date: 16 Nov 1996 07:00:05 GMT Organization: Oklahoma State University, Stillwater OK Lines: 148 Approved: news-answers-request@MIT.Edu,rgm-announce-request@theurgy.digex.net Expires: 14 Dec 1996 07:00:02 GMT Message-ID: References: Reply-To: jds@math.okstate.edu NNTP-Posting-Host: littlewood.math.okstate.edu Summary: info on rwho servers, and mudwho Keywords: muds rwho mwhod mudwho Originator: jds@littlewood.math.okstate.edu Xref: csus.edu rec.games.mud.announce:2600 rec.games.mud.misc:24301 news.answers:87455 rec.answers:25587 Archive-name: games/mud-faq/part3 FREQUENTLY ASKED QUESTIONS: Basic Information on RWHO and mudwho This is part 3 in a 3 part series of FAQs. $Id: mudfaq-p3.html,v 1.4 1996/03/05 16:41:45 jds Exp jds $ Table of Contents * 3.1. What is RWHO? * 3.2. How Does It All Work? * 3.3. Where Can I Get This Stuff? * 3.4. Where Are Some RWHO Servers? RWHO and mudwho _3.1. What is RWHO?_ RWHO stands for _Remote WHO_. It's a way of getting a WHO list from a MUD, without even having to connect to that MUD at all. Anyone can get this output from a RWHO server (an _mwhod_), by using straight telnet to connect to a certain port (6889), or by using the client program _mudwho_. RWHO servers talk to other mwhods, passing information around, and are talked to directly by some MUDs, receiving information from them. Any one mwhod keeps track of several MUDs, plus storing information passed it from other mwhods. Only MUDs that have the RWHO routines compiled in will be able to send their WHO list info to a mwhod. UnterMUDs have this capability built in; other MUDs have to have the routines installed first. The RWHO routines have been installed into TinyMUSH, TinyMUCK, LPMUD, DikuMUD, and AberMUD, as well as the Nightmare 2.5, TMI2, and Lima mudlibs for LPMUD without encountering any difficulty. _3.2. How Does It All Work?_ _mwhod_ is the RWHO server that runs on a particular host and keeps a list of known MUDs. It is initially primed with a list of "trusted" MUDs and passwords used for authentication, and will accept information about who is logged into those MUDs. The server also has a notion of a "peer" server, which can transfer it (occasionally) a copy of all of its list of who is logged on, and where. The idea is that the whole MUDding community could probably be served pretty well by about 5 peer mwhods that kept each other up to date about what each one is seeing. Communication between mwhods (and server updates sent to mwhods) is done with UDP datagrams, since they're fast, nonblocking, and throw-away. (RWHO information is considered to be interesting but not vital information, if you get my drift). Each MUD server only sends updates to a single mwhod, which may then propagate that information to its peers. This is done within the MUD server as follows: * whenever the server boots, it sends a "hi there" packet to the mwhod, telling it that it's up and running. * whenever a player connects, it sends a "so and so is here" packet to the mwhod, telling it that the user has connected. * whenever a player disconnects, it sends a "so and so left" packet to the mwhod, telling it to delete the entry. * every so often ("so often" being defined as a time agreed upon by the mwhod's owner, and the MUD's wizard, usually every 5 minutes or so) the MUD sends a "hi there" packet and a complete list of everyone that is on, just to refresh the mwhod's idea of who is logged into that MUD. If a user connects to a specific port (6889) of a host machine running an mwhod they are given a formatted dump of the mwhod's current table of MUDs and players, and then disconnected. _mudwho_ is a simple little program that contacts an mwhod and downloads this information. Ideally, the functionality of _mudwho_ would be built into a player's client software, for ease of use. Two handy options can be used by _mudwho_, if the netlag to the mwhod server isn't too bad. The options are _-u _, and _-m _. If received before the timeout, the mwhod will then only dump WHO list information for the specified player or MUD. The mwhod does some clever stuff as far as eventually timing information about of its tables - for example, if it hears absolutely nothing from a MUD for a certain amount of time, it will mark the MUD as down. Player entries are expired similarly. The design is based on the idea that we'll use UDP to just fling information out and hope it sticks, and then let the recipient clean it up, rather than to develop a more complex protocol based on TCPs and timeouts. To prevent a packet circular send situation, each entry that is sent is given a "generation" number, which is incremented by one each time it is forwarded along. In this manner, a MUD server might send a "so and so is here" (generation zero) to its local mwhod. The local mwhod will eventually send a copy to any peers it may have (generation one), and so forth. Part of the initial table that an mwhod uses to establish what peers it trusts contains a generation value, and it will neither accept nor propagate information to a specific peer that is of a higher generation value. This way, a "tree" of servers could theoretically be constructed, with the highest level one having a total view of a large MudIverse. _3.3. Where Can I Get This Stuff?_ The unix client program _mudwho_ can be ftp'd from ftp.math.okstate.edu, in /pub/muds/clients/UnixClients. The shar file contains both mudwho.c and a README file, listing a few mwhod sites. The plain mudwho.c file can be found at decuac.dec.com. The RWHO routines can be ftp'd from decuac.dec.com, in pub/mud. Included is a HOW_TO file, which describes how to plug the routines into a MUD server, and also where to ask for a mwhod to use. The mwhod program itself can also be found on decuac, but there is currently little need for another one running in the USA, except perhaps as a backup. There is, however, only one running in all of Europe, and further expansion may need to be made in that area. _3.4. Where Are Some RWHO Servers?_ Currently, there's only one main RWHO server running. At any one time, there's an average of 20 muds, of various types, talking to mwhods. * Site: littlewood.math.okstate.edu IP: 139.78.112.1 Port: 6889 Admin: jds@math.okstate.edu _________________________________________________________________ This posting has been generated as a public service, but is still copyrighted 1996 by Jennifer Smith. If you have any suggestions, questions, additions, comments or criticisms concerning this posting, contact Jennifer Smith, aka Moira (jds@math.okstate.edu). Other Frequently Asked Questions (FAQ) postings contain information dealing with MUDs, MUDding, clients, servers, and FTP sites. While these items aren't necessary, they are quite useful. I'd also like to thank Marcus J Ranum (mjr@v-one.com) for writing such a wonderful program (and decent docs), and everyone else for helpful comments and suggestions. The most recent versions of these FAQs are archived on ftp.math.okstate.edu in pub/muds/misc/mud-faq, plus on rtfm.mit.edu in the news.answers archives. HTML-ized versions are available at URL http://www.math.okstate.edu/~jds/mudfaqs.html. Have fun! - Moira _________________________________________________________________ Jennifer Smith / jds@math.okstate.edu -- Jennifer Smith jds@math.okstate.edu On MUDs: Moira, etc. | But still I fear and still Here, have a clue. Take two, they're small. | I dare not Laugh at the Madman.