Series Info...#1: Introduction

by Richard Bartle
September 05, 2001

I have a problem with writing articles to do with games.

Because I co-wrote the first MUD and am therefore one of the few people to have what passes for name recognition in this field (sigh), anything I pen is meticulously picked over by flocks of players eager to discover the extent to which I’m a has-been. I’d hope that occasionally I surprise, and deliver a juicy morsel or two, but inevitably there are some who find my words not quite to their taste and others who actually choke on them. A few deliberately look for the worst bits of gristle so they can advise anyone who’ll listen to keep away. The result can rapidly get out of hand.

As a consequence, I have to be very careful if write anything remotely controversial. Sadly, however, I am rarely careful enough and have to pay for what I write ten times over. See if you don’t believe me...

There are two main difficulties I face. The first is that some people come to believe that whatever I’m advocating was written especially for their specific character in their specific game, when more often than not it doesn’t apply to them at all. I end up a laughing stock on servers I’ve never even heard of.

The second difficulty is that people read what they think I wrote instead of what I actually wrote. I have to tell them ever so politely that no, I have never proposed giving killers a free rein; that yes, I am quite aware of what would happen if they did have a free rein; and that uh, I thought I was writing about the business models of graphical MUDs, not the purity of their respective combat systems.

Thus, if I’m going to write a series of articles for Skotos, I need to figure some means of wangling it so that I don’t spend more time answering emails and forum postings than I do writing my pieces in the first place.

OK, I won’t talk about players.


Players are the most important component of a MUD, be it textual, graphical or otherwise. Without players, you have nothing but an intellectual exercise. The players should always come first, and the game should be designed with consideration of what the players will do in it always to the forefront.

I agree, this seems a ridiculously obvious point to make, but it’s only in recent years that designers have come round to thinking, well, gee, you know, maybe this game isn’t my personal sandpit, and maybe people really will go play someone else’s game if I don’t spend time making this one fun.

In part, the old attitude prevailed for so long because players couldn’t play anyone else’s game, but now that Internet access is ubiquitous people can jump ship a lot easier — or choose a different ship for their voyage from the very beginning. We’re still seeing arrogance from some of the big, graphical MUDs, of course, because they don’t have much competition to speak of as yet. However, this will pass; if you think EverQuest is addictive, remember that 60% of the people who bought a copy didn’t.

Reluctant though I am to say it, the debate about what players actually want from a game was probably sparked by a paper I wrote 5 or 6 years ago, Players Who Suit MUDs. Prior to that, people talked about technical aspects of game design, or the integrity of game worlds, or class balance, or whether hack & slay was better than slack & hay, or a score of other interesting but insular topics. If they wrote about players at all it was to disapprove of the cross-gender play that goes on.

Nowadays, people write about players. Eventually, someone will come up with a better way to model player interactions than I have, but my principal goal was getting players on the agenda at all; in this regard, I think my paper has done its job. Whether you agree or disagree with what I wrote, at least you’re thinking about players now.

Given, then, that players are so important, why am I not going to talk about them?

Easy: because they talk back! Lots of them! All at once! I’d spend my whole life doing damage limitation!

Let’s Get Technical

OK, so there is another reason...

Skotos’ reputation for technical excellence means I can write stuff here that would be out of place elsewhere. I can talk about parsers, or binders, or sensory propagation, or help systems, or protocols (I’m so proud of my HTML/JavaScript client!); I can talk about anything! I don’t have to talk about players, so I shan’t.

Part of what spurred me to do this was the realisation that in some areas modern MUD design is behind what I implemented for MUD2 back in 1985. I was alarmed to learn from Trials, Triumphs & Trivialities #20 that inheritance is still dragging its knuckles as it walks, grunting at passing mammoths. I have a version that can run gracefully at speed, and that doesn’t fight like a bear when you try to implement it. There are better solutions, of course — programming language design has advanced considerably since 1985 — but if people aren’t told what works in the first place then they won’t know something that works better when it comes along.

I’ll start my series, therefore, discussing inheritance systems: what you have now; why it’s dud; what you really want; how to go about getting it. This could conceivably help people who are thinking of writing their own MUDs from scratch, and it doesn’t involve players so I won’t get savaged. Hooray!

Except programmers are people too.


Recent Discussions on Notes from the Dawn of Time:

jump new