Line Games Hat

LINE GAMES

Reaction to last issue's LINE GAMES...

The Generation Game!

CompuServe Mail
From: Richard Bartle
Subj: THE MESSAGE

Hi! Just a short letter [ :-) Ed.] about an article in issue 4 ot THE MESSAGE: in response to Blane Bramble's article "Line Games", on pages 10 to 11.

As his first generation, Blane gives ADVENTURE. I find this surprising! His reason is that "without ADVENTURE, there would be no MUGs". Well, that's simply not true: Roy Trubshaw's initial efforts concerning MUD1 were sparked off by his discovery of a way to implement shared, writeable memory on a DECsystem-10 mainframe, and he'd have written a multi-user game with it whether he'd seen ADVENTURE or not. Similarly, my own influences were more from D&D than ADVENTURE, which I regarded as too directed; there's much more freedom in a game like MUD than there is in a single-player game like ADVENTURE - you're not tied down to a world in which all there is to do is solve puzzles.

Generation 2 games are cited as being MUD1, SHADES and MIRRORWORLD (I'd also have included GODS). What isn't mentioned is that MUD1 itself was the third rewrite of the game. The games that were written by MUDl players tended to make implementational errors which had been removed in the rewrites of MUD1 itself, and therefore some of them were more limited than MUD, the game that came first. SHADES' containers, for example, were a notorious example of a backward step.

Generation 3 worlds appear to be the same as generation 2 worlds except with more original settings. I don't see these as anything fundamentally different to generation 2 worlds, personally.

The fourth generation is supposedly games where you can add objects (but not code) to your game. It's not actually all that hard to add a facility to incorporate commands, puzzles etc. to a game, once you can add objects, but it's more sensible not to! If full-blown code is allowed, then unless all your coders are expert programmers, there'll be bugs and crashes all the time. It's things like recursion, conditionals and function definition that are at the heart of what a programming language does. I don't blame AVALON for not letting people program their own puzzles and the like - it's a recipe for chaos (well, for CHAOS WORLD OF WIZARDS anyway!).

The final generation of games, the fifth, Blane says are those which allow the actual code to be written on-line. What an advance! Well, yes, except remember I said that the original MUD1 was a third rewrite? The version before it actually DID have all that Blane says fifth generation games should have! You could code directly on-line - indeed, it was the ONLY way to add rooms, objects, commands. puzzles, words, etc. to the game! The reason we took it out, however, was because although that sort of thing is fine when you're developing a game, it makes for a thoroughly rotten creation. Unless there is only one person doing the additions, or one person in overall editorial control, the following tends to happen: the size of the game balloons, so you can never find anyone; there are spelling/grammar/punctuation/typing mistakes everywhere; there's no consistency of depth or breadth; objects with meaning in some rooms have none in areas designed by other people; all semblance of atmosphere is lost; styles vary as much as the programmers do; the game is forever crashing as people test their additions (and boy, do they need testing!) .

The facility to add things to a game while it is running is much cherished by some players, particularly those on InterNet, and I confess that I like the fact that it allows many more people access to the creation and design of their own games than would be possible otherwise. In the long term, though, the best games are going to be the ones where building isn't allowed, rather than the ones where it is. Rarely is a novel worth reading if it has two authors, and it's the same with multi-user adventures.

I think the reason I'm at odds with much of Blane's classification is that he's used the normal idea of 'generation' (i.e. 'descended from the previous generation') but wrapped it up with what he sees as technological advances. However, I feel he's been over-optimistic, in that some of the advances are actually just re-emergences of what was already in earlier generations, or may make no appreciable improvement to the general technology level of such games. The supposition that being a fifth-generation game is better than being, say, a third-generation game (Blane doesn't say it is, but it seems implicit) doesn't follow from this understanding of different 'generations'. Only different TECHNOLOGICAL generations will normally allow such generalisations to be made. I'd have no qualms about the following definition of different generations, for example:

O Coded directly in a conventional language like C (eg. FEDERATION II).

1 Objects/rooms, some commands in a definitions file, with the more difficult actions and concepts coded directly into the interpreter (eg. MUD1, SHADES, MIRRORWORLD).

2 The entire game coded in a special language designed explicitly for the purpose of writing multi-user adventures. No functionality is hidden: you could write a compiler for the language within the language itself (eg. MUD2).

The point is, though, that whatever you use to determine what 'generation' a game is, you ought to say what dimension the 'line of descent' follows. If you don't, the default would naturally be that something in generation N+1 was created as a response to something in generation N. Blane's list of generations is, in this respect, very good; it's just the way that each generation is explained as if it were an advance on the previous one that worries me.

Keep up the good work!

Best wishes,

Richard Bartle


Richard A. Bartle (richard@mud.co.uk)
21st January 1999: tmsum93l.htm