For some time now, educational software has been going through a pretty lean period, and only recently has it been making a noticeable recovery. It isn't hard to see why the educational market almost collapsed, either. A few years back, teachers were made very aware that the Microchip Age had dawned. It was felt increasingly important for young children to have access, as quickly as possible, to the world of computers. Meanwhile, the government was making money available to ensure that every primary school had at least one micro, and children were already, of course, experimenting with micros at home. Indeed, in many cases, the children were far more 'computerate' than their teachers.

For eighteen months, there was quite a staggering increase in the sale of home computers, and since I intended to equip my school with at least half a dozen micros as quickly as possible, I considered it important that I should have a micro at home too. There's no substitute for experience at first hand, and owning one would give me the confidence of knowing what I was talking about in conversation with the Microchip Kids at my school.

I opted for a BBC 'B' because I considered it to be head and shoulders above any other model, and even today, though the 128K model beckons appealingly, I have no reason to change my opinion.

Those first few weeks of owning a Beeb were immensely exciting. I experimented with it deep into the night and crawled into school in the mornings searching for a mug of black coffee to keep my eyelids open. There seemed so much to learn, and the massive handbook left me very enthusiastic but rather bewildered, rather like an amateur car mechanic who plans to strip the engine down when he's only just found out where the sparking plugs are!

Nevertheless, it wasn't too long before I'd made my new toy perform sums at the speed of light, write and draw in different colours, and make a few doubtful musical noises. Interestingly, practically every education authority chose the BBC too. It had such an ideal combination of features, and offered just about everything a school, or home user could want. Unlike the software that was around at the time...

The software publishers must take their fair share of blame... and many were guilty of thinking that a goldmine lay in the educational market. Many of the early "educational" programs were dire beyond belief, but after an initial and rather confused period of experimentation, children, teachers and parents saw these programs for what they were... merely bits of textbook material given a computerised gloss.

Since I'd been experimenting at home with the beginnings of program writing, I'd begun to realise how much had to be typed into the machine to get even a very small result. Just designing a little character in BASIC involved a string of numbers, and moving him up and down the screen was something else again. Being a raw beginner, it took me a whole week to write a little sequence that actually moved my 'creature' across the screen and blew him up if he encountered a land mine. And even then I hadn't added any sound effects...

I also bought a large number of books to help me, including a few containing lots of 'educational program' listings. I spent three evenings typing in a program that sounded fascinating... grapple with the giant squid as he tries to lure you into the ocean if you don't get your sums right! Having worn out my fingertip typing the thing in, and then spent another couple of nights debugging like fury, I ran the program for my daughter. She thought it was rotten. So did the kids at school. The squid looked and moved like a retarded cabbage, and, to be quite honest, I thought it was rotten too.

To a great extent, the computer programmer is in the same position as an animated film maker. Enormous amounts of effort go into producing a relatively small amount of movement on screen, but in the final analysis it's not enough for the creator to say: "You've *got* to enjoy it, look at all the effort I put into making it!" It either works, or it doesn't.

Fortunately, things are now much improved in the educational sector, and currently the primary age range seems to have settled on six viable and very important areas of use for the computer; word processing, simulation work, databasing, adventure programs, Logo... and a handful of programs which help children practise essential skills but are also a lot of fun to use.

My own school gradually increased its stock of computers until there was at least one for each class, and I found it fascinating to study how several groups of young children used and reacted to the programs they encountered. Indeed, it wasn't long before a number of interesting facts emerged, enabling me to generalise about what they liked to find in different program categories. Take the 'skills practise' type of program, for example.

Firstly, colours of characters and backgrounds - and screen layout in general - were important, and so was clarity of instruction. If children didn't understand what they were supposed to do relatively quickly, they lost interest and turned to something else. It wasn't essential to have instructions written on the screen; indeed, they often preferred to search out the information they needed from a booklet or pamphlet. They liked characters or happenings on screen that made them laugh, and a good selection of lively noises helped too.

Surprisingly, splendid and intricate graphics would seem to be less important to most children than adults. Provided interest can be maintained, the pictures for children in educational programs can be relatively simple. Finally, and most important, children liked variety within the program; changes of 'scene' or layout, however small, helped sustain their interest enormously.

I got over the initial 'play' period with my own Beeb at home fairly quickly. You know the sort of thing; you spend hours and hours typing in a word processor program, then find it's far too limiting, and go out and buy a Wordwise ROM - which is what you should have done in the first place! You play arcade games endlessly until three in the morning, and you get stuck into an adventure package which nearly drives you up the wall. The computer seems ideal for handling all your home accounts... until you find the interest repayments on your new car could have been worked out in the same time it took the cassette just to load the program! Which reminds you to save up for a disc drive...

