Archive for March, 2007|Monthly archive page

very small talk

Alan Schwartz, AKA Javelin of PennMUSH, just released the first in I hope a long series of quality podcasts about mushes. Check it out:


users persist space persists users

Raph Koster threw down a pretty good post today. In the light of developing this RP mush (if you don’t know a RP (roleplay) mush is a mud with less emphasis on coded systems and more emphasis on player collaboration, storytelling, etc.) I’m thinking about these very concepts:

  • space
  • persistence
  • users

Space is at the top of the list and the top of my mind lately. Historically space in a mush game has gone through some twists and turns, from the free-for-all anything goes topologies of early social mushes, to strictly laid out game grids, to dynamic space creating and destroying rooms to save on DB space while simulating a huge world, to RP ‘stages’ and philosophies that decried large grids as a RP killer.

While I agree in principal with the idea of RP stages, I don’t think it takes advantage of the space that you can represent in a mush game. However some mush players are not interested in typical mud areas, zork-like adventures, or anything so rigidly defined. So the idea would be to take advantage of the mush space without really representing the game world as either a straight-up grid or a series of interconnected stages (which, when you get down to it, is just a game grid anyway).

To go off on a tangent: forgetting about the virtual physical space for a second, take a look at Raph Koster’s list of what we talk about when we talk about space:

* distance
* vectors
* relationships
* sizes
* eyelines

How could you transform these concepts to suit the strengths of a mush game?

One word: Shock.

Shock: Social Science Fiction is a fiction game of culture and future shock. Based on the works of Bruce Sterling, Kim Stanley Robinson, Ursula K. LeGuin, and Philip K. Dick, the game pushes the players to make stories that matter to them — stories about politics, philosophy, love, and death.

I’m kind of….uh, amazed that this theme describes the mush I have in mind pretty well. The Shock system even uses some of the same mechanic concepts I’ve come up with so far.

I’ve yet to get my copy of the game, but one thing that leapt out at me from reading the reviews is the description of the Grid, a table of issues (e.g. morality) across the top row and shocks (e.g. religious domination, basically an aspect of the future world) down the left column. Players occupy the intersections of issues and shocks, and each player has narrative control over some issue and/or shock. So basically you have a web of players on this grid; you can define relationships, vectors, distances.

This system looks really good — there are a lot of things that could suit a mush. I’ll have to give a detailed review later.

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.

Oh the humanity

Picked up my copy of Second Person today. It looks really good!

And to top it all off, I got the Ubuntu book Ubuntu Linux for non-geeks. Maybe I’ll print myself a ‘non-geek’ sticker. The upshot of the story is that I’m writing this post from my new Ubuntu gnome desktop! Ubuntu 6.06 installed flawlessly on my (1999) 600x. Everything works. My wireless card even works better than it did under Windows 2000. Go figure.

Anyway, I’m not planning at the moment to use this system for IF, but I do have a notion to get a mush server running….the thrills never stop.

IF Art Show deadline set

Marni Parker has made it official,

IF Art Show deadline May 18

This is good news. Planning for my Karinth area to be done by the end of this month, so I have almost a month and a half to write something for the show.

why can’t little Susie read?

After busting around some bricks today, we stopped at a bagel shop for lunch (whose owner, outta Brooklyn, claimed the best bialis in town…just don’t move to Seattle for the biali, OK?). There in the P-I I read this article by Cecelia Goodnow (is that her real name?):

Teens buying books at fastest rate in decades.

Pull quote: “”We are right smack-dab in the new golden age of young adult literature.”

However the article mentions:

the recent gloomy update from the National Assessment of Educational Progress, which found that 12th-graders nationally scored lower in reading in 2005 than in 1992, with scores virtually unchanged since 2002.

Declines were seen at all levels except the top 10th percentile of students — the teens who presumably make up a good share of the book-buying public.

But remember that reading assessment is not cut and dried — how accurate is the NAEP update? What’s clear is that kids are reading more books, and kids who read turn into adults who read (until they have kids, I guess, and have no time to read).

How many kids are playing IF? I know quite a few kids play muds, but IF seems closer to YA literature than muds — most muds, anyway. Maybe this is a prime time for an IF author to write and market a YA IF. I wonder how well the YouTube and MySpace kids would respond to it…if this article is any indication, maybe the response would be pretty good.