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

[Lardo Boffin]

As a guide without adventure specific code the program is about 5.2K and with the verbs etc. loaded for the Ransom adventure there is about 2.2K of heap used by variables / data.
I make that about 17K free for user code and additional verbs etc. on a beeb model B with DFS in mode 7.

[Pablos544]

It sounds very interesting this system of yours. I was hoping to do a PAW for the BBC Micro myself, with graphics similar to TKV. Yours seems like it's got some of the right stuff and it's going the right way, I hope you do well LardoBoffin

[Lardo Boffin]

It sounds very interesting this system of yours. I was hoping to do a PAW for the BBC Micro myself, with graphics similar to TKV. Yours seems like it's got some of the right stuff and it's going the right way, I hope you do well LardoBoffin

Thanks. Graphic are not on my radar - I would not know where to start!
Hopefully I will be able to shrink the main program down and speed it up by replacing some of the stuff with machine code. That way if someone wanted to add graphics they could run it in a mode where that is possible. Although having seen some of the mode 7 artwork it could work right now!

[Pablos544]

Graphic are not on my radar - I would not know where to start!
Hopefully I will be able to shrink the main program down and speed it up by replacing some of the stuff with machine code. That way if someone wanted to add graphics they could run it in a mode where that is possible...

Might well be worth taking a look at this. Although my 6502 assembler skills are slightly non existent. I was always very partial to PAW, in my youth I made an Adventure Game sort of like TKV that easily could have been published had er.. things not got in the way of it. I actually really loved that system and see it as a long term goal to make it work on a BBC B with sideways RAM. As I said though my 6502 assembler skills are pretty well on the non-existent side, so I'm really hoping your BASIC/6502 is a bit better than mine and I'll definitely be checking out your code. Thanks Lardo Boffin

[lurkio]

I have changed it to load the system messages into an array ...

Would it speed things up a bit more if you cached the current location-description in memory and then used the cache (instead of accessing the disc) if the player types LOOK when they haven't moved to a new location?

[Lardo Boffin]

I have changed it to load the system messages into an array ...

Would it speed things up a bit more if you cached the current location-description in memory and then used the cache (instead of accessing the disc) if the player types LOOK when they haven't moved to a new location?

It would but rooms are allowed any number of messages for their description (well, up to around 100) so it could in theory be caching a load of data.
It should be possoble to always cache the first one as I suspect most rooms will only have one or two.

[Lardo Boffin]

I have finally managed to get to a beeb and install an SD card reader and it actually runs quite well! Certainly somewhat better than BeebEm which presumably more accurately reflects the disc drives of the day.

[Lardo Boffin]

In an effort to learn C I have rewritten the BASIC framework in C, because, well, why not?

I have written it using the Norcroft Compiler and Twin as an editor on my Master 128 running a Pi ARM Co-processor. Having the files installed on my DataCentre HDD has helped somewhat with speed issues! Over a 1000 lines (with comments and white space) tends to compile in around 30 seconds.

As it stands it is BBC Basic rewritten as C and so is not really making much use of the extra facilities of the language and my head hurts from trying to get to grips with pointers - given all of the text and array handling it turns out this was an ideal crash course in using them. So in effect the program is as before - a chunk of generic code acting as an API and then functions where the game logic is implemented.

I have written it using only commands taken from the Beebug C manual so presumably it will be compatible with this but as I move forward with this program I am getting spoilt by having 4MB of RAM... It is kind of tempting to load everything into RAM and avoid all wait times where previously it was loading from disc.

It is still a little rough around the edges with some unwanted formatting and lack of nice colouration in Mode 7 yet but this will be added as I go along. I have added the facility to use IT in commands, so you can type "Take lamp", "Light it". It will refer to the previous noun.

I am planning on adding the ability to have NPCs (which can wander around like in TKV) along with combat and a more sophisticated parser etc. After I get it to do everything like this I think it needs (any suggestions welcome) I will start the process of creating its own language so it no longer needs any skills in C or use of the compiler to create the game logic. I think that the 10MHz processor coupled with the C compiling to ARM Code (I believe) will make an interpreter fast enough without me immediately having to resort to learning assembly. Once I have the language working in C I suspect the assembly implementation will be a lot easier (not easy but easier ).

Attached is the Ransom SSD - you will need a Beeb running DFS and an ARM co-proc to run it. I appreciate that running it on the ARM limits its target audience somewhat but hopefully most people have a Pi co-proc by now. Given that they only cost the equivalent of a good night out on the ale there is really little reason not to.

It saves to disc at times (the achievements process, which I think I will make optional so it can be switched off via a command line or similar).