At this stage, having tried out a number of shop-bought educational programs at school, I thought it might be fun to teach myself BASIC by writing a 'skills practise' kind of educational program. Too often, I'd found the commercial offerings either very academic and full for youngsters, or very limiting in scope.

Shape-matching, for example, is an important concept for very small children, yet one program I saw put four shapes in a row on the screen, had a travelling shape moving along underneath, and invited the user to press Return when the travelling shape lay directly underneath a shape which was identical. It repeated itself, ad nauseum, presumably until the player switched off in desperation or wrote to the software house and complained, especially as the tape cost eight pounds!

Originally, my intention in writing a program was to use it just in my own school. I wanted it to be very lighthearted and fun to use, but to contain lots of puzzlers and games using words and numbers. It would be necessary to make provision for teachers or parents to change the words and numbers to suit different children, and there would need to be several grades of difficulty so that mums and dads might like to have an occasional play with it too! It needed to be colourful, lively and challenging enough for top Juniors, though not hard enough to discourage the children in the Infant department!

This was a quite a brief... but on reflection, that was the easy part! I now had to think of a basic theme for the program, and this came to me after trying out a relatively short 'practise' listing in a BASIC book for young children. The game was extremely simple; a haunted house appeared on screen (actually just a rectangle with a lid!) and six room 'windows' were shown. You had to guess which room a ghost was hiding in, and if the guess was correct you were rewarded with a whoopee noise. If not... well, tough. Try again. Since the listing was fairly restricted, you never actually got to see the ghost.

Trite as the program was, it set me thinking. Why not have a haunted castle with a rather nasty resident Count who wasn't overkeen on visitors? There would be eight rooms in the castle, but Room 8 would remain locked because it concealed the object that was the source of the Baron's power. In order to get into Room 8, the child would have to earn seven golden keys by visiting the other rooms and solving word games or number puzzles.

I sat down with a pencil and piece of paper, and played around with this idea. It seemed reasonable enough, and the first job was to design, and then write, seven 'mini' programs for the room puzzles. I sketched these out on paper first, and dealt with them carefully one at a time. Because my initial knowledge of BASIC was small, I had to keep referring to my growing stock of books to find out how to achieve particular effects, and although keeping to my original plans for the rooms tasks, I changed layouts, characters and movements as my programming slowly improved.

Looking back, I suppose each mini-program took anything up to a couple of months before I was happy with it. An experienced programmer could probably have done it in half an hour, but I gritted my teeth in determination whenever I hit a snag, and on several occasions worked through until dawn! Debugging was a nightmare. Just when I thought I'd completed a piece of programming, something else would go wrong and I'd have to re-think the whole piece. After four months, though, I thought I had the backbone of the program "in the can". The room puzzles were complete at last and were to be worked out amongst mazes, swimming pools, a haunted tower, spiders, bats, indescribable blobs, ghosts, sharks, and a rubber-necked duck called Oswald. A score sheet system was also completed so that each time a task was finished and a Golden Key earned, the occasion was announced by various happy noises and the key was drawn on the screen.

