The ghost of Didcot and teaching the computer to build spaceships.
"Building a Rolls Royce not a Mini"
Thinking about 3D Space Wars and looking at a few retro gaming sites has brought back so many memories of those early days. When I left work I knew I had a years wages saved up to draw on. However the royalties that came in every month meant I could survive without using my savings. I had not planned on taking on any staff but a friend Andrew Braybrook was very keen to be a games programmer. A mutual friend had introduced him as he had written some games to run on an IBM mainframe. He badgered me for a job saying he would work for peanuts. I was finding it a bit lonely working all on my own so worked out a deal where he worked for a core wage which was enhanced with royalties from any games he wrote. To get a bit of cash he started out rewriting a program in Basic for a double glazing company. His Dad worked there and they used a home made Basic program to produce a cutting list of all the bits for any window design. The project turned into a bit of a monster as their program was a heap of spaghetti code with no documentation. I remember having to reverse engineer the part of the code with all the maths in and overrunning the budget. Andrew greatly improved their design, when they complained of extra cost Andrew said he was building a Rolls Royce not a mini.
Andrew programmed the Dragon 32 version of 3D Space Wars. He improved the look by adding more explosions and managed to get a better frame rate than the Spectrum version with more efficient graphics routines. It was a shame it only sold in hundreds rather than tens of thousands as it was by far the best version. I adopted his way of processing the graphics for my next Spectrum game and added a few improvements. We were always trying to outdo each other like that and that pushed our games. Andrew was fun to work with. Our office was my dining room. We had room for a couple of desks side by side. The dining chairs were a bit hard so I bought a pair of swish leather directors style chairs. We still had the glass dining table in the room behind us. Our kit only cost a few hundred pounds. We had a couple of colour televisions, our computers, a printer and a couple of cheap cassette players and last but not least a pair of calculators with a hexadecimal function. They were indispensable as we were always having to type numbers in as hexadecimal. That is base 16 for the uninitiated so 255 would be written as FF. After a while we could convert small numbers to hex and back in our heads but larger numbers with up to 4 hex digits were another matter. The computers we programmed were 8 bit but had 16 bit addressing so we had to deal with hex numbers up to FFFF. I used to draw graphics on squared paper. I then converted the graphics to hex writing it along side in columns. I became very fast at this, you get used to the 16 combinations of 4 pixels after a while. Andrew wrote a little program on the Dragon to do this automatically but you had to enter the graphics in a grid. I mostly just used paper as it was quicker. I used to sketch an outline in light pencil then colour in the squares. Saving code was always a nightmare. We used to use about 5 tapes cyclically to make sure we could recover at least one version if we had a corrupt save. The C64 disk was even slower than tape. Our machines were very susceptible to power fluctuations and crashes due to program errors or wobbly connectors. I only had to tap a key too hard on the Spectrum to reset it and lose all my work.
Things that go bump in the night.
We used to like going to visit Hewson's as we came back with sample programs, posters etc. I was good to see the process of manufacturing. Once we stayed the night at a local old inn. It was very old fashioned and was very old. I had this strange experience in the night. I was lying in bed in the early morning and I thought I heard the soft click of the door lock. I could just about see a maid dressed in old fashioned dress standing by the door. Without a word she softly walked to the bed and lay beside me. I was both frightened yet felt really tranquil. I remember the softness and warmth of her skin. I eventually fell asleep in her arms. In the morning I assumed this was a dream, but yet not like a normal dream. Dreams normally have all sorts of anomalies, they skip from place to place, do not follow a realistic time line and for me anyway do not usually involve touch. Later at breakfast Andrew started to tell me he thought he felt someone was in his room in the night. I asked whether it was a maid in old fashioned dress he was really spooked. He was glad to get out the place and we certainly never went there again.
Deepest Blue Progress
Anyway back to the plot. At this stage I had the beginnings of a game. I could fly my ship around in 3D fire weapons and chase and kill enemies. I had a rudimentary collision system that worked on collision boxes. The AI ships used the same system to find ships to attach. They randomly chose a cube of space in front of them and if an enemy was there targeted it. I got the AI targeting debugged by letting the targeting routine control the player ship so I could see what was happening. For the technically minded I transformed a vector to the target to the frame of reference of the chaser. To make this fast I wrote a matrix transform that used the chasers matrix in reverse. This saved having to invert the matrix then do a transform. Once the vector was in the chasers coordinate system I could find the turn angle to the target and the pitch to the target. I added some roll if the chaser had to turn left or right as it looks more natural than a sideways turn and puts the G force downwards like in a fighter plane. I used a similar routine to control homing missiles. I wrote a data driven missile routine that controlled homing missiles, mines, bullets shells or any other projectiles. The data had things such as damage, speed, homing, proximity explosion, shrapnel, range. Then one routine could control any type of missile in the game and it would be easy to just add new types and tune up the damage.
Having quite a few test graphics in the game was getting confusing. You need to know how where each is to be able to refer to it. There are textures, models , model parts, sprites, palettes, materials. Each has to be treated slightly differently but shared many attributes. The have to be loaded on to the graphics card , loaded into the machine, disposed of and need some way of referencing them. I decided to tidy my system up by writing a graphics manager. This would make all the graphics types use the same system. To get hold of any graphic object I could just ask the graphic manager giving it a handle that was unique to that graphic. The Graphic Manager would be responsible for loading to the graphic card and restoring if necessary. It tidied up a lot of code but was a bit of a diversion from the game.
The Spaceship Part 3d Editor.
Behind each game there is a whole system of code to maintain the data and graphics. I have a graphics loaded program that can read a set of 3d models and textures and other graphics and output a file that I input to the main program. Its easy to forget all these ancillary bits you need to make a game. In the old days it was just the same, we spent a few months between games honing the tools for the next game. At Graftgold we had some excellent tools like our sound editor and map editor. We actually sold our tools to a few other software houses. A good tool saves you many hours of rote work in the long run but they take time to develop. The trick is to make them as general as possible so they can be used for game after game. The picture shows the editor I am currently constructing to enable me to rapidly build and texture spaceship parts that can then be joined together in the game. The editor has not got proper graphics for it buttons and other controls yet. That is the way I do things. I get the code working then the graphics. That did not work with publishers, they cannot see the code and always wanted visuals first. I remember taking the first cut of Avalon to Hewson. I had the wizard graphic in and the walls but that is about all. The wizard could pick up wizards, fire wizards at wizards and destroy them.
Thinking about 3D Space Wars and looking at a few retro gaming sites has brought back so many memories of those early days. When I left work I knew I had a years wages saved up to draw on. However the royalties that came in every month meant I could survive without using my savings. I had not planned on taking on any staff but a friend Andrew Braybrook was very keen to be a games programmer. A mutual friend had introduced him as he had written some games to run on an IBM mainframe. He badgered me for a job saying he would work for peanuts. I was finding it a bit lonely working all on my own so worked out a deal where he worked for a core wage which was enhanced with royalties from any games he wrote. To get a bit of cash he started out rewriting a program in Basic for a double glazing company. His Dad worked there and they used a home made Basic program to produce a cutting list of all the bits for any window design. The project turned into a bit of a monster as their program was a heap of spaghetti code with no documentation. I remember having to reverse engineer the part of the code with all the maths in and overrunning the budget. Andrew greatly improved their design, when they complained of extra cost Andrew said he was building a Rolls Royce not a mini.
"We were always trying to outdo each other "
Andrew programmed the Dragon 32 version of 3D Space Wars. He improved the look by adding more explosions and managed to get a better frame rate than the Spectrum version with more efficient graphics routines. It was a shame it only sold in hundreds rather than tens of thousands as it was by far the best version. I adopted his way of processing the graphics for my next Spectrum game and added a few improvements. We were always trying to outdo each other like that and that pushed our games. Andrew was fun to work with. Our office was my dining room. We had room for a couple of desks side by side. The dining chairs were a bit hard so I bought a pair of swish leather directors style chairs. We still had the glass dining table in the room behind us. Our kit only cost a few hundred pounds. We had a couple of colour televisions, our computers, a printer and a couple of cheap cassette players and last but not least a pair of calculators with a hexadecimal function. They were indispensable as we were always having to type numbers in as hexadecimal. That is base 16 for the uninitiated so 255 would be written as FF. After a while we could convert small numbers to hex and back in our heads but larger numbers with up to 4 hex digits were another matter. The computers we programmed were 8 bit but had 16 bit addressing so we had to deal with hex numbers up to FFFF. I used to draw graphics on squared paper. I then converted the graphics to hex writing it along side in columns. I became very fast at this, you get used to the 16 combinations of 4 pixels after a while. Andrew wrote a little program on the Dragon to do this automatically but you had to enter the graphics in a grid. I mostly just used paper as it was quicker. I used to sketch an outline in light pencil then colour in the squares. Saving code was always a nightmare. We used to use about 5 tapes cyclically to make sure we could recover at least one version if we had a corrupt save. The C64 disk was even slower than tape. Our machines were very susceptible to power fluctuations and crashes due to program errors or wobbly connectors. I only had to tap a key too hard on the Spectrum to reset it and lose all my work.
Things that go bump in the night.
We used to like going to visit Hewson's as we came back with sample programs, posters etc. I was good to see the process of manufacturing. Once we stayed the night at a local old inn. It was very old fashioned and was very old. I had this strange experience in the night. I was lying in bed in the early morning and I thought I heard the soft click of the door lock. I could just about see a maid dressed in old fashioned dress standing by the door. Without a word she softly walked to the bed and lay beside me. I was both frightened yet felt really tranquil. I remember the softness and warmth of her skin. I eventually fell asleep in her arms. In the morning I assumed this was a dream, but yet not like a normal dream. Dreams normally have all sorts of anomalies, they skip from place to place, do not follow a realistic time line and for me anyway do not usually involve touch. Later at breakfast Andrew started to tell me he thought he felt someone was in his room in the night. I asked whether it was a maid in old fashioned dress he was really spooked. He was glad to get out the place and we certainly never went there again.
Deepest Blue Progress
Anyway back to the plot. At this stage I had the beginnings of a game. I could fly my ship around in 3D fire weapons and chase and kill enemies. I had a rudimentary collision system that worked on collision boxes. The AI ships used the same system to find ships to attach. They randomly chose a cube of space in front of them and if an enemy was there targeted it. I got the AI targeting debugged by letting the targeting routine control the player ship so I could see what was happening. For the technically minded I transformed a vector to the target to the frame of reference of the chaser. To make this fast I wrote a matrix transform that used the chasers matrix in reverse. This saved having to invert the matrix then do a transform. Once the vector was in the chasers coordinate system I could find the turn angle to the target and the pitch to the target. I added some roll if the chaser had to turn left or right as it looks more natural than a sideways turn and puts the G force downwards like in a fighter plane. I used a similar routine to control homing missiles. I wrote a data driven missile routine that controlled homing missiles, mines, bullets shells or any other projectiles. The data had things such as damage, speed, homing, proximity explosion, shrapnel, range. Then one routine could control any type of missile in the game and it would be easy to just add new types and tune up the damage.
"I would teach the computer how to build spaceships"I could not make my mind up about whether to include shields. I sketched out an energy system whereby shields were depleted by damage and replenished via a capacitor which was itself recharged form the main energy source or from batteries. Then different configurations could be assembled by buying different bits. Andrew had a multi part ship in Morpheus. I thought that would be a nice touch. So the player could buy different hulls engines and add-ons to make there own ship. I would need a screen to allow the player to choose from different parts and put them together. This would be the next thing I would write. To try this out I needed graphics of different Spaceship parts that I could paste together. For the test models in the game I had downloaded any spacecraft models I could find on the internet. I thought that these 3d models would probably be made of different parts, that's how my artists used to make models. I wrote a routine to split these parts but found the models were mostly a single part. Perhaps graphics have moved on since I has artists working for me. My Spacedock routines therefore could add spaceships to spaceships. Now I needed a decent set of model parts to play with. I looked at some free tools then decided as I had such a specific need I would teach the computer how to build spaceships. First I needed to revise my graphics system.
Having quite a few test graphics in the game was getting confusing. You need to know how where each is to be able to refer to it. There are textures, models , model parts, sprites, palettes, materials. Each has to be treated slightly differently but shared many attributes. The have to be loaded on to the graphics card , loaded into the machine, disposed of and need some way of referencing them. I decided to tidy my system up by writing a graphics manager. This would make all the graphics types use the same system. To get hold of any graphic object I could just ask the graphic manager giving it a handle that was unique to that graphic. The Graphic Manager would be responsible for loading to the graphic card and restoring if necessary. It tidied up a lot of code but was a bit of a diversion from the game.
The Spaceship Part 3d Editor.
Behind each game there is a whole system of code to maintain the data and graphics. I have a graphics loaded program that can read a set of 3d models and textures and other graphics and output a file that I input to the main program. Its easy to forget all these ancillary bits you need to make a game. In the old days it was just the same, we spent a few months between games honing the tools for the next game. At Graftgold we had some excellent tools like our sound editor and map editor. We actually sold our tools to a few other software houses. A good tool saves you many hours of rote work in the long run but they take time to develop. The trick is to make them as general as possible so they can be used for game after game. The picture shows the editor I am currently constructing to enable me to rapidly build and texture spaceship parts that can then be joined together in the game. The editor has not got proper graphics for it buttons and other controls yet. That is the way I do things. I get the code working then the graphics. That did not work with publishers, they cannot see the code and always wanted visuals first. I remember taking the first cut of Avalon to Hewson. I had the wizard graphic in and the walls but that is about all. The wizard could pick up wizards, fire wizards at wizards and destroy them.
Comments
Post a Comment