Back To Work

I have not blogged for six months because I went back to my old firm Eurobase to work with Andrew Braybrook on insurance software. It was quite strange going back to a place I worked for over ten years. Some things had not changed at all but there were a lot of new faces. It was quite challenging getting up at 7 and working all day. I was so tired when I got home all I wanted to do was fall asleep. In the end I cut it down to three days a week.  Now I am retired again and can get back to games programming and playing guitars.

I was usually a pretty good judge of people. Just look at where the Graftgold staff have ended up. I started off with Andrew Braybrook. Andrew was a professional programmer just like me so we understood each other. Yet he had a unique way of seeing things that added something different to his games. When Telecomsoft agreed to fund Graftgold I made the big decision to change from 2 people to a team of 8. I knew Dominic and John from Hewson and they had a proven record. I wanted staff to cover lots of skus, that seemed to be the way to go to get games in the charts. I already knew Gary Foreman as he worked outhouse on C64 Ranarama. He did a good job so thought it sensible to bring him in house. He only lived 15 miles away so would not have to relocate. I had a letter with a demo from David O'Connor. The spectrum game was really impressive. It was a platform game with a really smooth fast scroll that showed real technical ability.  I also had a letter from Andrew Whittaker. He seemed to really know his stuff on the Z80. He impressed me at his interview with knowledge of Z80 interrupts and Spectrum techniques.  I needed an Amstrad programmer so decided to take him on as well. He was the only one that was a bad choice. Doubts arose when he had difficulty setting up the Amstrad CPC and seemed to be asking the others to for assistance all the time. I wanted to give him a fair chance so specified a sound routine for the Amstrad based on the logic of the C64 version and the specification of the AY sound chip. Most of the logic could just be ported and translated from 6502 to Z80. The instructions to send data to the chip would have to be recoded but the AY was much simpler. It was a task that anyone with a bit of Z80 should have found easy. It became obvious that he was not up to the job. In the end I had to admit I had made a big mistake. Andrew was the only one not to pass the probationary period. I cannot remember using anything that he produced and had to take the Amstrad version over myself. I am amazed that now he claims to have been a programmer on not only Flying Shark but  many of our other games.  It is simply not true,  the only games the team were programming at the time were Flying Shark while I was finishing Magnetron and Andrew Braybrook was finishing Morpheus. Andrew Whittaker may have played some of these but  did not contribute to the programming. It just shows you that you cannot believe all people say about themselves on the internet or in magazine interviews. The credit should go to the people who deserve it. Dominic Robinson  did a superb job on the Spectrum version  and John Cumming did an excellent job on the graphics.


Deepest Blue
I have managed to keep things going a little bit in between working at Eurobase and visiting aging parents. At my mother-in-law's is where Deepest Blue began. She is housebound and we have been visiting two days a week as well as being there while she is ill. I usually take my laptop and try to program while she tells me the same old things such as beware the white butterflies that come out of roses because if they come in the windows they lay eggs that turn into spiders. One day I showed her pictures on the internet of butterflies eating nectar explaining the don't come from roses they just feed on them. Then I showed her pictures of spiders laying eggs in nests that produced baby spiders. The penny dropped and she told my wife all about it. But next week  we had the same old mantra.

She is quite deaf so talking back I not required, she just keeps talking at you all day long apart from the occasional snooze. So I find for most of the time I can program just looking up now and then to acknowledge her. She has a thing about spiders. When I first got the spaceship moving around the screen he thought it was a spidery thing.

So what have I been up to in the last six months? I would like to say the AI is finished but I expect I will be developing it till the game is finished Here is a summary of the progress,


I started play testing missions leading a squad and being part of a squad. I added a squad HUD that used a similar display to the dock HUD to show the place in the formation. Squads on missions were troublesome. The squad process has to know which member can do the mission or which are just there in a support role. So a squad member can be a leader or a follower and these can be going to a mission , in or out of formation, doing the mission or supporting the mission. If the leader does a mission then someone else has to lead the support. A series of flags and counts keeps track of all this and a lot of the debugging was to find when the counts or flags were wrong. I placed assertions at all critical moments when actions changed and gradually ironed out the issues.

Ai bottleneck, these ships are all waiting to dock at the same base,

I had similar issues with squads navigating the warp paths.  Flags and counts controlled how many squad ships were in the same sector and how many in formation. That way the leader knew whether to wait or warp.

