Part 23 The fall of Graftgold.

The Final Days Of Graftgold.

I watched From Bedroom To Billions a few days ago. There was a clip of me talking about the last days of Graftgold. The clip was placed out of context suggesting that it was the Console era that finished Graftgold. On the contrary we made a huge amount out of console games, both licensed conversions and original games.  What finished us began with the sale of Renegade to Warner and then Warners sale of the publishing rights of Motox, This caused a delay in receiving the royalties including royalties for the Playstation version. Graftgold just could not survive as we needed royalties from one game to pay for the next. So I sold the majority of the company.

We survived for about two years financed by the new owner Perfect who successfully placed our last product with a publisher who presumably were paying staged advances.  We used to get our wages and agreed expenses transferred to our bank account each month. One month the transfer did not arrive so I could not pat the wages.  When I contacted the parent company I was told Graftgold would no longer receive any more financial support. That made Graftgold technically insolvent unless I could secure finance from elsewhere.

I was always very open to all the staff. They unanimously said they would work for nothing to keep the company going.   I immediately explored options including finding prospective buyers. There was at least one interesting buyer but they needed to agree a sale of Perfect's shares and no agreement was reached.  Worse than that it became clear that no buyer (and that included me), would ever agree to the terms that were being asked.

So that was it, I called the staff together and told them. They still did not go.  I gave them written notice and sent them to get forms from the Job Office to claim insolvency payments.  Gradually the realisation set in that the end had come. I attended a meeting with a receiver and handed over the control of the company. Fifteen years of work building up the development systems and intellectual property, the name and goodwill of Graftgold , everything, all gone, at the stroke of a pen.

It was like a death of a close relative. I walked about the now empty offices in a daze the reality overwhelming me as alone I dismantled the office and wiped the hard drives. So many memories all boxed up to go to the highest bidder. A van came from the receiver and picked up all the furniture and hardware. The lads driving the van were delighted by a cardboard full size model of one of the spice girls, putting it pride of place near the door of the van.

Then the office seemed really empty but I now needed to redecorate and get the office on the rental market. My wife and I owned the office personally, perhaps the best business move I made. At least that was still mine. I had not paid myself or my wife for a couple of months so we were broke. We spent the next couple of weeks painting beige paint until we were sick of the colour. We managed to get a couple of tenants.

My wife and I went for an interview at the Job Centre. They said being directors we had to claim insolvency from the Receiver. He said we should claim from the Job Centre. We didn't get a penny from either despite all the hundreds of thousands of tax and NI we had paid as a company over the years.  My wife managed to find a local company that needed a payroll and accounts person. That was her role in Graftgold as well as Personnel including making of birthday cakes and running the Graftgold sweet and drinks shop. (At times that made more money than royalties).

Andrew Braybrook managed to find a local firm needing programmers and got a job. He introduced me to the company getting a large introductory fee. Some of this I believe he used to pay some of the little guys like our cleaner and stationery supplier who Graftgold was indebted to. That's the kind of person Andrew is.

I still own the office and it still affects me going there. I see the repair mark on the front door where John Lilley kicked the door in frustration and made a hole. I remember the hot summer nights working round the clock to meet deadlines, the night we came back from a Xmas party in London and I managed to get the first Magic Pockets working on the PlayStation after many beers. Or the thrills when our games succeeded and a payment came through, the pangs in the stomach when I realised pay day was nearly on us;  in all it had been quite a roller coaster ride.

Deepest Blue.

Sound Studio.

I have a Zoom MRS ten track digital recorder which is fine for recording guitars using its internal drum kits but is limited if you want to record drums over many tracks. It also has no MIDI recording facility other than to set up drum patterns. For Deepest Blue I wanted to record some tracks with lots of spacey sounds using synths and orchestral sounds. That all meant more tracks.

My first thought was to upgrade to a 24 or 32 track recorder. I even got as far as putting a few bids on Ebay. I noticed that a couple of sellers said they were upgrading to a computer solution so decided I had better check that out. I was quite surprised how far technology had moved on. There was a bewildering array of audio software. I read lots of articles of setting up a home studio based on a computer. It seemed the main extra components I needed were:

Audio Interface.   

These have 1 or more inputs and allow you to connect a variety of input sources such as guitar or keyboard to the computer. They allow volume adjusting and monitoring of the source or recorded sound. Prices range from £50 to thousands depending on the number of inputs you want to have connected at once and the quality. They connect via USB or special interfaces such as Firewire.

Focusrite 2i4 Audio interface

DAW  (Digital Audio Workstation)

This is a software equivalent of a digital recorder. It allows recording of MIDI or audio on many tracks. It allows editing of the recordings and usually the joining of mini recordings into larger sections of music. They include a mixer that allows all the tracks to be adjusted to the correct sound level, pan and tone. Different effects can be placed in the signal path to add things like reverb,echo, compression.  They also allow for virtual instruments to be applied to MIDI tracks so the DAW runs a synthesiser to generate the audio on the fly from the recorded MIDI data.

The ability to record and manipulate MIDI made it a no brainer. This was the way to go. I spent ages reading reviews and comparisons of interfaces and DAWs.  Many interface came with a bundled DAW. The catch was this was usually a cut down version of an expensive DAW and could be seriously limiting. I suppose the idea is that you get to like it, outgrow it and have to pay a lot for the proper version.

