New adventure game and BASIC (and now C) framework (don’t expect a new Ravenswood)

[Lardo Boffin]

Recently I tried to build a simple adventure game using GAC after being inspired by various recent posts about GAC and some new adventure games appearing that were MIA.

My idea started out fairly simple but rapidly got fairly complex even though it was just a small proof of concept adventure. I eventually gave up on GAC and decided to go it alone. Albeit heavily inspired by GAC’s structure along with a bit of how ALPS does things. No point reinventing the wheel!

So far I have done the following (all in BASIC so far):-

A parser that takes a single sentence and understands a verb, up to two nouns and an adverb (as per GAC). It returns the ID number of each item and stores them in a set of global variables for use wherever. Currently all of these items are stored as DATA statements in an ID number / text pair.

An Excel spreadsheet (cheating I know but time is not my friend) which holds the list of messages and from this produces a Beeb data file and associated index file. The index file allows me to know a message number and get its pointer location from the main message file by setting PTR#.

Code to take a message number and then find its index entry and based on the pointer get the message from the file. This is quite fast although the message file is currently only 6K in size.

Code to take a message and put it on the screen with word wrapping. This is currently quite slow - I may need to improve this or use some assembly at some point.

The idea moving forward is that all the infrastructure code is kept totally generic - it will take loaded message lists or typed DATA lists etc. and have a number of functions built it to handle displaying messages / moving from room to room and handling inventory etc.

There will then be three or four functions which are called at appropriate points by this framework code (high priority, local and low priority events etc.).
All of the adventure specific logic will go in these and will interact with the system variables (parser results etc.) and built in functions in order to make things happen.
Doubtless these functions will start out mirroring the functions in GAC.
All of the adventure specific code will be written in BASIC. In effect you will start out with an empty program and add code to create the adventure.

Conceptually I am not sure about following the GAC process of having objects and related nouns and checking against the noun to be able to interact with the object. Unless you sync the two lists together you have to write custom code to pick anything up.

Also I quite like the way ALPS doesn’t have room text just a reference to a message number. In essence virtually all displayed text is just a message. I can see this saving space when having multiple locations with the same descriptions (e.g. a maze).

The next major chunk to code is handing moving from location to location and its associated data structures. I’m not sure I like the way GAC handless moves - moving from location to location is handled before anything else making some situations difficult to handle.

Following on from that will be inventory handling and general functions / save and load. I would imagine the saving will basically be a case of serialising the various variables in play.

I was wondering about text compression using a simple tokenisation process. Given the linitation on the size of a single DFS disc and load on demand text there is no major rush to implement this.

[Lardo Boffin]

I’m more about the programming challenge than the game itself so don’t expect anything too brilliant from that perspective (hence don’t expect a new Ravenswood ).

[Lardo Boffin]

One question - is there a size limit for individual files in DFS or on the various MMC platforms?

[hoglet]

One question - is there a size limit for individual files in DFS or on the various MMC platforms?

