Introduction
Over the years I have worked on many programs, in a few languages, and had any number of disagreements on how and what was to be done. I think it's important to do what you believe in, and while I'll always listen to advice and suggestions, I won't necessarily follow them! It is important to get the correct result in the end.
The Italian Program
My first database program was one we got from the Italian office in about 1981. I was tasked with making sense of the program so that we could convert it to work on our OS. The program was an online screen to update engineering parts. By today's standards I guess it was fairly simple, but I hadn't met a DBMS database before. That wasn't the problem though. This COBOL program was written in Italian! The COBOL keywords were all English, but the variables and routine names were all Italian. They didn't give me an English-Italian dictionary. I recall that I was given about 6 weeks to do the work.
I could see what the program was doing: but working out which parts of the program were doing what was proving difficult. My project leader was getting rather agitated as I wasn't showing the expected progress. I explained that I was having trouble understanding the source code. The one "variable" I did understand was called UNO-BINARIO-NEGATIVO, and was a binary value of minus one, used to multiply and negate values. After about 3 weeks I had all but given up. We had a summit meeting and whilst I got a sympathetic ear, they still wanted the job done on time and they weren't going to get me an Italian translator. The logic in the program was also somewhat awkward to work with, I wasn't even sure that it was bug-free.
My solution at that point was to rewrite the whole thing. I understood what the program was doing pretty well. I knew they'd regard this as high-risk, but I could see that it was the only way. So when they asked how it was going I just said "OK". 3 weeks later I presented the program to them to show it was working. After they decided it was looking good, I let them know it was all new code. I didn't get fired, so it must have been OK.
The CICS Room
As well as working on batch programs, we also had some online systems, running on an OS called CICS, pronounced "kicks". This OS was a bit more fragile than the VM system we used to write and run our batch programs.
My team had been pulling evening shifts for about 3 weeks to get an online system written for a particular department. We had a short development time as the goal was to speed the throughput from an old invoicing system and release about a million pounds that was being held for too long. We were on the last leg and I needed to get the documentation finished. There were about 10 screens in the system and we needed some screen shots.
The CICS room had about 4 terminals and a printer. I was quite familiar with the CICS system and had administrator privileges. The time was coming up to 5pm (home time), and I had got 8 screens done. It was a case of using the system to get to the required screen and just hitting the PRINT button on the keyboard. One of the senior programmers piped up that he was going to test his program and it might crash the OS. I asked him to just give me 5 minutes to finish what I was doing as I was on a mission. He just pressed the "GO" button, and sure enough the system crashed. At that time of night we knew the operators would not be putting the system back up until the morning. I was quite cross at this point, but I let it go.
Next morning I went in there again when I was told the system was up. Wouldn't you know it the same guy was in there and I asked if he was intending to crash the system again. He said he might well do. He was still sorting out his paperwork so I went onto the admin screen for the OS and locked his terminal out. I then got into my system and started getting those last 2 screenshots. He was puzzled at first that his terminal wasn't letting him access the system, but he twigged pretty quickly what I'd done. He ordered me to enable his terminal immediately, which I refused to do. He then stormed out of the room to go and talk to my project manager. I knew I'd have the screenshots done by the time he came back. I then re-enabled his terminal so when he came back I just said "It's all yours." and walked out with my printouts. I don't know whether he did or didn't bring the system down again.
Naturally I got called into my project manager's office and was told to close the door and sit down. I explained what happened the previous evening and that morning. He had quite a stern face, but he did say: "Thanks for getting the documents done, but don't do that again, eh?" He'd probably got quite an ear-bashing, but at least he saw the funny side of it. I don't think I ever spoke another word to the senior programmer. I will carry my grudges to my grave.
It Sort of Happened Again
By 1983 the company was being re-arranged and we had to learn some more new systems that were being brought in. 4 of us got sent to another site to study the code for a couple of days. I remember eating far too much in the hotel restaurant one night.
The project manager was a very angry bloke. This stemmed from the fact that he had wanted to emigrate to Australia, and his wife didn't want to go. He decided to just take out his anger on his team, for all eternity.
There was another program that they wanted converting from one system to another. Again, I was given 6 weeks to do it. I said I could rewrite it from scratch in 4, and they didn't believe me. Get on and convert it, they said. I didn't. I did the rewrite, in time, and got shouted at. This episode rather spelled the end for my stay there.
It's important to know your own capabilities when going out on a limb like this, and if I had more reasonable trusting management then they might listen to my case, but when I encounter stubbornness and belligerence I will take a similar stance. It's a bad habit. There are worse!
On to the Games
My first 3 projects at ST Software were to convert Steve Turner's Seiddab trilogy from the Spectrum to the Dragon 32. Actually I suppose it wasn't a trilogy yet, he was putting the finishing touches to part 2 when I started on part 1. The games were written for the 16K Spectrum, and I had a 32K machine. The conversion process was done by diagram and explanation only. Steve was not using an assembler, he was writing in hexadecimal, typing it into strings in BASIC. He had what he called his HEX AUTOLOADER that read his strings and converted them from ASCII into the actual machine code. He at least had labels in there so it worked out the relative jumps for him. The upshot of this was that I had no source code to look at, and even if I did, converting assembler from one chip to another is difficult and prone to error. It's better to code cleanly on the new platform.
Converting a 16K program to a 32K platform fortunately leaves plenty of space. I added a few more graphics to add some more variety to the meanies but I didn't feel empowered to change the game much. I also didn't have a graphics editor yet, we were drawing the graphics on graph paper and converting them to hex and keying them into my assembler - at least I had one of those. That's also an error prone process when you have to get the supporting data around the graphics right as well.
The second project, Seiddab Attack, took a little longer to write. The simulated 3D for the buildings was a bit more complicated. I wrote a graphics editor in BASIC on the Dragon 32 so I could get the graphics done a bit quicker. I did it in secret because I wasn't sure Steve would approve. I added some more meanies to shoot at again..
At the end I still had some more space to play with. I decided to expand the title page a little bit with a line of scrolling text. RMC (that's Revenge of the Mutant Camels, not Rich M. Collopy), did a bit of that, as well as a myriad of demos since. It started with some rudimentary game instructions, but then I started to waffle a bit, well, quite a lot actually. I was going for some kind of record. I think I got away with that because it took a while to get through all the text, and probably no-one bothered to review it all. I had to sit through it all at least once to make sure it wrapped around properly.
After Lunattack was done on the Dragon 32 we decided I had to switch platforms, to the new up and coming Commodore 64. I had been playing C64 games for a year or so and knew what the hardware could do. Best of all, the amount of RAM went up again. I added a radar map and a couple more titles screens. I still had a load more space so I decided to have a waffle screen, very much in the style of Yak the Hairy. That takes less than 1K of RAM, so I did another one. When it was sent off to the publisher they decided they didn't approve of my waffle screens. I was just trying to apply some personality to it. I already didn't appreciate meddling, but Steve sort of agreed with them, so I hatched a plan.
What can't publishers do? Play games! I rigged up the first waffle screen to only be displayed once the player has got onto the high score table, and the second one only appears if you get the top spot. I figured they'd never got on the high score table, especially if I put some more challenging scores in to start with. Even if they did get on the table they'd still have to notice the new screen in the titles sequence.
Rainbow Islands
I'd become quite officious once we started sending frequent disk versions of games to publishers for testing. It seemed mighty important to me for the publisher to tell us which version they find a bug in, so we can then tell them which version we fixed it in. I wanted to put an internal version number at the bottom of one of the title screens. Their response was: "No-one wants to see a version number on their software". They clearly hadn't anticipated the interweb with an update every fortnight. I may have hidden that one such that you have to hold a particular key combination down at the right time to get that to display. Since I can't remember what that key combination is, I can't prove it's still there! It might not be. You'll notice there is a version on Uridium 2, of both program and data disks. Also, sometimes we made fine-tuning changes after a game was released, so we'd bump the version number up.
I did try out the old Uridium/Paradroid 90 technique for a starfield on Monster Island. I quite liked it, but switched it off. To switch it on, you have to complete the game properly, i.e. get to the end of island 7 with all 7 big gems. This switches on the starfield for Monster Island, so you then have to get back there to see it.
For the enhanced version of Rainbow Islands, that is the Akklaim PC, PlayStation and Sega Saturn release in new look mode, we got to add some extra backgrounds. Another feature I tried was the camera shake. This happened when the big boss spider bounced on the ground. Quite possibly not all skews have that enhancement, due to 'Elf and Safety. The PC version should be OK, though it's probably a 16-bit version and won't play on modern PCs. I re-iterate my request for an emulator!
We found a few mistakes in the backgrounds of Monster Island and Toy Island. There was a shadow missing in a couple of places, and a mis-matched character or two, Again, we debated whether to be true to the original or patch it up. I reasoned that if they had spotted the mistakes they'd have patched them up, so we did fix them. It's not a big thing, it doesn't affect the game in any way, but I didn't like the idea of someone spotting the mistake and thinking we'd put it there.
By the way, there's a video of the PlayStation enhanced version being played quite magnificently all the way through by someone who clearly knows what's what at:
and I thought that the wrong version got released because the final end sequence had a nasty show-stopper that we fixed at 11pm on the last day. We got some sample disks back and the bug was still in it. I guess they'd made some up and decided to dump them on us. Anyway, the final release version appears to be clean.
On the Sega Saturn version, one of the Rainbow frames is a pixel too far to one side, that still irritates me, and I don't even have a Sega Saturn. I do have the boxed disk, maybe one day we'll unwrap it.
In Conclusion
It takes a lot of determination and hard work to put a game together, whether it be a 6-week conversion or an 18-month original product. There are so many challenges along the way, whether battling with the hardware, other people's software, or your own code. You need some doggedness and stubbornness to get through some of the problems, Other times it's great to have someone like Steve Turner to help out with the tricky issues, or indeed a functional team with experts in their own fields. You need to know whom to trust, and when, and when to trust yourself. Work hard and take pride in your work.
0 Yorumlar