Help Programming Text Adventure in BASIC

[bluejay]

I've started programming a text adventure game on my VIC-20 with BASIC, and I have little details(some big ones too) that I might need help on. For example, how can I make it so that if a player tries to use the "get" command in an empty field, how do I make it so that the game answers something like "There's nothing to get!"?

[carlsson]

Text adventures are best programmed as an engine, meaning a parser that takes input and breaks it up into actions and objects for the classic two-word game. Your data ideally are stored in DATA statements which are loaded into matrices on initialization. The data will consist of names of locations, possible exits and index to which items are available in each place, plus a separate list of actual items. When you initialize the game, everything ends up in those matrices, and as you pick something up, it moves from the matrix telling which objects are in a certain place to your inventory.

 

A little hard to explain by words, but either you could look around for engines or I could post an example engine I used to use which I found rather decent.

[pacman000]

That's a great way to do it! I've always tried to treat it like a Choose Your Own Adventure book, & have never gotten that far.

 

10....

20 INPUT N$

30 IF N$ = "GO NORTH" THEN GOTO 175

[bluejay]

2 hours ago, pacman000 said:

10....

20 INPUT N$

30 IF N$ = "GO NORTH" THEN GOTO 175

This is exactly what I'm trying to do...

Yeah. Maybe I should use different methods.

[pacman000]

You don't have to use a two command system; you could give players a menu of options. If they choose "Search Area," & nothing's there, display "Nothing Found."

[carlsson]

My biggest, still not fully debugged and never released, text adventure on the C64 was about 60 locations. Implementing it as a CYOA book with tons of repeated IF statements and spaghetti code would have been an even bigger nightmare than it really was.

 

You could list some typical BASIC adventures or look up one of many tutorials in how to make one. Eventually I'll have some time to tidy up my code and be able to post it here, though I'm not saying I have the perfect solution.

[CapitanClassic]

You might want to checkout archive.org for some old digitized programming books designed for beginners/kids. These books give good examples of how you could design a BASIC game parser (standard 2-word verb, noun variety), how all the parts work together, and even includes a Haunted House game listing as an example of a working prototype.

 

There were several books within the series, with Write Your Own Adventure Program probably covering exactly what you would like to do.

 

https://archive.org/details/write-your-own-adventure-programs/page/n1

 

 

[jhd]

 

There is also:

Creating Adventure Games on Your Computer
Golden Flutes & Great Escapes: How to Write Adventure Games

http://69.60.118.202/generic/generic-books-games.htm

 

I had both Creating Adventure Games on Your Computer and Write Your Own Adventure Programs in print back in the 1980s. The first book is really good -- it develops a sample adventure game, adding more features and complexity with each chapter. 

 

 

With the Vic-20, you may quickly encounter issues with the screen size and the limited RAM, especially as the game grows larger. You may wish to consider an alternative platform before spending too much time on this.  (I had a Coco BITD, and the 32-column screen was a serious impediment to porting/playing adventure games originally developed on other systems.)

 

Edited November 7, 2019 by jhd

[CapitanClassic]

I wasn’t looking that closely. The Vic-20 only has 3583 bytes available after basic loads. Your text adventure game is going to have to be pretty small, with very short descriptions for the rooms.

[bluejay]

Changed plans. I accidentally erased the files of the game(damn sound effect program!), and since it's already all gone, why not just make it on a CoCo2?

Now I have about 11k of free data to play with, and a much better(imo) version of BASIC!

My cassette drive doesn't exactly work fine, so I'll have to leave it on for a few days...

[Gamemoose]

On 11/10/2019 at 5:31 PM, bluejay said:

Changed plans. I accidentally erased the files of the game(damn sound effect program!), and since it's already all gone, why not just make it on a CoCo2?

Now I have about 11k of free data to play with, and a much better(imo) version of BASIC!

My cassette drive doesn't exactly work fine, so I'll have to leave it on for a few days...

In some issue of "The Rainbow" magazine is a text adventure creator written in BASIC.  It's been decades since I looked at it, but it basically asks some general questions then coughs up a program with the engine in place. All you need to do is fill in the locations, descriptions, objects, etc.  

 

