Creating a Fantasy World on the 8080

Although personal computer owners have devised a remarkable number of applications for their machines, game playing probably still ranks as the number-one use. Besides providing entertainment, games can be challenging and educational; in addition, games are often fascinating programming problems.

The most mind-stretching computer games yet devised may be the fantasy-adventure games which have become popular in recent years. All of the current fantasy-adventure games, including Adventure and Zork, seem to be based on Dungeons and Dragons. Dungeons and Dragons is a noncomputerized game developed by Gary Gygax and Dave Arneson in the late 1960s. In Dungeons and Dragons, as in its computerized counterparts, the player represents a character in a fantasy world, taking part in great adventures, slaying monsters, and accumulating treasures.

The success of such a game, of course, depends upon the program's ability to produce a rich fantasy world; that is, an environment which poses many interesting problems for the player, and which responds in a reasonable way to the player's attempts at problem solving. For example, if the player finds matches and a candle in the course of the game, then the program should allow the player to light the candle when entering a dark chamber. A richer environment would also react appropriately to the player's attempts to light other objects with the matches (“DON'T BE SILLY... SWORDS DON'T BURN!”), or to use the candle in some unintended manner.

Creating such a rich world requires a program which possesses a relatively large vocabulary and a great deal of logic to determine whether or not the player's actions are reasonable. It is also necessary for the program to have thousands of words of text to describe places, objects, and the results of any given action. There requirements are especially difficult to meet on a personal computer, where main memory is very limited and disk accesses are slow (by large computer standards). The problems, however, are certainly not insurmountable, as demonstrated by the existence of CASTLE, the author's 8080-based fantasy-adventure game.

Listing 1: Portion of a typical CASTLE game.

?LOOK
THIS IS THE KING'S CHAMBERS
THE ROOM IS DOMINATED BY A MASSIVE OAK BED, BUT ITS FURNITURE ALSO INCLUDES A VARIETY OF LARGE CHAIRS AND CABINETS. STAIRS IN OPPOSITE CORNERS LEAD UP AND DOWN, AND A DOORWAY LEADS WEST.

IN THE ROOM YOU SEE:
ERMINE ROBE

?GET THE ROBE
DONE.

?CLIMB THE STAIRS.
YOU ARE IN THE KING'S LOOKOUT
THE NORTH AND EAST WALLS OF THE ROOM CONTAIN A NUMBER OF SMALL WINDOWS. A SMALL DOOR LEADS TO THE WEST. ON THE SOUTH WALL IS A CURIOUS STONE INLAY, ROUGHLY THE SIZE OF A DOOR.

?OPEN INLAY
THAT WOULD TAKE MORE MAGIC THAN YOU CURRENTLY POSSESS.

?GO WEST
YOU ARE IN THE WIZARD'S WORKSHOP
THE ROOM IS FURNISHED WITH SEVERAL WOODEN TABLES AND BENCHES, AND A GREAT FIREPLACE ON THE SOUTH WALL. DOORWAYS LEAD EAST AND WEST, AND SMALL WINDOWS LOOK OUT TO THE NORTH.

IN THE ROOM YOU SEE:
GOLDEN RING

?WEAR THE RING.
AS YOU DON THE MAGIC RING, YOU ARE ENGULFED IN A CLOUD OF THICK SMOKE. WHEN IT CLEARS...
YOU ARE IN THE DEEP FORTRESS
THIS ROOM WAS BUILT AS A 'LAST REFUGE' FOR THE INHABITANTS OF THE CASTLE, SHOULD ITS OUTER WALLS EVER BE BREACHED BY ENEMIES. THERE IS A MASSIVE WOODEN DOOR TO THE SOUTH, AND A DOORWAY EAST.

?EAST
YOU ARE IN THE SIEGE STOREROOM
THE LARGE ROOM IS EMPTY AND COVERED WITH DUST. ROW AFTER ROW OF SHELVES ATTEST, HOWEVER, TO ITS ORIGINAL PURPOSE... AS A SOURCE OF SUPPLIES IN TIMES OF SIEGE. DOORWAYS LEAD EAST AND WEST.

?EAST
YOU ARE IN THE UNFINISHED EXCAVATIONS
THE WALLS HERE ARE OF ROUGH-HEWN STONE. THE FLOOR IS UNEVEN AND COVERED WITH BROKEN ROCKS AND RUBBLE WHICH HAVE FALLEN FROM THE CEILING.

IN THE ROOM YOU SEE:
NASTY RED DRAGON
JEWELLED COLLAR

