Adventurers Club Ltd. Member's Dossier, December, 1988 Hat

Richard Bartle's Pages

This issue, I thought I'd talk a bit about something we can expect to see pervading the Multi-User Adventure (MUA) field over the next few years, computer graphics. I had been saving this particular subject up for when I couldn't think of anything else to talk about, but I found to my surprise that some of the more futuristic aspects are a little closer than I anticipated, and I may be overtaken by events if I hold back much longer!

Some of the more fundamental changes I expect to see soon in MUAs are due to a ripple effect from normal, single-user adventures. In particular, due to the recent breakthrough of graphics in SUAs, pretty pictures are sure to be playing more of a role in the MUAs of the future. The technology of having graphics for MUAs has been around for ages, but hasn't been implemented mainly because of the wide variety of computers used by the players.

Basically, in a graphics MUA the players run special comms software which is written to marry up with a particular class of MUAs (eg. all the ones written by the same company). In the course of play, the MUA sends down the phone line the normal text you get from other players, plus special control codes which the receiving software converts into graphics. It doesn't send down the pictures directly, it uses more like "draw a tree here, a house here, and a player here". Alternatively, if the comms software is specific to a particular MUA only, then the control codes could translate into "draw background picture 219, with a player here".

There is a third alternative, and this is to send down the phone line a description of what is there, and let the software itself work out how to draw it. This means the game has to have a very ordered topography, eg. a network of squares, so the terminal software can interpret it in a quick and algorithmic fashion. The same thing was tried in SUAs some time back with "Valhalla", but more recently the "Dungeon Maste phenomenon has taken the idea a whole lot further. From rather simple internal representations for rooms, sophisticated graphical output can be generated. All the receiving software needs to know is that there is a wall to the left, an opening to the right, a passage leading off to darkness in front, with a mummy standing 3 squares down, and it can knock up a picture for that on-the-fly. Most inpressive!

Now I was expecting to see the first MUAs of this sort emerging from the USA some time this year. My reasons for this are that there already is a similar sort of thing for flight simulators, and that one of their existing multi-user role-playing games, "Island of Kesmai", bears a very striking resemblance to a multi-player "Dungeon Master" without the fancy pictures. Both the multi-user flight simulator and IOK are produced by the same company, so you can assume they'll be modifying their existing terminal software for IOK to draw nifty pictures.

However, the UK has beaten them to it! Reports are out that a game called "Bloodstone" will be launched on Prestel shortly. Its initial specifications (given in Popular Computing Weekly) are impressive, with 2,500 mobiles, up to 112 simultaneous users, and 4,500,000 locations. How big the game "feels" to the players is yet to be seen, though - if there are that many locations, then even with 112 players you'd have to search through around 40,000 of them before you meet anyone else! Clearly, players must be able to interact across several locations, and the granularity of this gives a rough idea of the "room" size in the game.

One problem you get in making graphical versions of MUAs is how to draw players. It's clear that players MUST be drawn, but they need to be made to look different from one another, at least close-up. The way to implement this is to supply with the game an "identikit" program. The players sit down and create a face for their persona by putting together different features of their choosing. Even by having just 3 basic face shapes, 3 eye colours, 3 mouth shapes, 3 nose shapes, 4 skin tones, 4 hair colour, 4 hair lengths and 3 degrees of waviness, you end up with 15,552 permutations. That's just with a small number of features - I'm sure there are more than 3 basic nose shapes, and I didn't even mention beards & moustaches!

With an identikit, drawing people becomes easier. The basic shape of the body we can assume is defined by sex and clothing. The face is now reduced to a number which encodes the identikit picture. The computer running the game need only tell the local program to draw a woman in a long green gown with a face that looks like 3/2/2/1/4/2/3/1/ and the graphics module can do the rest.

Putting graphics into existing MUAs is not so simple, though. The problem is, their rooms are very different from one another. Some have exceedingly complicated descriptions employing components not used elsewhere. It's alright drawing forests and seas, but ruins, underground lakes, dwarf-sized treasure chambers, rings of stones - most are only in the game once. The "Dungeon Master" style of graphics won't work for such environments, and the "build a picture from these components" approach only succeeds for some of the more common types of room. The only real solution is to have a picture for all the unique rooms, which is OK except since MUAs typically have several hundred rooms, most of them wouldn't have a picture at all or you'd need a dozen discs to store the images! And what about games like GODS and MUD, where the top level players can create their OWN rooms, on-line?

To have a MUA which deals properly with graphics, it has to be written specifically with that in mind. You also need to write the appropriate comms software for each of the machines you expect yout players to have - and most modem-users do NOT opt for the same class of micro at the moment. However, if graphics succeed in getting MUAs into computer magazines on a regular basis, and attract people to these games who would otherwise ignore them, then it can't be a bad thing.

I just wish I could draw, that's all!


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