"And the winner is .."

After lots of deliberation I decided to go for a Focus Scarlett 2i4 audio interface. The Scarlett range seemed to stand out in the reviews. The 2i4 was the cheapest model they did that included a MIDI interface. It came with both Ableton Live Lite and Pro Tools DAWs.  These were both limited in tracks and the better versions were quite expensive so I decided to look around. I tested Ardour, Reaper, FL Studio which were all impressive. Ardour and Reaper were both  much cheaper  so became the front runners. I liked both of these but was impressed by the way you could customise Reaper. There were little things on Ardour that were more difficult, such as deleting a note or changing its velocity. If you had a wheeled mouse rather than a touch pad it would be better but I wanted to be able to work on the laptop. I am very often stuck away from home with just the laptop and it is then I take the opportunity to work on Deepest Blue.  So the winner is Reaper as long as speed tests with my interface are ok.

Reaper DAW

Artificial Intelligence.

The game infrastructure is built by AI ships that find and survey space sectors, build bases, mine resources trade, help each other or fight.  The recent progress has been putting together the booting of this world. Each faction starts with a base and a load of resources and then starts building scout ships to explore. Each faction has its own view of the world that grows as things are found.

I had a base that generated a scout ship, ordered a pioneering mission which the ship picked up. This month I debugged the action routines that the ship followed.

Leaving the shipyard.  The ship had to carefully fly away from the base that built it.

Travel To base.   The ship had to fly to its destination base and dock.

Assign Mission.  The ship had to pick a suitable mission from the mission list and travel to the location.

Pioneer Mission   The ship had to systematically do a long range scan to locate things in the sector and if found investigate them.

For the Pioneer Mission I needed a way of recording how much of a sector was explored. I made a template search network with nodes in the middle of giant hexagonal areas that spanned the sector.

This was shared between each sector. Each factions view of the exploration status was recorded by a simple bit store of 32 bits. When a pioneer ship had explored a hex it just set the matching bit in the factions view of the sector. The pioneer could use the search network to work out the nearest unexplored region.   I had a bit of trouble with the ships not steering properly as if they had a few too many beers. It was the old bug of copying lines of  X processing  for Y and Z and not changing one of the X.s.

The pioneer ship had to scan a sphere by pointing in each direction. I did this by continuously looping the loop while gradually changing direction. I use a system of dividing up all the things ships can do into actions, each of which runs through several states. Actions can change to other actions or call actions. They each have there own variable space so they can be inverted, that is executed in stages over many cycles of processing.  Any action may be interrupted, for example if attacked a ship must run a combat or flee action. It then can return to its original action.   Its almost like a workflow scheduler.   I had an issue when I returned from an action I had changed to rather than called.  The actions stack rather like subroutine calls. When at the top it executes a null action. Looks like I need to rename all the sub actions to make a clear distinction between an action that can be called rather than changed to. This like the dreaded GOTO problems of early languages. I have noticed that workflow ,state systems or scripting systems often allow unstructured flow which can be inherently unprovable. I resolve to keep a diagram of the overall flow between actions to make sure it is well structured.

While getting my pioneer to work I found some duplication of constants to do with the scale of things such as size of a sector, range of radar etc. I brought all these together and rationalised them so I could tune the scale of the game from one set of variables. This is really important in a game. Its like making a set of controls to fine tune a game , you never want constants in the actual code  and its even better to group them in a central place  and derive them from each other where possible.

Programming Tip.

Abstraction.

If you want to store anything in a particular way write a wrapper to put the information on the store or retrieve it.  Then if you need to change the way the data is stored you do not have to change the rest of the program, as long as you preserve the calls.    This is a basic principal of object oriented programming that I use although if prefer to write in C rather than C++.

For example of I am storing  data about a new thing for example Faction:

I might  write  functions for:

FactionCreate       Allocate and initialise a faction.

FactionInit            Initialise a faction

FactionTerm         Deallocate a faction

FactionGet            Get a pointer to a faction from an Id.

FactionAdd           Add a faction to the store

FactionRemove   Remove a faction from a store

FactionNext        Gives the first or next faction in the store , useful to loop through factions

Where I differ from strict object oriented philosophy is in considering most structures as public structures as far as reading is concerned. This is really a speed and ease of development decision. I like to be able to examine structures from anywhere in the program without having to call a public method. As a matter of design I will rarely write to a structure except in its own routines.


An advantage of wrapping the getting of  structures of data is that it becomes much easier if you need to split processing between client and server. All you need to do is make the original Get call a call on the client to a proxy stub that does nothing but call the server, waits for the data and returns it to the caller.

Client
Call Faction Get     > send server get Faction message

Server
Receive get Faction message, calls servers FactionGet routine to get the data
Puts the data in a message and sends it back to the client.

Client
Receives get Faction reply message.
returns the data to the caller.


So the caller can transparently  access remote data. In practice in a game there are design implications due to the time delay of getting remote data. You may need to go s step further and under the hood cache data on the client. The code that maintains this is hidden to the actual caller.

                                         __________________________________