At the moment the RANSOM exe is about 49K in size so no concern yet about the 64K file limit in some DFS implementations.

So there you go, nothing particularly clever but I suspect there are not too many games for the beeb written in C running on the ARM (cue a huge list of games that do... )

Any problems running it please let me know.

[Lardo Boffin]

I have done a bit on the parser and you can now use IT and AND.

So for example you could type

TAKE LAMP(return)

LIGHT IT(return)

Or type

TAKE LAMP AND LIGHT IT(return)

Both will work. Using AND effectively chops a sentence into separate actions and is only limited by the size of the input buffer (255 chars at the mo).
IT retrieves the last NOUN used.

You could therefore type the following in Ransom: -

TAKE LAMP AND LIGHT IT AND E AND S AND TAKE RAT AND N AND E AND E AND SEARCH TREE AND TAKE KEY AND W AND W

etc.

Note that normal actions occur in between each input chunk so in games where there are wandering monsters or random traps you may not get to the end of the input without dying.
Also if the parser detects an error or cannot pick up an object in the input etc. it will (hopefully) stop at that point and ignore the rest.

[Deleted User 9295]

In an effort to learn C I have rewritten the BASIC framework in C, because, well, why not?

Why not? A few reasons that I can think of (albeit that I am somewhat prejudiced):

1. Ease of porting to other platforms. If it was coded in 'portable' BBC BASIC it could run without modification on a BBC Micro, RISC OS, Windows, MacOS, Linux, Raspberry Pi, Android, iOS and more. Although C is itself a very portable language, once you introduce a dependency on MODE 7 it would be much more difficult to build for the majority of those platforms,
2. Ease of being modified / improved by others. I would suggest that many more people would feel confident in making changes to the code if it was in BASIC.
3. Memory efficiency. Crunched BBC BASIC is likely to use considerably less memory than the same functionality achieved in compiled C or assembler, so should increase the chance of it fitting on a machine with limited resources (I appreciate that an adventure game may be mostly data rather than code so this may not apply).

Just my twopence-worth, there may be equally valid arguments in the opposite direction.

[lurkio]

... as I move forward with this program I am getting spoilt by having 4MB of RAM... It is kind of tempting to load everything into RAM and avoid all wait times where previously it was loading from disc ... I suspect there are not too many games for the beeb written in C running on the ARM

FWIW, my take is that it's a shame you don't seem to be targeting an ordinary Beeb any more. If your code's in C and requires several MB of RAM then you've left 32K Beebs far behind. Or have I got the wrong end of the stick?

[Lardo Boffin]

In an effort to learn C I have rewritten the BASIC framework in C, because, well, why not?

Why not? A few reasons that I can think of (albeit that I am somewhat prejudiced):

1. Ease of porting to other platforms. If it was coded in 'portable' BBC BASIC it could run without modification on a BBC Micro, RISC OS, Windows, MacOS, Linux, Raspberry Pi, Android, iOS and more. Although C is itself a very portable language, once you introduce a dependency on MODE 7 it would be much more difficult to build for the majority of those platforms,
2. Ease of being modified / improved by others. I would suggest that many more people would feel confident in making changes to the code if it was in BASIC.
3. Memory efficiency. Crunched BBC BASIC is likely to use considerably less memory than the same functionality achieved in compiled C or assembler, so should increase the chance of it fitting on a machine with limited resources (I appreciate that an adventure game may be mostly data rather than code so this may not apply).

Just my twopence-worth, there may be equally valid arguments in the opposite direction.

All very valid points. The program compiles to a stand alone exe of over 40K. The same program in BASIC is about 6 or so K.

But to quote the Billie defence:-
‘Why did you write that code in C?’
‘Because we want to!’
‘Why didn’t you write it BASICally?’
‘Because we want to!’

I think she also ‘sang’ that writing code in C was ‘Like honey to the bee(b)’. But that may be pushing it.

It was for me purely an exercise in learning C and also doing something a little different on the beeb. We have all these co-procs and I wanted to do something in one of them. So when I saw a C compiler on the ARM that was it.

BBC Basic is a great language and I pretty much owe my career to it - a hearty thanks to all at Acorn and the BBC who were involved. The built in assembler is genius - I doubt I would have ever dabbled in assembly otherwise and got to learn something about what makes computers tick.

[Lardo Boffin]

... as I move forward with this program I am getting spoilt by having 4MB of RAM... It is kind of tempting to load everything into RAM and avoid all wait times where previously it was loading from disc ... I suspect there are not too many games for the beeb written in C running on the ARM

