Breaking change

We all make mistakes. One early mistake I made was copying (partly) the old thing in Microsoft BASIC where you didn't have to declare variables at all.

If you do this in Microsoft BASIC it will just print "0" ; the default value, as do versions prior to 0.93

It now requires you to declare variables. There are three ways to do this - an assignment statement, a LOCAL statement, and as a procedure parameter. (Well, four if you include DIM, but that's something different).

Running the games so far shows why. Most worked fine. Asteroids didn't, because the RPL code that does the movement and collision checks accessed variables that didn't exist. There were a couple of mistakes - a game that should have been a game.score , but didn't matter because it was initialised to zero. Pacman had one mistake. Everything else works ... I think :)

I might make it optional again, but I probably won't. It's like GOTO GOSUB and RETURN. They're there ; RENUM ignores them to discourage you, really it's just for type-ins. I seriously considered disable the tokeniser code for those three.

So next up ; the Sprite microlanguage, a sort of high level compiler, and inline documentation for RPL words. The high level compiler is based something I've done before, it's very simple and clean and designed round the architecture of the machine.

Game#10 : Lunar Jetman

So the completely original arcade adventure is now working except for sound effects.

I think the next thing I'll do is this sort of "Micro sprite language" ; no use for main objects, but useful for twiddly things.  When bad guys die on this game, they just vanish, and it would be good to have a little, simple , animation for that.

Game#10 : Sabre Wulf

So, after a quiet day or two, more work on the new game. This is still all in BASIC.

Ganes do look very Spectrum-like I think, mainly because of the single colour sprites. The sprites are all done in software and are part of the kernel ROM, so there's no actual reason why they have to be single colour. At present, they just are.

Game#10a :Atac Atic (no relation)

This game is not slightly based on "Sabre Wulf"

So this is coming along okay though I haven't done a huge amount on it yet. It's still all done in BASIC (the text on the right isn't a bug and I do write comments in the source but they're filtered out in cross development usually).

However, I did find a bug this morning. I have a command SPRITE 1 END which kills Sprite 1. Which didn't actually work. So the completely original non derivative game shot the spell out but didn't actually remove the spell graphic when it had finished.

So fixed that.

One of the things I've considered, which I first saw on STOS I think, was the idea of being able to attach a background program to a sprite. Simple sequences - move here, change to this graphic, fade out. I'm very tempted to implement this (will finish this game first). It wouldn't be much use here, because it wouldn't be able to bounce of the walls, but it'd be quite handy for simple things ; like in arcade games where you shoot something and it puts up a little "100" in colour which disappears, or explosions. To do those requires the use of timers/events or AFTER. Could use a syntax like SPRITE 4 RUN "xxxxx" though you'd probably need some way of stopping it, and testing status as well.

True story. I've actually visited Ultimate, when they were in Ashby de la Zouch (ACG = Ashby Computers and Graphics) and I was at Keele University (both in central England). I pulled this trick on more than on occasion ; if some game is unavailable due to demand (in the case, the BBC Micro version of "Alien 8") I managed to sort of buy it direct. I tried it with Revs at Acornsoft's HQ in Wellingborough, as well. They think you're mad, but it worked :)

Spent a whole day removing the copy protection to put it on disk. You had to , because it was XORed with the free running timer in the 6522, so you either had to do cycle perfect emulation (non starter in 1985) or add in code and add in enough dummy code so the counter looped back round back to where it would have been anyway. This worked fine, but of course introduced a slow down factor of 65,536, which meant the second or so it spent unscrambling it padded out to about 20 hours. I didn't distribute it though :)

Game # 10a ... quiz of the week.

As I got fed up just porting someone else's work, this game is under way. This weeks CoronaQuiz is "guess what it is ?" (modelled on). Nearly as hard as those phone in quizzes which charge £2 / minute when you enter.

It's not the derivativeness (real word ?) that's the problem, it's the tedium of line by line translation. If you've ever read a Jilly Cooper book (it was the only thing left) you'll have some idea.

Confession time. I've done this before. I wrote this 35 years ago and it was published in the "BBC Micro User" as a type in. I found it poking round the BBC Micro archives a few days ago.  I've never been able to draw. I still can't. I think it's why I liked coding for the RCA Studio 2 ; at 64x32 resolution you can't actually do much with graphics.

Annoyingly when ever so slightly derivative game was published they got my name wrong ; I became "Hobson" :(


Not the best thing I ever wrote for the BBC Micro. My favourite thing was a derivative of Galaxians that was a multiprocessing tutorial (or just fun). Every enemy was a process running its own script, but it was massively accessible.  Learning through play. I also wrote a hacking game (I got the idea from a Spectrum game System 15000) where my pupils had to use various systems (no internet then) to change the exam results on exam board computers to all A's. It was a simulation, of course, but probably some idiot from OFSTED would accuse me of teaching them to be criminals these days.

Game # 10 : On hold

I'm quite surprised. I actually am finding doing this rather, well, boring.

It's a bit like manually translating a foreign language using an encylopaedia. It's not particularly difficult, it won't come out that well, and in this situation I don't think it's really worth it.

So Game#10, which is basically a Port of the game, is being dropped. Not quite sure what I'm doing yet, but I might actually produce something which is a homage to it or similar ARPGs, but not actually the same game literally. Either way, it's time for a rethink.

The one upside is that as you can probably guess, this is produced randomly. And I hadn't realised quite how dreadful the LFSR based random number generator I was using is. So that's been thrown away and replaced by one I found on the net based on shift-XOR ing which seems way way better. The Random generator is actually part of the Kernel, so this is not a big deal.

Game #10 : Sword of Fargoal

Game#10 is going to be Sword of Fargoal, which is a C64 classic from 1982.

This is chosen largely because I already have reverse engineered it, so I know exactly how it works.

It's an early wander through the dungeons action RPG.

This is assuming I can find the reverse engineered version and it's not lost on a damaged CD or something like that.