Last week Mike and Pete Gerrard outlined the general approach to adapting a book. Now programmer Pete converts the Conan Doyle yarn that they chose, 'The Sign of Four', from printed page to program

In the previous article we discussed the problems of making a Conan Doyle story into an adventure. We said we divide the work into writing and programming, and then go our own separate ways.

As the programmer, I am presented with a collection of A4 sheets, usually one for each location (see issue 105). These contain the room descriptions, and any possible changes as the adventure progresses, the challenges (if any) to be found at each location, messages or objects to be found there, and the directions in which the player can move from.

I also get the map for the game at this stage, although this is of surprisingly little use until it comes to testing the finished game.

You might think this would make life a lot easier, but in fact it's the source of many problems. As with preparing the A4 sheets in the first place, the question is always 'where to start?'

Obviously a short introductory program is needed to set the scene, which is the purpose of the short listing called Start. Examining the listing reveals that a number of conventions have been observed.

For instance, Line 10 contains the cryptic phrase:

   PRINT "[CLR,BLC]";:.

This means: type in the word PRINT, a set of quotation marks, and then the keys marked CLR and BLK. In other words, we want to clear the screen and start printing text in the colour black. [CD] implies that you need to press the cursor down key, to move text down, and any others used should be self-explanatory.

Another point to note is that you must use the abbreviations for keywords when entering some of the longer lines, e.g. use ? instead of PRINT, T shifted H instead of THEN, and so on. Finally, owing to the limitations of my printer, letters entered using the SHIFT key are printed out in italics, and letters entered normally appear in upper case. Just something that we all have to live with.

Lines 210 and 220 load and run the main program by printing the name on the screen and poking a carriage return, the letters R, U, N, and another carriage return into the keyboard buffer. This program is for disk use, so tape users should exchange the 8 towards the end of line 210 for a 1.

First, write out all the verbs and nouns you think you'll need in the program. This list will change and expand as you get further into the program, but this gives you a starting point. The program checks for the first four letters of any word that the player might use, so lines 5100 to 5103 contain the data for all your verbs, and lines 5200 to 5205 contain the data for all nouns - objects - used in the game. All these objects have to start life out somewhere, or be hidden from view until the player can find them, so line 5004 initially sets everything to zero. The player won't come across anything until we let him.

You also need some longer descriptions for each object as it isn't much use telling a player that he can see a TELE when we want him to see A TELEPHONE. This is all found in lines 5500 to 5513.

What I usually do next is type in the map data, with possible directions of movement. Lines 5050 to 5058 contain this; four numbers for each location, which tell you which room a player can go to by moving north, south, east or west respectively. This is read in by line 5001.

All that remains before the real work begins is to type in the location description. Initially, these are taken directly from the sheets of A4 paper supplied by Mike Gerrard. Quite often when the adventure expands faster than the universe, you have to go back and abbreviate some, but as this is simply a boring typing job which requires no programming skill at all, it's best got over and done with.

Consequently, lines 2000 to 2384 contain all the location descriptions. The variable used to tell the program which location the player is currently in is the variable CP, which is controlled by lines 4000 to 4004. This ensures the correct description is printed up for each location.

I've made no attempt at text compression here, as the adventure isn't particularly large and getting it all to fit into the memory of the Commodore 64 wasn't a problem. However, owners of other machines might like to tackle this problem. Perhaps the simplest way to tackle this is to use symbols instead of common words, and then use a program to check through each room description, printing the full word instead of the symbol if the program finds it. For example you might use the shifted T instead of the word the, since it frequently occurs. And not only by itself: words such as rather, another, and so on, all contain the.

Next comes the coding for the verbs, and checking what the player types in. Taking the latter first, take a look at lines 60000 onwards. This is the input routine, which makes sure that the player cannot escape from the program by pressing e.g. the cursor keys. Run/Stop and Restore have not been disabled, though they could be if you wanted to make the program foolproof.

The player is limited to 27 letters (line 60080 sees to that) and generally the routine checks for ASCII values of keys being pressed, enabling the player to correct any mistakes, and to press the RETURN key once happy about what has been typed in.