FWIW, my take is that it's a shame you don't seem to be targeting an ordinary Beeb any more. If your code's in C and requires several MB of RAM then you've left 32K Beebs far behind. Or have I got the wrong end of the stick?

Thus far all of the code is written using C that is in the Beebug C manual and therefore should compile onto a normal beeb and run (assuming it has 16K of sideways RAM for the C ROM) although I have not tried it yet.

I thought it might be an interesting opportunity to be able to write larger adventures that make use of the ARM co-proc’s increased memory. Given the advent of very cheap pi co-procs I wonder if only targeting standard beebs is as necessary as it used to be?

[marcusjambler]

Its working great on my Integra B Nula Beeb with Gotek

Marcus

[lurkio]

Thus far all of the code is written using C that is in the Beebug C manual and therefore should compile onto a normal beeb and run (assuming it has 16K of sideways RAM for the C ROM) although I have not tried it yet.

Does the Beebug C ROM have to be present while the game is running? Or only during compilation?

[Lardo Boffin]

Thus far all of the code is written using C that is in the Beebug C manual and therefore should compile onto a normal beeb and run (assuming it has 16K of sideways RAM for the C ROM) although I have not tried it yet.

Does the Beebug C ROM have to be present while the game is running? Or only during compilation?

There is a run-time compiler for this but otherwise the ROM has to be present. I suspect the runtime would take up a fair chunk of RAM (I think it starts at around 5K) so added to the game code would probably mean a 6502 co-proc.
Otherwise 16k of sideways RAM is required.

I suspect the C version of this will probably prove to be a dead end but a) I wanted to learn a bit of C and b) writing it in C is actually quite good for (hopefully, eventually) writing it in pure 6502.

[Soruk]

In an effort to learn C I have rewritten the BASIC framework in C, because, well, why not?

Why not? A few reasons that I can think of (albeit that I am somewhat prejudiced):

1. Ease of porting to other platforms. If it was coded in 'portable' BBC BASIC it could run without modification on a BBC Micro, RISC OS, Windows, MacOS, Linux, Raspberry Pi, Android, iOS and more. Although C is itself a very portable language, once you introduce a dependency on MODE 7 it would be much more difficult to build for the majority of those platforms,
2. Ease of being modified / improved by others. I would suggest that many more people would feel confident in making changes to the code if it was in BASIC.
3. Memory efficiency. Crunched BBC BASIC is likely to use considerably less memory than the same functionality achieved in compiled C or assembler, so should increase the chance of it fitting on a machine with limited resources (I appreciate that an adventure game may be mostly data rather than code so this may not apply).

Just my twopence-worth, there may be equally valid arguments in the opposite direction.

