MOSAIC

Following on from last Issue's look into the reflection of the MirrorWorld, Pip Cordrey also spoke about the progression of adventure games in the years to come. And his interest is not merely passing either, for he is currently working on a little project which should open a few doors on the static groundwork of the adventure game format. With different approaches to the problem being tested all the time and whispers of everyone's new system being unveiled very soon, we should see some extraordinary changes in the layout of our well-known beast. This could be one of them, for although this article was intended primarily for the multi-user sector, the points it raises are equally valid on every level of the home computer market.

MOSAIC

A 3RD GENERATION ADVENTURE GAME

CONCEPT BY PIP CORDREY

Introduction

Traditionally, Multi-User Adventure games have been strictly based upon rooms (or 'cells') with discrete interconnections. When players move they always go from one room to another. When a player says something it will only be directed to people in the same room. More importantly, objects are only visible in the room that they are in, and other features of the game are normally only available in long room descriptions which (a) have to be written and (b) are more often than not turned off after a few goes because they are an incumbrance on a communications system with limited bandwidth.

The Land

The MOSAIC concept defines the land in which the game is played in a completely different way. All features are actually available as game elements and are defined as size, shape and position. Unless a specifically detailed description is required for a particular location, the game itself generates descriptions of what a player can see automatically, including processing for line of sight and atmospheric conditions. Also. rather than working on a room-by-room basis, everything is handled in terms of distance - the game is defined on a co-ordinate system of 1m cubes, and everything else revolves around this fact.

Here are a few specific examples of how things work.

Movement

Currently movement is handled by supplying directions in which the player is allowed to travel (eg. N, S, E, W, etc.), and then supplying identifiers for rooms to link one room to another in a particular direction. In a MOSAIC environment, movement can also be accomplished in N S E W directions, but these simply alter the co-ordinates of the player. Therefore, if a player is at (100,100,0) and he types NE, he may end up at (103,104,0), and has therefore moved 5m in more-or-less that direction. Moving UP is only possible if, when the player has moved up, there is a surface on which he can stand at the new position. For example, putting a player at (100,100,50) will simply cause him to fall 50m (in real time, perhaps) and be crushed to a pulp (1) on the ground. Similarly, walking off the edge of the cliff would achieve the same ends. When the player moves he will see descriptions of where he has moved to, but these are dealt with later.

Looking

In current systems, a player is able to type LOOK, which produces a piece of text explicitly typed in by the game's creator and assigned to that room. The description is then augmented by supplying a list of objects that are in that room (these descriptions may be folded into the text of the room description). For speed, the player may select brief descriptions, in which case a single line of text is produced, simply to identify the room.

In a MOSAIC system, there are a number of different ways in which the player is informed of his location. If there is a piece of very detailed explanation required, perhaps for a puzzle, it can be assigned to a co-ordinate (or a set of co-ordinates if, say, a room in a castle is large) and will be displayed when a player is actually at that location and types LOOK. If a player is standing somewhere, he must be on a surface which is always going to be defined as a feature, so the computer may generate a description for the surface (eg. a dusty plain, uneven grassy terrain, etc.). Also, any features at the location and immediately around it are also described by the computer. Additionally, however, the player can type LOOK N or LOOK AWAY TO THE NORTH (assuming the parser can handle this). Note that LOOK N is different from LOOK AWAY TO THE NORTH in its extent. The former would produce a generated description of features that are in the player's line of sight in that direction along a few metres. The latter would probably attempt to resolve everything that the player could possibly see in a given direction, taking into account how good his eyesight is and, of course, whether or not he is wearing contact lenses.

In addition to direct surface descriptions, the computer would be able to generate slightly varied descriptions based on the direction in which the player was facing. For example, if the player were standing on an area of land mapped thus:
========== ========== ========= =========== ======== ============ ======== ============ ======== ============ ======== * ============ ======== ============ ======== ============ ======== ============ ======== ============ ======== ============ where '===' represents grasslands with a dirt track running along it and '*' is the player.

In the above map, if the player were facing north, a (simple) description might read:

>You are on a dirt track, with grasslands on either side.

If the player were facing west, the description would change to:

>You are on a dirt track, facing an expanse of grassland.

Note that, of course, the grassland behind the player is not described because - well - it's behind him. Note that the equivalent of the brief flag in a traditional Multi-User game could simply be a variable indicating the maximum range of objects that should be described, or else (or as well as) a variable indicating the level of detail ie. the maximum size of an object before it is described.

Objects

In current systems, objects appear only when the player is in the same room as the object. The actual description is either folded into the room description or else displayed in a separate list. However brief you have selected room descriptions to be, you cannot turn off object descriptions.

In a MOSAIC system, objects are visible whenever they are in the player's line of sight and range of vision. Therefore, they can be obscured by other things, but do not need to be in the same grid square to be seen.

For example, a dining hall may have a large table in it, on which items are placed. Clearly they are at different co-ordinates from the player, but he can still see them. Also, the player can walk around the table within the room.

Objects will still need descriptions and, in fact, they need more than one, as the description of an object (or feature) will change according to its distance. This is the area of programming your game which requires the most amount of text to be generated.

Mobiles and players follow the same rules as objects insofar as when and how you see them.

Fighting

In normal games, fights always take place within one room. They continue until one person flees from the fight losing points and whatever he/she was carrying, or until one of the combatants is killed.

MOSAIC fighting is rather more sophisticated (and true to life) in that players can move around during fights. There is no fleeing as such, because points are only scored for hits and kills. A player can flee by running off, but the other player may pursue him and, in any case, he will probably be wounded and therefore be moving more slowly. In unarmed combat blows can only be exchanged when the combatants are within 1m of each other - other weapons may have longer ranges.

Note that players' statistics are much more complex in a MOSAIC game, including height, weight, build, fitness, agility, skill (with each individual type of weapon), body temperature, breathing rate, heart rate, blood pressure, endocrinic activity, etc.

* An extra note about movement. In normal games, players can move around as fast as they can type movement commands. In a MOSAIC system, because distances are rigidly defined, players can only move at certain speeds, depending obviously on their physical characteristics. If they move too fast, therefore, they will run out of 'puff'.

Feature Definition

Features would be defined in terms of their position and their dimensions (x, y and z). Clearly, however, shaped objects require more detail. For this two approaches are possible. One is to build the object out of 1m cubes: although this approach is prohibitively expensive for large objects such as mountains, it does have the advantage of allowing exact mapping of contours, so you could, in fact, model an existing object with ease. An altemative way of defining features is to do so in terms of angled faces, which would then be calculated each time a line-of-sight calculation was required. In fact, a combination of these methods would work best, with an editor identifying easy-to-define surfaces and volumes.

Associated with each of these spatial definitions there must, of course, be descriptions of various types, although these could be kept down to a minimum, allowing the rest of a description to be built up from descriptions of objects and other features around the place

Physical Forces

On the whole, traditional systems do not have built-in support for physical conditions. MOSAIC, on the other hand, can have several. Firstly, gravity. When an object is placed such that its co-ordinates are in mid-air, it can fall in real time. Other physical forces that can be included are light - since the sun itself can be a feature of the processing for it would be the reverse of line of sight - and wind - if a feature is given a weight and a volume its density is directly apparent, and so it would float and be moved by the wind if, say, it was a cloud.

Does anyone have any ideas on the future of adventure games? Where will they develop and how will they change to suit the games' climate? Send your comments and criticisms to the usual address. You never know, we may change the face of tomorrow's adventuring.

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