Mini-update:

It seems like I'll be able to use fairly extensive commenting now for the game which should save a lot of time especially during times when I have to be away from the program for periods.

I've got *crunch working with !Beebit and !6502em on RISC OS although not without problems. This presumably will allow limitless comments but 6502em won't properly do Mode7 for some reason (it does a kind of Mode0 with symbols for the CHR$ codes) although and !Beebit loads a new copy of the application each time it's run.

Anyway the tasks now I think are to finish the map and ability to move through it and re-familiarise with the routines commenting along the way.

One interesting I've just noticed was a transport system in part 2 (of 3) of the map I had working where a train took you to different parts of the complex which should be fun to develop.

Basic layout of pt2 attached.

Given that there's supposed to be 3 parts and the part 1 especially is quite big, would it be feasible to release a part at a time as a standalone game leading - hopefully - to a sequel? Suggestions?

For me, I don't mind, if part 1 is quite big and challenging then you'd probably have released the 2nd part before I'd comlpleted part 1 anyway !

I don't have a problem with episodic games either, but I think that each "episode" should assume that the player hasn't played the previous one.

You may also want think about things like how the inventory transfers from one part to the next. Does the player start off with carrying just a standard list of objects or will other objects that they may optionally have collected be there?

Kind regards,

Francis.

Those are good points, thanks.

It's worked OK for Sam & Max.


I'm strongly of the opinion that loading in objects is the wrong way to go. For a start, I remember reading abut the practical problems in Beeb mags of the past about ppl having difficulty loading in their expected inventory etc. Or of corrupted SAVE files.

Personally, I think separating them completely is much preferable so that you don't constantly worry about whether you missed something in Episode 1 when you're in Episode 5. That sort of trick does not make playing adventures fun. Are you listening, Douglas Adams, with that damn sandwich and the dog ???

If you must stop ppl playing later episodes without completing the earlier ones, use passwords. Possibly generating part of the password to represent the score, if you want to take that forward.

My 2p's worth,

Sam.

Agreed, it seems good on paper but ease/enjoyment of play would probably go right down.

Checking in...after a relocate, hopefully more development soon.

Andrew

Andrew, just re-reading your earlier post. I wonder whether your experiences with *CRUNCH working with !Beebit and !6502em on RISC OS might be worth writing up on the Sample Code section of the site? It sounds like you had some work to get it going and that might benefit other Risc OS users ...

Just a thought,

Sam.

Yes okay. Sam - can you paste it in? Short story: Non-JS browser and Firefox port buggy atm.


Limitless commenting in BASIC
========================

Recently picking up some work I did on a sequel to Dominion a few years ago now I realised that it'd be necessary to comment it as I refamiliarised with the structure let alone get used to programming again not being a programmer by trade.

So having heard of the crunching utilities for the Beeb as well as trying them a couple of times with RISC OS it seemed possible to make the listing as long as you liked in the RISC OS desktop (or potentially any other OS desktop) and then on runtime just have Crunch remove the REMs.

I haven't yet tested it with assembler comments although for Dominion I just *LOADed the pre-assembled code into memory before the main game loaded.

For RISC OS BBC emulators there are "scriptfiles" which provide information to the RISC OS environment that you're running a BBC program and a limited amount of instructions to emulator.

So using Toolkit+2 with Beebit (put the ROM in the ROMs directory first), the ROM is loaded followed by a series of command lines to crunch. The script is as follows and sits within the application directory:

BBC Script
Machine BBC B
LoadROM Toolkit+-2
OSCLI"EXEC CRUNCHER

The EXEC file is a BASIC file (not sure what its parameters were on the Beeb?) that's in the application directory for the new game:

REM CRUNCHER
LOAD "VICTORY"
OSCLI"CRUNCH BCLSVT:"
SAVE "VICTORY2"
CH."HMLOAD"

What's happening is simply the main game program file "Victory" is being programmed in a RISC OS text editor (I find !StrongEd far better than !Zap) thus opening up theoretically limitless programming space. However the program needs to be crunch'd using the Beeb environment so it has to be within the limits of the emulator machine that is operating Crunch.

The object is however to reduce the game to below 20K which is probably what any author of almost any game using machine code and/or graphics would have as an upper limit I would imagine. So using the BBC to crunch is fine and a RISC OS cruncher might well object to 6502 assembler.

The listing is duly saved with REM's removed and the game is started as normal with "HMLoad" that sets up integer variables, *key's, assembler *Loads and then of course loads the main game program that was just crunch'd.

I hope this is useful - any comments, improvements and suggestions welcome.

Thanks to Jonathan G.Harston for some help with this as well.

So is this any use to you Samwise?

Apologies, Andrew. Did you by any chance edit your last post to include this information? If so, that'll be why I didn't get notified of it, as I'd already read that post. Best to post again if you're adding new information - which is why it was only flagged up to me, when you added your new post last night.

I've added your information to the Sample Code Library, which you should be able to edit and update - I don't think there's any requirement for Javascript with the Mediawiki editor ...

Sam.

Great, thanks.

It's probably a bit late in the day to mention this, but the most recent version of ElectrEm has a built-in BASIC II tokeniser/detokeniser which is specifically coded to be cleanly severable and usable elsewhere. You could either adapt that to skip straight to the next line on encountering a REM and perform a process of writing in a text editor, tokenising and storing to BBC disk in tokenised format, or I guess you could take tokenised BASIC (as stored in the BBC's RAM), run it through the detokeniser, modified to not reproduce REM statements, then retokenise and then inject it straight back into the BBC.

Anyway, the code is specifically meant to be freely used by other people, and it understands the BASIC memory map so it should be trivial to incorporate into other emulators/etc. ElectrEm has an "Import BASIC..." menu item, I guess you could add that with a little preferences tickbox somewhere to say whether or not to throw away REM statements during the conversion.

Thanks Thomas, luckily the system with Toolkit seems to be working quite well. Hopefully it'll be possible to add plenty of comments within the ~31K limit of Mode7. They're needed, it's taking a long time to understand the code that was written a few years ago as it was as "compacted" as possible.

Well I've chucked my tokeniser/detokeniser in the wiki as sample code, since I figure it could be helpful to people building the toolsets for other projects. I'm glad things are working out for you! Shame you need that 31kb or I'd maybe consider trying to pressure you into an Electron port...