Line Games Hat

Blane Bramble on What's New in MUGs?

It seems at least one person read my attempt to define MUG generations - and replied to them, making some very valid points, some of which I shall address here. Others I shall simply ignore (oh the joys of being egotistical...).

Perhaps, the biggest problem in trying to dcfine some hierachy of MUGs is due to the ever-changing nature of them. Games are rewritten or upgraded regularly as new technology and equipment becomes availablc, and often it is difficult to decide quite where one version ends and another begins. Also people have different views as to what qualifies as a different generation. MUG writers are more likely to take a technical view (it's written in Extended-COBOL 2/99 with full Object Disorientation enhancements, so it must be Generation-10), and players are more likely to look at the sophistication of the setting and how their characters can interact with the game (it doesn't understand G ALL, so its Generation 0). On top of this, any attempt to define a generation@ is almost bound to be out of date the moment it is written.

STRUCTURE

Now, back to where I left off in thc previous article... Having tried to define a structure to fit games into, now to try and look at more of what the future might hold. Though, these ideas were originally drafted in 1990, not an awful lot has happened to change them. Modem speeds may have increased, but 2400 with MNP 5 is still about the maximum standard for MUGs.

GRAPHICS

So what does the future hold? Perhaps the most obvious conclusion, and probably the most popular is 'graphics'. Looking at MUG's, most players dream of having an interface similar perhaps to that used in Populous, or maybe in Dungeon Master, whereby you can actually SEE your surroundings, in glorious technicolour (or in my case, glorious mono, oh well). With faster modems and using dedicated terminal software, a few calculations seem to indicate this is possible. 2400 baud allows 240 characters a second. If it requires on average 5 bytes for a graphical command, that's 48 graphical primitives a second; and if those primitives are complex enough, that - as they say - will do nicely.

This however ignores a number of facts. One, the technology at the host end to manipulate a database and translate it to a 3-dimensional or planar view is expensive in terms of processing power. Secondly, the text interface is almost ideal for a game where experimentation is often the key to working things out - Parody has 250 verbs, having them all on a pull-down menu would not only be unwieldy, but give far too much away. Also. for detailed examination, text is vital. Graphics can give an overall image. but there is nothing like prose to actually describe something in detail.

So, we need both a textual and graphical interface, probably using separate windows in a similar way to some graphical adventures, well that's not too hard, but doesn't really address the problem that it's much easier to overlook (or simply miss out on altogether) possibly-important data with a graphical representation than with a text description. This in itself might not be a problem (was that a dragon's ear you saw momentarily pop up over the wall, or did you imagine it?), but with players using different machines, with different graphical capabilities, it might put certain players at a disadvantage.

Why is this so? Quite simply because the resolution on a graphics screen is finite, so when a line is drawn diagonally from (x,y) to (a,b) it is jagged - however the exact route the line takes is dependant both on the resolution of the screen, the pixel ratio height:width, and the algorithm used. Now if we have a lot of information on the screcn, much of the time it's going to be next to other information. If a particular piece of information is small enough (say a demon's red eye peeking out from around a wall), and we draw a diagonal line adjacent to it on one type of screen, on another it may simply overwrite it. The problems are, no doubt, surmountable - but from the coding point of view, developing a graphics system that works, is fast, flexible and linked to a fair playable game, is much more than just adding a few fancy pictures to the screen...

NEXT...

Next time, we start to get a bit technical and look at some of the methods behind MUGs, and how certain effects are achieved. With luck it will help players understand games a little better, and maybe provide budding MUG writers with a few hints...


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