Diary of a Game
Mental Procreation Part 3
Between eye operations and Trans-Atlantic jaunts to oversee the adoption of his third child, Father-To-Be, Andrew Braybrook, misses his ante-natal classes, and throws up ideas in the early hours of the morning...
Friday 13th February
Yet another "Why don't you... " from Mr Liddon, wanting a rotating starfield rather than a vector one. This could make the control mode rather more interesting, giving speed and rotation instead of X and Y speeds. Altered the starfield coding accordingly and instead of the stars rotating around the ship, they veered away from it. This looked very peculiar, like anti-gravity shields. Aha! Reverse the vectors and try again. Same thing happens. How about reversing only one vector? That's better, it doesn't even matter which one, except that the direction of rotation changes. Unfortunately the calculation isn't quite accurate, as the stars slowly spiral outwards and collect in the top left corner. More accurate calculations are required. Nevertheless it proves that ST and I still remember a bit of basic maths although I don't recall ever being taught the application of controlling moving starfields!
Monday 16th February
Increased the accuracy of the star rotation system to a 65536th of a pixel which holds things steadier, although the lack of subtlety involved in the calculation method still causes some inaccuracy. I left it running and leaving trails over lunch, and returned to a screen full of dotty circles, the stars had again crept outwards. As long as the game itself tends to discourage just sitting still and spinning then I see no problem. I suppose now that you know that you'll all try it.
To stop things moving in an oval orbit, (I'd used slightly incompatible co-ordinate systems for X and Y), I reduced the resolution of star movement vertically onto alternate pixels only. This has the beneficial side-effect that it frees 48 characters that were reserved for those star positions, and allows me to run the full quota of stars while docking. Previously the moving grid system used 32 of the star characters.
I'm also bursting to tell everyone that I've got an Amiga at last, and they're wonderful! Got it second-hand from Mr Liddon (would you buy a used computer from this man?) with an instant software collection, which is the only way to get one until the A500 comes out. I've been using the Deluxe Paint utility on it to do screen mock-ups of Morpheus. It's very useful for experimenting with graphics designs.
Tuesday 17th February
Off to hospital for a quick eye operation - normal service will be resumed as soon as I can see again!
Thursday 26th February
Back after a week of convalescing with an eye that feels as if Frank Bruno hit it, and being unable to sit in front of a TV for long, let alone a computer screen. I've been thinking about the game scenario and have nearly sorted out the gameplay - but not quite. So, I decided to design some sprites instead! For a docking-type sequence I want m suggest a giant platform at the side of the screen by only displaying some of it. This will be built of sprites to give me another movement speed and colour set. I have already designed something similar on the Amiga, so I started drawing the sprites on the sprite editor. It's quite difficult to check that they knit together so I also wrote a small BASIC program to display all the sprites together as they will be This worked fine until I needed more than eight sprites. Whilst Morpheus is capable of displaying more sprites, my sprite editor isn't - and considering the trouble CBM BASIC has to even display one sprite, I didn't hold out much hope for writing a sprite multiplexor in BASIC. I designed the sprites as best I could and then put them straight into the game. By directly accessing the sprite display positions while the game was running I could manoeuvre the blocks into their correct positions. I used 19 sprites in all for this. I didn't make too many graphical errors, although one pixel took a while to correct- it turned out to be a speck of dust on the screen.
This docking station can now be a different colour scheme from the moving grids, and will slide onto the side of the screen independently.
Friday 27th February
Gone to Peterborough to try to get a passport in a hurry - that sounds a bit suspicious, doesn't it? I've been invited to Chicago to help start the Uridium conversion to the PC, Apple, ST and Amiga. Who am I to argue? Pity though, I wanted to do the Amiga version myself but at least I'll be able to help out, and ensure that a first class mega-wonderful job is done.
The Braybrook work-station BEFORE......and AFTER installing the Opus
Scribbled further notes on the scenario whilst on the train. By just following through various arguments some theories show up as glaringly impossible, whilst new ideas are revealed which can be handled by existing theories. What I need is some way of showing two different factions of meanies. Colour is normally used but I don't think that will be possible as my sprite system is speeded up by the fact that any one sprite frame will always be the same colour. It also annoys the players with black and white TVs which I'd rather not do.
I'm also again wondering about a two player option where the players play simultaneously. This invariably eats more CPU time and complicates matters because I have to effectively design two games, for the single or dual player options. Both games must be similar and equally equally as good.
Monday 2nd March
Morpheus unfortunately has to take a back seat again as I have to prepare some disks for taking to America - assembler source files, graphics data, development versions that allows perusal of levels - the usual stuff. It would be rather embarrassing to arrive with only half the material - you can't just nip back for anything you've forgotten!
Tuesday 3rd March
Began writing a thesis on Uridium, going through it all, making notes on how it all works. Now it may look very simple lo you out there, but half the reason for that is that the program really does go out of its way to lie friendly and do whatever you want. I figure that the moment the player gets Irritated by the program not appearing totally transparent then the magic is lost. How many times have you been thumping fire to play another game when all the program will do is play a stupid jingle or show you the high score table? Never in Uridium. The game must appear real, and the moment manky programming rears its ugly head, the game is destroyed. Not many games are up to this standard. The player should never by limited by the programmer's inability.
Wednesday 4th March
Off to the American Embassy to get a Visa, apparently my Barclaycard won't do nicely enough!
Thursday 5th March
Back to the thesis on Uridium. I never knew there was so much in it. I really get involved in the current game that I'm working on to the exclusion of everything I've written before, so looking back at the code is really weird, almost like it was written by someone else. It takes me ages to fathom out what it's doing in places, the control mode is really complex to get it really working smoothly. It may appear simple to some reviewers but I assure you that appearances are deceptive. I have to remember the sequence in which I developed various features to work out why it's doing some things, as I'm bound to get asked questions, and there's nothing worse than not being able to explain your own work.
Friday 6th March
Still on the thesis. I'll have to finish it over the weekend.
Monday 9th - Tuesday 17th March
Off to Chicago. I'll have to get down to some real graft to make up the time, otherwise I'll be overtaken by the unscrupulous programmers who are already cloning Morpheus.
To be continued...
If you have any idea what should go in this box, please let me know! :)