Writing Adventure Games (Long)
Paul Allen Panks
By: Paul Allen Panks
Years ago, when the first text adventures were being developed, computers
didn't have a whole lot of memory. Thus, text was often used instead of
graphics to describe enchanted worlds and mysterious landscapes. A mythical
monster such as a large troll or hulking dragon would be described not in
pictures but in words.
What made the text adventure popular back then is what books still employ
today: Imagination. We love to read and imagine characters and places in
a story -- especially when it is entirely fictional. This explains why,
in the 1970s, TSR Hobbies successfully launched Dungeons & Dragons
on the heels of J.R.R. Tolkien's release of "Lord of the Rings". Imagination
is at the heart of every great story, and text adventures are no exception.
Almost everyone has (at one time or another) wanted to write a story
about something they did, heard, saw or dreamt up. The sheer amount of
books on the subject of writing give testimony to that truth. People
have been collecting and writing about their thoughts and activities
for thousands of years. This brings culture and families together
into one arena, allowing imagination to bare fruit.
People have often asked me, via email, just how an adventure game
is written. How did I write, for instance, "Westfront PC: The Trials
of Guilder"? What language did I use? Could I show x, y and z how it
was done?
Most of my adventure games -- with the exception of "HLA Adventure" -- were
written in BASIC. Yes, that's right, BASIC. The old language most people
had given up on after the end of the 1980's. With the exception of
PowerBASIC and a few other commercial products, BASIC has indeed
shifted into the background. So why write an adventure game
in such an unused language?
The answer is simplicity. BASIC uses English-like commands and an
easy-to-use structure. It handles strings and arrays well. And I have
been using the language since 1983, when I first started out in BASIC
on the Commodore 64. It's just natural that I turned to BASIC to write
adventure games.
Thus, to answer several requests via email, I will explain how to write
an adventure game. In BASIC. Without any hidden explanation as to what
to does what or how it works. I will explain line-by-line what is
happening in a BASIC adventure (in this case, my game "Orathan",
detokenized from a Commodore 64 listing).
I must first apologize to those who, upon examining the listing below,
notice several unusual characters encased in some PRINT statements. The
listing was detokenized from the Commodore 64 version of my game
"Orathan". The unusual characters are actually Commodore PET ASCII
control characters, ranging from 1 to 255. Some are screen codes
for clearing the screen, changing the text color, and so on. If
converting this game to the PC and Windows, make sure to edit
out these Commodore-specific control codes, as they have no
meaning whatsoever on a regular PC.
We begin by explaining the first ten lines of the program, then
explain at a pace of a few lines at a time. This will take quite
awhile to read, so please take frequent breaks when reading.
Program Initilization
---------------------
0 POKE 53280,0: POKE 53281,0:HP = 25:LV = 2:EX = 0:G = 100:HM = 25:MM = 15:MP = 15:IC = 5:CT = 102:RM = 1:A$ = "":L1$ = "": PRINT CHR$ (14)"“" CHR$ (8): GOTO 50
1 PRINT "/OW SAVING "NA$"’...": OPEN 15,8,15,"S0:" + NA$ + ",S,W": OPEN 2,8,2,"0:" + NA$ + ",S,W"
2 PRINT# 2,HP: PRINT# 2,HM: PRINT# 2,MP: PRINT# 2,MM: PRINT# 2,G: PRINT# 2,RM: PRINT# 2,CT: PRINT# 2,IC: PRINT# 2,DM: PRINT# 2,AC
3 PRINT# 2,EX: PRINT# 2,N: PRINT# 2,V: FOR X = 7 TO 25: PRINT# 2,LO(X): NEXT : CLOSE 2: PRINT "ÄONE.": GOTO 107
4 PRINT "/OW LOADING "NA$"’...": OPEN 2,8,2,"0:" + NA$ + ",S,R"
5 INPUT# 2,HP: INPUT# 2,HM: INPUT# 2,MP: INPUT# 2,MM: INPUT# 2,G: INPUT# 2,RM: INPUT# 2,CT: INPUT# 2,IC: INPUT# 2,DM: INPUT# 2,AC
6 INPUT# 2,EX: INPUT# 2,N: INPUT# 2,V: FOR X = 7 TO 25: INPUT# 2,LO(X): NEXT : CLOSE 2: PRINT "ÄONE.": FOR X = 1 TO 1900: NEXT : PRINT "“": GOTO 100
7 PRINT "“ ÄONTINUE’": PRINT : PRINT "ÄNTER YOUR CHARACTER NAME";: INPUT NA$: IF LEN (NA$) > 16 THEN PRINT : PRINT "łOO LONG!": FOR X = 1 TO 1900: NEXT : GOTO 7
8 GOTO 4
Line 0 sets up the screen display, turning it to black, then assigns
values to player hit points (HP=25), level (LV=2), and experience (EX=2).
Gold values for the player are tabulated in G (G=100). The hit point
maximum is stored in HM (HM=25). Magic points are stored as values
MM (MM=15) and MP (MP=15).
We also see, in Line 0, that the player can carry a maximum of 5
items total (IC=5), and that the game resets every 102 "moves" (CT=102).
The player begins in Room #1 (RM=1). The character set is made
lowercase (PRINT CHR$(14)), and the Commodore/Shift key combination
is disabled (CHR$(8)). The program then jumps to line 50.
Lines 1 through 3 SAVE the player character data to disk, to be
restored later when the player LOADs a saved game (the game
will prompt the player at the beginning with: 'Are you playing
a saved game?'). All of the important variables we discussed
in the preceeding paragraphs are saved to disk as well, including
the values stored in LO(X) -- this contains the room locations of
the 25 items important to our adventure...I'll discuss those more
indepth in a minute.
Lines 4 through 6 LOAD the player character data from disk. This
restores the original game state to what it was previously, essentially
allowing the player character to begin his or her game right where
they left off.
Lines 7 and 8 are a subroutine called if the player responds with
"Y" to the prompt: 'Are you playing a saved game?'. This asks the
player to provide a 16 (or less) character filename for the
saved game data to be load. For example, if the player has on
disk a saved game character named "charlie", the player would
then type charlie, and the game would then be loaded.
Initilization of Data Structures
--------------------------------
Let's examine a few more lines down the listing:
50 PRINT " ÚRATHAN’": PRINT "(Ä)OPYRIGHT 2003 BY żAUL żANKS": PRINT "ţLL RIGHTS RESERVED.": PRINT : PRINT "żLEASE WAIT...": DIM NO$(25),LO(25),M(45,6),DE$(45),VB$(18),EX$(25)
51 FOR X = 1 TO 25: READ NO$(X): NEXT
52 FOR X = 1 TO 25: READ LO(X): NEXT
53 FOR X = 1 TO 43: FOR Y = 1 TO 6: READ M(X,Y): NEXT : NEXT
54 FOR X = 1 TO 43: READ DE$(X): NEXT
55 FOR X = 1 TO 15: READ VB$(X): NEXT : FOR X = 1 TO 25: READ EX$(X): NEXT : GOSUB 800
56 PRINT "“ţRE YOU PLAYING A SAVED GAME ( Y’/ N’)";
57 GET K$: IF K$ = "" THEN 57
58 IF K$ = "Y" OR K$ = "ł" THEN GOTO 7
59 IF K$ = "N" OR K$ = "/" THEN GOTO 75
60 GOTO 57
Line 50 prints a small title screen -- not much, but it still resembles
a title. It also dimensions important arrays. These include
NO$(25), LO(25), M(45,6), DE$(45), VB$(18), and EX$(25). Our nouns and
items used in the game are stored in NO$, and their locations are
processed through LO(25).
M(45,6) holds our game map. This is a two-dimensional array containing
6 compass directions per room location. For example, to set room 45
heading north to, say, room 23, you would assign M(45,1) = 23. This
means that going NORTH from room 45 will take the player to room 23.
As such, "1" corresponds to north, "2" to south, "3" to east, "4" to
west, "5" to up and "6" to down. The number at the beginning of "M("
will *always* be the room number, followed by one of 6 compass
directions as described above.
DE$(45) stores the room descriptions. This allows the program to
store up to 45 room descriptions, but this may be expanded further, and
limited only by available memory.
VB$(18) contains our verb names. These include common verbs such as
GO,GET,DROP,WIELD,UNWIELD,WEAR,REMOVE,BUY,SELL,USE,CLIMB,INVENTORY,LOOK,
EXAMINE,READ,KILL,SAVE,QUIT,EAT and DRINK. The more verbs we have, the more
complex our game becomes. But that also means it becomes much longer, too.
Finally, Line 50 also dimensions the string array EX$(25). EX$ holds
the item and monster descriptions. In Orathan, these include the SWORD,
TORCH, LANTERN, ROPE, GOBLIN and other items or monsters (up to 25).
This may also be expanded upon, but be aware that program memory
requirements also increase.
Lines 51 through 55 READ in the DATA near the end of the program listing.
These are all of the information discussed previously, including
data dimensioned in Line 50 above. I tried to separate each READ statement
(in a FOR/NEXT loop) as single program lines. This makes debugging an
adventure game much easier, rather than just "cramming" as much information
on a line as possible.
Lines 56 through 60 prompt the user if he or she wishes to restore
a saved game from disk. Line 57 halts the program to wait for a keypress,
while lines 58 and 59 determine what the acceptable keypresses are. If
neither keypress is determined to be true, then the program falls
down to Line 60, which pushes program flow back up to Line 57 and
the Yes/No prompt above.
Let's examine a few more lines down the listing:
75 PRINT : PRINT "ÄNTER A CHARACTER NAME";: INPUT NA$: IF LEN (NA$) > 16 THEN PRINT : PRINT "łOO LONG!": FOR X = 1 TO 1900: NEXT : GOTO 56
Line 75 is called if the player is starting a new game. It stores the
player name in string variable NA$. If the length of NA$ exceeds 16
characters (the maxium allowed), then it jumps program flow back up
to line 56 (the "Yes/No" prompt).
The Main Loop
-------------
This next section is rather big, and also the main loop of the entire
program. Thusly, I will break each explanation down to a few lines
at a time here:
100 PRINT " ““ ™ÚRATHAN ’": PRINT DE$(RM)
101 FOR X = 7 TO 25: IF LO(X) = RM THEN PRINT NO$(X)"."
102 NEXT
Line 100 clears the screen, PRINTs "ORATHAN" across a single line in
Reverse Highlight, before skipping a line and PRINTing the current room
description stored in DE$(RM).
Line 101 opens a loop, checking to see if any of the 25 items in our
game are present in the current room (IF LO(X)=RM THEN PRINT NO$(X)".")
If they are, the game PRINTs them out (PRINT NO$(X)".")
Line 102 increases the value stored in X above until it reaches 25,
where the loop then terminates.
103 IF LO(25) = 998 THEN PRINT : PRINT " ÄONGRATULATIONS!!’": PRINT "łOU HAVE DEFEATED \ORDIMAR!!!": FOR X = 1 TO 1900: NEXT : PRINT " łREAT JOB!’": PRINT : PRINT "łHE END": CLR : END
Line 103 is very important. It checks for a specific "Win Factor" in
the current game state. Since the goal in "Orathan" is to defeat a
certain monster, this flag is very important. If that monster is
defeated in battle, it will be set to location 998 (LO(25)=998). If
this game state is true, then a brief congratulatory message is printed,
and the game ends. Not much of a celebration, but it works for our purposes
here.
105 PRINT "ÚBVIOUS EXITS:": FOR X = 1 TO 6: IF M(RM,X) > 0 THEN PRINT NO$(X)" ";
106 NEXT : PRINT
Line 105 prints out "Obvious Exits:" before cycling through a brief loop
stored again in value X. If the value of M(RM,X) is above 0, then we
know that a valid room can be found by going in that direction (remember
our discussion earlier above what each of the 6 compass directions
meant?)
The Parser
----------
If the condition is true, then PRINT NO$(X)" "; tells us
what obvious exits our player can move towards.
107 CLOSE 2: PRINT : PRINT ">";: OPEN 2,0: INPUT# 2,A$: CLOSE 2: PRINT
Line 107 is called more times than any other line in the program.
This line is the beginning of the parser routine. A parser is basically
a routine that breaks up sentences into individual words, before
passing them onto verb and noun routines for processing. It is sort
of the "traffic cop" directing traffic flow, except that it is
responsible for making the game "appear" to understand English
(or other language) sentences.
All player input is stored in the string variable A$. In most cases,
this should truncate at a specific point (possibly 255 characters). However,
in a simple adventure game such as "Orathan", simple two word verb/noun
commands such as GET SWORD or GO NORTH will suffice.
OPEN 2,0 opens a channel to the Commodore 64, and INPUT#2,A$ acts
like a simple INPUT statement, but with one exception: it eliminates
the annoying "?" question mark at the beginning of expected input.
CLOSE 2 tidies up this process, and then Line 107 shifts the screen
display down one line.
108 IF A$ = "N" OR A$ = "NORTH" THEN N = 1: GOTO 130
109 IF A$ = "S" OR A$ = "SOUTH" THEN N = 2: GOTO 130
110 IF A$ = "E" OR A$ = "EAST" THEN N = 3: GOTO 130
111 IF A$ = "W" OR A$ = "WEST" THEN N = 4: GOTO 130
112 IF A$ = "U" OR A$ = "UP" THEN N = 5: GOTO 130
113 IF A$ = "D" OR A$ = "DOWN" THEN N = 6: GOTO 130
Lines 108 through 113 do exactly as they suggest. If A$
is equal to a compass direction (such as NORTH, or an
abbreviation of N), then the appropriate Noun Flag is set
to the corresponding compass direction (e.g. north=1,south=2,
east=3, etc.)
Program flow is then sent to Line 130 (to speed up processing,
due to GO NORTH and other commands like it being the most
often used by the player).
114 IF A$ = "L" OR A$ = "LOOK" THEN GOTO 100
Line 114 checks to see if the player typed "L" or "LOOK" at
the game prompt. If so, it jumps back to Line 100, and reprints
the room description.
115 IF A$ = "I" OR A$ = "INV" OR A$ = "INVE" OR A$ = "INVEN" OR A$ = "INVENTORY" THEN GOTO 150
Line 115 checks to see if "INVENTORY" (or any variation thereof) has been
entered. If so, program flow is directed to the Inventory Routine in
Line 150 (I'll explain how this important routine is handled in a moment).
116 IF A$ = "SAVE" OR A$ = "SAVE GAME" THEN GOTO 1
Line 116 checks for "SAVE" or "SAVE GAME". If the condition is true,
the program directs flow to Line 1, where the SAVE GAME subroutine is
located.
117 IF A$ = "LIST" THEN GOTO 850
Line 117 checks to see if A$="LIST". This command can only be
used in the village store. If the condition is true, then Line 850
is then called.
118 IF A$ = "SCORE" OR A$ = "?" OR A$ = "SC" THEN GOTO 860
Line 118 checks to see if A$="SCORE" (or the abbreviation, which is
commonly "?" or "SC"). If proven correct, the program is taken to
Line 860, where the player statistics are then PRINTed to the screen.
120 FOR X = 1 TO LEN (A$): IF MID$ (A$,X,1) = " " THEN V$ = LEFT$ (A$,X - 1):N$ = MID$ (A$,X + 1,X + 30)
121 NEXT
Lines 120 and 121 parse the sentence entered (and stored) in A$ into
two or more words. This is a simplified parsing routine, and it can
be fooled rather easily. However, if the two word verb/noun
sequence is followed, it does the job beautifually.
Line 120 cycles through the length of A$ (LEN(A$)), and then checks
for a single SPACE in the sentence (IF MID$(A$,X,1)=" "). If this is so,
then V$ is set to the first characters preceeding the SPACE (V$=LEFT$(A$,
X-1)), while N$ is set to everything after the SPACE (N$ = MID$ (A$,X + 1,
X + 30)). While this isn't the most efficient way of doing things, it
works well enough for a simple adventure game. There is a more
complex parser that I employ in other games I have written, but such
an advanced parser is beyond the scope of this article.
Line 21 increments the loop, until the length of A$ (LEN(A$)) is
reached.
125 V = 0: FOR X = 1 TO 15: IF V$ = VB$(X) THEN V = X
126 NEXT : IF V = 0 THEN PRINT "łUH? ÄHECK YOUR VERB.": GOTO 107
Lines 125 and 126 check for a matching VERB in our data structures
at the end of the program. In this case, those stored in the string
array (VB$(15)). If one of the 15 verbs are matched up with the
word stored in V$, then the Variable Flag is set to X (V=X), and
the loop terminates at that point. If not, the loop drops down
to Line 126 and continues to increment the loop until all 15
verbs have been cross-checked. If nothing is found, then V is
set to 0 (V=0), and "HUH? CHECK YOUR VERB." is printed. Program
flow is then directed back to the main loop at Line 107.
It is important to note, also, that the Variable Flag is reset to 0
(V=0) at the beginning of Line 125 everytime the routine is called
by the parser. This ensures that previous entries by the player
are not found in the current command sequence entered.
127 N = 0: FOR X = 1 TO 25: IF N$ = NO$(X) THEN N = X
128 NEXT : IF N = 0 AND V < > 10 THEN PRINT "łUH? ÄHECK YOUR NOUN.": GOTO 107
Lines 127 and 128 are very similar to the preceeding lines. Line 127
sets the Noun Flag to 0 (N=0), and proceeds to cycle through a very
similar loop as the above paragraph explains. However, there is
one difference: if N=0 and the Verb Flag is *not* 10, then the
program prints out "HUH? CHECK YOUR NOUN.". This is important
because the player may type EXAMINE TAVERN. Since TAVERN is
clearly described in the room descriptions but *not* in our
data table of items or monsters, then the program needs
to just to the EXAMINE command instead. Examine is the
10th command in our verb list, hence, if V=10 THEN program
flow will drop down below Line 128 to process the Examine
command even though we don't have a valid noun (N=0).
The Post-Parser Routine
-----------------------
The next several lines are important as well:
129 ON V GOTO 130,140,160,170,180,190,200,207,210,220,230,239,250,270,280
Line 129 is like the "Traffic Cop" described in an earlier paragraph.
It directs program flow to the necessary VERB subroutine, depending
on what the player enters, of course. Based upon our VERB data list,
this could be any of fifteen different subroutines throughout
the program. "ON V GOTO" essentially tells BASIC: "ON V equaling a certain
number (or step, 1 through 15), GOTO step 1,2,3,4,5,6,7,8,9,10,11,12,13,
14 or 15.
There are other ways to handle this, of course, but you will find that
"ON V GOTO" is the most effective method (as it occupies only a single
program line).
The GO Verb
-----------
The next set of program lines, 130 through 135, detail the GO command.
"GO" moves the player between "rooms" (or locations) within our game.
It is probably the easiest VERB subroutine to write, but certain
aspects of it must be explained:
130 IF RM = 11 AND N = 2 THEN IF LO(8) < > 0 AND LO(9) < > 0 THEN PRINT "żT'S MUCH TOO DARK!": PRINT "łOU NEED A SOURCE OF LIGHT.": GOTO 107
Line 130 checks to see if the player is in Room 11 (RM=11), and also
if they are attempting to move SOUTH (N=2). If so, then it further
cross-checks to see if the player is lacking both the TORCH and LANTERN
(LO(8)<>0 AND LO(9)<>0). In my programs, Location 0 is used to signify
that the player character is carrying an item. Thus, if LO(8) were equal
to that number (0), the player would then be carrying the TORCH. If
LO(9) were set to 0, the player would have the LANTERN in hand.
Since both lantern and fuel are required to move SOUTH from Room 11 (RM=11),
the program may halt with the message "IT'S MUCH TOO DARK! YOU NEED A SOURCE
OF LIGHT." Program control is then directed back to Line 107 (the Main
Loop and parser routines).
131 IF LO(19) = 41 AND RM = 41 AND N = 1 THEN PRINT "łOU ARE STOPPED BY "NO$(19)".": PRINT "żT HISSES,'łOU MAY NOT PASS!'": GOTO 107
132 IF LO(24) = 39 AND RM = 39 AND N = 1 THEN PRINT "łOU ARE STOPPED BY "NO$(24)".": PRINT "łE GROWLS,'/O PASSAGE HERE!'": GOTO 107
Lines 131 and 132 are interesting, as they halt the player from moving NORTH
in certain rooms (39 and 41, in this case) if certain conditions are met. In
this case, if the TROLL is in Room 41 (LO(19)=41), then Line 131 informs
the player that "YOU ARE STOPPED BY TROLL. IT HISSES,'YOU MAY NOT PASS!'".
Line 132 does the same thing, only this time it checks for the presence
of the BARBARIAN, who if present, halts movement north with the
message,"YOU ARE STOPPED BY BARBARIAN. IT GROWLS,'NO PASSAGE HERE!'.
133 IF RM = 8 AND N = 3 THEN PRINT "łHE DOOR (TO THE EAST) IS LOCKED!": GOTO 107
Line 133 checks to see if the player is in Room 8 (IF RM=8), and
heading EAST (N=3). If so, it prints out that the doorway is locked.
Program flow is then returned to Line 107.
134 IF M(RM,N) > 0 THEN RM = M(RM,N): GOTO 100
Line 134 is what we've been waiting for. If all conditions above
have been proven false, then Line 134 checks to see if our
hero can move in any of the 6 compass directions (e.g. North,
South,East,West,Up and Down). If so, then the current
room is set to the destination room (RM=M(RM,N). RM=M(RM,N)
may sound confusing, but what it is really telling BASIC
is that the value stored in M(RM,N) should be stored
as well in variable RM. Remember that N cannot be
anything over 6. Since our data structures in Lines
1301 through 1343 are intentionally preset this way,
the player cannot move into a direction the map
doesn't "know".
135 PRINT "łOU CAN'T GO THAT WAY!": GOTO 107
Line 135 is called if the player *cannot* move in
any of the 6 valid compass directions, or if
the chosen compass direction (stored in N) is
equal to zero. A simple error message is
printed, and the program returns to Line 107.
The GET Verb
------------
140 IF LO(N) = RM AND N < 18 AND N > 6 THEN LO(N) = 0:IC = IC + 1: PRINT "łAKEN.": GOTO 107
141 PRINT "łOU CAN'T DO THAT HERE.": GOTO 107
GET is a very simple routine. Lines 140 through 141 are all
that are necessary to process the data. Line 140 checks to
see if the location of the noun is equal to the present
room (IF LO(N)=RM), and also if our noun (stored in variable
N) is above 6 but not above 17 (N<18 AND N>6).
If N<18, then it must be an item such as the LANTERN, FUEL,
SWORD, etc and thus *not* a monster (monsters are stored in
N above value 17). If N>6, then it is clearly not NORTH, SOUTH,
EAST or any of the other compass directions.
If both conditions in Line 140 are met, then the location of the
value stored in N is set to 0 (the player's inventory). The item
counter is incremented by a value of 1 (IC=IC+1), and a simple
message is displayed, indicating that the item was picked up
successfully. Program flow is then directed back to Line 107.
If, however, the conditions in Line 140 remain unsatisfied, then
the program displays the message,"YOU CAN'T DO THAT HERE." and
returns to the parser routine starting in Line 107.
The INVENTORY Verb
------------------
The INVENTORY command allows the player to check what he or she
is currently carrying. This is a very necessary verb in a text
adventure, otherwise things can become rapidly confusing to the
player. It does precisely what the name suggests (e.g. it is
a method of taking INVENTORY of items the player has in hand).
It is thus a visible check or inspection (by the player) of
currently carried items.
150 PRINT "łOU ARE CARRYING:":AC = 0:DM = 1:SI = 0:IC = 0: FOR X = 7 TO 25: IF LO(X) = 0 THEN PRINT NO$(X):IC = IC + 1:SI = 1
Line 150 prints out a simple,"YOU ARE CARRYING:" message, before
reseting specific varibles. "AC=0" just means that the armor class
is reset prior to the inventory loop, which when checks for it.
Ditto with DM=1 (the "Player Potential Damage Inflicted Flag"),
as well as items carried (IC=0), and a special flag stored
in variable SI (SI=0).
Line 150 then cycles through a short loop (FOR X=7 TO 25), starting
X out at 7 (in order to skip over the item names for NORTH, SOUTH, EAST,
WEST, etc.) If the player is *carrying* an item (IF LO(X)=0)), then
it is displayed on the screen (PRINT NO$(X)), and the items carried
flag is incremented by 1 (IC=IC+1). The special flag discussed
earlier (SI) is then set to 1. I'll explain in a moment what it does.
151 IF LO(X) = 105 THEN PRINT NO$(X)" (WIELDED)":IC = IC + 1:SI = 1:DM = N:WD = 1
Line 151 checks for the presence of wielded weapons. I store this
value in 105, way above the maximum room limit of 45 (at least in
this adventure). You may choose any number that seems easy to
remember, such as 1000, or 999. Just make sure it is *not*
a room number or inventory location; otherwise, it will
appear to be located in two places at once!
Line 151 evaluates if the player is WIELDING something, in which
case it is then printed out, followed by a " (WIELDED)" label, signifying
that it is being wielded. The value of IC is incremented (IC=IC+1), and
the "Player Potential Damage Inflicted Flag" stored in DM is changed
to equal the current item value stored in N (DM=N). Our special
flag, stored in SI, is also set to 1 (SI=1). Additionally,
a simple flag is then set, stored in WD, that tells the program
an item is being wielded (WD=1).
152 IF LO(X) = 205 THEN PRINT NO$(X)" (WORN)":IC = IC + 1:SI = 1:AC = AC + N
Line 152 checks for the presence of worn armor. I store this value
in 205, again way above the maximum room limit in my programs. Since
this is only 100 more than 105, it is easy for me to remember. But
please choose any number that is easy for you to remember, such as
2000, or 1999. Just make sure, again, that it is *not* either a room
number or inventory location.
153 NEXT : IF SI = 0 THEN PRINT "ţLAS, YOU ARE EMPTY-HANDED.": GOTO 107
Line 153 increments the loop started in Line 150 by 1. IF X=25, then
the loop terminates, and the line continues to process additional
information. In this case, it checks to see if our special flag
(stored in SI) is equal to 0. Remember our value SI? This is a
flag that is set to 1 *if* a player is carrying *anything* at all
(i.e. carrying, wielding or wearing anything).
If it is not true (IF SI=0), then the player is
obviously not carrying anything, and so a simple,"ALAS, YOU
ARE EMPTY-HANDED." is displayed to the screen. The program
then directs flow back up to Line 107.
154 GOTO 107
If SI=1, and the player *is* carrying something, then
program flow drops down to 154, where it is then directed
back to Line 107 (the Main Loop and parser routine).
The DROP Verb
-------------
Drop is a fairly easy verb. It is simply a reversal of GET or TAKE:
160 IF LO(N) = 0 THEN LO(N) = RM:IC = IC - 1: PRINT "ÄROPPED.": GOTO 107
161 PRINT "łOU MUST BE CARRYING THAT TO DROP.": GOTO 107
Line 160 checks to see if the location of N is equal to 0 (IF LO(N)=0). If
our present noun remains located within the player's inventory, then
it is moved to the room (or location) the player is currently standing
within (LO(N)=RM). In other words, the player "drops" the item on
the ground. The items carried flag is decreased by 1 (IC=IC-1), and
the game prints out a simple message,i.e. "DROPPED." Program flow is then
directed back up to Line 107.
The WIELD verb
--------------
Wield is a verb that confuses some people, and rightly so. What, exactly,
does wield do, and is "equip" a more viable alternative? Would must people
type "equip [item]", where "[item]" is any valid noun or object? Or would
they simply type,"wield [item]"?
This question was answered for me when I began playing online MUDs (Multi-
User Dungeons) way back in 1994. By and large, the most common verb used
to "equip" a weapon was "wield". Thus, I stuck with it, even today.
The wield command is fairly straightforward:
170 IF LO(N) = 0 THEN IF N = 7 THEN LO(7) = 105:DM = N: PRINT "ţWORD IS NOW WIELDED.": GOTO 107
171 IF LO(N) = 0 THEN IF N = 15 THEN LO(15) = 105:DM = N: PRINT "łROADSWORD IS NOW WIELDED.": GOTO 107
172 PRINT "łOU CAN'T WIELD THAT!": GOTO 107
Lines 170 and 171 check to see if the player is carrying the
intended item (IF LO(N)=0)), and if that is so, then
checks further to see if it is either the SWORD (N=7), or the
BROADSWORD (N=15). If either condition is true, both Line 170
and Line 171 set the locations for either object to 105, the
location I use to designate a wielded weapon (e.g. LO(7)=105).
The "Player Damage Potential Flag", stored in DM, is then set to
correspond with the current noun, stored in N. In both cases above,
"N" corresponds to either the SWORD (N=7), or the BROADSWORD (N=15).
If both conditions are false, however, program flow drops down to Line
172, where a simple error message is then displayed, sending the program
back up to Line 107.
The wield command may also be processed via a FOR/NEXT loop. However,
that method is beyond the scope of this article (intended for
beginners or novice adventure game authors).
The UNWIELD verb
----------------
The unwield command is simply the opposite of wield. The player
is wielding an item, and if this Sub-Routine is called, the program
checks Lines 180 through 181 to see if it *can* be unwielded, and
if so, what can be done with it:
180 IF LO(N) = 105 THEN LO(N) = 0: PRINT "ÚK.":DM = 1: GOTO 107
181 PRINT "łOU CAN'T UNWIELD THAT!": GOTO 107
Line 180 checks to see if the player is wielding a weapon (IF LO(N)=105).
If this is so, and if the location of the present Noun stored in "N" *is*
equal to 105 (the location of wielded items), then the location is
changed to equal 0 (the player's inventory location; in other words,
we are telling it to process: LO(N)=0 ). The "Player Potential Damage
Flag", stored in DM, is set to 1, indicating the player is wielding
nothing save their bare hands, and the damage is minimal at best (DM=1).
Program control is then passed by Line 181 to Line 107.
The WEAR verb
-------------
The wear verb is simple. The player may only wear certain items, and
only if they aren't already wearing them.
190 IF LO(N) = 0 THEN IF N > 10 AND N < 18 AND N < > 12 AND N < > 15 THEN LO(N) = 205: PRINT "łOU WEAR "NO$(N)".":AC = AC + N: GOTO 107
Line 190 checks to see if the player is *carrying* the item (IF LO(N)=0),
and if so, it further checks to see if the current noun number, stored
in variable "N", is between 10 and 18, and further, also does not equal 12 *or*
15. If *all* these conditions remain true, then item is considered wearable
armor and LO(N)=205 moves the item into the player "wear" location (usually 205
in my adventure programs). As with wield above, be sure that the "wear" location
is *above* all possible locations (or "rooms") in your adventure game!
Line 190 completes by incrementing the armor class of the player, stored
in AC, by the noun number, stored in "N" (AC=AC+N). It then prints out
a message informing the player that he or she is now wearing the item,
and program flow is again directed back to the Main loop and parser
routines beginning in Line 107.
191 PRINT "łOU CAN'T WEAR THAT.": GOTO 107
Line 191 is reached if conditions in Line 190 remain unsatisfied. It
merely prints an error message, informing the player that he or she
cannot wear the specified noun or item (stored in N). Program control
is passed again to Line 107.
The REMOVE verb
---------------
Remove is the opposite of wear, and a very valuable verb. Once the
player obtains new and more useful armor, it is necessary to "remove"
such "weaker" armor and put on "better" ones.
200 IF LO(N) = 205 THEN LO(N) = 0:AC = AC - N: PRINT "łOU REMOVE "NO$(N)".": GOTO 107
201 PRINT "łOU CAN'T REMOVE THAT!": GOTO 107
Line 200 checks to see if the current noun number, stored in "N", is
equal to 205 (IF LO(N)=205), with 205 being the "wear" location
used by the program. If so, the item is considered a piece of armor,
it is considered worn, and the program removes it back to the
player's inventory (LO(N)=0). The armor class flag, stored in AC,
is then decreased by the value stored in N, or the current armor
being worn (AC=AC-N). A simple message is then displayed, informing
the player that he or she has just removed the intended piece of armor.
Program control is again passed back up to Line 107.
If Line 200 fails, or remains "false", then Line 201 is activated
by the program and displays an error message (informing the player
that they cannot "remove" the intended item, stored in "N". Program
control is passed to Line 107, the Main loop and parser routines.
The LIGHT verb
--------------
202 IF LO(N) = 0 THEN IF N = 7 OR N = 8 THEN IF LT = 0 THEN LT = 1: PRINT "żT IS NOW ABLAZE.": GOTO 107
203 PRINT "łOU CAN'T DO THAT.": GOTO 107
207 IF LO(N) = 0 THEN IF N = 8 OR N = 9 THEN IF LT = 0 THEN LT = 1: PRINT "żT IS NOW ABLAZE.": GOTO 107
208 PRINT "ŔIGHT WHAT?": GOTO 107
The EXTINGUISH verb
-------------------
210 IF LT = 0 THEN PRINT "ÄXTINGUISH WHAT?": GOTO 107
211 IF LO(N) = 0 THEN IF N = 8 OR N = 9 THEN LT = 0: PRINT "ÚK.": GOTO 107
212 PRINT "łOU CAN'T EXTINGUISH THAT!": GOTO 107
The CLIMB verb
--------------
220 IF RM = 26 THEN IF LO(10) = 0 THEN RM = 27: PRINT "łOU CLIMB UP...": FOR X = 1 TO 1900: NEXT : GOTO 100
221 PRINT "łOU CAN'T CLIMB THAT, SILLY!": GOTO 107
The USE verb
------------
230 IF LO(N) = 0 THEN IF N = 8 OR N = 9 THEN IF LT = 0 THEN LT = 1: PRINT "żT IS NOW ABLAZE.": GOTO 107
231 IF LO(N) = 0 THEN IF N = 10 THEN IF RM = 26 THEN RM = 27: PRINT "łOU CLIMB UP...": FOR X = 1 TO 1900: NEXT : GOTO 100
232 IF LO(N) = 0 THEN IF N = 12 THEN IF RM = 8 THEN RM = 9: PRINT "ÄLICK!": FOR X = 1 TO 1900: NEXT : GOTO 100
233 PRINT "ÚSE WHAT?": GOTO 107
The KILL verb/Fight Routine, Part 1
-----------------------------------
The kill verb is fairly complex, and requires a line by line explanation
of what is going on. It is not an easy Sub-Routine to implement, and
thus requires a great deal of beta-testing to bug fix.
This verb is also broken into two parts. Lines 239 through 246 contain
the first part, while Lines 400 through 499 contain the second section.
I will describe this verb line-by-line:
239 MH = INT ( RND (1) * 250) + 1: IF N = 25 THEN MH = 1200
Line 239 sets the variable MH (monster hit points) to a random number,
ranging from 1 through 250, inclusive ("inclusive" means that it includes
all numbers within the specified range).
Line 239 also checks to see if the current noun number, stored in "N",
is equal to 25 (IF N=25). If so, the monster hit points (MH) are then
set to 1200 (MH=1200).
240 I = INT ( RND (1) * 25) + 1: IF N < 18 OR LO(N) < > RM THEN PRINT "łOU MUST BE JOKING!": GOTO 107
Line 240 sets variable "I" to a random number between 1 and 25, inclusive.
It further checks to see if the noun number, stored in "N", is either
less than 18 (N<18), or not in the current room (LO(N)<>RM). If both
conditions are thus true, then the player has attempted to attack
something other than a monster (perhaps he or she got mad at the
LANTERN?), and program flow is again directed back to the Main loop
and parser routines beginning at Line 107.
241 IF I < = 5 THEN PRINT "łOU MISSED."
Line 241 checks to see if the value of I, defined above, is less than
or equal to 5 (I<=5). If true, it means that the player missed
his or her intended target (e.g. the monster, whether it be the
DRAGON, GOBLIN or otherwise).
242 DM = 1: FOR X = 7 TO 25: IF LO(X) = 105 THEN DM = X
Line 242 sets the "Player Potential Damage Flag", stored in DM, to 1 (DM=1).
It also starts a loop, beginning with X=7, and ending with 25 (FOR X=7
TO 25). It performs a check to see if the item being compared (LO(X))
is located in the "wield" location (IF LO(X)=105). If true, then
the value of DM is set to the wielded weapon (DM=X). The loop
will then drop down to Line 243, and compare more items, but since
the player may only wield one weapon at a time, it won't change the
value stored in DM.
243 NEXT : IF I > = 6 AND I < = 10 THEN PRINT "łOU HIT "NO$(N)" HARD!":MH = MH - DM
Line 243 begins with a NEXT statement, which increments the preceeding
line's loop, begun in Line 242. Once X reaches the maximum value indicated in
the loop (25), Line 243 then continues by processing the value stored
in "I".
If "I" is between 6 and 10, inclusive, this signals to the program
that the player's character has scored a hard hit on the monster. A message
is displayed, and the monster's hit points (stored in MH) are decreased
accordingly (MH=MH-DM).
244 IF I > = 11 AND I < = 18 THEN PRINT "łOU SMASHED "NO$(N): PRINT "WITH A BONE-CRUSHING SOUND!!":MH = MH - DM * 2
Line 244 does much the same thing as Line 244, but this time compares
the value of I, ranging from 11 through 18, inclusive. If this is true,
then a message is displayed -- "YOU SMASHED SO AND SO WITH A BONE-CRUSHING SOUND!!" --
and the monster's hit points are decreased even further (MH=MH-DM*2).
Note: When writing your own fight routine, make sure to always increase the
available damage a player (or monster) can inflict line-by-line, according to
severity; otherwise, it can become quite confusing when writing the routine!
So, "love taps" and "glancing blows" would naturally be followed by
"hit hard" and "shashed to pieces". It should also, most necessarily, be
much harder to score stronger hits on a monster (and vice versa).
245 IF I > = 19 THEN PRINT "łHE "NO$(N)" DODGED": PRINT "YOUR ATTACK."
Line 245 checks to see if I is greater than or equal to 19 (IF I>=19).
If it is so, then the monster has effectively dodged the player's attack
and the player thus inflicts "0 damage" on the monster.
246 GOTO 400
Line 246 passes program control flow to Line 400, the second portion
of our Fight routine. This will be discussed later on in the article.
The BUY verb
------------
Buy isn't always a necessary verb. Use it only if you intend
to include a village in your adventures, where the player can
purchase needed goods (e.g. items, armor, weapons, etc.)
Lines 250 through 265 handle the BUY verb:
250 IF RM < > 3 THEN PRINT "/O SHOP HERE!": GOTO 107
251 IF LO(18) < > 3 THEN PRINT "/O CLERK HERE.": GOTO 107
252 P = 0: GOSUB 500
263 IF P = 0 OR LO(N) < > 99 THEN PRINT "łHE CLERK FROWNS.": PRINT "łE SAYS,'OE DON'T SELL THAT HERE.'": GOTO 107
264 IF G > = P THEN LO(N) = 0:G = G - P:IC = IC + 1: PRINT "łOU HAND THE CLERK"P"GOLD COINS.": PRINT "łHE CLERK HANDS YOU": PRINT "THE "NO$(N)".": PRINT "łE SAYS,'łHANK YOU.'": GOTO 107
265 PRINT "łHE CLERK SAYS,'łOU CAN'T AFFORD THAT.'": GOTO 107
Line 250 checks to see if the player is, indeed, inside the village
shop (IF RM<>3). If not, the program declares,"NO SHOP HERE!", and
moves back up to Line 107.
Line 251 checks for the presence of the clerk (IF LO(18)<>3). If he
is not present in the shop, the program tells the player he is
absent, and resumes back up at Line 107.
Line 252 sets the Price Flag, stored in "P", to 0 (P=0), and passes
control momentarily to Line 500 (the Shop Prices Sub-Routine).
Line 263 checks to see if "P" is "0" (IF P=0), or if the location
stored in "N" (the present noun, compared in Line 500) is located
in the village shop (LO(N)<>99). IF LO(N)<>99, then the item is
not located in the shop, and the clerk then becomes rather mean-
spirited towards the player. Program flow is then directed to Line
107.
Line 264 seems to do a lot, but what it is really saying is,"If the price
of the item is *below or equal to* the gold carried by the player, allow
the sale."
It first checks to see if that is so (IF G>=P), and if correct, the
item is moved into the player's inventory (LO(N)=0), the correct
amount of gold coins are subtracted (G=G-P), and the items carried
flag (IC) is increased by 1 (IC=IC+1). A message is displayed,
informing the player of the transactions success, and program
flow is passed back up to Line 107.
Line 265 comes into play if the player doesn't have enough
gold, to which the computer replies,"THE CLERK SAYS,'YOU CAN'T
AFFORD THAT.'". Program control is passed back to Line 107.
The SELL verb
-------------
The sell verb is the exact opposite of buy. It checks to see
if the player is in the shop, with the clerk present, and if
the player is actually carrying the specified item to sell. If so,
it allows the sale, increases the player's gold amount as
indicated below, and places the item sold inside the shop's
inventory of items to sell:
270 IF RM < > 3 THEN PRINT "łOU ARE NOT IN THE SHOP!": GOTO 107
Line 270 checkes for the correct room, the village shop (IF RM<>3).
If the condition is satisfied, Line 271 is reached below:
271 IF LO(18) < > 3 THEN PRINT "łHE CLERK ISN'T HERE.": GOTO 107
Line 271 checks for the presence of the clerk. If he is not present,
the program halts with the obvious error message above, and directs
program control back up to Line 107.
272 P = 0: GOSUB 500: IF P = 0 OR LO(N) < > 0 THEN PRINT "łHE CLERK SAYS,'łOU AREN'T": PRINT "CARRYING THAT.'": GOTO 107
Line 272 sets the Shop Prices flag, stored in "P", to 0 (P=0). It also
calls the exact same Shop Prices Sub-Routine (beginning in Line 500)
as the buy verb. If P equals 0 (IF P=0), or the location of the
present noun being compared (N) is not equal to 0 (LO(N)<>0), then
an error message is played, and the sale is not completed.
In other words, if the player isn't carrying the item, or the item
has no value (0), then the sale cannot continue.
273 G = G + P / 2:LO(N) = 99: PRINT "łOU HAND THE CLERK": PRINT "THE "NO$(N)".": PRINT "łHE CLERK HANDS YOU"P / 2: PRINT "GOLD COINS.": PRINT "łE SAYS,'łHANK YOU.'": GOTO 107
Line 273 increases the gold amount of the player by *half* the value
of the originally sold item. This is commonly used in online MUDs to
ensure that shop prices reflect real life more substantially. An item
sold to someone might drop in value, perhaps by half, and so this
line is useful in halving the price of the sold item (G=G+P/2).
The location of the sold item, stored in "N", is changed to 99 (LO(N)=99),
the location of the village shop's inventory.
The EXAMINE verb
----------------
The examine verb can be handled differently, depending on how
you intend to write your adventure. If you, like me, like to have
the player examine things in both the room and items present on
the ground or being carried, then this routine can be of value
to your adventure.
It is isn't always necessary to reduce the examine command to
one or two lines; you can make this section as simple or as complex
as necessary.
280 IF LO(N) = RM OR LO(N) = 0 OR LO(N) = 105 OR LO(N) = 205 THEN PRINT EX$(N): GOTO 107
281 IF N = 0 THEN PRINT "łOU NOTICE NOTHING UNUSUAL": PRINT "ABOUT THE "N$".": GOTO 107
282 PRINT "łHAT ISN'T HERE.": GOTO 107
399 END
Line 280 checks to see if the Noun (noun item), is present in
the current room (IF LO(N)=RM), as well as verifying that the
item is being carried (LO(N)=0), wielded (LO(N)=105), or worn
(LO(N)=205. If any of those conditions remain true, then
the program prints out the description for that particular
item (PRINT EX$(N)). Program control is then directed back
up to Line 107.
Line 281 checks to see if the value of "N" is 0. Remember from Line 128
when the program compared N=0 AND V<>10? V=10 means that the "examine"
command was entered by the player, and if N=0, that must mean he or she
is attempting to examine (for instance) the TAVERN, or WELL. These
are items described in the rooms, but not regular items, such as
the LANTERN or SWORD. Thus, a simple message is displayed, and
the program goes back to Line 107.
If needed, Line 281 (and others like it) can be further expanded
as follows:
281 IF N=0 THEN IF A$="EXAMINE WELL" AND RM=3 THEN PRINT"THE WELL
EXTENDS DOWN SOME 300 FEET. THERE IS MOSS GROWING ON THE INSIDE WALLS.":GOTO 107
This way, you can seemingly extend the vocabulary of the game without much
work, as well as give the player the freedom to explore the areas of the
game more indepth.
Line 282 prints out an error message, sending program flow back
up to Line 107.
Line 399 ends the program, but is never called, so it really
isn't necessary. This was left in because I was still debugging
the program prior to writing this article.
The KILL verb/Fight Routine, Part 2
-----------------------------------
The kill verb, began in Lines 239 through 246, are continued
below in Lines 400 through 499. I will, again, describe what
is happening line-by-line.
This routine can be made more complex by adding in special
spells, moves, hits, etc. It all depends on the player and
what they expect to see during combat. In truth, the more
complex the battle engine, the more complex the outcome.
400 PRINT ">": FOR X = 1 TO 1900: NEXT : PRINT " łOUR łż’:"HP"/"HM: PRINT " łHEIRS ’:"MH
Line 400 displays a prompt (PRINT">"), pauses for almost two seconds (FOR X=1 TO 1900),
and then prints out a status line (PRINT"YOUR HP :"HP"/"HM:PRINT"THEIRS :"MH).
401 PRINT ">":I = INT ( RND (1) * 25) + 1: IF I < = 5 THEN PRINT "łHEY MISSED YOU."
Line 401 again displays a prompt (PRINT">"), sets variable "I" to a number
between 1 and 25, inclusive, before comparing I with (IF I<=5 THEN PRINT "THEY MISSED YOU.")
402 IF I > = 6 AND I < = 10 THEN PRINT "łHE "NO$(N)" HIT YOU HARD!":HP = HP + AC / 2:HP = HP - AC:HP = HP - I
Line 402 checks to see if I ranges between 6 and 10, inclusive.
If it is, it displays a message that the monster landed a hard hit on the
player, further decreasing the player's hit points (HP=HP+AC/2:HP=HP-AC:HP=HP-I).
(HP=HP+AC/2) momentarily increases the player's hit points by *half* the
value stored in AC (the armor class flag), before decreasing HP by AC (HP=HP-AC).
Finally, to give the game more balance, HP is decreased by I (between 6 and 10, in this case).
403 IF I > = 11 AND I < = 18 THEN PRINT "łHE "NO$(N)" SMASHED": PRINT "YOU WITH A BONE-CRUSHING SOUND!!":HP = HP - 150:HP = HP + AC
Line 403 is slightly less complex. It first checks to see if "I" is between
11 and 18, inclusive, and if so, prints out a message indicating that the
monster successfully struck the player "with a bone-crushing sound".
The player's hitpoints are decreased (HP=HP-150), before the game then adds
the armor class value into the equation (HP=HP+AC). In essence, the more
armor a player is wearing, the fewer hit points her or she will lose
when struck with a very strong blow.
404 IF I > = 19 THEN PRINT "łOU DODGED THEIR ATTACK."
Line 404 checks to see if I is above or equal to 19 (IF I>=19). If it
is, then the player successfully dodged the monster's attack.
405 PRINT ">": FOR X = 1 TO 1900: NEXT : IF MH < 1 THEN PRINT "łHE "NO$(N)" DIED.": PRINT "łOU KILLED "NO$(N)".": GOTO 410
Line 405 displays a prompt (PRINT">"), before pausing for nearly two
seconds (FOR X=1 TO 1900:NEXT). It then checks to see if the value
stored in MH, the monster's hit points, are below 1 (IF MH<1).
If so, the program declares that the monster has died in battle, and
jumps to Line 410.
406 IF HP < 1 THEN PRINT "ţLAS, YOU HAVE FALLEN...": FOR X = 1 TO 1900: NEXT : PRINT "“łETTER LUCK NEXT TIME!": CLR : END
Line 406 checks to see if the player has perished in battle (IF HP<1).
If so, the program notes that the player has "fallen", before pausing
a few seconds, and printing out a brief message thanking the player
for playing. It then ends the program.
In most adventures, however, you may wish to jump back to the Main Menu
of the game. Or you could, alternatively, have a "purgatory" where the
player must exit out of, perhaps with a reduction in hit points or gold.
In my other adventures, including "Westfront PC: The Trials of Guilder",
I employ such a method. The game doesn't just "end" when the player
is defeated in battle. Rather, it returns the player to the game,
with a reduction in either hit points and/or gold, and he or she
must then make their way out of Purgatory.
407 FOR X = 1 TO 200: NEXT : GOTO 240
Line 407 pauses for a few milliseconds, before sending program flow
back up to Line 240.
410 FOR X = 7 TO 25: IF LO(X) = 100 + N THEN PRINT "łOU FOUND "NO$(X)" ON IT!":LO(X) = RM
411 NEXT : IF I > 20 THEN LV = LV + 1:HM = HM + 25:HP = HM:MM = MM + 8:MP = MM:G = G + I: PRINT "łOU GAINED A LEVEL!"
Line 410 and 411 perform a valuable function: inventory retrieval from
a vanquished (or defeated) monster. In some online MUDs, defeated
monsters may be carrying valuable items that the player may use. In this
case, as in all of my adventure games, this is also true.
Line 410 starts by cycling through a loop, stored in X, and ranging from
7 to 25 (FOR X=7 TO 25). This eliminates checking for compass directions
with X equaling 7, and extends the range of the loop's search to every
possible item the monster may be carrying (up to X=25).
If the location of X is equal to 100 plus the value of "N" (IF LO(X)=100+N),
then the item is located on the monster, and a message is displayed. The
item discovered by the player while searching the deceased monster is
then placed in the room (LO(X)=RM).
Note: I normally place items monsters are carrying in locations above
100, *plus* the noun number (stored in "N") of the monster. Thus, and
for example, if the CLERK (N=18) is carrying the LANTERN (N=9), the
location of the LANTERN would be (LO(9)=118, or LO(9)=18 + 100).
Hopefully this makes sense.
Line 411 increments the value of X with the NEXT statement (NEXT),
and when it finally reaches the maximum value of 25, it continues
on by evaluating if "I" is greater than 20 (IF I>20). If so, then
the player has successfully gained a level, and his or her level
is then increased by 1 (LV=LV+1).
Additionally, the values stored in HM (hit points maximum) are increased
by 25 (HM=HM+25), as well as normal hit points (HP=HM), maximum magic
points (MM=MM+8), and regular magic points (MP=MM). Finally, gold
(stored in the variable "G") is increased by the value stored
in "I" (G=G+I).
412 G = G + I:EX = EX + N:LO(N) = 998: GOTO 107
Line 412 tidies up the fight routine for us, setting gold to the value
of "I" (G=G+I), increasing the player's experience by "N" (EX=EX+N), while
placing the defeated monster in the "spirit" location (LO(N)=998). This is
usually just a number above the maximum room number allowed. I just use
998 for simplicity.
499 END
Line 499 ends the program, but isn't really necessary, and may be excluded.
The Shop Prices Sub-routine
---------------------------
Lines 500 through 512 determine the prices in the village shop. First,
Line 500 sets the value of "P" to 0 (P=0), then checks for several
conditions to be satisfied in preceeding lines:
500 P = 0: IF N = 7 THEN P = 40
501 IF N = 8 THEN P = 10
502 IF N = 9 THEN P = 22
503 IF N = 10 THEN P = 6
504 IF N = 11 THEN P = 180
505 IF N = 12 THEN P = 4
506 IF N = 13 THEN P = 126
507 IF N = 14 THEN P = 88
508 IF N = 15 THEN P = 500
509 IF N = 16 THEN P = 45
510 IF N = 17 THEN P = 50
512 RETURN
The lines above are fairly self-explanatory. If the loop
reaches a certain value stored in "N", then that is the current
shop item being compared by the program, and the price flag
is then set to whatever price that line determines to
be the present value stored in "P".
So, thusly, if the shop is trying to see if the LANTERN (N=9) is
in stock, and if it is, it checks this subroutine above to see
what the price for the LANTERN might be. In this case, Line 502
checks and finds a match (N=9), setting P to 22 (P=22). The
price of the LANTERN is then 22 gold coins.
The Item Location Sub-routine
-----------------------------
Lines 700 through 715 are unusual program lines, and aren't
usually necessary for normal adventure game writing use.
These routines were left in for debugging purposes. I am not
certain if Orathan still uses them. Nonetheless, what they do
is check the value stored in string variable L1$ for the presence
of two letters, either AL, BL, CL, DL, EL, FL, GL, HL, IL, JL, or
KL. If it finds a match, then the string variable HP$ is set to
the middle point of L1$, where it is further converted and
placed in locations in LO(25) (LO(X)=VAL(HP$)):
700 FOR X = 1 TO LEN (L1$)
701 IF MID$ (L1$,X,2) = "AL" THEN HP$ = MID$ (L1$,X + 2,4):LO(7) = VAL (HP$)
702 IF MID$ (L1$,X,2) = "BL" THEN HP$ = MID$ (L1$,X + 2,4):LO(8) = VAL (HP$)
703 IF MID$ (L1$,X,2) = "CL" THEN HP$ = MID$ (L1$,X + 2,4):LO(9) = VAL (HP$)
704 IF MID$ (L1$,X,2) = "DL" THEN HP$ = MID$ (L1$,X + 2,4):LO(10) = VAL (HP$)
705 IF MID$ (L1$,X,2) = "EL" THEN HP$ = MID$ (L1$,X + 2,4):LO(11) = VAL (HP$)
706 IF MID$ (L1$,X,2) = "FL" THEN HP$ = MID$ (L1$,X + 2,4):LO(12) = VAL (HP$)
707 IF MID$ (L1$,X,2) = "GL" THEN HP$ = MID$ (L1$,X + 2,4):LO(13) = VAL (HP$)
708 IF MID$ (L1$,X,2) = "HL" THEN HP$ = MID$ (L1$,X + 2,4):LO(14) = VAL (HP$)
709 IF MID$ (L1$,X,2) = "IL" THEN HP$ = MID$ (L1$,X + 2,4):LO(15) = VAL (HP$)
710 IF MID$ (L1$,X,2) = "JL" THEN HP$ = MID$ (L1$,X + 2,4):LO(16) = VAL (HP$)
711 IF MID$ (L1$,X,2) = "KL" THEN HP$ = MID$ (L1$,X + 2,4):LO(17) = VAL (HP$)
712 NEXT : RETURN
714 FOR X = 1 TO 20: PRINT MID$ (A$,X,1);: NEXT : PRINT : FOR X = 21 TO 40: PRINT MID$ (A$,X,1);: NEXT : PRINT : FOR X = 41 TO 60: PRINT MID$ (A$,X,1);: NEXT : PRINT : FOR X = 61 TO 80: PRINT MID$ (A$,X,1);
715 NEXT : PRINT : FOR X = 81 TO 100: PRINT MID$ (A$,X,1);: NEXT : PRINT : RETURN
Print out Instructions
----------------------
Lines 800 through 804 handle the instructions for "Orathan".
This is somewhat necessary, even absolutely necessary, if the player
wants to give his or her intended audience an understanding of what
the goal(s) of the game might be. Or, alternatively, they may choose
to include a brief HELP command, where all VERBS the program allows
are displayed. Either way, this section should be included in any
adventure game, whether it has 45 rooms, or 4,500.
800 PRINT "“™ÚRATHAN ’": PRINT : PRINT "łOUR GOAL IN ÚRATHAN IS TO DEFEAT": PRINT "AN EVIL SORCERER. łE IS SAID TO"
801 PRINT "BE HOLED UP IN A HULKING CASTLE (JUST": PRINT "BEYOND THE FOREST).": PRINT : PRINT "łE HAS MANY HENCHMAN TO CALL TO HIS": PRINT "AIDE, SO BE CAREFUL!": PRINT
802 PRINT " żRESS ANY KEY TO BEGIN!’"
Lines 800 through 802 print out the instructions for the game. In this
case, it prints out what the goal(s) of Orathan are. It then asks
for a key to be pressed (Line 802).
803 GET K$: IF K$ = "" THEN GOTO 803
Lines 803 halts the program to wait for a keypress. If none is
entered, the program stays on line 803. If not, it drops down
to the line below:
804 PRINT "“": RETURN
Line 804 clears the screen, and RETURNs program flow back to where
the Sub-Routine was originally called.
The LIST verb
-------------
Lines 850 throuhg 853 are the LIST command, useful only in
the village shop. This, effectively, LISTs what the store
currently has in stock to sell:
850 IF RM < > 3 THEN PRINT "OHAT?": GOTO 107
Line 850 checks to see if the Room is 3 (the shop). If not,
a simple error message is printed, and program flow returns to
Line 107.
851 IF LO(18) < > 3 THEN PRINT "łHE CLERK ISN'T HERE.": GOTO 107
Line 851 determines if the CLERK is located in the same
room as the player (IF LO(18)<>3) (in this case, the village shop,
or location "3"). If not, an error message is displayed and control
is passed to Line 107.
852 SI = 0: FOR X = 7 TO 18: IF LO(X) = 99 THEN PRINT NO$(X);":";:N = X: GOSUB 500: PRINT P
853 NEXT : GOTO 107
Lines 852 and 853 perform the LIST function for the village shop,
displaying what is currently in stock (if anything). It first cycles
through a short loop, stored in X, and beginning at a value of
7 (FOR X=7 TO 18). The value of X in the loop stops at 18. Both
of these parameters tell the program that the LIST command may
*only* check for Nouns (noun items) *between* 7 and 18 (in other
words, items the player can carry, wear, wield, drop, remove,
use, examine, read, or otherwise manipulate in some way).
If the value of LO(X) is 99 (IF LO(X)=99), then the program
displays the Noun item's name (PRINT NO$(X);":";), followed
with an assignation of N to the same number as X (N=X), before
branching to the Sub-Routine in Line 500 (the Shop Prices
Sub-Routine several paragraphs above). Line 852 ends by
printing out the price of the item, stored in variable
"P" (PRINT P).
Line 853 increments the loop begun in the previous Line 852, and
then closes by directing program flow back up to Line 107.
The SCORE verb
--------------
The SCORE verb is only one line long (Line 860), but it is
probably second only to the INVENTORY command in necessity. How
else would the player be able to see his or her hit points and
experience earned? Thus, the SCORE command is included here:
860 PRINT "łOU ARE "NA$"’.": PRINT "łOU HAVE"HP"OF"HM"HIT POINTS.": PRINT "łOU ALSO HAVE"EX"EXPERIENCE": PRINT "POINTS AND"G"GOLD COINS.": PRINT "łOU ARE CARRYING"IC"ITEMS.": GOTO 107
The DATA Structures - Noun Names - Stored in NO$(25)
----------------------------------------------------
At last, we finally reach the Data Structures themselves. This
is the data engine that drives the program, for a text adventure
(and other games like it) are nothing more than huge databases
of information that are then parsed and used accordingly by
both the program and the game player. In other words, they
are necessary for text adventures to work, and are needed
by our program (even if they also take up a lot of space).
Lines 1100 through 1124 store the Noun names in
string variable NO$(25). Notice how they are separated
by type. The names of the compass directions are
listed first, followed by the common items, and
then finally the monster names. This makes parsing
commands easier, and allows the various VERB routines
to easily stratify the data as needed:
1100 DATA "NORTH","SOUTH","EAST","WEST","UP","DOWN"
1107 DATA "SWORD","TORCH","LANTERN","ROPE","ARMOR"
1112 DATA "KEY","SHIELD","ROBE","BROADSWORD","HELMET","RING"
1118 DATA "CLERK","TROLL","GOBLIN","ELF","DRAGON","WIZARD"
1124 DATA "BARBARIAN","MORDIMAR"
The DATA Structures - Noun Locations - Stored in LO(25)
-------------------------------------------------------
Lines 1200 through 1218 are where the program gets the
values stores in LO(25). If an item location is
above 17, it is considered a "monster" and cannot
be picked up (hence, Line 1200 sets the first 6
noun locations to 89, which makes them impossible
to pick up; besides, you cannot pick up a
compass direction such as north, south, east,
west, up or down, right?)
Anyways, the following data list should be fairly
self-explanatory. The numbers correspond to room
locations where the Nouns (noun items) are located:
1200 DATA 89,89,89,89,89,89
1207 DATA 9,5,99,21,124,5,38,31,99,118,121
1218 DATA 3,41,18,13,15,36,39,43
The DATA Structures - Game Map - Stored in M(45,6)
--------------------------------------------------
Lines 1301 through 1343 list the game map, room by
room, stored in M(45,6). Each line thus corresponds
to a room (or "location") within the game. And each
line also includes the 6 possible compass directions
of North, South, East, West, Up or Down.
Also, remember that when M(RM,N)>0, then the player
*can* move in the direction indicated by N (1=north,
2=south, etc). If it is 0 (M(RM,N)=0), then the
player cannot, and an error message is then
displayed.
In our table below, anything that is "0"
indicates to the game program that it is
not a valid movement for that particular
room. As an example, in Room 1:
1301 DATA 0,2,0,0,4,0: REM ROOM 1
The player *cannot* move north, but *can* move
to Room 2 to the south. But moving east or west
is not allowed. Likewise, moving up *is* allowed,
taking the player to Room 4 upstairs, but moving
down is *not* allowed.
The same principles apply to the rest of the map data
statements below:
1302 DATA 1,6,3,0,0,0: REM ROOM 2
1303 DATA 0,0,0,2,0,0: REM ROOM 3
1304 DATA 0,0,5,0,0,1: REM ROOM 4
1305 DATA 0,0,0,4,0,0: REM ROOM 5
1306 DATA 2,10,7,0,0,0: REM ROOM 6
1307 DATA 8,0,0,6,0,0: REM ROOM 7
1308 DATA 0,7,9,0,0,0: REM ROOM 8
1309 DATA 0,0,0,8,0,0: REM ROOM 9
1310 DATA 6,11,12,0,0,0: REM ROOM 10
1311 DATA 10,25,0,18,0,0: REM ROOM 11
1312 DATA 0,19,13,10,0,0: REM ROOM 12
1313 DATA 14,0,15,12,0,0: REM ROOM 13
1314 DATA 0,13,0,0,0,0: REM ROOM 14
1315 DATA 0,20,0,13,0,0: REM ROOM 15
1316 DATA 0,18,0,0,0,0: REM ROOM 16
1317 DATA 0,0,18,0,0,0: REM ROOM 17
1318 DATA 16,24,11,17,0,0: REM ROOM 18
1319 DATA 12,26,0,0,0,0: REM ROOM 19
1320 DATA 15,0,21,0,0,0: REM ROOM 20
1321 DATA 0,0,0,20,0,0: REM ROOM 21
1322 DATA 0,30,23,0,0,0: REM ROOM 22
1323 DATA 0,0,0,22,0,0: REM ROOM 23
1324 DATA 18,0,0,0,0,0: REM ROOM 24
1325 DATA 11,0,28,0,0,0: REM ROOM 25
1326 DATA 19,0,0,0,0,0: REM ROOM 26
1327 DATA 0,0,0,0,0,26: REM ROOM 27
1328 DATA 0,36,0,25,0,0: REM ROOM 28
1329 DATA 0,37,0,0,0,0: REM ROOM 29
1330 DATA 22,33,0,31,0,0: REM ROOM 30
1331 DATA 0,32,30,0,0,0: REM ROOM 31
1332 DATA 31,0,0,0,0,0: REM ROOM 32
1333 DATA 30,0,33,0,0,0: REM ROOM 33
1334 DATA 0,0,35,33,0,0: REM ROOM 34
1335 DATA 43,39,0,34,0,0: REM ROOM 35
1336 DATA 28,42,37,0,0,0: REM ROOM 36
1337 DATA 29,0,0,36,0,0: REM ROOM 37
1338 DATA 0,0,0,39,0,0: REM ROOM 38
1339 DATA 35,41,38,40,0,0: REM ROOM 39
1340 DATA 0,0,39,0,0,0: REM ROOM 40
1341 DATA 39,0,42,0,0,0: REM ROOM 41
1342 DATA 36,0,0,41,0,0: REM ROOM 42
1343 DATA 0,35,0,0,0,0: REM ROOM 43
The DATA Structures - Room Descriptions - Stored in DE$(45)
-----------------------------------------------------------
Line 1401 through 1443 store the room descriptions used in the
game. Room descriptions, remember, were stored in string variable
DE$(45) in Line 50. These include all of the rooms in our adventure
game. Make sure these lines match up to the rooms you want them
to (e.g. the map data stored in M(45,6). When the RM variable
is set to the current room, one of these room descriptions
will then be displayed on the screen:
1401 DATA "łOU ARE INSIDE A SMALL TAVERN. ţN UPSTAIRS HALLWAY HEADS TO THE SECOND FLOOR."
1402 DATA "łOU ARE STANDING BY A WELL. łO THE SOUTHLIES A PATH OUT OF TOWN."
1403 DATA "łOU ARE IN A SMALL STORE. ÄOMMANDS HERE INCLUDE 'BUY <ITEM>','SELL <ITEM> AND 'LIST'."
1404 DATA "łOU ARE STANDING ON THE SECOND FLOOR OF THIS TAVERN. ţ ROOM STANDS TO THE EAST."
1405 DATA "łOU ARE INSIDE A SMALL ROOM. ţ BED IS HERE WHERE YOU CAN REST COMFORTABLY."
1406 DATA "łOU ARE ON A PATH HEADING OUT OF TOWN. ţ VILLAGE WELL STANDS TO THE NORTH."
1407 DATA "łOU ARE IN A SMALL CATHEDRAL. ţN ALTAR STANDS TO THE NORTH."
1408 DATA "łOU ARE STANDING IN FRONT OF AN ALTAR. żT HAS A FEW ITEMS ON IT OF INTEREST. ţ STORAGE ROOM IS TO THE EAST."
1409 DATA "łOU ARE IN A STORAGE ROOM. /OT MUCH HERESAVE FOR A FEW WOODEN BARRELS."
1410 DATA "łOU ARE ON A WELL-LIT PATH HEADING OUT OF TOWN. ţ FOREST LOOMS TO THE EAST, DARK AND FORBODING."
1411 DATA "łOU ARE ON A PATH TRAVELING SOUTH. ţ LUSH, GREEN MEADOW IS DIRECTLY SOUTH."
1412 DATA "łOU ARE IN A DARK FOREST. łREES SURROUNDYOU IN ALL DIRECTIONS HERE."
1413 DATA "łOU ARE IN A DARK FOREST. łHE TREES ARE QUITE THICK HERE. ţ LAKE IS DIRECTLY EAST."
1414 DATA "łOU ARE FACING A DEAD END IN THE FOREST.ţTORM TOSSED TREES BLOCK YOUR PATH NORTH AND EAST."
1415 DATA "łOU ARE STANDING BY A LAKE. łHE WATER GLISTENS IN THE FADING SUN. ţ CLEARING IS SOUTH."
1416 DATA "łOU ARE STANDING IN A BURNT FOREST. łHE TREES ARE CHARRED BY A RECENT FIRE. łHE ONLY EXIT IS BACK SOUTH."
1417 DATA "łOU ARE STANDING IN A DYING, BURNT FOREST. żT HAS BEEN CHARRED BLACK TO THEEARTH BY A RECENT BLAZE."
1418 DATA "łOU HAVE REACHED A BURNT FOREST. łHE TREES ARE CHARRED BLACK. łO THE EAST LIES A NARROW PATH."
1419 DATA "łOU ARE WALKING IN A FOREST. ŔITTLE CREATURES SCURRY ABOUT THE GROUND, WHILE LIGHT FILTERS DOWN FROM THE CANOPYABOVE."
1420 DATA "łOU ARE STANDING IN A SMALL CLEARING. łHERE IS NOTHING AROUND BUT BLUE SKY."
1421 DATA "łOU HAVE REACHED A SMALL COTTAGE ACROSS FROM A CLEARING. żT IS MOSTLY BARE, BUT HAS SOME USEFUL ITEMS NONETHELESS."
1422 DATA "łOU ARE INSIDE A DARKENED CELL. żT IS MOSTLY BARE."
1423 DATA "łOU ARE FACING ANOTHER CELL. łHIS ONE HAS A PORTION OF THE WALL KNOCKED OUT."
1424 DATA "łOU ARE STANDING IN A BURNT FOREST. łHE PATH IS BLOCKED SOUTH BY FALLEN TREES AND DEBRIS."
1425 DATA "łOU ARE WALKING IN A LUSH, GREEN MEADOW.łHE GRASS TICKLES YOUR FEET AS YOU WALK ON BY. łO THE EAST, THE HILLSIDE SLOPES DOWN SOME SOUTH."
1426 DATA "łOU ARE FACING A TREE WITH LOW-LYING BRANCHES. żT LOOKS CLIMBABLE. łOU MAY NEED A ROPE, HOWEVER."
1427 DATA "łOU ARE STANDING IN A HUT ATOP THE TREE.łHERE IS A BOOKSHELF HERE NEXT TO A TABLE. ţOMEONE OBVIOUSLY LIVES HERE."
1428 DATA "łOU ARE WALKING IN A LUSH MEADOW SOUTH OF THE FOREST. łO THE WEST, THE MEADOW OPENS UP SOME INTO A MOUNTAIN RANGE NEARBY."
1429 DATA "łOU HAVE REACHED A SMALL HILLSIDE IN THE MEADOW. żT SLOPES DOWN HERE NEAR A LARGE PATH (HEADING WEST)."
1430 DATA "łOU ARE INSIDE A DARK DUNGEON BELOW THE CASTLE. żT TURNS HERE AND HEADS EAST PAST A ROW OF CELLS."
1431 DATA "łOU ARE INSIDE A SMALL CELL. żT IS MOST-LY BARE, SAVE FOR A SMALL TABLE."
1432 DATA "łOU ARE INSIDE A DARK CELL. łHERE IS NOTHING HERE BUT COBWEBS."
1433 DATA "łOU ARE INSIDE A DARK DUNGEON BELOW THE CASTLE LIBRARY. żT IS VERY DARK HERE! ÚPAHEAD, YOU CAN MAKE OUT THE FAINT OUT- LINE OF SMALL CELLS."
1434 DATA "łOU ARE INSIDE THE CASTLE LIBRARY. ţTRA-NGLY, MOST OF THE BOOKS HAVE BEEN TAKEN."
1435 DATA "łOU ARE IN A PARLOR INSIDE THE CASTLE. ţ THRONE ROOM IS NORTH, AND A LIBRARY WEST."
1436 DATA "łOU ARE ON A PATH BY A LARGE, ROLLING MEADOW. łHE PATH BREAKS OFF HERE AND HEADS WEST."
1437 DATA "łOU ARE IN A LUSH, GREEN MEADOW. żT TURNS HERE BY A LARGE STONE CASTLE."
1438 DATA "łOU ARE IN A ROOM INSIDE THE CASTLE. żT IS MOSTLY EMPTY."
1439 DATA "łOU ARE IN THE MAIN HALL OF THE CASTLE. żT HEADS NORTH HERE INTO THE MAIN PAR- LOR."
1440 DATA "łOU ARE IN A SMALL ROOM. łHERE ISN'T MUCH HERE OF INTEREST, OBVIOUSLY."
1441 DATA "łOU ARE STANDING BEFORE A LARGE, HULKINGCASTLE. łHE DRAWBRIDGE IS DOWN. ÄOULD SOMEBODY BE EXPECTING YOU?"
1442 DATA "łOU ARE ON A PATH NEAR A LARGE MEADOW. ţ CASTLE LOOMS TO THE WEST, BECKONING YOU TO EXPLORE IT FURTHER."
1443 DATA "łOU ARE STANDING BEFORE A GOLDEN THRONE.łHE JEWELS ENCRUSTED ON EITHER SIDE SHOWA BRILLIANCE RARELY SEEN."
The DATA Structures - Verb names - Stored in VB$(25)
----------------------------------------------------
Line 1500 is rather simple. It is a short list of all the known
verbs understood by the program. The more verbs we add, the more complex
our adventure thus becomes. But always understand that increasing
verbs within an adventure program also increases the work required
to implement them. If a verb isn't really necessary, consider
leaving it out, or altering the usage of the verb slightly to be
more serviceable to the player:
1500 DATA "GO","GET","DROP","WIELD","UNWIELD","WEAR","REMOVE","LIGHT","EXTINGUISH","CLIMB","USE","KILL","BUY","SELL","EXAMINE"
The DATA Structures - Noun descriptions - Stored in EX$(25)
-----------------------------------------------------------
Lines 1600 through 1623 store the data for our Noun descriptions.
These differ from those stored previously in NO$(25). NO$(25) stores
the Noun names, *not* the noun descriptions, while EX$(25) stores our
noun descriptions.
This is confusing enough, so please try to pick a suitable variable
such as NO$ for the noun names, and EX$ for the noun descriptions. A
typical noun description (EX$) might be,"A SMALL TORCH", whereas the
noun name (NO$) could be,"TORCH". Pick and choose how your nouns
are described. The larger the description, the more vivid it thus
becomes in the mind of the player:
1600 DATA "N","S","E","W","U","D"
1607 DATA "ţ NORMAL SWORD.","ţ SMALL TORCH.","ţ BRASS LANTERN STAINED WITH BLOOD.","ţ SMALL COIL OF ROPE.","ţ PIECE OF CHAINLINKED ARMOR."
1612 DATA "ţ SMALL KEY.","ţ LARGE CRUSADER SHIELD.","ţN ELVEN ROBE.","ţ LARGE BROADSWORD.","ţ BRASS HELMET.","ţ MAGICAL RING OF PROTECTION."
1618 DATA "łHIS IS A STOUT CLERK.","ţ VICIOUS TROLL.","ţ GOBLIN WITH HIDEOUS TEETH.","ţN ELF OF THE SURROUNDING FOREST.","ţ LARGE DRAGON WITH TOUGH SCALES."
1623 DATA "ţ WIZARD WITH FLOWING HAIR AND A LONG BEARD. łE APPEARS WISE.","ţ DEADLY BARBARIAN. łE LOOKS MEAN.","łHIS IS \ORDIMAR, AN EVIL SORCERER."
Finally, the last line of our program "Orathan":
62999 END
Line 62999 ENDs the program. No other explanation is necessary.
I hope you've enjoyed reading this BASIC tutorial. It highlights
how to write a fairly complex, yet simple, text adventure program.
Since BASIC is used, it may be adapted fairly easily to other
languages, such as C and C++. Hopefully, with enough time
and practice, writing adventure games will come easier to
you and allow you to creatively express yourself through
an interesting story and character development! :)
Happy Computing! :)
P.S. Check out my website at: http://www.geocities.com/dunric/westfront.html
for other adventure games I have written.
Sincerely,
Paul Allen Panks
dun...@yahoo.com
Phoenix, AZ USA
Author of: "Westfront PC: The Trials of Guilder"
...and other games...
--
pa...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
pax
Rob Nicoletti
give me a couple of weeks for checking the whole thing.
Meanwhile, thank you!