Now I had to flesh out the program a bit, since I wanted to keep to my initial plan to add as much variety as possible. In odd moments of spare time during the day, I could be seen crazily scribbling ideas down on the back of any scrap of paper to hand, or even *on* my hand if no paper was available! I was in a world of my own, my mind churning over bits of BASIC and occasionally giving me flashes of inspiration about how to make a particular effect work (it usually didn't when I tried it out in the evening!).

I soon added a "combination lock" sequence to each room; a child would be able to choose any room he liked, but couldn't enter unless the combination was cracked by adding a set of numbers correctly. I also thought that if a child had successfully completed a room task and earned a key, it might be nice if the Count offered the chance of a bonus key. I wrote a procedure with a maze, some pretty malicious skulls, and a helicopter, with the child having to find the hidden bonus key by driving the helicopter around. If he's good at working out co-ordinates, the Count actually gives him a sporting chance!

Central to the program is a large, colourful picture of the castle, from which the choices of rooms to be visited are made, and having completed this, I added another couple of items usually connected with castles - a dungeon and a moat. If the player meets up with one of the Count's ghosts, he or she is whisked off to the dungeon where there's another puzzler to solve before an escape can be made. I added the moat so that the player, represented by a little character, can be thrown into it if he fails in a task!

I also thought it might be fun if the Count introduced himself visually the first time the game was played, and had a 'chat' to the player, mentioning how thoroughly nasty he was! All the other instructions could be kept for a descriptive leaflet, in the form of a further letter from the Count.

One of the most vital aspects of creating the game was to have each stage checked and played by a 'review' group of children at my school. The selected group contained children of various ages and abilities, and they were asked to assess each section for general interest and 'playability'. Their comments were honest, straightforward, and immensely useful, and their nimble fingers soon showed up any defects in the sequences. Being the unpredictable creatures children are, they often did things I hadn't even anticipated in my programming. Further long sessions of de-bugging were virtually guaranteed after each 'review' session!

My review team also felt that the game would be a lot more exciting if there were a few dangers in the castle; after all, since the object was to collect seven keys and get into Room 8, why not create a few faithful but objectionable friends for the Count who would appear at very inconvenient times and try hard to steal a few keys back again.

The children's ideas were carefully noted, and a set of mean key stealers were brought into play. A fat green key-squashing spider, a bat that hovers around your keys, giving you seconds to solve a program before stealing one, a key-eating blue skull, a plump black multi-legged lump that shoots across to your collection of keys as fast as it can... even a few hungry piranha fish in the moat who are very keen to meet you unless you can do a few nimble calculations can be performed first.

There's no doubt that the children loved trying to outwit the creatures, and the puzzles within the game taxed their speed, spelling accuracy, calculating ability and logical thinking. I knew things were really beginning to pull together when I had to have the game running on four Beebs in the library to accommodate the demand, and my little review team put off going for their lunch until the last possible moment. Even so, they were back at the keyboard the moment they'd finished eating!

Since my programming skills had improved immeasurably, it was an ever-increasing temptation to keep adding bits to the program, and I found a little sequence (like a power failure in the castle, where the lights can only be turned back on if the player solves a problem) could be written in half a dozen lines and slipped in on a random occurrence basis. Eventually, though, I ran out of memory, probably due to my rather longwinded BASIC. I had to stop... and I realised that ten months had slipped by since I'd started the thing!

Although pleased that children seemed to enjoy the program, I felt mentally drained by the sleepless nights and the programming problems I'd wrestled with. So many very short sequences had taken up a staggering amount of time; even the drawing of the castle had been done over and over again as I'd changed the design. I'd originally started writing the program in Mode 2, using all the colours in every sequence, little realising what huge memory chunks were being absorbed. It wasn't too long before I had to switch to Mode 5 and be a little more careful with my graphics.

I'd been incredibly bad with my program structuring too. On going back to the earliest sequences I'd written, in order to try and claim back a bit of memory, I'd usually find I could write a routine in four lines instead of sixteen! I'd also made all the dreadful mistakes a beginner usually makes, like jumping out of a loop and getting in a dreadful mess when the computer found out a bit later on!

Nevertheless, all had turned out quite well, and that would have been that... except, after playing the game for the umpteenth time, one of young review team casually said: "You know Sir. You ought to sell this in a shop. I'd even buy it meself!"

Thinking about this piece of advice, there certainly seemed no harm in trying to have my game professionally published, though I wasn't optimistic since the educational sector of the computer market was fairly depressed. I chose eight publishers from the lists at the back of A&B Computing, enclosed a covering letter and instruction booklet, and waited to see what would happen.

Within a few weeks, I'd had a reply from all but two, asking to see a copy of the program. Six cassettes were duly recorded (I didn't have a disc drive at the time), parcelled up carefully, and posted off, and once again I waited to see what would happen. Of the two who didn't ask to see the program, one was a publisher who only viewed material on disc, and the other held the view that educational programs shouldn't contain sequences where things are blown up or shot at. I found this view a trifle naive.

Then came the really exciting moment when two of the publishers got in touch and said they were interested in marketing the program. I had a slight dilemma here; I simply didn't know which one to choose. However, the problem was solved a couple of days later when Mirrorsoft also rang up and expressed interest. I already had a number of Mirrorsoft programs (The Mr Men Series, Count With Oliver, etc) at school, and they were extremely popular with the children. Mirrorsoft's programs are also always attractively packaged and presented, and I was naturally very interested in their offer.

From preliminary discussion to getting a program in the shops always takes a while, as it has to be tested (most good edsoft publishers always try out their prospective material in a number of schools), carefully debugged, and sometimes changed around a little. My program was no exception, and since it contains many puzzles and games, it was decided to link it with Crack It! - a quarterly magazine for children filled from cover to cover with puzzle fun - and call the program Crack It! Towers. Mirrorsoft's resident programming genius tossed the graphics around a little, too: he must have been appalled at my early BASIC!

As I write this, the program is about to be distributed, and I was recently asked what it is that software publishers look for in deciding whether or not to publish a program. It's a difficult question to answer for prospective authors, but in a nutshell, I think the 'idea' is the essence. Whether the program is submitted in BASIC or machine code is immaterial; if it is entertaining, it can be quickly rewritten by a professional anyway.

Without doubt, Crack It! Towers isn't going to earn me a Porsche, but it should at least pay for a disc drive. And if children spend a few pleasant hours playing it - and sharpening up their learning skills in the process - I shall be more than happy.