Part 28 First base.

We used to have a Christmas lunch and  came back to the office put some music on and played video games.  Sometimes we would have a lucky dip or  prizes for things like  quote of the year, I remember "all banks are bastards" won the prize one particular year.  Julie would usually bring in mince pies or similar goodies to eat.  One year one of Dominic's  programmer friends came over with a huge box of jelly babies. It was a good way to end the year.

We used to close the office for a week at Christmas. Many of our staff relocated to work at  Graftgold and lived in rented rooms. They used to return home to their families for a well earned break. Andrew and I would often take home a development kit so if we got bored we could do a bit of programming. Writing games was fun and we missed it in the holidays. It was so good to have a job where you looked forward to Monday mornings or returning to work after a holiday.

One Christmas I can remember doing a lot of work on the Graftgold map editor.  Gary Foreman had worked on this before leaving to join Sega. I wanted it really flexible so if we needed to change the format of a map we could just specify the new format and the editor would read in the old format and write the new format. We could specify how many bytes each map cell had and how each bit was used. Then the map editor could be used to input data and place it on the map.   The data may be heights, no go codes, type codes meanie start points or any other data that needed to be set to the map.


Sometimes I just took a games machine or console home. I rarely had time to play games so I would find a game to play over the holiday. One year the choice was Civilisation on the PC and I can remember some marathon games played into the night. One game I was all but wiped out , all I had was one city in Ceylon, after being invaded by a faction with tanks. I managed to get their technology and gradually retake India and finished up winning the game. My son loved the game and used to play along with me and later on his own. He played a very patient game creating huge areas of farmland and building an economy before attacking anyone. He grew up playing all Graftgold's games and those we had lying around the office.  He would ask me to bring home an Amiga and later a console so he could play with it over the holiday.

Things weren't so rosy at all games houses. Programmers from one software house told us that the boss called them into a meeting and said "Christmas is cancelled". Apparently they were behind on a project and they needed everyone to stay to get back on schedule.

Deepest Blue

I am glad I have not got a schedule as progress has been slow but steady. Debugging speed has increased now I can get AI pilots to start things off for me and just switch to control them to test new bits or things that are not working properly. I can start many off them off on different missions and monitor their progress.  At first this lead to more issues than I had time to sort out but it is gradually calming down and crashes generally happen in new bits of code.

I have a very frustrating issue with the dev system but at least Microsoft are investigating it. When I stop the code to examine something and change some code it should just restart and let me debug. Instead it comes up with spurious errors telling me I have changed things I haven't touched for ages and will accept the changes showing me an old version of the code. If its a fatal error I have fixed I cannot continue and have to spend ages running the game up to the same point. This can happen over and over making progress painfully slow.

Docking HUD showing virtual runway

I have finally managed to create a deploy base mission, sign up to the mission , get my ship to dock to the base part, tow it to the deployment site, virtual dock to the deployment location and deploy the base. All of this is guided by various HUD messages and displays.  I wrote the code so that it can also deal with deploying fortresses, minefields, sentinels etc so that is a bug step forward. I now have to try upgrading a base by docking  additional parts. The AI version of the same routine is written but only partially tested. It shares as much code as possible with the player version so hopefully will not be too painful to get working. I really need to get this finished. I have had the AI factions ships supressed for ages so I can see what is going on. I can't wait to switching on and seeing how it works when their is a war going on.

I played around with the main view getting rid of the spaceships control panel. Now everything is presented as HUD displays. It needs a bit of tidying as now thongs are not in the best places but I like the look and the increased view it gives. The on screen radar for things behind the player presents a problem as these plots are shown round the edge of the screen so you get a feeling of which way to turn. That means other HUD displays need to avoid this region.

I experimented with a push scroll when the cursor is near the edge of the screen allowing the player to look left right up or down. It seems to work well but is annoying when I move the cursor off the screen to activate the debugger.

Debugging using the AI squads has changed my view of how the game will play. It is what makes the game different from other games so I will allow the player to manage squads and swap to remote ships. It allows the player to use the AI to do things they don't want to do. You can just send your remotes out to earn you credits if you don't want to fly them. Or you can be in the hot seat.

I think my plan will be to finish in 2018. This project has taken far longer than I ever imagined but that is how programming goes.

Programming Tips.

As I have been mostly debugging lately I offer some more on the techniques I have used to find out where things are going wrong.

Find All references:
I find this tool very useful. I lists all the places in a program or module that contain a specific but of text. If you are clever in naming things you can find every place where say a certain class/structure member has been referred to. If I was using strict object oriented programming with get and put methods for each member the I would only have to look in the owning classes module. I find this slow for gaming so allow direct access to structure members but do keep any substantial processing of a structure strictly in its own module.

The trick is to consider all the lines referring to a member or variable as a little program on their own that should be consistent and meaningful. You can focus on that part of the processing  with a program wide perspective. It is easy to change meaning slightly of a member during the development  of a long project. Doing this allows to check and add notes to make sure the use is properly documented. It also finds instances of unnecessary processing.

Memory Dump.
In the old days all we had to look at was the memory dump. I still find it useful. A watch will only show a variable or structure while in scope. Displaying it as a memory dump will show the memory at all times the debugger has control. I would like it to display while the program is running, we used to do this on the Spectrum/C64. We also used to change memory on the fly, extremely useful if you have data driven routines. You cant change data coded in the source modules and continue debugging. I don't know why MS has this restriction. I would love to tune up data tables while running or at least stop/starting a debug session.
Anyway the nice thing about a memory dump is that changes are shown in red. So you can look at a structure whilst tracing and see if any routines are illegally writing to a piece of memory. This could happen if you have forgotten to wipe out a pointer to a bit of memory that has been release or if an array goes out of bounds.

Live Feedback.
I like to get as much feedback on the screen while the game is running. I wired the HUD radar so that in debug mode it can display the name of the action an AI ship is performing. Then when something funny is happening I know where to start looking. I also use my textbox controls as debug displays. I can quickly make a custom overlay to display a few fields in real time on the screen.

Test routines.
For core routines I like to write test routines that check integrity. When the routine is running correctly I switch them off but keep them in the code. If I suspect a problem I switch them on to eliminate the possibility of a core problem. Sometimes its a question of elimination.

Error Logs.
One of the first systems I got working was an error log. I vet all the data I read into the game and print out any errors or warnings with the item name and line number of the input files. I can switch om timing messages and log warning debug messages. If I have trouble with a bit of code I can easily add messages to print out data etc so I can see what is happening. This is useful for things that take many frames of gameplay to take place. For example calculations to do with decelerating to a precise speed or location. I print data in a way that I can transfer it to a spreadsheet if I need to. Spreadsheets are an excellent way to check formulae are working properly.