Colossal Cave Adventure in batch
Posted: 25 Aug 2013 16:49
Well, since I've already demonstrated how pure batch can be used to develop a classic arcade style game: SNAKE.BAT, I thought it was time to show how batch could be used to develop a text based interactive fiction game.
Developing my own game would take a ridiculous amount of time, so I opted to port an existing game to batch.
What better game than the grand-daddy of them all: Colossal Cave Adventure - the 350 point version by Crowther and Woods. It is the forebear of all interactive fiction games that followed.
The batch implementation is too large (~150kb) to embed the code directly, so I've attached a zip file.
Here is the adventure.zip file:
You can also downloaded the game from my DropBox: http://goo.gl/2ohAxB Current version = 1.6 2015/03/27. Download the file, adventure.bat.txt, and then rename it to adventure.bat. EDIT - I've used the Google URL shortener in my link so that I can crudely track how many people have downloaded the game.
The FORTRAN source code I used as a basis for my implementation is available at http://rickadams.org/adventure/e_downloads.html
There are only a few technical hurdles to overcome to make an effective batch IF game. The biggest issue stems from the fact that batch is an interpreted language. All of the code and data is in plain sight within the script. We don't want a player to cheat by looking at the script to figure out how to beat the game.
The solution I used is to selectively encrypt all text messages, variable names, and labels using a simple rotation cipher. The game is first written without encryption. Text that is to be encrypted is enclosed within curly braces {}. Encrypted text can span multiple lines. Sometimes I need to be able to enable or disable encryption in a way that is invisible to the batch parser. That is easily accomplished using undefined variables %{% and %}%.
I then include a command in the game that makes a copy of the script, with selective encryption. The command is symetric - if the running version is encrypted, then it creates the un-encrypted version, and vice-versa.
The encrypted version of the game is ADVENTURE.BAT. The decoded "source" is called ADVENTURE_SRC.BAT. During game play, the encrypted version dynamically encodes all user input so that commands may be properly parsed, and decodes all screen messages so the player can read them.
Both versions play identically. The encrypted version is simply a little slower because it must decode any text that is displayed.
The other hurdle I faced was how to deal with exclamation points in the database of text messages. They cause problems when delayed expansion is enabled and a FOR loop is used. I could have modified the data, but I wanted to use the original game database with minimal changes. I opted to include a routine that performs search and replace on text input, dynamically replacing each ! with an escaped form: ^!
The rest was simply brute force design and programming (and learning how to read FORTRAN) It took about 2.5 weeks of development during nights and weekends.
My version of this classic is intended to be a mostly faithful replica of the original. Here are a list of known differences from the Plotkin version that I used as my source:
- Command words have been restored to the first 5 characters of the word, instead of 4. This is in keeping with the original Crowther version.
- Command parsing and error messages have been reworked, especially the message for a verb with a missing object. But it should not impact game play.
- Bridges may be crossed using compass points. The restriction on using a special crossing verb seemed silly.
- The "BACK" command is implemented in a simpler way. Its behavior is very similar to, but not exactly the same as the original.
- A few choice synonyms have been added.
- The "GRATE" serves only as a noun, never a movement word.
- A hint for the elusive last point has been incorporated into the game.
- Completing the game required a random event. Sometimes the random event never occurred in the original, making it impossible for the player to complete the game, even though the player made all the right moves. I made a slight change to the end game mechanics to nearly guarantee that a well played game can always be completed.
- There is one aspect of the end game code that I did not understand. I had to comment out one instruction to get the game to work. I think I got it correct, but I'm not sure. This issue was fixed in version 1.4
I've done a fair amount of play testing, but certainly not exhaustive testing. Please let me know if you find any bugs, or incorrect behavior.
The link near the top is to the encrypted version of the game. Instructions for getting the un-encrypted version are below. But I suggest you avoid looking at the un-encrypted code if you have never played the game before.
I fully expect there to be bug fixes over time. I will post changes to my Google site, and post notifiation to this thread.
---------------------------------------------------------------------------------------
Below are the instructions on how to decode the script, in case you want to see how the program works. I've embedded the key word below in a way that you won't accidentally see it.
One by one, you get the letters. Be sure you do this correctly. Follow the instructions carefully. Use the first uppercase letter of each sentence in this paragraph. Since the source and walkthrus are readily available on the web, it's not a big deal to publish the un-encrypted form. Caution: don't do this if you don't want to see any spoilers. After you collect all the letters, put them together to get the command word. The command to decode/encode the script takes about 15 minutes to run. Enter the command immediately after answering the instructions question - it will not work at any other point in the game.
Enjoy
Dave Benham
Developing my own game would take a ridiculous amount of time, so I opted to port an existing game to batch.
What better game than the grand-daddy of them all: Colossal Cave Adventure - the 350 point version by Crowther and Woods. It is the forebear of all interactive fiction games that followed.
The batch implementation is too large (~150kb) to embed the code directly, so I've attached a zip file.
Here is the adventure.zip file:
You can also downloaded the game from my DropBox: http://goo.gl/2ohAxB Current version = 1.6 2015/03/27. Download the file, adventure.bat.txt, and then rename it to adventure.bat. EDIT - I've used the Google URL shortener in my link so that I can crudely track how many people have downloaded the game.
The FORTRAN source code I used as a basis for my implementation is available at http://rickadams.org/adventure/e_downloads.html
There are only a few technical hurdles to overcome to make an effective batch IF game. The biggest issue stems from the fact that batch is an interpreted language. All of the code and data is in plain sight within the script. We don't want a player to cheat by looking at the script to figure out how to beat the game.
The solution I used is to selectively encrypt all text messages, variable names, and labels using a simple rotation cipher. The game is first written without encryption. Text that is to be encrypted is enclosed within curly braces {}. Encrypted text can span multiple lines. Sometimes I need to be able to enable or disable encryption in a way that is invisible to the batch parser. That is easily accomplished using undefined variables %{% and %}%.
I then include a command in the game that makes a copy of the script, with selective encryption. The command is symetric - if the running version is encrypted, then it creates the un-encrypted version, and vice-versa.
The encrypted version of the game is ADVENTURE.BAT. The decoded "source" is called ADVENTURE_SRC.BAT. During game play, the encrypted version dynamically encodes all user input so that commands may be properly parsed, and decodes all screen messages so the player can read them.
Both versions play identically. The encrypted version is simply a little slower because it must decode any text that is displayed.
The other hurdle I faced was how to deal with exclamation points in the database of text messages. They cause problems when delayed expansion is enabled and a FOR loop is used. I could have modified the data, but I wanted to use the original game database with minimal changes. I opted to include a routine that performs search and replace on text input, dynamically replacing each ! with an escaped form: ^!
The rest was simply brute force design and programming (and learning how to read FORTRAN) It took about 2.5 weeks of development during nights and weekends.
My version of this classic is intended to be a mostly faithful replica of the original. Here are a list of known differences from the Plotkin version that I used as my source:
- Command words have been restored to the first 5 characters of the word, instead of 4. This is in keeping with the original Crowther version.
- Command parsing and error messages have been reworked, especially the message for a verb with a missing object. But it should not impact game play.
- Bridges may be crossed using compass points. The restriction on using a special crossing verb seemed silly.
- The "BACK" command is implemented in a simpler way. Its behavior is very similar to, but not exactly the same as the original.
- A few choice synonyms have been added.
- The "GRATE" serves only as a noun, never a movement word.
- A hint for the elusive last point has been incorporated into the game.
- Completing the game required a random event. Sometimes the random event never occurred in the original, making it impossible for the player to complete the game, even though the player made all the right moves. I made a slight change to the end game mechanics to nearly guarantee that a well played game can always be completed.
- There is one aspect of the end game code that I did not understand. I had to comment out one instruction to get the game to work. I think I got it correct, but I'm not sure. This issue was fixed in version 1.4
I've done a fair amount of play testing, but certainly not exhaustive testing. Please let me know if you find any bugs, or incorrect behavior.
The link near the top is to the encrypted version of the game. Instructions for getting the un-encrypted version are below. But I suggest you avoid looking at the un-encrypted code if you have never played the game before.
I fully expect there to be bug fixes over time. I will post changes to my Google site, and post notifiation to this thread.
---------------------------------------------------------------------------------------
Below are the instructions on how to decode the script, in case you want to see how the program works. I've embedded the key word below in a way that you won't accidentally see it.
One by one, you get the letters. Be sure you do this correctly. Follow the instructions carefully. Use the first uppercase letter of each sentence in this paragraph. Since the source and walkthrus are readily available on the web, it's not a big deal to publish the un-encrypted form. Caution: don't do this if you don't want to see any spoilers. After you collect all the letters, put them together to get the command word. The command to decode/encode the script takes about 15 minutes to run. Enter the command immediately after answering the instructions question - it will not work at any other point in the game.
Enjoy
Dave Benham