Shoo's Beginner's Guide to MUSH Administration or: The Panic Button is over there. Edition 1.02 (C) 1996 Table of Contents: ------------------ I. Getting a Site - Where to find a site for your MUSH - How to ask a sysadmin if you can use their site - How many licks does it take? II. Post-Site: Now what? (pennmush.tinymurg.org) - What's all this stuff mean? - Where can I find pennmush? - Which files do I need? - What do all these files mean? - Okay, I have the file, now what? - You really are great, Shoo. III. Setting up your MUSH - Pre-Installation--how much room and memory do I need? - How do I set up my MUSH? - What's an option? - Where's Javelin, in case I panic and you're dead wrong, Shoo? - Isn't 'compiling' what you do after you vomit? IV. Getting Started - Databases and their many uses - Mush.cnf and the restart script, or Calculus all over again - Backing up and you - On-site vs. Off-site - How do I turn it on? V. MUSH Administration, take one - Which rock do I find administrators under? - How many meals a day? - Getting along and Playing well with Others - Code vs. RP, abridged (thankfully) VI. Even more MUSH Administration technique - How to make something from nothing, or: Instant Water - MUSH vs. Real Life, or Which One Shall I Live - Get your degree in TV/VCR Repair with Sally Struthers - What to do if your workplace, friends, and cat looks like MUSH VII. Appendix - Important people, Or: Javelin, Javelin, Javelin! - Operating Systems, can't have too many - Credits, or: Thanks vs. Special Thanks (Author's Note: The author does not claim responsibility for any lost, stolen, or damaged items--hardware or software--that become damaged, lost or stolen as a result of following my instructions. I claim neither expertise or really even a good passing knowledge. At the time of this writing, the latest version of PennMUSH is 1.6.9p4, which was released on October 9th, 1996. If you are using TinyMUSH--well, God help you, 'cause I certainly can't.) If you are reading this, you are hopefully one of the few, the proud, the clueless--the sort who has this /great/ idea for a MUSH, but all of the people who know anything about everything that has to do with MUSHes either speak in all lowercase letters, refuse to use puncuation, don't get along or play well with others, or are heavily swamped with mail anyway. For your information, I claim all but the latter, but thanks to modern word-processing I am able to write beyond the fifth grade level. Anyway! I would go insofar as to say that the first thing you need when pondering a MUSH is a theme. Think out your MUSH beforehand. Don't go ad hoc and just throw something together--have a plan, but leave room for errors, which are both common and bad-tasting, and improvements, which, as we all know, come only from Javelin(tm). If you have a theme in mind, read on. If you do not, complain bitterly to your congressman. The structure of this guide will be relatively simple; next to important, boring technical facts, I will put two asteriks (**) and warn you in advance of boring technical facts. The good news is that I know perhaps one or two good technical facts, and they both came from the /actual/ guide on running MUSHes, which is around here somewhere. If a paragraph is not marked with any eye-catching and extraneous symbol, it is almost definitely irrelavent, stupid, long-winded, opinionated drivel. Anything marked with two dashes (--) is a Really Useful Tip, but worry not, there are only a few of those as well. Onto The Site! I. Getting a Site. Both in theory and practically, obtaining a well-functioning, well-managed site for your MUSH is absolutely impossible, simply because no such place exists that has any room. Your best bet is to go around to some existing MUSHes you know, and ask them if their sysadmin has any room for a /small/ MUSH--and I say small because you must always start small, and if you get huge, you will have more people out looking for a site. In the long run, this doesn't help, because when it comes down to it, nobody but you will be looking for a site, no matter how many fanatic players you have. The /wrong/ thing to do when looking for a site is to find a list of every internet provider known to man and beast and email the sysadmins. As with MUSH administration, I am not particularly competent at running a UNIX system, but once upon a time I /did/--and I guarantee that if the 'to:' line of email addresses was longer than the actual message, I would almost never consider it. If you know of one or two sysadmins in particular whom you know directly or through someone, or have had some contact with them, it can't hurt to ask--but asking, in itself, is a whole different world. I'll summarize: the best way to ask is to greet them politely, tell your name, and begin by saying that you have a MUSH with X theme and are looking for a site; you are familiar (hopefully) with the site and/or the sysadmin, and think Y site would be great for X-themed MUSH. Try to outline how much space--memory and disk space--you will need, if you will require direct shell access (read: a shell account on the server) and if you can donate any money at all to the ISP. It has been my experience that an ISP will either take you for free or charges you horrendous amounts of money, and having no money of my own, I prefer the former. (**) Boring Technical Fact: Beginning MUSHes do not require much room on a server. The file that runs your MUSH is generally going to be about a meg. The rest of your MUSH software, including your new database, is usually about 2 megs, so it's 3 megabytes altogether, roughly, after everything's compiled and what-not. I would not start a MUSH, personally, with any less than 30 megabytes available for my sole usage. Between backups and MUSH growth, it can easily get to 30, depending on how popular you are and how meticulous you are about backups. Preferably, you'll get at least 100 for emergencies when you have nine backups living in your directories. II. Post-site-getting: Now What? (See Appendix for information on Operating Systems) Okay, you've got permission and a shell account from your sysadmin. If I haven't mentioned that already, you need one. Don't let your sysadmin fool you into thinking that (s)he will 'do everything for you.' The only occasion in which this is acceptable is if the sysadmin has an active role in the development of your MUSH. This can be a good thing, in that your site is almost guaranteed, as well as a bad thing, in that if you somehow don't get along with the sysadmin you may lose the site; and sysadmin relationships are usually brief and curt when the sysadmin does /not/ work on your MUSH. So it's pick and choose, but beggars can't be choosers, always. The first thing you'll want to do is FTP the latest distribution of Pennmush. Type, at the prompt of your MUSHes' shell account, 'ftp pennmush.tinymush.org' and login with the username 'ftp' and the email address of your /shell account/ at the MUSH's machine for your password. If you can, type 'ncftp' and not 'ftp,' because ncftp is much nicer and friendlier. :> After it tells you how great it is that you've logged into their server, type: cd /pub/PennMUSH/Source You will get this prompt: pennmush.tinymush.org:/pub/PennMUSH/Source ncftp> Type 'ls.' This is how my screen looks today, the 21st of October, 1996. ncftp> ls 1.6.8p1-1.6.9p0 Javelin.pgp pennmush-1.6.9p0.tar.Z 1.6.9-patch01 README.CSRI pennmush-1.6.9p0.tar.asc 1.6.9-patch02 contrib/ pennmush-1.6.9p0.tar.gz 1.6.9-patch03 funcrypt.c.RESTRICTED private/ 1.6.9-patch04 oldpatches/ CSRImalloc.tar.gz oldsrc/ pennmush.tinymush.org:/pub/PennMUSH/Source ncftp> If you are in a UNIX shell--and I don't really have time or inclination to go into different Unix vs. VMS discussions because I know nothing about either. Were I setting up a new MUSH, I would want pennmush-1.6.9p0.tar.gz, 1.6.9-patch01, 1.6.9-patch02, 1.6.9-patch03, and 1.6.9-patch04. Here's a quick explanation of everything you'll see in this directory: pennmush-1.6.9p0.tar.gz: The latest packed source-code of the Pennmush distribution. This is usually done every time there is a new minor code revision, or, every time the last number in the three--the '9' in 1.6.9--goes up one, and the patchlevel becomes zero. I'll explain this later on in more detail. :> You will want this file if you are setting up a new MUSH--it /is/ the MUSH. pennmush-1.6.9p0.tar.Z: This is the same thing as the previous file, using the regular UNIX 'compress' compression. These are traditionally larger than their GNU 'gzip' (or .gz files) counterparts. Check if your machine has gzip and gunzip--type 'gzip' and 'gunzip' at the prompt, and see if it says 'command not found' or some silly thing about compressed data being written to terminal. If it says command not found, get the '.Z' variety. Otherwise, .gz is the way to go. :> 1.6.9-patch0<# here>: This is a MUSH patch. If your MUSH has been around a while, you most likely have about a trillion of these lying in your directory. I certainly do, and I am proud of each one of them. :> Every time a fix is made to MUSHcode, there is a 'patch' put out. It would be a huge pain to have to re-unzip and re-setup your whole MUSH just for a minor change that may not even affect you, and so we have patches! (**) Note about patches: Some more conservative MUSH administrators prefer to wait a week after a patch is put out to make sure that those foolish enough to rush out and scoop it up immediately find nothing wrong with it. This is called prudence, though I usually rush out and apply every patch I can find. Technically, it /could/ make a difference, but if a patch doesn't work, chances are another patch will be released almost immediately to fix it; so it's usually not worth the trouble to wait. (**) The other kind of patch you see here is 1.6.8p1-1.6.9p0. This is what's called a 'big patch,' and yes, that's the technical term (honest! Er, really....) Here's what The Numbers Mean: (**) 1.6.9p4--PennMUSH release version one, major code revision six, minor code revision nine, patchlevel four. A release version is like--/the program/. 2.6.9 would probably be entirely different than 1.6.9. The first version I ever saw was 1.50, and that was in the beginning of 1995, so don't expect to see too many changes in the first number. The second number is a major change in the code, usually something recognizable and having a large impact on the MUSH. The last number is a minor code revision, though is almost always of some signifigance, especially if your MUSH is heavily code-based. These usually go up every month or two. The final number is the patchlevel. Patchlevels are updated every week or two, depending on whether or not the next patch is a Big Patch or a little bug fix. Their changes may or may not affect your MUSH in particular, but it's best to apply them anyway, because if you're running patch 1, and patch 2 is useless but patch 3 is not, you can't just apply patch 3 to patch 1 and get something beautiful. Apply all patches. :> /contrib: The mystery directory. You'll find some bits of code here, unsupported patches from people who are Not Javelin. Not a directory I use often, but it can't hurt to peek. /oldpatches: If you went on vacation for..oh, six months, and wanted to upgrade your mush, you could use the oldpatches directory and find all of the older patches that are not kept in the /Source directory. I wouldn't suggest using a lot of old patches. Save your /game/txt and your database, and reinstall MUSH entirely. I'll explain saving stuff later. :> /oldsrc: Old packed source code. I have no idea why you'd want it. :> /private: Javelin's super-secret directory. I'm the last person he'd want to trust with /that/ directory, but I would imagine he keeps code-in-progress there for his Elite Team Of Code People(tm) to decypher. Eef! That was really long. I apologize. Hah! No I don't. (--) Download the latest version of the packed code (the .gz file with the highest numbers) and if the patches are higher in numbers than the packed file, download those too. That is really all I said in the last page or so. III. Setting up your MUSH. (--) One of the key elements of being the site admin for any MUSH is to use technical terms interchangably. To 'set up' a mush is also to 'compile' MUSH, to 'install' MUSH, to 'upgrade' MUSH, or to 'make a few changes,' all of which are quite impressive to the average player. The ideal system to run a MUSH that will expand is a P90 with 32 megs of RAM. For any sized mush, you need a dedicated internet connection, preferably with at least a 56k ISDN line. This means that if you have a dialup PPP line over a modem with '144' or '288' printed on it, don't bother. :> THe connection is very important, but the CPU speed has some leeway. Depending on the code you have and what else is running on that site, you can get away with a 486/66 and 16 megs of ram, as long as the MUSH isn't going to be too big. After you have FTP'd (not /downloaded/, FTPd) all the appropriate files, you have to uncompress them! I'll go on the assumpion you got the. gz files. If you got the .Z files, just replace all my usage of the word 'gunzip' with 'uncompress.' When you uncompress PennMUSH, it does not create its own directory--so if you have not FTPd the MUSH files to the directory you actually want the MUSH in, move them there. Then do this: gunzip pennmush-1.6.9p0.tar.gz (wait for that to finish. It will not tell you when it does, that would be helpful. UNIX is not.) tar -xvf pennmush-1.6.9p0.tar You will then see many screenfuls of meaningless filenames spouting by. If at all possible, try to have your computer-clueless friends watch as you do this; they will either be very impressed, or get very sick of seeing you do silly computer things and put toothpaste in your hair. After all of this scrolling is done, your MUSH is uncompressed! But you're not /done/. Hah. Yeah. Like that'll happen in ten pages of documentation. (--) Stop! Go into the directory where you uncompressed MUSH and type 'more README' -- read it carefully! I'll summarize first-time startups here, but it's already written there, so you don't need me to repeat it. :> The first part of the file explains the history of Pennmush. Although mildly interesting, it is not immediately important to getting your new MUSH to work right. Only after your MUSH works and you break it, and must ask the people named here for questions will you go running back to this document, and finding names like Javelin to email. The next bit explains the directory structure of Pennmush. This /is/ important. Read it and understand it, especially direcotories like /game/data (where the databases are kept) and /game/txt (where your opening screen, MOTD, and such things are). Next is the quickstart. Forget it. You don't want a quickstart. If you don't understand how to really stop, fix, and start your MUSH, you will have big trouble. :> (--) Important things! The three most important files at the top of your MUSH directory tree are 'Configure,' 'dune.h,' and 'options.h' Before you do anything else, run through Configure. There are so many things that can happen during Configure, and so many different circumstances, and Configure is written to accomodate these, I won't really go into it; rule of thumb with Configure, though: when in doubt, just hit enter. The default will usually be right. the only thing I would really double-check is the 'hints' part, which doesn't make a lot of sense unless you understand programming; if you are like me, and have the Linux kernel 2.0.0, you don't see anything that says linux_2. You see linux_0 and linux_1. Don't be tempted to put in linux_1! Even if Linux 2.0 looks the same to use as Linux 1.2 might have, it is really quite different. If your default says [none], *put in none*. Please. (--) After configuring! You copy options.h.dist to options.h, and dune.h.dist to dune.h. You do this by typing 'cp options.h.dist options.h' and 'cp dune.h.dist dune.h'. This copies the original options files to the files the MUSH actually uses when it 'compiles.' (**) Compiling! This is an important concept, so please push the 'power' button on your computer monitor now. When you get MUSH from p.t.org, in the form I have explained, you get the 'source code.' This is all of the programming language that forms MUSH. It is designed so you can customize parts of it, which is a Good Thing. When you edit your options files and 'compile' it, it takes /all/ of that programming, and those options files, and stuffs it into one big program called 'netmud.' When you run your 'restart' program to start your MUSH, it activated 'netmud.' WIth only a few exceptions, the only files you actually need to /run/ your MUSH are netmud, and your database--it's only when you want to upgrade it or change your options that the source code comes in. So don't delete it. :> You'll want to go through options.h and dune.h carefully. Most of the important options are explained in the file, but here's a quick run-through of some important ones. An option that is 'defined' (or enabled) looks like this: #define HARSH_GUEST /* */ An option that is 'undefined' (disabled) looks like this: /* #define HARSH_GUEST /* */ The way this works is that everything after the '/*' sign is ignored by the computer until it hits the */ sign. As long as there is no /* before the #define HARSH_GUEST, it means it's going to be defined. The options you define are going to depend on the type of MUSH you want. The safety options which say they 'add typically 4 bytes to every object' are usually important--4 bytes to every object isn't a whole lot, really, in exchange for what you get back. You kind of have to figure out what the options mean to you, but one word of advice: Enable /all/ of the 'functions'. The first time I compiled MUSH, I looked at this stuff and thought, 'When will I /ever/ need the arc-tangent of an obtuse angle?' This is kind of like high school geometry, in that you think you will never hear the words 'reflected about the y-axis' again in your adult life as a multi-millionaire, but if you actually want to /code/ anything, you will need to know that kind of thing--oh, and, enable those functions too. It can't hurt, anyway. I'll go into code a little later, but only where and where not to use it. :> The directory structure of PennMUSH is very neat and organized, unlike some other M** software I could name, ahem. :> The structure is in a nice pretty tree in the README file in the top level, so I won't repeat that; when I say the 'top level,' I mean the directory in which you de-'tar'd the pennmush-1.6.9p4.tar.gz file. /src : This is where all the 'C' programming code is which is used every time you recompile MUSH. Unless you really know what you're doing, you'll never want to touch anything in this directory; and if you really know what you're doing, you're reading the wrong MUSH manual. Under this directory are the IDENT/ and RWHO/ directories. 'Identd' or 'Identity Daemon' is a program that compiles with MUSH by default that allows people with wizard-bits to see the complete site name and username for every person logged in. This is only useful if both the MUSH server and the site the player is connecting from are using IDENTd--if only the MUSH is, you may still see the name of the site the user is connecting from, but rarely the name. Anyway, since it compiles by default, I use it with the logic that I would have to change actual settings to disable it, and it's nice to have, so I don't worry about it. (**) PennMUSH does not include an IDENTD server, only libraries so that MUSH can talk to sites that /do/ have identd servers. RWHO is a slightly less useful gizmo which is not enabled by default. It connects to an 'RWHO Server' while your MUSH is up, and people--and MUSHes--can connect to this RWHO server to see how many people are on all the MUSHes that are connected to that RWHO server. It's kind of amusing, but not terribly necessary, and I'm sure it has documentation. If you want it, check out the README and maybe even the /src/RWHO directory. /hdrs and /hints: These directories contain files used when your MUSH is compiled. You should not have to touch anything here. /utils: As far as I know, these contain perl and 'sh' utilites for doing things like updating your access.cnf file, and running two or more MUSHes off of one MUSH binary. I have never had to do either of these directly, and so couldn't tell you much about them. If you use them regularly, feel free to mail me with what they're good for and I'll put in something about it. /win32: For those of you brave enough to try and run a MUSH off of Windows '95, or--I think it may work on NT. Windows is fun if you want to play around with MUSH, but if you actually want to run one, I wouldn't suggest it. Javelin assures me that MUSH will work beautifully on Windows '95 and NT, and I have tested it on WIndows '95--and it's not so much that it won't work on Win95 so much as it's just the fact that it'll run better on just about anything else. For those of us who don't have $400 lying around to buy Visual C, and who don't have 128 megs of RAM in our windows machines, it's just best not to bother. Use Windows if you want to play around with soft-code (which is code you write on the mush, not mush server code--or, 'hard code') and need a test-site. /game: This is really the only directory you have to be concerned with. Everything you need to run the game is in this directory, or under it, for the most part. It contains your restart command, the mush configuration file, the /txt directory (where your login screen and other fun things go), and the /data directory, where your databases go. I'll go on about this one later. IV. Starting your MUSH! I lied. You can't start it yet. You should be so lucky. You have to compile it! After you've gone through dune.h and options.h, which should be done after you've gone through Configure (type ./Configure at the top level before you do anything else) you have only one more step. At the top level directory, type 'make install'. Depending on the speed of the computer you're on, this will take anywhere between three and thirty minutes. There are a few things that can go wrong here, most of which will result from you having a strange operating system; if you have NextStep (insert random capitilization here) or VMS, or are using Windows, or one of any assortment of non-standard operating systems, all of which have their strong points (none of which, unfortunately, are MUSH) then you may still be able to compile MUSH; there is most likely some strange ritual you have to perform beforehand, and there may be documentation on that in the README. I cannot help you, though, but Javelin can! (--) If you have an error compiling MUSH, write down or cut-and-paste /everything/ you see after it says there's an error, and send it to Javelin. His address is javelin@pennmush.tinymush.org, which I'll state later. Memorize it. You will need it. Occasionally, if you've just upgradded to a new patchlevel, there'll be a simple problem that manages to prevent you from compiling at all; this has happened to me twice, and both times, there was a patch to fix it five minutes later. After you have compiled your MUSH, there are only a couple things you have to do. Firstly, go to your /game directory, and edit the 'mush.cnf' file. Edit 'mud_name' to be something you want; the line should read 'mud_name NameOfMyMush'. If you want to name your indb and outdb something other than indb and outdb, change 'indb.Z' and 'outdb.Z' to whatever clever name you want; but remember to include the suffix of .Z or .gz. If you are not using the default setting of 'compress' to compress your MUSH database, you will have to change this to .gz anyway, but make sure the database name matches the type of compression you want. (**) Indb vs. Outdb. PennMUSH keeps three seperate databases that it uses. The two most important are outdb and maildb. I will refer to them as outdb or maildb.Z, because I'm too lazy to go and enable the gzip kind of compression, and that's what I'm used to seeing. Whenever PennMUSH makes a 'dump' (backs up the database) it creates a temporary file and then copies it over to outdb.Z. If there is an existing outdb.Z at the time you start the MUSH, that is what it will use. Whenever you @shutdown the MUSH, or startup the MUSH, it copies the currently existing outdb.Z to indb.Z. maildb.Z is not affected by startup or shutdown, as it is changed as people send and delete mail, and the MUSH keeps only one copy of it. If you backup your MUSH's database, copy outdb.Z and maildb.Z to a backups directory; like, if I were making a backup on October 22nd, and didn't yet have a backup directory, I would do this: mserv1> cd ./game/data mserv1> mkdir backups mserv1> cp outdb.Z ./backups/outdb.1022.Z mserv1> cp maildb.Z ./backups/maildb.1022.Z (--) I cannot stress how important backups are! Making a backup on-site (what I just did, i.e. copying the outdb.Z into another directory) should be done every day, or every two days. Get someone to do this, or do it yourself. It is really, really important. Every two weeks or so, FTP to your MUSH's site, login with your MUSH account, and FTP the database to your computer. This is called an off-site backup. you use those when the site on which your MUSH lives has a disk crash, and this /does/ happen. After you have gone through your mush.cnf file, edit the 'restart' file. The only thing you should have to change is the 'CONF_FILE' line, if you've renamed mush.cnf to something specific to your mush, like pern.cnf or mymush.cnf, or what have you--and you will have to change GAMEDIR to the *full pathname* of your game directory. For my site at home, that's /home/sammy/mush/game; it's different on every system. If you're on a linux system, type 'export |more' and look at the first value, 'HOME'. This is the full pathname to your user directory. If your home directory were /usr/home/jsmith, your mush directory could be /usr/home/jsmith/mush/game. Replace 'mush' with whatever directory you uncompressed Pennmush to. Once you have done all of that, you should be ready to restart your MUSH! In your mush.cnf file is a 'port' option, which is often 4201 or 7777. Set this to whatever you like, but make sure no other MUSHes or programs are running on that port. Use four digit ports, as numbers such as 23, 25, 80, 100, and 110 are often used by really important programs. In your /game directory, type './restart' and your MUSH /should/ go up. If there's a problem, you can always check the /game/log/netmush.log file for information if your MUSH doesn't go up properly. If it does go up, you can connect to it at whatever the address of the site is, with the port number attached. V. Big deal, that's all in the README! So what good are you, Shoo? --Or, the Fine Art of MUSH Administration. Not a whole lot. This next section will deal with the problems that crop up early on in MUSH development. I speak usually from my own experience, but this part is entirely opinonated; if all you want is the technical parts, skip to the appendix at the end. Picking administrators, or 'staffpeople,' as I like to call them, is one of the most important decisions you will ever make. The style and structure of your MUSH 'wizzen' or staff is going to depend on the type of MUSH you are running. I've checked out, played on, or tried to run varying coded sci-fi games, barely coded sci-fi games, Pern games, and tabletop games turned online (like Dragonlance and World of Darkness). Regardless of what kind of MUSH you are running, here are some guidelines to follow when picking staffmembers: 1) Pick people whose skills you know you will need, not because you think you might need them. For a Pern game, the most important thing to have is people with good communicative skills and lots of patience; patience is a virtue regardless of the sort of game you're running. Tabletop games -- D&D and WoD -- generally require a mixture of both communication and technical orientation, depending, once again, on how much you need coded. The stereotype is that administrators don't know how to code and technicians don't know how to administrate, though there are exceptions, of course, and once again it depends on the type of game you're running. 2) Pick people you know online. Try to avoid people you know in real life. Too many times real-life friendships or acquaintinces die out because of online differences, and that's just ridiculous. It /is/ just a game. :> Especially avoid girlfriends, finacees, or, God forbid you pick your spouse. 3) Pick people who will be there! Administration is a huge time commitment. Don't force someone into accepting an offered position; only have them take it if they really really want to. :> (--) This is the most important thing I say in the whole guide. (--) Decide whether or not you want a code based 'multi-user computer game' or a more artistic 'roleplaying game.' The term roleplaying has been butchered to mean simply 'being someone else,' which, although not incorrect, is only half the meaning. Don't try to do both. Lots of code attracts people who like lots of code, and the people who like lots of code and are really great at creative roleplaying are few and far between. I know this will be contraversial, but I can't stress it enough. If you want really great RP, don't code things like 'combat' or 'economy' or anything that directly challenges the /player/--think of it this way. If you want your game to be 'fun' for the player in the context that they can 'gain levels' or 'gain skills' then you are going for code and not RP. There are a lot of MUSHes out there that try to have both, and this almost never works. About the closest I have seen a MUSH coming to being some of each, and doing a halfway decent job in so doing is 'Clone Wars,' a Star-wars MUSH at mush.ddv.com 2222. I cannot admit to actually playing there with any regularity, so don't quote me on that. :> The opposite extreme is generally found in Pern MUSHes, where almost everything is left to the imagination. There are also hybrids, such as 'The Nexus' (nexus.tcp.com 2222) which is multi-themed, a huge project in and of itself, which tries regularly coded science-fiction themes with very little code to speak of. (Author's note: Nexus is a MOO, but the administration stuff I go over here applies to MOO as well as MUSH. The technical stuff does not.) The final sort of MUSH you will find is the tabletop kind, that include themes like White Wolf's World of Darkness, Dragonlance, Forgotten Realms, and the like. These can be coded or not, just like any other game; it is always my preference to avoid code whenever possible, because it restricts or limits players and makes your MUSH more of a 'computer game' and less of an artistic venture. This is entirely okay, if that's what you want, but be prepared for the often mind-boggling quality of intellect you will find here. (Disclaimer: I do not mean to criticize anyone who runs or plays on such a game. If you are witty enough to want to be angry with me for making such unfoudned, blanket statements against such games, you are probably the exception, so pat yourself on the back. :) VI. Getting your MUSH off the Ground, or We aren't done with opinionated drivel yet. One of the most important things I can tell you is that deadlines are a bad thing, up until a certain point; some MUSHes are ready in the space of a month or two, while others don't open for a good four years after they start development. Don't open early! The moment you let players in the door, they somehow think it means you want more players, and they invite their friends, who get irritated and walk out when there isn't anything to do because you haven't built anything but the welcoming room yet. A good rule of thumb is to not let anyone on the MUSH whom you don't know very well, or whom will not be doing anything constructive--until the MUSH opens, of course, at which time you want people who will just sit there and idle, so you can be proud that you've made a decent MUSH. (--) After you've got your administrators down, you need to Meet With Them. Big administration meetings are really up to you; some people like to have them weekly, while I prefer to have them bi-anually, or thereabouts. As far as hierarchy goes, if your game is less-code, more-RP, then structure is bad for you; artists, after all, are generally very sensitive, and you don't find the best combat coders walking off in a huff over 'creative differences.' :> The furthest I would go in running a game is to inform everyone that, although I would really enjoy never to use it, I do reserve final judgement in an emergency...and, in fact, that's what I did, and I have yet to have to use it. On the flip side, don't have committees or commissions to vote on things. Everything should be unanimous, or at least very close--remember, by calling yourself a staffperson, you are saying that 'I represent this MUSH and all it stands for,' and if you want to keep your MUSH and your staff together, you had better make sure they don't mind being a living representation of their mush. You, as Guy In Charge, must be eternally patient. There are bound to be disagreements, and you must never, ever, ever discount a fellow staffperson's objection entirely. Go out of your way to be exceedingly nice. The fellow whom I work with on a game that shall remain nameless is so maddeningly polite -all the time- that I simply cannot bring myself to really get mad at him. This is the kind of administrator you want to be. :> Maintenance and responsibility: Shell access! Don't give it to everyone. Keep access to the server to yourself, and maybe two or three other people. Don't make it an issue of trust, make an issue of necessity...if the only reason anyone has to login to your MUSH account is to restart it when something goes wrong, then let someone else do it. Backups should be made every one or two days, so that's one person who'll need it to do that. This should generally be the 'site admin' person on the MUSH, who takes care of upgrading the MUSH, fixing the .txt files, and backing everything up. The only exception is if the sysadmin of the server wants to do all this. I cannot express strongly enough how important it is that you keep the stafflist to people you know and trust. Even if your sysadmin is nice enough to let you run a MUSH on his/her server, that doesn't mean (s)he knows a thing about -running- a MUSH--more often than not, the sysadmin tries to learn, gets involved in MUSH politics, disagrees with you, and then boots you off the site. Most sysadmins are nicer/more wise than this, but it's an important precaution...remember, once you've made someone a staffperson, you're giving them the same authority you have, as far as they are concerned--you never know, you may wake up one day and not be a staffperson anymore... (--) Arguments: If you get into one, apologize, say you need to take a break, and will deal with it tomorrow. There is not a problem I have had, online or otherwise, that I cannot think about more clearly after I've slept on it. And I have been told this is not just me. :> Builders! You will need them. Again, you need people who will login and get it done. Grammar, puncuation, and spelling is a must, as is inclination. Builders burn out very quickly. ...and speaking of burnout. MUSH is only MUSH. It can be fun, it can be stressful. If it ever becomes more of a chore than a reward, take a break from it for a week or two--regardless of what stage your MUSH is in, it will never fall apart if you disappear for two weeks. The worst that can happen is that it won't be any better off when you get back. The worst that can happen to /you/ is that you get so drawn up in your MUSH, you live and breath MUSH. I have seen this happen to people, and it really is not pretty. You should be able to figure out things on your own, with the help of your staff from here on in. If you have a pressing concern and want my two bits, you are more than welcome to send me mail at sammy@bdsnet.com. This, of course, is quite arrogant on my behalf, and I assure you that I don't have all the answers. Like anyone else, it is much easier for me to say what /not/ to do than what to do. If you think of something you think I ought to add, remove, or change, please let me know as well. ------------------------------------------------------------------------------ Appendix I. Important People and Phrases: Javelin, aka Paul, author and miestro of PennMUSH: javelin@pennmush.tinymush.org I am in semi-frequent contact with Javelin on account that the MUSH for which I am sysadmin breaks often, and my first impulse is to tell him about it, even if I fix it ten minutes later. Mail turnaround time is usually about a day, if that, and the single most important reason I use Pennmush at all is because the author has no qualms about explaining to us sessile, leeching numbskulls why we are so stupid. Or, at least, if he does, he's remarkably good at keeping his impatience canned. :> sammy@bdsnet.com, aka Sammy, Shoo, or Dextra: Me! I wrote this pathetic excuse for documentation. If you find anything wrong with it, or want me to add something, mail me. Don't mail Javelin. Repeat that to yourself. mserv1.wizvax.net 4201: Legacies MUSH, the World of Darkness MUSH where you can find me (Shoo). root@localhost: The address Javelin will tell you to mail if you get a strange compiling error that involves /usr/include/something.c, if it's not His Fault. Do Unto Others as You Would Have Them Do Unto Yourself. This translates to: If you want people to be cool to you because you're a staffperson, you have to be nice to them. Even if they don't capitalize their 'I's.' A great man once said, 'I Like Cheese.' A squared plus B squared equals C squared, and (x+2) squared is not, in fact, just x squared plus four. II. Operating Systems I use Linux. I enjoy it. MUSH works beautifully on it. I would imagine that it would also work nicely on FreeBSD and BSDI systems. There is a list of the systems on which it has been tested, and supposedly Javelin tests his MUSH (moment of silence) on a SPARC. I tried running a MUSH on a recent release of SOlaris, and had absoulutely no luck doing anything, thanks to some kind of conflict between Solaris' compiler's setting between ELF and a.out binaries...some mysterious guy came in and fixed it, and it was a bizzare machine besides, so it could've just been me. Anyway, that's something I /can't/ help you with--mail Javelin! :> III. Credits: When I say 'I speak from experience,' I do not mean to imply that I am experienced or know a great deal about much of anything; I mean, I have seen other people screw up, and managed to make a wiseass remark at the time. Okay, that's even wrong--not even other people screwing up, just seeing stuff happen to or with someone, and /then/ I made the wise crack. - Isis @ Legacies, for limitless patience and lots of insight; - Arien @ Dragonsfire, for all the right answers, - Kaeldyn @ Nexus, for The Way Things Ought To Be, - Quinn @ Nexus, for Every Day is Saturday, or I Love Everyone - Osiris @ Legacies, for 200 ways to kill a man, - Nut @ Legacies, for being so durn cute, - Basil, Ahmed, Feynman, and Queue@Holomoo, for being experiences, - Javelin, for answering lots of mail, - Loreli @ Dragonsfire, for Comic Relief, - All the people about whom I have made snide remarks, and would they please not hurt me very terribly. IV. History of The Guide(tm) Nobody's going to read this, but I really like wasting time and space, almost as much as I like wasting money. Edition 1.0: The First Draft. Didn't even proofread the thing. Edition 1.01: Revised first draft, replaced some obvious things Javelin pointed out and some not-so-obvious things that no-one will notice. Edition 1.02: Added table of contents plus dripping sarcasm. Regards, Shoo, aka Sam Knowlton