I can dig through my magazines to see if I can find it. My Dad started to write a game with this that centered around a bomb placed in a hotel. You as the detective/officer on the scene had to find it along with the tools you need and other clues. It's playable but not finished. Unfortunately all I have of it is the faded master printout. 

 

If you wanted to do it from scratch, there are many adventure programs from Rainbow (like Rainbow Book of Adventures) or Hot CoCo magazine that you can learn from.  If you wanted to do graphic style text adventures, Richard Ramella's "Escape from Lurkley Manor" from an early-to-mid 80's October issue of Rainbow Magazine is a great example. He programmed in the alphabet in graphics which would print whatever you had typed in.

[GlennJupp]

On 1/28/2020 at 4:41 PM, Gamemoose said:

In some issue of "The Rainbow" magazine is a text adventure creator written in BASIC.  It's been decades since I looked at it, but it basically asks some general questions then coughs up a program with the engine in place. All you need to do is fill in the locations, descriptions, objects, etc. 

August '82, page 47, and the folks at the Internet Archive got it.

[Gamemoose]

3 hours ago, GlennJupp said:

August '82, page 47, and the folks at the Internet Archive got it.

That's a cool way to get one started and do the work, but that's not the program I'm thinking of. We never had that issue.

 

He worked on the program in 1987, though just skimming the Archive nothing popped out at me. You literally told it number of rooms, number of items and then it coughed up a program on tape (or disk) with general rooms , items, etc. You went in and changed the info or added if you wanted. 

 

Still-great start!

[GlennJupp]

37 minutes ago, Gamemoose said:

That's a cool way to get one started and do the work, but that's not the program I'm thinking of. We never had that issue.

 

He worked on the program in 1987, though just skimming the Archive nothing popped out at me. You literally told it number of rooms, number of items and then it coughed up a program on tape (or disk) with general rooms , items, etc. You went in and changed the info or added if you wanted. 

 

Still-great start!

Oh, that sounds so familiar now.  I'm sure I used to have that issue.

 

The Adventure Processor in the August '86 issue?  Sounds about right for '87.

[Gamemoose]

8 minutes ago, GlennJupp said:

Oh, that sounds so familiar now.  I'm sure I used to have that issue.

 

The Adventure Processor in the August '86 issue?  Sounds about right for '87.

Yup! I skimmed right over it. That's what I get squinting at a phone. Thanks!

[jhd]

 

There was also a three-part series in Rainbow February through April 1984. The first issue introduced the basic framework for a game, the second issue added enhancements, and the third demonstrated how to make it into a graphical adventure. It was modular and easy to expand to add new objects, commands, etc. 

 

I used that structure as the basis for a massive, albeit never released, game. 

[800xl_1984]

Ed Churnside wrote a great set of ML routines for the Atari to help with creating adventure games, published by Antic as "Dragon's Toolkit and Integrated Library (TAIL)" in the '80s. While the routines may be of no help on a non-Atari platform, the documentation includes a wealth of ideas on how to structure the programming mechanics to make things manageable. A few years ago, I cleaned up the text file and converted it to a PDF. Look at Part IV starting on page 87. The file is too large to upload here, but you can access it on my site.

Edited May 3, 2020 by 800xl_1984

[800xl_1984]

On 10/31/2019 at 2:55 PM, carlsson said:

A little hard to explain by words, but either you could look around for engines or I could post an example engine I used to use which I found rather decent.

Would love to see an examples you might have, even if the code isn't completely clean.

[carlsson]

Out of boredom, I dug up my so far never published text adventure Incantation (Besvärjelsen in Swedish). It is programmed for the Commodore 64 and features 65 locations, 67 items, 23 commands, combinations of items, 13 ways to die and a brief help system. It should be noted that I wrote this when I was 15 years old, so it contains some pubertal elements as well as some time typical references of which I removed the most obscure ones when I translated it into English.

 

The listing also contains some interesting cases of spaghetti code, FOR loops that are not properly ended, GOSUB in multiple steps until you run out of stack space and other programming issues that I would put more effort in fixing if I was to redo this now, more than 30 years later.

 

The main loop looks like this:

 

Line 4000: Print a description of your location, items available etc.

Line 3500: Input command. It breaks the input into two words and checks the first against the verb list, and the second against items. If a match was found, the variables ve and su are set accordingly.

