Buckets:

bl791
/

IFDB

Files

xet

bl791/IFDB / articles /byte80_nicholson.html

bl791

about 1 month ago

download

raw

13.2 kB

	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<html lang="en" xml:lang="en">
	<head>
	<title>Creating a Fantasy World on the 8080</title>
	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
	<meta name="Description" content=""Interactive Fiction as Literature" is an early literary analysis of IF.
	Originally written by Mary Ann Buckles and published in the May 1987 issue of BYTE magazine.
	Transcribed into HTML by David Welbourn." />
	</head>

	<body style="padding-left:0.5in;padding-right:0.5in;background-color:white;color:black">

	<h1>Creating a Fantasy World on the 8080</h1>

	<p style="text-align:center;width:25%;border-top:solid black 1px;border-bottom:solid black 1px"><b>Robert T Nicholson<br />
	4920 Harmony Way<br />San Jose CA 95130</b></p>

	<p>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.</p>

	<p>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.</p>

	<p>The success of such a game, of course, depends upon the program's ability to produce a <em>rich</em> 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.</p>

	<p>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.</p>

	<div style="float:right;width:60%;border:solid black 1px;padding:5px;font-size:80%">
	<p><b>Listing 1:</b> <i>Portion of a typical CASTLE game.</i></p>
	<p>?LOOK<br />THIS IS THE KING'S CHAMBERS<br />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.</p>
	<p>IN THE ROOM YOU SEE:<br />ERMINE ROBE</p>
	<p>?GET THE ROBE<br />DONE.</p>
	<p>?CLIMB THE STAIRS.<br />YOU ARE IN THE KING'S LOOKOUT<br />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.</p>
	<p>?OPEN INLAY<br />THAT WOULD TAKE MORE MAGIC THAN YOU CURRENTLY POSSESS.</p>
	<p>?GO WEST<br />YOU ARE IN THE WIZARD'S WORKSHOP<br />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.</p>
	<p>IN THE ROOM YOU SEE:<br />GOLDEN RING</p>
	<p>?WEAR THE RING.<br />AS YOU DON THE MAGIC RING, YOU ARE ENGULFED IN A CLOUD OF THICK SMOKE. WHEN IT CLEARS...<br />
	YOU ARE IN THE DEEP FORTRESS<br />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.</p>
	<p>?EAST<br />YOU ARE IN THE SIEGE STOREROOM<br />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.</p>
	<p>?EAST<br />YOU ARE IN THE UNFINISHED EXCAVATIONS<br />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.</p>
	<p>IN THE ROOM YOU SEE:<br />NASTY RED DRAGON<br />JEWELLED COLLAR</p>
	<p>?ATTACK!<br />WITHOUT WEAPONS, THAT IS A VERY BAD IDEA!<br />THE NASTY RED DRAGON ATTACKS, BUT YOU ARE ONLY SLIGHTLY
	WOUNDED. (COMFORTING, ISN'T IT?)</p>
	</div>

	<p>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.</p>

	<p>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 <i>semantic pair</i>). This is then passed on to the semantic routines. The syntax
	for CASTLE commands is very straightforward, as shown in listing 2; valid <i>action words</i> are identified by searching
	a file called VERBS, while <i>object words</i> 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.</p>

	<p>The semantic routines actually carry out the player's command. There is one routine for each <i>action</i> 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.</p>

	<p>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:</p>

	<ul>
	<li>a <i>label</i>, such as “BEAUTIFUL STRING OF PEARLS”, which routines may use in describing the object
	to the player</li>
	<li>the initial room <i>location</i> of the object, for use in CASTLE's initialization process (if this number is
	negative, CASTLE places the object randomly)</li>
	<li>the <i>value</i> of the object, which is used by the GET, WEAR, and DROP semantic routines for keeping track of
	the player's accumulated wealth</li>
	<li>the <i>weight</i> of the object, which is used by the GET, WEAR, and DROP routines to determine how much a player
	can carry.</li>
	</ul>

	<p>CASTLE also maintains, in a large array, the current location of all objects.</p>

	<p>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:</p>

	<ul>
	<li>the name of the room</li>
	<li>a one- to three-line description of the room</li>
	<li>a <i>transition array</i>, which lists the numbers of the rooms that can be reached by traveling in any one of
	the six directions which CASTLE understands. (The first number in the array is the room reached by going north, the
	second by going east, etc. A value of 0 in the array indicates that there is no path in that direction.)</li>
	</ul>

	<p>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.</p>

	<div style="float:right;width:60%;border:solid black 1px;padding:5px;font-size:80%">
	<p><b>Listing 2:</b> <i>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.</i></p>
	<p><command> ::= <action word> [<object phrase>][<punctuation>]</p>
	<p><action word> ::= (from VERB file)</p>
	<p><object phrase> ::= [<article word>] <object word></p>
	<p><article word> ::= A \| AN \| THE</p>
	<p><object word> ::= (from NOUN file)</p>
	<p><punctuation> ::= . \| !</p>
	<p>EXAMPLES:   GET THE GOLD!    GO NORTH    DON ARMOR    LISTEN.</p>
	</div>

	<p>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.</p>

	<p>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 <i>n</i> turns).</p>

	<p>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.</p>

	<p>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.</p>

	<p>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.</p>

	<p>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.</p>

	<p>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.</p>

	<p>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.
	<span style="font-family:Webdings"><</span></p>

	<p><small><b>210–214</b>     July 1980 © BYTE Publications Inc</small></p>
	</body>
	</html>

Xet Storage Details

Size:: 13.2 kB
Xet hash:: 679243e801c8f444586a218515e19fc650a00ea8f5c6125e6f60966276a6d896

Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.