Revised BASIC framework and tools to build an adventure

[Lardo Boffin]

I have started working on the environment flags and got that pretty much working, thanks to some efficient coding suggestions elsewhere.

I have also put the c# project on github - https://github.com/LardoBoffin/AdventureLanguage

Improvements, suggestions etc. welcome - I am very new to c#.

[Lardo Boffin]

I have made a few changes to the BASIC program so now it loads pretty much everything up front now. It runs a lot faster.

Attached is the latest SSD with about one third of a reimplementation of Buckaroo Banzai in it. I got a bit sick of Ransom. I will continue to add to Buckaroo as I go along.

It should just auto run.

[Lardo Boffin]

Updated to load the room data using *LOAD which is a bit quicker and persist the exit flags (that enable or disable the use of exits) via the SAVE / LOAD facility.

There is no valid use for it in Banzai but in the first room the exit down is disabled. If you type UNLOCK it will enable the down exit (needs a feedback message) and you can go down. If you go up and leave the building and then SAVE GAME you can LOAD GAME at some point in the future and the down exits will be enabled.

You can also type UNLOCK again to disable the exit down (obviously this would be done in the context of having a key etc. in a proper game).

See the readme on https://github.com/LardoBoffin/AdventureLanguage for more details.

[Lardo Boffin]

The adventure now prints out the directions from a room automatically rather than replying on message text to show them. This reduces the size of the message file somewhat.

I have also improved the ToUpper function based on the thread viewtopic.php?f=2&t=20072.

Attached is the latest build.

[Lardo Boffin]

I have implement the first stage of a memory cruncher - it removes all spaces (except in strings) from the tokenised file. In the part done Banzai adventure this removes around 900 bytes from the program.

Stage 2 will be to go through the procedure names and variables are ensure they are all as short as possible. Note that this will be done in the BBC BASIC file created by the command line program - all of the full names will be retained in the source file.

The updated project is on github.

[Lardo Boffin]

I have now got all PROC and FNs renamed to single characters (although it should handle multiple characters OK) in the output BBC BASIC file.

This has reduced the final program size by around 1600 bytes (including the space removal), so an extra 700 bytes or so, which is a fairly hefty chunk! It also means I can rewrite source.txt (the text file contain non-parsed BBC BASIC code) using far more meaningful names and not waste any memory.

Next to do is similar for variables...

Update code is on github and the latest SSD with crunched names is attached.

[Lardo Boffin]

Started working on adding NPCs to the framework.

Also reduced the number of allowable locations to 255 (0 is used by objects not yet available in the game) from 64000. Given that this is primarily targeted at the model B I don’t think it would be possible to make use of more than 255 locations anyway (plus I will be making this multi-part at some point).

Currently objects with multi states, e.g. a lamp that can be on or off, exist as two separate objects, one for each state. This makes a lot of stuff unnecessarily complex such as swapping objects when turning the lamp on or off. I will change this so that only one object is used but the message number stored against the object is updated when changing state. This will be a minimal change which should only require a bit of extra code to set the message number at runtime. Objects are already saved in the save game in order to retain their current location and the current message is displayed when looking at the inventory (e.g. lamp - off).

[Lardo Boffin]

Forgot to mention above but it is now possible to add new PROC and FNs to the framework as ‘user code’ which can be called from the normal user code sections. So if you have a lot of code relating to a single room or object etc. you can write

IF R%=7 THEN = FNyourcode

Rather than have 10 lines of IF R%=7 AND ....

Saves on bytes and should be faster.

[lurkio]

Update code is on github and the latest SSD with crunched names is attached.

This looks very good, but the example game, Banzai, fails when you try to use this walkthrough.

Have you uploaded the Banzai game data anywhere that's publicly accessible?

Also, a brief tutorial on how to use the latest version of the framework to write a game might be useful.

[Lardo Boffin]

Update code is on github and the latest SSD with crunched names is attached.

This looks very good, but the example game, Banzai, fails when you try to use this walkthrough.

Have you uploaded the Banzai game data anywhere that's publicly accessible?

Also, a brief tutorial on how to use the latest version of the framework to write a game might be useful.

I haven’t finished Banzai yet - I add bits as I go along but I keep finding so many things I want to change in the framework I have not got far!

I will write up how to use this once I stop changing it so often.

The game code and data is in the Source director:

https://github.com/LardoBoffin/Adventur ... reData.xml

The NPCs obviously don’t exist in the original game and are work in progress...

[Lardo Boffin]

The ‘framework’ code is in https://github.com/LardoBoffin/Adventur ... source.txt

This has the user code inserted into it, line numbers added (GOTO is not supported) and then a final text file is produced. On Windows this is then tokenised using a program from Richard Russel and crunched to reduce its size. It is easier to reduce the size once tokenised.

I may have a go at writing a tokeniser at some point when feeling brave enough.