How do we analyse this? Well, in Basic we're obviously not going to approach the sophisticated analysers of people such as Melbourne House or Infocom, but we can go a reasonable way towards that.

Lines 390 to 412 control this part of the program.

With this routine we can handle sentenced such as GO NORTH AND GET KEY or KNOCK AT HOUSE NUMBER 3, for example. Look at the listing to figure out how it works (lots of string handling); the basics of it are a check on each character typed in, and building that into a four-letter verb-noun format. The program then checks through every verb and noun that it knows; if this corresponds to what the player has typed in, we get a value for VB (the verb) and NO (the noun). The whole program revolves around VB, NO and CP.

Move on to enterting the code for each of the verbs, starting with essentials such as GET, DROP and those handling movement. Now you can get on with testing the program, and adding other verbs as you go. Be prepared to change with new developments. I'm sure Conan Doyle changed The Sign of Four a few times before it was published.

If you look at line 100 you'll see a SYS call (the machine code data is poked in by line 20000). This is a convenient way of handling program control, although if you're not using the Commodore 64 you may have problems. Essentially, it allows us to go to the program line whose number is given by adding 980 to the verb number times 20. So, if VB was equal to eight, we'd go to program line (980+8*20), i.e. line 1140. A computed GOTO for the Commodore 64.

The first verb is OPEN, so if the player had typed in OPEN then VB would equal 1, and we'd go to line 100. If the second verb, UNLO (short of UNLOCK), was typed in, we'd go to line 1020, and so on.

The verb OPEN is a handy example of how it all works. Line 1000 checks to see what room the player is in; if they're not in any of the rooms given, there's nothing to open, go GOTO line 1019. Always try to structure your verb-handling so that either the most likely, or the most unlikely, responses are dealt with at the beginning. Then program execution appears to be reasonably fast.

Line 1001: If the player is in room 56 and trying to open object 67, the chest, inform him that it's empty, and go back to the main part of the program. The next line simply goes to 1019 if they're in room 56, since there's nothing else to open there.

Line 1004: This checks to see if the player is in room 8; he's trying to open the window. That is, he's trying to open object number 20 and the window counter hasn't been set. If everything's okay, print the OPEN WINDOW message, set the variable, and add one to the variable CL. CL comes into play only at the start of the game, as the player is given a specific number of moves in which to find 12 Clues. In the book, the police arrive fairly soon after you do, so we've attempted to reproduce that part here. Line 392 keeps an eye on how many moves have elapsed.

Line 1005: Checks to see if the player is trying to open the door in any one of locations 1, 2 or 5, whereupon they are informed that the door is locked. Then, unless he's in the only other one where they can open anything (room 52), program control is sent off to line 1019 again.

And so it goes on, checking for objects and locations and variables before allowing the player to act. You will probably find that the first few versions of the program do not work correctly (checking your adventure is the most difficult part of all) and the version of The Sign of Four that you're looking at now is the fifth or sixth. We apologise for any errors that might remain in it, but if Melbourne House can have Watson charging into the hallway at Baker Street while still inside a Hansom cab, we're in good company.

Good adventures are not difficult to write. They just take a lot of time and perseverance. If you've ever baulked at taking up the challenge, why not give it a go now?

Try changing the listing, a little bit at a time, to get the feel of what's happening, and before you know it, you'll have a totally different game.

Cassette users need to make minor changes to the program.

This affects the save and load routines when you wish to record your progress onto tape. As it stands, the program is designed to save the current game status onto disk, so you must make the following changes:

1. Change line 1427 to read:
    
   1427 OPEN1,1,1,"SIGN DATA"
2. Alter the PRINT#2 statements in lines 1428 and 1434 to become PRINT#1 statements.
3. Change the CLOSE2 statement in line 1435 to become CLOSE1; then alter line 1447 to read:
    
   1447 OPEN 1,1,0,"SIGN DATA"
4. Alter the INPUT#2 statements, lines 1448 to 1452, to become INPUT#1 statements.
5. Change the CLOSE2 statement in line 1453 to become CLOSE1. Now you have a tape-based version.