Part 18 How to Design A Game.

Graftgold Memories.

Summer used to be a very busy time getting things ready for the big game shows. The office could get very hot. We used to work flexitime at Graftgold. Some of the early morning  starters used to open up all the windows to try to get the office cooled down enough for another sweltering day. I can remember it even being hot at night. Sometimes I used to work through to the early hours and it just didn't seem to cool down.  Programming can be very addictive especially if you are trying to get something to work. I had several all hot summer night sessions trying to get the PlayStation linked game working for MotoX. It was so frustrating it would work on their little test program sending one small packet of data between two machines but would freeze up as soon as I started the game. The system used interrupts so it was almost impossible to trace with the debugger. I did get it working went home in triumph but could not repeat it next morning. I knew my code must be ok if it worked once but could not see why it did not work. I logged loads of messages to prove I was doing everything the manual said.  The manual was more like trying to read a dictionary, it told you the call parameters to each routine but did not have much information on how to use several calls together. It also had the habit of saying things like "never set this bit" when it meant "this bit must always be set". So it ended up a game of trial and error with many permutations.  Sony technical support could not help and in the end the Japanese publisher Coconuts said to leave the link game out was sure it was something wrong with the Sony interrupts conflicting as it worked if I only ran the link system without any other interrupts.  As soon as I did things like poll the keypad it would just stop receiving or sending the data. There was no way to monitor  the data actually sent down the cable. That was the only time I can remember being defeated by a bug.

Deepest Blue Progress.

Running The Universe.

I had spent weeks thinking about the game and knew it was time to sort out the Artificial Intelligence running the game universe. It was pretty daunting. I just did not have time to design loads of scenarios or locations so had to get the computer to do all this programmatically.  I wanted an organic world that could grow from minimal data all on its own using the same rules as when the player is playing. The game world had to react to the players actions, that is important as then there is a point to doing things.  I wanted the Earth factions to have interesting interactions with a growing space economy. This would then be under attack from the Seiddab whenever the two major sides met.

The whole thing needed to work with a single player, linked players or net hosted games with loads of players. That flexibility puts huge demands on the design. The topology of the game universe had to be designed to suit these modes of play. That meant a space that could be divided into local sectors that could be run on different machines if need be. It meant that I had to consider what parts of the game would be run on a game server and what parts on the local client. I realised that I needed to change my player control system to send a linked machine any ship control the player had made via the interactive ship console along with any keyboard or device controls. The controls needed to be sync'd on all machines  as I wanted to duplicate processing on each machine with a ship in a sector.

Server Data
The next thing I needed was a system where the server could send game events to any connected machines to update any local copies of data owned by the server.  Local copies would be needed of data needed instantly during action gameplay. Other data such as market prices could be kept entirely on the server and accessed via a standard client/server  query and update mechanism. I had spent the last ten years designing and implementing client/server systems for insurance systems and that experience has come in very handy.

Mission Display System
I needed a system for the various factions to supply things for the player to do. I decided that factions will update a mission database which the player could access to find out what things were wanted in different sectors graded by danger and type of mission. The same mechanism could also be used to orchestrate fleet actions. Ai players and human players would both use the same data to apply for missions. Later when the human players had enough money they could post their own missions effectively becoming their own faction.

I wrote a mission query screen and a mission display screen using my standard window form system. I linked this to the sector display form so you can see what missions are available in a particular sector.

Route Finding
The Ai ships needed a way of finding their way around the network of sectors within a network of star systems. This of data can get very big exponentially as you need to consider all the permutations of start and finish points. I decided to use grid of start/finish and for each entry put in the distance and the best node to go to for the next step of the journey. By reading this at each node you can find the best route a step at a time.  Each faction only knows of locations it has found (or traded data) and some routes may be too dangerous. So each faction needed its own view of this and it needed updating when new routes are found. The whole thing needed to be worked out by the computer to save weeks of typing in data.


Sector and System Data
I had Sector and System structures in the game for ages but realised the factions needed some private data about their ships and bases within each so they could make game decisions. They needed somewhere to record if an enemy had been sighted, if resources had been found and to control there interactions within the sector. As the game progresses  SectorAi and System Ai structures are added to the Faction's data along with ship and base lists.

Faction Ai
Now I had the basic elements to model the game universe and the faction AI.  I needed a process to deal with each faction in turn over time so they continually assess the situation of their territory and construct missions to explore ,defend, attack or exploit a sector. This is what I am writing at the moment. Along with the boot code to create the primary factions. Its an exciting time, the game will be broken for a while but then will be a living world with ships going about their business and the player able to join in wherever they please.

Programming Tips:  How To Design A Game

Before I left work to become a games programmer I worked for a couple of years as a Systems Analyst/Programmer. A Systems Analyst  works out what a system needs to do and what is needed to achieve this. I was trained for business processes but the art of systems analysis is generic and can be applied to any problem. It is useful to know the basic steps of design. At first it seems back to front but that is because you need to know where you are going to decide the way to get there. The same process works designing a huge system or a small part of a game or business system.

1. What are you developing?

 Pin down the scope of what you are doing. If its big break it down into parts and follow the design process for each part. Have a clear idea of the goals of the process rather than the mechanism that comes later. In business this often consisted of recording what an existing process did and what changes were needed. With a game imagine a review summarising the gameplay and player experience. 

2. What are the outputs?

For static screens outputs can be the data the system is collecting and processing. A game as a whole tends only to have intermediary data  outputs but these need identifying and detailing down to field level. A games main outputs are audio and visual experiences for the player and these need at least categorising and listing so the following steps can be applied to each sort of data. For example you could list each special effect on the screen as an output.

3. What inputs are needed to create the outputs?

Input data for a game may be read in from data files, input by the player ,. It may even be outputs from some subsystem or pre-processor.  Any field of data in an output file has to come from somewhere. There is a mapping of input data to output data. Once this is clear the processing often just falls out.

4. What processes are needed the  create the outputs from the inputs?

A process only exists because it produces one of the outputs. That's why we look at outputs first. Some processes will be so big they need considering iteratively from stage 1 so they break down into sub processes with their own outputs and input data.