?ATTACK!
WITHOUT WEAPONS, THAT IS A VERY BAD IDEA!
THE NASTY RED DRAGON ATTACKS, BUT YOU ARE ONLY SLIGHTLY WOUNDED. (COMFORTING, ISN'T IT?)

Listing 1 shows a portion of a typical CASTLE session. The game is implemented in North Star disk BASIC and runs in 32 K bytes, with a response time of several seconds. Most of the program's time is spent in accessing its four major files. These files contain the vocabulary as well as descriptive text and details about the various props. The program itself is very simple, consisting of three basic sections: a command interpreter, a set of semantic routines, and an event routine.

The job of the command interpreter is simply to obtain a syntactically correct command from the player and translate it into a pair of numeric codes (a semantic pair). This is then passed on to the semantic routines. The syntax for CASTLE commands is very straightforward, as shown in listing 2; valid action words are identified by searching a file called VERBS, while object words are found in a file called NOUNS. When a match is found for a word, a code contained in the word's record is placed in the semantic pair; thus, a complete pair will contain a verb code and a noun code. If no match is found, the command interpreter prints an error message (“I DON'T UNDERSTAND THAT”) and reprompts the player.

The semantic routines actually carry out the player's command. There is one routine for each action which the program supports. The first number in the semantic pair (the verb code) is used as an index to the appropriate routine, and the second number (the noun code) is passed as a parameter. In the current version of CASTLE, each semantic routine must decided whether or not its particular action is allowable for the noun specified. For example, the BREAK routine knows that the crystal goblet (noun code 7) can be broken, but the sowrd (noun code 13) cannot. A better approach is to associate a bit string with each noun, using 1s to indicate allowable actions, and 0s to represent illegal actions.

Semantic routines currently have access to a number of item attributes. Most of these attributes are stored in a file called PROPS, which has one record for each noun code. The record contains:

Semantic routines may also require information on the player's location in the fantasy world. In CASTLE, the world consists of roughly one hundred rooms, each of which has a unique number. The numbers are used as keys into a descriptive file named MAP. Each record in the map file contains:

The primary users of the MAP file are the GO and LOOK semantic routines. LOOK uses the text in the current room's record to describe the room, while GO uses the record's transition array to determine the next room that the player will enter.

Listing 2: CASTLE command syntax, including examples of valid commands. “Action words” and “object words” are any words which appear in the appropriate files. Square brackets denote an optional word; vertical lines denote a choice of one object from several.

<command> ::= <action word> [<object phrase>][<punctuation>]

<action word> ::= (from VERB file)

<article word> ::= A | AN | THE

<punctuation> ::= . | !

EXAMPLES: GET THE GOLD! GO NORTH DON ARMOR LISTEN.

For purposes of the GO routine, the words NORTH, SOUTH, EAST, WEST, UP, and DOWN are defined as object words and stored in the noun file. The routine can therefore decide which entry in the transition array to use, based on the noun code.

After the player's command has been executed by a semantic routine, CASTLE enters the event routine, which handles all periodic and random events in the fantasy world. Events are currently limited to the movements of creatures in the castle, and possible attacks by hostile creatures in the same room as the player. Other possible events include: candles burning out, magic visions which occasionally appear, or reduction of the player's load-carrying and fighting capacities due to fatigue. Depending on their type, events may occur either randomly or periodically (once every n turns).

Once the event routine has completed its job, control is returned to the command interpreter for the player's next command. This control loop may be exited, and CASTLE terminated, by entering a QUIT command. QUIT is simply another semantic routine which closes files, prints the player's final accumulation of wealth, and stops.

CASTLE currently has twenty-five semantic routines, the largest of which contains twenty-four lines of code. Coding was greatly simplified by the fact that the most important information is contained in the files described previously rather than being embedded in code.

Unfortunately, the heavy dependence on file access is somewhat of a disadvantage on a typical microcomputer system. The CASTLE command interpreter currently performs sequential searches of the NOUN and VERB files. For this reason, the command vocabulary has been limited to approximately one hundred object words and sixty action words. Note that many of these words are synonyms and that the actual number of props and actions is more limited. A more sophisticated command interpreter might be designed to perform binary searches on the vocabulary files, thus allowing more words to be searched in the same amount of time.

Frequent accesses to the PROPS file also cause a noticeable delay. With sufficient main memory, a fantasy-adventure game could keep the prop information in memory-resident arrays.

In addition, more fundamental changes in the implementation could be made to greatly expand the possibilites of the game. The command interpreter could be made more sophisticated to accept a more general set of commands. The game could be modified to allow several players, who could either work together as a team, or compete for treasure. Also, the various files could be expanded, eliminating the need for game-specific logic in the program. Using such a scheme, new fantasy adventures could be created simply by replacing the files.

The real pleasure in fantasy-game development, however, is not simply the solution of programming problems, but the fact that the fantasy world the game portrays is limited only by the author's imagination. <