I originally had player code and AI code for each action. When I debug I let the camera follow an AI ship. Then I want all the HUD and messages as if it were a player so I can see what is going on. So it ended up being best to combine all the most important and complex  actions such as the mission control routine, the squad routine, navigating, docking etc. This meant getting rid of routines that were essentially duplicated but adding things like if camera ship then show message, if ai then steer. I have gradually been replacing more and more code to this style as it leaves one procedure for each complex action pattern to debug. It also makes it simpler when I switch a ship from AI to player and back again. The ship just continues on the path through its current action but just decided whether to do the AI bits.  I always say when you have finished writing a routine then you know how you should have written it. These we a case in point. I could not work out how to do it as combined routines until I had the finished separate ones to compare. Sometimes coding is like that you just have to prototype a solution to understand the problem.

I decided to enhance the map screen so I could see what was going on a lot easier. I added a ship count so you could see how many of each ship type were in each sector. I also added a mission route display. This showed the mission path from system to system or sector to sector or within a sector depending on the map level of focus. I added the ability to go to this display from the mission screen so you could check the route before accepting. This lead to another issue. Someone else could take the mission while you were looking at the route. So I added a locking system rather like a ticket booking system to reserve the mission while you were examining it. I also added filters to switch the various map display plots on or off, it can get very busy in a popular sector.

Programming Tips

While travelling to work I reread a book on Artificial Life that referenced a Turing Machine. When I read it six years ago I built a Turin machine in C and was amazed at how little code was required. Alan Turing showed how this simple mechanism was the equivalent of any computing machine or language. Each line is like an IF ELSE with GOTOs. I slightly modified the Turin machine instructions so all bit codes give a valid instruction. It reads and/or writes a character from a store  and can move up or down to the next storage location. From these universal coding lines you can build any program. You can build IF ELSE, LOOPS , SEQUENCES.  CALLS are a bit trickier as you have to refer to the storage.  I coded a Turin machine originally as a sandbox that always gave workable instructions so I could try evolving code. You start with several random sequences and then mate them taking half the code from one and half from the other. You then run the code and rate the results and keep the best ones and thro away the worst. You then repeat until you get code that does what you want.



 //the storage tape
static TCHAR szText[10000];
//move to the next storage location
#define RIGHT +1    
// move to the previous storage location             
#define LEFT -1
//the enhanced Turin instruction  defined as a macro
#define OP(Label,Go0,Op0,Mv0, Go1,Op1,Mv1)\
Label:\
         if (*ptr=='0')\
         {\
            *ptr =#@Op0;\
            ptr+=(Mv0);\
            goto Go0;\
         }else\
         {\
            *ptr =#@Op1;\
            ptr+=(Mv1);\
            goto Go1;\
         }


        
void DoTurinMachine ()
{
TCHAR* ptr = NULL;
TCHAR sTape[200] = "0000000000000000000000001111100";
long lHigh =0;
long lLow  =0;

 ptr = sTape+strlen(sTape)-1;
 OP (S0,  S0,0,LEFT, S1,0,LEFT);  //bypass 00 destroy  first 1
 OP (S1,  S2,1,RIGHT , S1,1,LEFT);  //bypass 111 add 1 to left
 OP (S2,  S3,0,LEFT , S4,0,LEFT);
 OP (S3,  Exit,1,LEFT ,S3,1,LEFT);
 OP (S4,  S5,1,RIGHT , S4,1,LEFT);
 OP (S5,  S2,1,RIGHT , S5,1,RIGHT);

Exit:
   return;
}

The sTape is both the input and output. The Turin machine reads the tape right to left. Each instruction is essentially an IF ELSE.It reads a digit from  the tape and does the IF when it is zero or the else when it is a one. The if/else writes a one or zero to the current location, moves the location left por right then goes to another instruction. The macro is the heart of this. If I remember correctly this coded progran adds one to a number encoded on the tape as a series of 1's.     The 00 at the start act as the marker for the start.

It is amazing that  you can code any routine in this code. In The Emperor's New Mind Roger Penrose describes in more detail how the Turin machine works and includes the code for a universal Turin Machine, that is the Turin machine that can read a tape of Turin machine instructions. I didn't bother to try that as it was two pages of binary and one typo would be fatal. It could even run itself  but that rather messes with my mind.

The interesting thing is that you can consider each Turin program as a number and list all possible programs up to any length. You can never be certain whether any program will end or loop continually. Turin showed it was impossible to write a universal program that could check whether any articular program ends or not for a particular input, you just have to wait and see.