I second this - indeed, while rather late to the party, I downloaded the last SSD that had the BASIC program, extracted the files then loaded it into Matrix Brandy. With a few adjustments (Brandy doesn't like a running program to change HIMEM), and not entirely sure what line 450 is trying to do (looks like it's writing to MODE7 screen memory, but when adjusted to Brandy's MODE7 frame buffer, nothing extra appears), it runs without error.

[Lardo Boffin]

I can’t remember what line 450 does but I do remember lowering himem to get a few bytes workspace for something. Certainly nothing should be written to screen memory.

I could almost certainly remove the himem change and store the workspace as something like DIM W% 10 or similar.

[Soruk]

I can’t remember what line 450 does but I do remember lowering himem to get a few bytes workspace for something. Certainly nothing should be written to screen memory.

I could almost certainly remove the himem change and store the workspace as something like DIM W% 10 or similar.

That would be better - and certainly more portable.

[Deleted User 9295]

That would be better - and certainly more portable.

What restrictions does Brandy impose on changing HIMEM? In my BASICs you can usually raise or lower HIMEM without any major concerns; the only things to be aware of are:

1. You should normally only change HIMEM when the stack is not in use (so not inside a loop or PROC/FN etc.).
2. Attempting to raise HIMEM beyond the available memory (typically at least 250 Mbytes) will result in a 'No room' error.
3. Because my BASICs store libraries above HIMEM, raising HIMEM will cause all current libraries to be discarded.

[Soruk]

That would be better - and certainly more portable.

What restrictions does Brandy impose on changing HIMEM? In my BASICs you can usually raise or lower HIMEM without any major concerns; the only things to be aware of are:

1. You should normally only change HIMEM when the stack is not in use (so not inside a loop or PROC/FN etc.).
2. Attempting to raise HIMEM beyond the available memory (typically at least 250 Mbytes) will result in a 'No room' error.
3. Because my BASICs store libraries above HIMEM, raising HIMEM will cause all current libraries to be discarded.

Brandy won't permit HIMEM to be raised above its starting point, to expand space use NEW <size in bytes>

I was partially wrong about HIMEM not being changed in a running program - it can't be changed if the stack is in use, and on line 40 there's a REPEAT statement, putting the HIMEM change within the REPEAT loop.

[Lardo Boffin]

I think from memory himem is set to a hard coded amount rather than an offset so there is no reason it can’t be moved out of the loop.
Given a little time I’m sure it can be removed completely.

[Deleted User 9295]

I think from memory himem is set to a hard coded amount

In a cross-platform context HIMEM should always be set to a value offset from PAGE or LOMEM or something, not to a constant; typically you will have no idea what the absolute addresses might be. The 64-bit editions of my BASICs are extreme examples of this!

[Lardo Boffin]

I think from memory himem is set to a hard coded amount

In a cross-platform context HIMEM should always be set to a value offset from PAGE or LOMEM or something, not to a constant; typically you will have no idea what the absolute addresses might be. The 64-bit editions of my BASICs are extreme examples of this!

To be honest I had not even slightly thought about cross platform for this project!

I will have a look at removing the himem call completely when I get chance.

[Lardo Boffin]

That would be better - and certainly more portable.

What restrictions does Brandy impose on changing HIMEM? In my BASICs you can usually raise or lower HIMEM without any major concerns; the only things to be aware of are:

1. You should normally only change HIMEM when the stack is not in use (so not inside a loop or PROC/FN etc.).
2. Attempting to raise HIMEM beyond the available memory (typically at least 250 Mbytes) will result in a 'No room' error.
3. Because my BASICs store libraries above HIMEM, raising HIMEM will cause all current libraries to be discarded.

Brandy won't permit HIMEM to be raised above its starting point, to expand space use NEW <size in bytes>

I was partially wrong about HIMEM not being changed in a running program - it can't be changed if the stack is in use, and on line 40 there's a REPEAT statement, putting the HIMEM change within the REPEAT loop.

I have (finally) removed all references to HIMEM so hopefully that should help!

[lurkio]

Heh!:

[Lardo Boffin]

Heh!:

A helpful suggestion I thought.

[Lardo Boffin]

If you want genuine help then select the aware trait, go south from the briefing room and search. Enter the room you find and examine the terminal. Go back from time to time.

[Lardo Boffin]

Due to the increasing need to learn C# at work (and the fact that using the spreadsheet was clunky at best) I have decided to get rid of the spreadsheet and replace it with an XML file which contains messages, rooms and the game custom code etc. in a more manageable manner. The C# program will do the heavy lifting and merge a BBC Basic text file (containing the base game code) with the custom code and produce an output text file which can be tokenised and added to a SSD file etc.

The plan will be to get it working as-is but using the XML and then think about improvements. Adding NPCs will be a major part of that. Ideally I would like them to be able to wander around the place but interact correctly with locked doors etc. So if a door is locked then they cannot go that way but if the door gets unlocked they can.

This will be very difficult to do as is. In order to have a locked door there is currently no record in the room link table where the door is and room based code is run that checks a series of flags, e.g. IF Room=10 AND VERB=“East” AND check door flags THEN MOVE(11). If the flags are set then the game moves the player to the room directly, not by looking at the link table. In order to move an NPC through an unlocked door there would need to be custom code in each room with a ‘door’ (or other factor that limits movement) that allows the NPCs through.

Another way to do this would be to have a flag for each direction in the room link table that determines whether you can go through the door etc. (1 means the door east is locked but 0 means it is opened and then the normal movement process can be followed so long as the flags are taken into account). But doing this would mean having to save the state of all the these flags in the save game along with everything else (I wonder if Twin Kingdom Valley does this hence the size of their save file?). This would make NPC movement very easy and not require any ‘per room’ code. Hidden doors would also be fun! I guess there would have to be several states for each direction, maybe:
0 - passable
1 - not passable (e.g. locked)
2 - not visible
Etc.
I’m not even going to think about hidden exits being visible to the player but not to NPCs...

Is there another easier way to handle this process?

[cmorley]

XML, I hate XML. Bloaty and difficult to hand edit. I switched over to JSON for config ages ago and never looked back Very easy to use from C# with the Newtonsoft JSON package.

You could have objects to describe the links between rooms. Then passages, doors (locked or otherwise), tunnels that warp across the map, destructable walls and anything you can think of in the future all become possible by adding another object rather than editing all rooms. Your doors/passages can then hold state independent of the rooms to hold door locked/unlocked, puzzle solved to open passage etc.