Line 3515: Move into a given direction.

Line 2500: Interpret each command. This routine probably could be prettified with ON x GOSUB but the way I wrote the program, I'm checking each verb one by one and then skip to the next test routine if it doesn't match.

 

ve = 13 equals GET. It is checked against certain objects and locations and various messages are displayed.

ve = 14 equals DROP, ve = 15 equals OPEN and so on

 

Lines 100-105 are used for end of the game. As mentioned most of the time you would simply die and have to RUN to start again.

Line 500: Help system with stupid clues.

Line 750: Displays screen with available commands.

Line 1000: Endgame to solve the game.

Line 4700: Save game.

Line 4750: Load game.

 

Perhaps what is worth putting more description about are the DATA statements. Each object is assigned a location where you find it, with a minus sign for hidden items (i.e. you have to dig in order to find them). At the end of the object list are available abbreviations for each item, e.g. the jar of honey is abbreviated HON. All items that are not part of the game simply have no abbreviation (blank string) so those are only to fill out the game.

 

The locations consist of a brief description and then a string of locations, where # (ASCII 35) equals no direction and $ (ASCII 36) equals location 1, % for location 2, & for location 3 and so on. All ASCII symbols between 35 and 95 are used (60), and then another 5 graphic symbols CBM-K (161), CBM-I (162), CBM-T (163), CBM-@ (164), CBM-K (165). This may look quite cryptic, but is a rather space saving way to keep a map in memory. You just need to encode the path between each location carefully. I haven't fully play tested my game, so there may be glitches in the matrix. In particular it seems once you arrive at the Wizard's house, it is unintentionally an endless maze...

 

At the end of the DATA statements are the commands. I don't use GO NORTH in this game, I simply use the abbreviations N, S, E, W etc.

 

Not everything is strictly required and there could be a lot of improvements, in particular the routine that handles each verb, but it is an example of an adventure game engine similar to those which were around back in the 80's.

 

Anyway, have fun if you dare to! I might be able to answer some questions but won't put a lot of effort in bug fixing the game in question.

besvarjelsen-en.bas besvarjelsen-en.prg (executable runable on C64)

[Frozone212]

On 4/26/2021 at 8:54 AM, carlsson said:

Out of boredom, I dug up my so far never published text adventure Incantation (Besvärjelsen in Swedish). It is programmed for the Commodore 64 and features 65 locations, 67 items, 23 commands, combinations of items, 13 ways to die and a brief help system. It should be noted that I wrote this when I was 15 years old, so it contains some pubertal elements as well as some time typical references of which I removed the most obscure ones when I translated it into English.

 

The listing also contains some interesting cases of spaghetti code, FOR loops that are not properly ended, GOSUB in multiple steps until you run out of stack space and other programming issues that I would put more effort in fixing if I was to redo this now, more than 30 years later.

 

The main loop looks like this:

 

Line 4000: Print a description of your location, items available etc.

Line 3500: Input command. It breaks the input into two words and checks the first against the verb list, and the second against items. If a match was found, the variables ve and su are set accordingly.

Line 3515: Move into a given direction.

Line 2500: Interpret each command. This routine probably could be prettified with ON x GOSUB but the way I wrote the program, I'm checking each verb one by one and then skip to the next test routine if it doesn't match.

 

ve = 13 equals GET. It is checked against certain objects and locations and various messages are displayed.

ve = 14 equals DROP, ve = 15 equals OPEN and so on

 

Lines 100-105 are used for end of the game. As mentioned most of the time you would simply die and have to RUN to start again.

Line 500: Help system with stupid clues.

Line 750: Displays screen with available commands.

Line 1000: Endgame to solve the game.

Line 4700: Save game.

Line 4750: Load game.

 

Perhaps what is worth putting more description about are the DATA statements. Each object is assigned a location where you find it, with a minus sign for hidden items (i.e. you have to dig in order to find them). At the end of the object list are available abbreviations for each item, e.g. the jar of honey is abbreviated HON. All items that are not part of the game simply have no abbreviation (blank string) so those are only to fill out the game.

 

