Part 16. Mapping The heavens, reviewing the design.

Graftgold Memories.

I have been reading Hints and Tips For Video Game Pioneers and it brings back a lot of nostalgic memories and I recommend it. It really captures the feel of what it was like and also a feel of what you need to be able to sustain a business in the games industry.  It was my dream to leave work and start a business so when the computer game market took off I was quick to chuck in a well paid job to write my own games. I can remember I saved up £12000 which was my annual salary. I then knew I had a years buffer if things didn't go as planned.

The game That Never Was.
I wanted to write a real time strategy fantasy  war game on the Spectrum. I wanted to do what I had done to adventure games to the strategy game. I wanted a huge playing area where you could build defences and march armies around. I started the design and drew up some test graphics. I tried several presentations but just could not get something that looked impressive and was the right scale to get lots of little men on. The Spectrum resolution meant that the soldiers just could not be tiny. I tried graphics representing a whole troop of men  which almost worked. I was going for tilted map approach which I wanted to scroll around. I started experimenting with a landscape built out of blocks which showed promise but did not work at the scale I wanted. In the end I admitted defeat and shelved the idea. It was later resurrected as Realms on the PC and 16 bit machines. The Spectrum graphics engine evolved into the landscape for Quazatron. It is important when designing to do what a machine is good at and I realised that it would not of worked on the Spectrum.

Deepest Blue Progress.

I keep thinking that one of these days I will come up with a real catchy name for the game. I fancy getting the word "Retro" in the title. There has already been a RetroThruster. I would also like a reference to 3D Space Wars and I also like the word Cosmos. This leaves me with something like Retro Cosmos Wars which just doesn't have the ring I want. I used to come up with names by joining two words or sub words together to form a new word such as Quasar and Tron. I've still got tons of coding to go so I'm sure Ill come up with something. Deepest Blue is the name of a song I wrote. Titles can be a right pain, especially when you think you have a good one and you realise it has already been used.

This month my goal was to program the AI of the actual game to drive the game world. I started doing this and realised that in order to debug this I really needed to write the player/world system interface. I had imagined a web like screen system that would present the world information to the player and give the illusion of a real world.

It was at this point I had to remind myself of my aims. I did not want the game to be a long winded detailed simulation strategy game. I wanted the game world to be able to create scenarios that would be fast and full of action. Thus the player has the best of both worlds. The main game play would be more like a first person shooter but the results of the fighting would impact on the world situation.

"A game is an illusion of reality"
In designing a game it is juts as important to decide what to leave out as to what to put in.  A game is an illusion of reality and it is up to the designer to include the things that maintain the illusion without acting as baggage to the player.

I wanted a cool way of presenting screen data so decided to tweak my game engine to allow any graphics to be printed on another surface rather than the screen surface. This allows say a page to be pre-printed as a texture then manipulated onto the real screen surface in fancy ways. It could be scaled rotated wrapped around 3d shapes distorted, bent etc. Doing something technical is also a way of putting off decisions I still want to chew over. The coding went pretty well and I had this worked into my engine with only a few coding changes. I was pleased with that, it is a sign that your basic design is sound if it can cope with an upgrade without major shuffling.

"Just for fun I added a thrust on the camera so you can drive through the starts in defiance of Einstein's speed limit. "
When I started the game I imported a star catalogue, I liked the effect of flying at impossible speeds  through the galactic star field. In the game the stars are used as a sky box, there are 120,000 of them in their correct places so I didn't want to have to draw them every cycle. So I thought I would use the original dynamic star field as a map showing were you were in the galaxy. Showing star names would show that they were real stars in the correct locations.Just for fun I added a thrust on the camera so you can drive through the starts in defiance of Einstein's speed limit. I needed to show how various stars were linked with warp paths.  Each star system has a number of interconnected sectors  again connected by warp paths. So I needed to be able to zoom in on a chosen system and show the sectors. I the decided to allow you to focus in again on any sector to see the various things in a sector.

"Space is huge"
That should have been pretty easy but it was the first time a lot of code was being used. I had  code that automatically connected near stars with warp paths and generated linked sectors. It was a 3 tiered network, 1 for the star systems, 1 for the sectors and 1 for the waypoints in a sector. I cursed myself for making it so complicated and almost combined the levels. Then I remembered why I had designed it like that. Space is huge and you just cannot use the same numbering system for the whole of space.
Floating point numbers cannot be huge and accurate so are only good within a certain range.
Having Sectors interconnected with warp paths was essential to maintain the scale but to have each scenario  with its own coordinate system. It also meant it was easy for the game to just run in detail the current sector and do a background low detail update of the other sectors. This gives the illusion they are all working in the same detail as the viewed sector. For an internet hosted game I could get different servers to host different star systems or even sectors if need be.


"This is a one man show so I have to get the computer to do as much work as I can."
The game background processing is firming up in my head, I don't want to start till I can imagine it all working. First I will write the other information screens the game needs. The game world will present the player a dynamic list of missions or opportunities to choose from. It will also provide info about alliances and trading. I am tempted to key in a periodic table and have a detailed trading game and have to stop myself.  I want the trading to be the backdrop for the conflict not to take over so only a few representative classes of resource are enough. I have to keep telling myself the game world is there to spontaneously generate dynamic scenarions rather than a fixed list that gets boring once you have got to the end. This also has the benefit of not having to type in data for loads of scenarios. This is a one man show so I have to get the computer to do as much work as I can.

Programming Tip

I am always surprised when I put a major bug in some code. It is important to remind yourself that you are human and should expect to make mistakes, that is the best way to eliminate them. I once had a nurse friend who said If they made as many mistakes as programmers all their patients would be dead. The truth is they are human too and make just as many mistakes, they just do not have a computer that shows them up so clearly. To avoid mistakes recognise you will make them. Then introduce practices to minimise the amount of errors and to find them when they occur.

Sometimes it is hard to distinguish between a design error and an implementation error. Say you come up with a new formula to calculate the trajectory of a bullet so it hits the opponent. You try it and it doesn't hit.  It could be the design ie the formula was incorrect or that you made a mistake encoding it. It is all too easy to give up on a design because it is not implanted correctly. 

For formulas or mathematical routines  I often test them in a spreadsheet to validate them before programming. You can also use the results to spot test the coding.  Spreadsheets can give you a good feel for how an equation works with different values. Simple things like deceleration so you stop at a particular point can be a lot more difficult to code than you expect especially if you want to limit deceleration of a game object to its abilities.

For more complicated algorithms such as the City growth curves in Realms we started of by programming them in BASIC and printing out tables of results. It was a chaotic algorithm involving positive and negative feedback. We needed to tune it so it responded to the various parameters such as food, population, wealth , health. When we had the right degree of stableness and variability we recoded it as assembler coding.

I always try to think of how I am going to prove that a piece of code works . Sometimes that means a bit of extra data to aid debugging. You can always add some #ifs  to remove it in the live version. If you have many items to process you very often are only interested in debugging one of them. So you need to be able to clearly identify them when looking at data dumps. You can also add a temporary
if statement to execute only on your selected object. I like to give objects names in their data structures while I am debugging, its far easier to see what you are looking at.

                                            _______________________________