I am also considering ‘borrowing’ your maze input routine concept to automatically change the case as it is entered as this will save some time parsing the input.

[lurkio]

I am also considering ‘borrowing’ your maze input routine concept to automatically change the case as it is entered as this will save some time parsing the input.

Feel free!

[Lardo Boffin]

Implemented the changing state for objects so there are no longer two object records for the torch etc. Also finished off the code that allows the user to write their own FNs etc. without having to amend the source program.

Not yet stolen the change case process from Lurkio (but it is on the to do list, thanks!) but have fixed a bug where you could not type the noun in first. So for example you could type LIGHT LAMP (verb, noun) but not TORCH ON (noun, verb) or TORCH OFF. You can now type TORCH ON etc.

I am looking into having an object have some additional data:

Location (already present and is 0 to 255), with 0 being not yet in the game.
Carried by (0 to 255) and will specify which NPC is carrying the object.
Capacity (0 to 255) which will specify the weight of items that can be put in this object.
Parent object ID (0 to 255) which will specify which object this object has been put into.

If an object is being carried then its location will be 0 and Carried By will be set. If put in a container then Location and Carried By will be 0 and Parent Object ID will be set.

Updates in github, no updated SSD.

[Lardo Boffin]

I am also considering ‘borrowing’ your maze input routine concept to automatically change the case as it is entered as this will save some time parsing the input.

Feel free!

Thanks! The other major benefit of this type of process vs INPUT is that the program stays in control of the passage of time rather than handing it over to BASIC and waiting for INPUT to conclude. This will of course make it easier to implement something like ‘Time passes’ if you don’t type for ages (and therefore make Thorin sit down and sing about gold )

[Lardo Boffin]

I have added more gameplay from Banzai and more importantly for me I have set function keys 1 to 5 to automatically type in all the moves for what is working so far... Press them to see the game whizz by!

I am up to the point where you MAKE FUEL so I think about 60 to 70% done on the walkthrough I am using (http://solutionarchive.com/file/id%2C79/).

[Lardo Boffin]

Added some more gameplay last night - you can now make the fuel, fill the jet car and attach the batteries to it.

Sadly I am now getting a ‘Bad key at line ##’ error when I try to add any more to the function keys so it looks like there is only enough space to define about 2/3 of the game walkthrough in there. Ah well, still saves a LOT of typing.

[Lardo Boffin]

Following on from having run out of function key definition space I decided to do it properly and add the ability to type in a walkthrough solution as part of the game code (see the end of https://github.com/LardoBoffin/Adventur ... reData.xml ) and have this create a text file.

When you start the game on the beeb in debug mode you can press 3 at the start (although the option is not shown on the screen) and it then steps through the walk through file one command at a time.
If the game returns ‘you can’t’ or ‘I can’t find that’ etc. then it stops stepping through and reports the step number that failed. This can be compared to ‘output’ file (which has the steps with numbering) to see exactly where it went wrong.
Otherwise once it finishes the file it hands back control to the player.

Updated SSD to follow.

[Lardo Boffin]

Updated SSD attached.

I have added some rudimentary conditional compilation (of sorts) to the source BBC basic file - if you are building in debug mode then any lines starting with #D will be included but any lines beginning with #R (for release) will be ignored. When building in release mode #D will be ignored and #R included. This allows the inclusion of option 3 (run the walkthrough) being displayed in the menu without splitting lines and wasting bytes.

[Lardo Boffin]

I’m thinking it is time for a built in tokeniser, or at least having a go at one. When building and running a work in progress game the process is:

1) Build the output files / tokenise (separate program) / crunch / SSD and launch BeebEm
2) Load all the game data
3) Run the walkthrough

1) is pretty fast but 2) and 3) can take a while so when you add a bit more game code, run it all to test it and then instantly get a syntax error it is really irritating. Also the Mac version doesn’t tokenise so the program has to be *EXEC’d in. And isn’t crunched.

Adding a tokeniser will mean that I can also easily add in some basic syntax checks, e.g. does the PROC exist that you are calling? Are the “ closed etc.?

[Lardo Boffin]

After a brief break from this I have started adding some notes and fixing some general infrastructure issues that have crept in:

https://github.com/LardoBoffin/Adventur ... /Notes.txt

The tokeniser is very much a work in progress...

I'm about 3/4 of the way through rebuilding Buckaroo Banzai using this framework so this will serve as a good sample adventure / tutorial thing.

[Lardo Boffin]

Thanks to SteveF (viewtopic.php?p=315577#p315577) creating BasicTool (and Lurkio for posting a built mac version) I have been able to abandon my stalled attempt to create a tokeniser in C# (which I will finish one day ) and get back to developing the main project.

I have pretty much integrated basictool into the mac toolchain now so it tokenises the raw text file and builds it into the SSD file.