DAY FOUR – SATURDAY
The day started at noon for me today, and I realised a drastic time plan change had to be made. I would probably spend the whole day debugging D.P.A. and the mainline routines and the adventure handler would have to wait until Sunday or Monday.
A good thinking session was in order, so I plugged my bass through my compressor, turned my amp right up to full volume and had a thoughtful two hour break!
Fully refreshed, I tackled the problem with renewed vigour and in view of the ever looming deadline, I decided to take a logical approach.
The best way to cope with this situation was to (you guessed right!) put the Joe Hubbard album on the turn-table, get a printer listing and go through it looking for the proverbial needle in a haystack.
Well, needless to say I found it (or rather, them!) and exterminated them one by one. As the saying goes, the only good bug is dead bug! I finally got D.P.A. working at 2am and it was truly astonishing… the speed left me breathless.
DAY FIVE – SUNDAY
I woke up at the crack of noon today, and I’m one of those people who is usually a bear in the mornings. Well today I was a mouse, and I was frightened to death of how much time I had before my head was to be placed on the block.
Well, it wasn’t quite that serious but trying to get a good machine language game running on a computer which you’ve never seen before in your life within the space of a week is no mean feat, and takes a lot of hard work, determination and self control.
In fact, I took care of most of my debugging today! The screen looks good, and I’ve been moving the man around, and seeing some background animation, but I still haven’t written the adventure handler!
DAY SIX – MONDAY
Well today is the last day – or is it? You will by now, fully appreciate that there are seven days in a week, assuming that you count from one.
Well, therein lies the catch, because I’m sure that you also realise that programmers (and I’m no exception) count from zero, not one – sneaky eh?
Fear not, because yes, I did have a working version of the program that can be played and completed relatively early in the evening.
My D.P.A. method works a treat and there are now no glitches in it at all, and with a man on the screen and an animated object, the speed is ridiculously fast. So fast, in fact that I have had to put many delay loops in it to slow the game down.
At last, I had written the adventure handler, and at the end of the day, I had a version of Chimera that could be played, completed and even enjoyed.
The only thing that I have leapt over is some sound and a title page, but these are trivial tasks that do need even need thought, except perhaps, in their presentation.
If I have to dedicate this game to anyone, then surely the honours must go to Joe Hubbard, who else? This is a truly knackered signing off.
CONCLUSION – TUESDAY TO THURSDAY
One can draw a few useful points from this exercise.The first point is that it is quite possible to write a very good game in a week, as I have proved.
This can be countered by the fact that no programmer worth his salt would dare attempt to design, create, implement and program a game of top quality in this short space of time, though watch out, I may try it sometime in the future.
It helps a great deal to have a good system to work on. I used the Amstrad CPC6128 system with colour monitor and the HiSoft Devpac 80 macro assembler, both products for which I can honestly say it has been a pleasure to use them.
I am now a convert to small disks, but I feel Amstrad should have chosen the more sensible (and popular) 3.5 inch format.
I also have a few words of warning to all you budding programmers out there, especially those delving into machine code.
Please pay attention to design. Think about how you would write a particular program.Think about what might cause you problems. Do comment liberally. It helps to have a good working knowledge of the machine. Always keep strict rules about entry and exit conditions in subroutines; do not rely on values that may be lying around.
Remember, write with clarity in mind. If your code is not clear, you won’t understand it when you’re trying to debug it! Optimise it for speed afterwards, and only if it is necessary. Do not become a ‘speed junkie’. It is not a prerequisite for games programming.
That’s all there is to it! Oh, one more thing. It’ll help a great deal if you can listen to a great album like ‘Nip it in the Bud’ by Joe Hubbard!
How should you approach ebugging? Simple. You just turn the machine off after getting a fresh listing (I hope you have a printer!), then go and get a beer or a coffee and look at the listing very, very carefully for half an hour. You’ll nearly always find the culprit. What if you can’t? Give up programming and take up tennis or aerobics!