Adventure Language

I had previously developed a framework for creating BBC Micro text adventure games using Excel to hold the game data and build the output files which were then manually added to an SSD disc image. The details can be found here - https://stardot.org.uk/forums/viewtopic.php?f=65&t=14770#p197797

The data files were consumed by the BBC Basic program which was in effect the game engine - this program also included the appropriate game specific logic.

This approach had a number of issues:

1 - Excel was very clunky to use for this and not everybody has it

2 - The files it created (e.g. message files, object and location files) had to be manually added to the SSD image each time they were changed

3 - The game engine program also directly included the game specific code so if any bugs were fixed in the game engine or improvements made a new game engine program had to be created (effectively by deleting all game logic)

All of which is a pain.

The new approach is to do away with Excel and hold all the game objects and logic in an XML file. The game logic is combined into a BBC Basic source file (held in plain text) at the appropriate points and then output a combination of game engine + logic and data files.

The BBC Basic source file can be amended and managed under source control and any fixes applied can be retained for future versions as it is not amended during the game development process (and even if it is the source and logic are separate).

Each new game to be created is created as a project in a folder structure which is created by calling the "-new" command line with a path and project name (preferably kept to 7 letters - the reasoning behind this should be obvious to DFS users).

Source.txt and AdventureData.xml are amended and then the "-b" (build) command line is used to 'compile' the project into the appropriate files.

Thanks to the presence of various programs for Windows and Mac (and the fact that the main project is written in .Net Core 3.1) it is possible to establish a full tool chain for development. So long as everything is configured correctly once compiled the files are tokenised (Windows only), placed into an SSD file and BeebEm is started up with the SSD loaded and ready to go. On the Mac unfortunately the BASIC is not tokenised so the user has to press Command + W (to unlock drive 0) and then press 'F0' (which is mapped to F10 on my Mac) to call an *EXEC process to tokenise the program within the Beeb itself. Once tokenised the program is saved and run.

A build .bat or .command file are generated by the project creation process in order to simplify the build / compile process - just double click the file!

Improvements made so far:

1. Got rid of Excel and replaced with a main XML file and separate text source file for the BASIC program. Having the game logic in the XML file allows the parser to replace names of variables with their numbers (so @IsDark@ is replaced with 1 at compile time etc.) thus making it easier to change stuff.

2. Full tool chain meaning changes can be made and seen in BeebEm in seconds not minutes.

3. All messages loaded into RAM so the game plays faster

4. Added IT to the parse so you can type TAKE LAMP and then LIGHT IT

5. Added some basic debug facilities (based on a compile setting to include or not) so you can print out the values of variables etc.

6. The compiler produces a verbose listing of what is compiled (called EventLog.txt) which also shows the numbers assigned to variables and messages etc.

7. Locations are now held in RAM (faster) and loaded using *LOAD rather than being read in a byte at a time

8. Locations have flags to determine whether a location is dark or has some other environmental factor of note (underwater, hot or cold etc.) It is dark, you cannot see. Ah those wonderful words... You are in space, you cannot breath. You are in the desert, it is hot and you are getting thirsty. All wonderfully irritating uses of such flags.

9. Exits from locations can now be enabled and disabled (enabled by default) to better handle locked doors in anticipation of wandering monsters. The state of the exits is saved with game save file. Locking is done by adding 128 to the verb number for the direction and checking for the value being < 128 at point of moving. If it is >127 it is locked / disabled. Otherwise it is not. To enable an exit reduce the verb number by 128. This process also means that if the door east is locked and you type EAST the system automatically tells you 'You can't' without further code as the verb does not match.

10. The directions for a room are now automatically shown as part of the room code. This allows much reduced message file size. Some work still to do on making it look nice!

11. Implement a process to remove spaces from the tokenised BBC BASIC file (based on a switch). This currently removes about 900 bytes from the Banzai adventure.

12. Implement a process to rename all PROC and FNs to a single character where possible. This has saved a further 600 bytes in the example game.

13. Added code to allow changing of object messages at run time. This means that objects with two or more states (e.g. lamp on and lamp off) don't have to be two separate objects with associated problems with nouns and code for swapping.

14. Added a walkthrough process in debug mode - press 3 to run the walkthrough steps. The walkthrough stops when an 'error' type message is encountered (e.g. 'I can't find that') and reports the line number where it failed.

I have a number of immediate plans for the game engine and compiler (in no specific order):

1. Include wandering monsters / NPCs. They will have a basic hostility rating towards the player (1 = worst enemy, attack on sight while 100 = best buddies). The initial value will vary by NPC. The monsters will of course be able to carry stuff and attack. Unlike some other games if they run away it will tell you which direction they went in. :)

2. Make the games multi-part. Loading more stuff into RAM will mean less space for game logic. By making the game split over several separate programs large games can still be created which run quickly (once loaded). This will need to include things like global variables (that are retained between sections), global objects and probably a single menu program that controls which section is called when. The save games will get a lot more complex...