Yes, many DFS based MMC file systems (as well as Data Centre's RAM FS) have a 64KB max file size.

MMFS version 1.23 (and later) fixes this, allowing the whole side of a disk to be used for one file (so effectively a 199.5KB limit)

Dave

[Lardo Boffin]

One question - is there a size limit for individual files in DFS or on the various MMC platforms?

Yes, many DFS based MMC file systems (as well as Data Centre's RAM FS) have a 64KB max file size.

MMFS version 1.23 (and later) fixes this, allowing the whole side of a disk to be used for one file (so effectively a 199.5KB limit)

Dave

Thanks. I remember not being able to run PANOS or similar a while back due to file size on my MMC but could not remember what the limit was.

[richardtoohey]

Have you seen the Peter Kilworth book? (And there are others like it).

Not intending to put you off what you've started, just asking ... might give you some ideas.

[Lardo Boffin]

Have you seen the Peter Kilworth book? (And there are others like it).

Not intending to put you off what you've started, just asking ... might give you some ideas.

What is it called? I do have a few simple how to create adventure books.

[richardtoohey]

Tried to find the proper title of it and then gave up when it wasn't easy Mainly because I got his name wrong.

Bit more effort this time:

How To Write Adventure Games for the BBC Microcomputer Model B and Acorn Electron by Peter Killworth.

[lurkio]

How To Write Adventure Games for the BBC Microcomputer Model B and Acorn Electron by Peter Killworth

viewtopic.php?t=6701#p93243

[Lardo Boffin]

Thanks. I have seen that on eBay from time to time and it is always expensive!

[richardtoohey]

lurkio's link gives you a way of getting to the PDF, so you can save your pounds.

(Re-sharing the link here: http://www.mocagh.org/softguide/writeadventuregames.pdf to save digging).

[Lardo Boffin]

Progress recently: -

All of the verbs and nouns now load from data files into string arrays so no more DATA statements! Adverbs and objects to do, as well as dynamically setting the size of the arrays so you don't need to do it by hand. I suspect the only way to do this would be to step through the file once to count the number of items, dimension the array and then step through again to load it. That or put the size at the front of the file.

Improved the text wrapping for displaying messages. Previously I was working out the next word in the message and seeing if it would fit on the line, if so print it, if not print a new line and then print it. Repeat until the message is done. While seeing each word appear one at a time was quite cool it was also slow and a little distracting.
The new method is hacky but quite fast - get the 40th character in the message and see if it is a space, if so print the 40 chars, if not step back until a space is found (if no space is found by 0 then display an error) and then PRINT MID$(message, start , number of chars) and reset the pointers to continue through the message where I left off. This is not a lot slower than printing without wrapping.

If I ever rewrite the message display in assembly I will do the first message method as it seems somewhat 'cleaner'.

[Lardo Boffin]

Adverbs and objects now load on demand although I need to decide on what attributes the objects have. As a minimum I suspect name, location and weight.

I have also added the facility to have multiple instances of the verbs and nouns etc. so you can have N and NORTH or SWITCH and TURN (e.g. TURN ON / SWITCH ON)

I think for rooms I will allow multiple messages (room descriptions) per room so that large descriptions can be used where required (i.e. larger than 255 chars).

Also there is a ‘progress bar’ while loading the initial data.

[lurkio]

... Also ...

Can you upload a beta, or some screenshots, so we have a better idea of what it all looks like?

[Lardo Boffin]

... Also ...

Can you upload a beta, or some screenshots, so we have a better idea of what it all looks like?

I will try to send a sanitised version tonight. Not a huge amount to show at this stage though.

[Lardo Boffin]

Started working on the Rooms. The room will essentially be an ID number (an artificial limit of 9999 rooms), a list of one or more messages (room descriptions - this will allow for multiple 255 byte strings for large descriptions) and a list of none or more links to other rooms. The links are in the form of verb / room number to link to.
This data is all parsed in the spreadsheet (cheating I know...) so each room has: -

1 byte for number of messages
2 bytes per message to hold the message number
1 byte for number of links
Each link is held in 3 bytes - 1st byte is the verb number and the next two bytes hold the room number

There is an accompanying index file holding the position of the room data so that the room can be found from the file quickly without having to be held in RAM. The index is basically a list of integers of the room file offset position. The first room record is at position 0 and the next record is at the length of the first record plus 1. Retrieving the room position in the file is just a case of applying (RoomNumber - 1) * 5 to a pointer in the index and reading the number there. This number will be the pointer position for the room data. Room 1 is held at position 0 of the index, room 2 is held at position 5 of the index etc.

[Lardo Boffin]

Multiple description rooms are now working although I still need to do something to stop the text scrolling off the screen when it gets to the bottom...

The arrays that hold the verbs and nouns etc. are now dynamically dimensioned so no more wasted RAM or having to increase them by hand.

You can now follow the room links and go from room to room.

Next up will be objects. I am thinking the easiest way to know what is carried and what is not is to have an unreachable room (0 or -1) where the objects are located and go there when picked up. That way finding whether an object is present is as easy as checking the objects location against -1 and the current room number and checking to see if it is carried is as easy checking for -1.

I may end up replacing the text in objects with a reference to a message number to save on what is loaded into RAM if there are a large number of them. Messages seems to load pretty quickly (although no actual hardware to test on yet) and object descriptions are not used constantly.

[lurkio]

Messages seems to load pretty quickly (although no actual hardware to test on yet)

Have you tried it in the latest version of JSBeeb? The audible disc-drive emulation might give you a feel for how slow a real floppy drive might be:

• https://bbc.godbolt.org

[Lardo Boffin]

Messages seems to load pretty quickly (although no actual hardware to test on yet)

Have you tried it in the latest version of JSBeeb? The audible disc-drive emulation might give you a feel for how slow a real floppy drive might be:

• https://bbc.godbolt.org

Thanks, I’ll give it a go. Although to be honest I think this would need to run from MMC or similar otherwise it would be a lot of wear and tear on a disc drive! Each message is load on demand so that is each room entered as well as examining inventory etc. (objects have a reference to a message rather than their own text).

[Lardo Boffin]

Managed to spend a little time on this recently - still far from finished but I have been able to code the example GAC adventure 'Ransom' using the framework and no 'custom code' - i.e. all of the game logic is in the three developer facing procedures and all of it references appropriate API type calls (although that makes it sound grander than it is). All of the data comes from the various files it loads as it goes. These are built in a spreadsheet (which needs further work such as some validation...)

I still need to get load and save to work along with carry weight and score etc.

I have no doubt there are bugs. There are certainly improvements to be made such as the 'You also see .... nothing' message. Hate that but not had time to sort it.

Any suggestions for improvement etc. welcome. There are GOTO statements in there. I know. Bad developer etc. However they are only within procedures to skip unwanted actions and used where any other method would be silly / complex or overkill. So there.

The framework plus Ransom logic is up to about 6K. The variables and data held is just over 1.6K (I think) so plenty of room left in mode 7!

Also this has not been tried on actual hardware as I don't have any at the moment. Beeb-Em only!

Edit - corrected a spelling mistake and got rid of the 'You can also see' message when there are no objects to see.

[Lardo Boffin]

Next up is to finish the framework and actually write the game I was planning to write.

[lurkio]

Very intriguing! I'll have a proper play later.



Oh, already a feature request!: can you make clear-screen-on-new-location optional?

[Lardo Boffin]

Done. Change Q% on line 30 from 1 to 0 to re-enable CLS on change. I may have to do it properly with a command like CLS ON and CLS OFF etc.

I have also added SAVE and LOAD. They seem to work!

That mostly leaves carry weight and a lot of work on the spreadsheet...

[Lardo Boffin]

Clearing the screen is now off by default but can be changed by CLS ON and CLS OFF. This is part of the saved state.

I have added carry weight allowing you set a maximum and prevent items being picked up etc. Also added a front facing function for random numbers which is reseeded by TIME every time it is called.

Score, spreadsheet and some improvements on the message printing system to do!

[lurkio]

I have added ...

Tried the latest update.

Can't type L as an abbreviation for LOOK.

Can't DROP LAMP.

See attached disc-image with savegame.

Btw, the BASIC program is inevitably slowing down now as you add more features, but it can be compressed and speeded up slightly by using the Pack routine in the PRES Advanced BASIC Editor ROMs.

• ransom-2.ssd.zip

  (6.57 KiB) Downloaded 88 times

[Lardo Boffin]

Thanks. Some of it will definitely need to be relaced with machine code, specifically the parser first - that is the slowest part.
Packing will help a little and I will give it go.

I have not set up abbreviations for many of the words so they will only take the full word - this is ‘user’ data and not hard coded anywhere so easy enough to add.

As for the lamp I suspect that is because it is the lit lamp? I noticed that myself. This is what I would call an adventure logic bug! Will resolve and update.

[Lardo Boffin]

Added L for look.
Fixed the lamp - you can now drop and pick it up when lit.

Not done anything about the speed yet....

[Lardo Boffin]

I have just done a bit of timing:-

Room (including loading message file etc.) - 1.3 seconds

Parser (e.g. TAKE LAMP) - 0.4 seconds (longer sentences with no matches take several seconds)

Conditions - around 1 to 1.2 seconds. This is with only around 27 lines of conditions. A large adventure may have several hundred conditions.

This is all running in beeb-em. I notice with interest that running it with a 6502 co-processor makes very little difference, maybe 10 to 15%. Which surprised me somewhat.

Conclusion. Doh!!!

I can speed up the parser with relatively simple machine code but the conditions would have to have their own language invented in order to be significantly faster.

Or I try the whole thing in BCPL? I do not fancy trying to make a runtime of that lot though!

[Lardo Boffin]

I have spent additional time looking at where it is slow and while it is down to the conditions it is not down to quantity of them so much as the functions they call when activated so I think this while thing may still be reasonable in BASIC. Although I may need to do the object handling in assembly at some point as I think this is where the major slow down creeps in.
Regardless I have trimmed some fat and improved some code and this version is a little faster although I am not sure how noticeable it will be.



I have however introduced a crash bug if you miss type stuff now. Argh.

Edit - bug fixed.

I think I may load the system messages into RAM rather than loading them on demand as this should speed things up somewhat.

[Lardo Boffin]

I have changed it to load the system messages into an array rather than on demand every time. This takes up an extra 300 to 400 bytes (mostly for the messages array) but any actions using them are now significantly faster, e.g. TAKE LAMP is more or less instant, while LIGHT LAMP (which still loads a messages) takes a noticeable amount of time.

Still I guess this is a small price to pay for being able to load from 64K (on an SSD) of messages. Thats a lot of words!

I have attached the spreadsheet that is used to build the adventure.

Some notes:-

Excel:-
Messages are held in a string file. There is a corresponding index file (integer list) to point to each message based on its number. E.g. message 5 starts at the number pointed to by integer starting at ((5-1)*5)=20. Therefore set the PTR# and retrieve the number in the index. This is the PTR# for the message. Excel builds the index file as it builds the message file.

Rooms are held as a byte structure file.
* 1 byte for number of messages
* 2 bytes per message number
* 1 byte for number of links to other locs
* 3 bytes per link (verb / room number)
There is an index file to point to rooms based on its number.

Verbs, adverbs and nouns are held in an int / string file (number / word). This allows multiple different text for the same number (e.g. Get / Take)

Objects are held as byte files.
* 1 byte for number
* 2 bytes for message number
* 2 bytes for location
* 1 byte for weight
* 2 bytes for value (e.g. for score)

Object location is typically 0 (not yet in play), a room number or 10,000 (in inventory). When saving the game the object list in included.

On the Command tab click the button Output Files to create the various files - these automatically go into a sub folder where ever the XLS is. I then use FSManager.exe to drag the files into the appropriate SSD file (making sure it is not still open in beeb-em as this seems to corrupt it)

General notes

The verb, adverb, noun and object files are loaded into dynamically dimensioned arrays (step through the file once to see how big it is, set the array, step through the file again).
Messages and rooms are loaded on demand.

Parser notes

Each word in a sentence is compared to the array lists in the following order:-
1. Verb
2. Noun 1
3. Adverb
4. Noun 2

As this is the most likely order of typing. When a word is matched the appropriate variable is set and that list is not looked at again (except nouns). E.g. light the lamp with the flint:-
1. Verb = light
2. Noun 1 = lamp
3. Adverb = with
4. Noun 2 = flint

If verb = 0 at the end say ‘pardon?’. If >0 and no code claims the sentence say ‘you cannot do that’.

Basic code flow
1. Pre-room code
2. Show room messages
3. High priority code
4. Low priority code
5. Check move table

Pre-room code is run before the room description is shown and will typically be used for setting room environment data, e.g. light / dark. In other systems you have to set this when you move from other locations into an area. If you therefore can get into the location from 4 other locations that makes for 4 sets of code. This is an adventure specific PROC for the dev to populate.

Show messages
* Check for light dark and if dark and no light source display a ‘you cannot see’ message
* Show all messages
* Show all items visible (object location = here)

High priority code runs after entering a room and displaying the message(s). This is an adventure specific PROC for the dev to populate.

Low priority code runs after the user types something. This is an adventure specific PROC for the dev to populate.

Check the move table is the final process. This is automated based on the room location link table. Assuming other code has not moved the character.

Counters - there are 256 counters which can be treated as either boolean or 8 bit numbers.

And of course this is all written in BASIC so any functions you feel like can be added.