to build a mush

So I’m thinking about making a mush. What do you need to build the basic infrastructure?

Of course my need ain’t your need, but that’s a given, right. So, what do you need?

  • A box to put it in
  • As I wrote before I’ve set up Ubuntu on an extra 500 MHZ, 256 MB PII Thinkpad 600x. This should be adequate for development work.

  • A game server
  • Your main options are Rhost, Tiny, Penn and MUX; some others are Pern and Cobra (?). Penn and Mux are pretty similar and what I’m most familiar with, and I like MUX a little better for the way it’s chat and mail systems are set up. Penn has a nice community site at There are other more fundamental differences but I believe for my purposes they aren’t deal-breakers either way. I think I would go with MUX.

  • Backup and recovery plan
  • Definitely daily backups on the box. Once a week to something offbox — once a month to something off-site?

  • Version control
  • Which I know next to nothing about (this will become a common refrain). I’ll make it easy on myself and say my choice is between CVS and Subversion, though I’ve heard good things about Perforce as well (free for up to two users). Let’s say I go with Subversion. There are a few clients out there to use as well, for example pysvn. Check out a big list at the Subversion site. And oh yeah, the MUX team uses google.code, hence subversion. I expect I’ll be using version control much more for mushcode than the MUX server files themselves, which leads me to…

  • Mushcode unformatter
  • This is mushcode:

    ,77,%b)])]%r[ansi(r,[repeat(*,77)])]%r%b[ansi(hw,On For:

    A mushcode unformatter lets you write that code so your eyes don’t bleed, and then turn it into the glob above to quote into your mush — your mush doesn’t want to see formatted code.

    There are a couple of unformatters available. Adam Dray wrote Formatted Softcode at Electric Soup a couple of years ago, and some of the links to the unformatter scripts still work (except his own script, which now resides at

  • MySQL
  • I’m finally convinced that a mux should use MySQL (the only relational DB I have any familiarity with, there must be others, right? But I’ll just say, use MySQL). Not necessarily to run the game, but definitely as a back end you can periodically dump files into. The nice thing here is when you build your website, you can use…

  • MediaWiki
  • The advantage of MediaWiki is it’s a great place to put all your help files, bulletin board info, really whatever information you have in the game server, and let’s you easily create user permissions so your players can build pages for their characters, post logs, right in the same place. I know that I like to have a website where I can read up on the game. Navigating a lot of help files on a MUX server kind of blows. Another alternative would be something like the Postnuke CMS. Both can pull files from the MySQL DB.

    Currently if you send a MySQL request to the MUX server, it blocks other commands until the DB responds. This could be a problem — though several games using this setup so far are doing OK by all reports. However one alternative would be to run a job once a night to refresh the DB for the website, so your website would update daily. Good enough in my book and avoids the single thread problem. MUX is looking to add some alternatives in the future, so it seems like setting up with MySQL and MediaWiki would be a wise long-term investment.

  • Backbone code
  • Any mush should have certain systems in place before you start to do anything. By systems I mean mushcode or hardcode systems (i.e., written in the server language C and C++ and compiled). Here is what you want:

    • @mail
    • +jobs, a job tracking system in the game
    • a bulletin board
    • a +help system — +help covers your game, help covers the MUX server help

    You may want a web-based set of forums as well for development, but I think for now you can get away with an on-game bb — especially because you’re the only one who’ll be working on it. At some point this post has devolved to me talking to myself. Perhaps this should be expected.

  • Oh wait, I forgot about the game
  • Yeah, the whole point is to make a mush game, right? So I need two things: a design document with two parts, theme and mechanics (in other words the setting and the system), and a style guide, that includes topics like code conventions and typography standards that I can use as a game bible. Accompanying these docs is a graph of…

  • Milestones
  • Schedule, roadmap, targets, whatever — you want to know when you have to hit the ground with what to keep the train rolling.

Did I miss anything? Man, that’s a lot of work.


Adam Dray added some things over at Electric Soup

* A player request system.
* An email registration system.
* An ic/ooc system.
* Tools for organizing the Master Room.
* Tools for organizing parent objects.
* “Old standard” globals: +who, +where, +finger.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: