The very first 'game' I can remember writing (aside from a horrid space game that I'll try to forget) was intended as a class tool for school. This would have been about first year, so when I was about 11, I guess - which would put it before Press Gang, which is surprising. Anyhow, the idea I'd had (or had come from somewhere - I don't really remember) was that you could use the computer to inject interest into a lesson and provide a greater sense of reality to the lesson. The program could provide timed reports through the printer, of events which were 'happening' in real time through the lesson. Over the course of an hour's lesson reports would come in through the machine, and would be passed to groups to write stories for.
My main interest was to be able to use the computer to bring something more interesting to dull English classes (and of course to have fun writing a little program, and to try to get someone to pay attention to the fact that I could do this stuff). I'd used BASIC in the past, but because I wanted to use the computer to edit the stories as well, I would need an actual text editor. I wasn't up to writing a text editor as well, but WordWise+ was a capable editor, and had a programming language built in to it which was advanced for its time (considering that this was on a BBC, with 32K of memory which had to hold the story, the programs and the reports that were produced).
The controlling program which I wrote would sit around the main text editor which allowed the user to edit an article. In a separate buffer, the program held a text file containing the time offsets that each report should be printed and the text of the report. From the point that the program was started, the timer began and reports would be printed at their prescribed time, followed by a a bunch of line feeds which would ensure that the report was both visible, and could be torn off safely.
The program could also save or print off the article that had been edited as well, so that it could be reviewed by other people if necessary. But that was about it, really. It wasn't very complicated, and I'm sure I could knock up something similar these days quite easily - especially as I wouldn't have to worry about packing the editor and reports printer into the same program!
I created a few different scenarios, ranging from 20 minutes in length to over an hour. I learnt a few things from creating and testing them myself:
- You need a few reports early on to provide an initial seed with which to work...
- ... but you can't keep churning out reports quickly after that - a report every 2 minutes is still very fast, unless the reports are from disconnected stories.
- Having a main story through the reports is good, but it is useful to insert unrelated reports, otherwise the feeling that it is 'live' and that other things are happening is lost.
- Stories must have conclusions, even if reports are still coming in after that conclusion - a hostage situation can 'end'. but you can still provide reports after that point which have less impact.
- Particularly if reports come in too fast it becomes very easy to just watch the events unfold, rather than trying to report on them.
I demonstrated the system to my English teacher at the time, and they were interested, but not enough to take it up. That's quite understandable as the curriculum doesn't exactly have leeway for 'stuff that one of the students think might be interesting' . They mentioned that there was other software that was available that did a similar thing, and showed me it. It makes me wonder whether I'd seen some reference to the other software, or overheard someone, before the 'idea' came to me. I don't know, but it seems more likely that that was the case.
One Christmas, we did play with it as a family, and it worked reasonably well. I don't remember whether Mum and Dad enjoyed it or not, but I have a good memory of it anyhow!
It has been pointed out to me that this isn't really part of RISC OS work at all, but I want to mention it because it was the first 'game' I wrote which had was actually complete and did everything I ever wanted of it. Not only that, but it also made me feel that I could produce something that was worthwhile myself. And I still think it was pretty impressive .
Around the same time, we visited our cousins and they had a Commodore 64 - which was a little more powerful than the BBC and had a couple of fun games that we played. One was Feud, and the other was Icicle Works. I recreated Icicle Works in Repton Infinity a couple of times, but it never really worked out very well. Feud, on the other hand was a bigger challenge and I wanted to create something all myself.
In the game, you played one wizard who was out to kill his brother. To mix the spells you required, you had to collect a selection of herbs and mix them at a cauldron. In the original, the second player was computer controlled, and there were also a bunch of other villagers wandering the map as well.
One of the big differences to the Commodore 64 original is that ... well, I wasn't as good at such things. The large map and huge graphics were so far beyond my skills at the time and I had to scale back my ambitions. It seemed to use something like a 12x6 grid per screen, and scrolled between them as you moved off the edges. This made it look quite impressive, and meant that you had to memorise the map. I wasn't going to be able to do that, and in any case I wanted to make the game support two players, rather than having a computer controlled player.
I had a lot of graph paper with large designs of graphics before I scaled back and opted for 8x8 pixel graphics, using 4 colours - a mode 1 screen. This made it easier to decide how to draw the graphics as well. Each sprite on the screen could be rendered by having bitmap characters redefined to the right shape. Multicolour sprites were multiple characters which were overlaid in different colours.
Each player, for example, consisted of a body in one colour and a head, hands and feed in another colour. So the body was plotted first in one colour, and then another colour selected and the other parts plotted. The herbs, trees and houses were similarly constructed from multiple images. To keep things simple, all the graphics were plotted in a little bit of machine code that would step through the sequence needed to plot the character, calling the OS character plotting code to do the plotting. Really not a good use of low level code, but it was one of the first things I'd written.
This simple form of graphics was enough for what I needed. I had intended, originally, to replace the graphics plotting with custom routines, but never got around to doing so. In terms of speed it was quite slow, but it sufficed for the game.
Once I had the sprite plotting working - and it was pretty simple, I needed to have a way to describe the levels. Remember, this is a BBC with 32K of memory and 20K of that is taken up with the screen, and a whole bunch with the OS and disc workspace. You had to take your memory were you could find it and try to keep the waste down. The levels were a 25x25 grid, which meant that the level data alone was over half a kilobyte. This was stored in the cassette buffer workspace as it wouldn't be used when you loaded the game from disc.
The maps themselves were just text - it wasn't compressed. I don't think I'd considered compressing it at the time. But the maps could be edited in a simple text editor and were then loaded in with the level loader and checked for validity before being stored in the workspace. The positions of the player starts, and the herbs were remembered and stored at the end of the workspace so that they didn't have to be decoded by the main game.
Because the levels were just text, it meant that they could be edited by anyone, and my brothers designed some levels that we could play. This was far more interesting, because the levels I designed tended to be quite samey, and so it added a little more variety.
The original game had quite a bit of choice for spells and herbs. My version restricted this to just 4 herbs and only 10 spells. However, the spells were configurable as part of the loader. During the load process the spells would be placed in another area of workspace so that they could be used by the main game, which actually meant that if you wanted to change the balance of the game you could swap around the herbs required for the spells.
The 'clone' spell, which fired a clone of you in the direction you were facing, was a low damage projectile, but you could fire a few times before it ran out. The 'lightning' spell, which fired a lightning bolt, was a high damage spell, but you could only fire four times before you needed to mix it again. If you changed the settings in the loader program, you could have a different balance - for example, making the projectiles both require all the herbs and only produce a couple of shots would make things far more frustrating, especially if the 'heal' spell was easy to obtain.
I knew from the start that having two people hunched over a keyboard was very frustrating - because the keyboard was small and you had to sit right next to one another. Instead, I chose to use the keyboard for one of the players, and the joystick for the second player. This meant that I got to use the joystick for something fun, and it stopped some of the arguments over people getting in the way of one another's keys.
Even still, there were too many keys for the joystick alone. There were the movement controls and fire (which were fine for the joystick) but then there was the 'mix' and 'turn spell book page' buttons, which had to go on keys. I placed these on the cursors where they generally didn't get in the way. We also swapped around now and then, especially when we accused one another of getting in the way or having an unfair advantage as another player. The latter problem also spurred my brothers (and me) to design different maps so that things were more balanced.
I wanted to add sound effects, but I hadn't managed to make anything that
sounded decent using the BBC's
ENVELOPE controls. In the end I
used the Watford Electronics Speech Synthesiser to produce the sounds. It
would say the names of the herbs as they were collected, call out 'yikes!'
when someone mixed one of the offensive spells, and 'ouch' when a player was
hit. It wasn't that great, but it made things a little less silent.
My brothers and I had lots of fun playing the game in its various forms. At least, I did, and I'm pretty sure they enjoyed it, too.
Before wrote Feud (which I couldn't even spell at the time - something that still embarrasses me!) I wrote a graphics editor, which could draw the usual simple things for the time. Dots, lines, rectangles, triangles, circles, and some other fonts that I'd picked up from other programs at different sizes. I used that to design the loading screen that the game used.
Late in 2003, I converted the game to RISC OS, and released it out to the RISC OS world to have a laugh at for Christmas. It worked quite well, albeit looking very dated and pretty bad. I left out the speech bits, changed the joystick to use the RISC OS Joystick interfaces, converted the loading screen to RISC OS format (on the fly) and updated the map selector to be a bit more friendly.
I wanted to use a name and hadn't chosen 'Gerph' yet.
I wanted to make the game a little more accessible, so I created a ROMFS version of the game, which didn't need anything else - you could just run it directly from boot. It was a little cut down, and didn't have graphical map selector, but it worked quite well. Instead of the selector it had a small menu of the 3 maps it contained in mode 7.
The original map selector, not in the ROM version, showed the maps at a reduced scale so you knew what you were going to play. Once selected, the relevant map would be stored in the workspace (in the RISC OS version, it was stored in a system variable).
I was really quite pleased with Feud, but it was never going to set the world on fire. It was a great little game to play against my brothers, partly because it was something I'd created (albeit based on another game). They had great patience when it crashed whilst we were playing it, too! As an actual, complete, playable game, I ought to be pleased - it was a bit of my childhood that I enjoyed .
(Animated version (17K))
Back in the BBC days I wrote some pretty unmaintainable things, and it's just reminded me quite how far I've come since those days. The results could be quite good but the code could be terrible. 'Explode' was an example of what looked pretty reasonable (well, I think so - it's still not that bad even now, although it could do with a bit of a tart up with some real sprites and fonts).
It's the typical chain explosion type game. Every square on the board can take a number of counters, limited by the number of squares that it borders on to. So corners can take 2 counters before needing to be split, edges can take 3 counters, and center squares can take 4 counters. When a square reaches its limit, the counters on that square are passed on to the surrounding squares. They may then have reached their limit and so spread their counters to their surroundings, and so on.
Players take turns to place counters, and the game continues until one player
has filled more than 80% of the board. Being written for the BBC, the controls
were keyboard based -
/. It's not that hard to play, and the computer player was pretty
simple, but gave a reasonable game, albeit not a very challenging one.
Internally it's a mess, which is partly due to the BBC having less memory than many modern systems, and running in MODE 1 took 20K of that memory. Comments on the functions would help - that seems like an eerily familiar statement - and some improved variable names and indentation would also be useful. I think it's likely that I've forgotten a lot of how the things work when you have limited resources, but still, it was an interesting experience going back to that code.
For the sprites, it uses the
VDU 23 user defined graphics, for
a couple of the graphics - the squares, and the explosions. The italic text
was also set up to be drawn character by character on demand. It runs a
little fast on RISC OS, but only a little, because it was already too fast
for the BBC and had to be slowed down.
It kept a very simple stack of the squares which had counters to be passed on to them from explosions. Nothing too complicated, but the stack was limited to just 50 counters, at which point it would exit. It was nice about it, and didn't crash, but still it was limited. It is interesting that I chose to use a memory array both to store the playing grid state and the stack of squares still to be processed. It's more efficient to do it that way, but a lot less clear in the code.
I think the most likely reason for that was that the efficiency really was necessary - with 20KB taken for the screen mode and 6¼KB taken by the operating system and disc filing system, there wasn't a whole lot left for the BASIC code and the data itself. The BASIC source is just under 4KB, so the data space remaining is 1¾KB. Ok... well that explains why there aren't so many comments (or spaces) in the code, and why the data isn't in BASIC arrays.
It's very easy to forget what 'low memory' means when talking about those systems, compared to the things that we work on these days. According to the couple of comments at the top of the file, Explode was written in March 1992, so it's hardly surprising that the style of code and memory requirements have changed. These days, my home server system has 2GB, and the systems I use at work have 12 GB or more - that will probably look quaint in 20 years time as well.
I sent it to Acorn User, but I think that at that time it really wasn't that that great. I guess they lowered their standards when I submitted other RISC OS things!
(Animated version (56K))