The locations consist of a brief description and then a string of locations, where # (ASCII 35) equals no direction and $ (ASCII 36) equals location 1, % for location 2, & for location 3 and so on. All ASCII symbols between 35 and 95 are used (60), and then another 5 graphic symbols CBM-K (161), CBM-I (162), CBM-T (163), CBM-@ (164), CBM-K (165). This may look quite cryptic, but is a rather space saving way to keep a map in memory. You just need to encode the path between each location carefully. I haven't fully play tested my game, so there may be glitches in the matrix. In particular it seems once you arrive at the Wizard's house, it is unintentionally an endless maze...

 

At the end of the DATA statements are the commands. I don't use GO NORTH in this game, I simply use the abbreviations N, S, E, W etc.

 

Not everything is strictly required and there could be a lot of improvements, in particular the routine that handles each verb, but it is an example of an adventure game engine similar to those which were around back in the 80's.

 

Anyway, have fun if you dare to! I might be able to answer some questions but won't put a lot of effort in bug fixing the game in question.

besvarjelsen-en.bas besvarjelsen-en.prg (executable runable on C64)

qq, what does you signature refer to? in sweden we have a model? model car? plane? what exactly

[carlsson]

It is a classic saying in international situations where in particular Swedish politicians want to show rest of the world how we do things differently from the rest, like an educational reference whether the model is better or applicable on rest of the world or not.

[Pokeypy]

Using a VIC-20 with just 3K RAM would be an additional challenge one could take, if one had already mastered writing text adventure games on more capable platforms.

Just for entertainment, here would be such an approach in 1K:

 

 

[Pokeypy]

Hmm, ok, this tiny adventure may be a different topic than writing adventure games in general.

 

Here would be its description and original source code:

https://spectrumcomputing.co.uk/zxdb/sinclair/entries/0030392/10CAVEADV.txt

 

And I just did a quick Python conversion. It is tricky code, so I hope, I got it right:

 

#!/usr/bin/python
# coding: utf-8

x = "100Cannot doYou walk Opened   Closed   a sword  a key    Nothing  a chest  a dragon a corpse "
a = 0
while a < 11:
    u = raw_input("You are in a " + "cavepit halllake"[int(x[0]) * 4 - 4 : int(x[0]) * 4] + " ")
    m = 2 * (u == "north") * (int(x[0]) < 3) - 2 * (u == "south") * (int(x[0]) > 2) + ((x[0] + u) == "2west") - ((x[0] + u) =="3east")
    a = (3 + int(x[1]) + 2 * (int(x[2]) == 2)) * ((x[0] + u) == "2look chest") + (11 + (int(x[2]) == 2)) * ((x[0] + u) == "3kill dragon") + (m != 0)


    a += (5 + int(x[0])) * (u == "look") + (6 - int(x[2])) * (u == "inventory") + (6 - (int(x[2]) == 0)) * ((x[0] + u) == "4look corpse")


    a += 10 * ((x[0:3] + u) == "400get key") + 2 * ((x[0:3] + u) == "201open chest") + 10 * ((x[0:3] + u) == "211get sword")
    temp = str(int(x[0]) + m) + str(int(x[1]) + (a == 2)) + str(int(x[2]) + (a == 10))
    x = x[3:]
    x = temp + x
    temp = x + "taken    you died you won. "
    print temp[a * 9 + 3 : a * 9 + 12]

[Pokeypy]

As for writing adventure games on today's platforms, I'd use a hash "exits" inside a Room class, that stores the directions and the rooms, they lead to. This way, you get a web-like structure, that holds all locations. One location points to another, and the player can easily move from one location to the other. I wouldn't use arrays for storing the locations.

In Python, the hash (in Python terms called "dictionary") would for example look like this:

self.exits = {"e" : "kitchen", "n": "living room", "d" : "cellar"}

Like this. This was described here:

 

 

It may be more difficult to achieve that on 8 bit platforms though.

 

In C or Pascal, you could maybe use pointers to achieve such a web-like structure. It's like implementing a linked list, but a multi-dimensional one, where nodes can point to multiple other nodes.

That's quite a different data structure than the 2D array, you may be tempted to use at first glance.

Edited April 28, 2021 by Pokeypy

[Pokeypy]

Now, that was a rather nasty piece of code ...

adventure.c adventure.xex