Day in the Life: Andy Thomason, Games Technology Researcher and Writer

Andy Thomason lives in Bristol, England. Starting by writing chess and arcade games in the early ‘80s, he has worked for the Psygnosis technology group, Rage Games and Confounding Factor before his current work for SN Systems, the console tools developer.

8:30 AM – I don't do early mornings by choice, but parental responsibility and a six-year old daughter, Josie, who needs to be made ready for school is the starting point for this typical working day. Her mum is a political cartoonist and often has to stand in smoky rooms with politicians and journalists till late at night.

I am up and out by 8:45 and walk a mile down to the boat yard to see how work is progressing on the houseboat that we are building on the docks in Bristol . Amongst the other projects that I am working on, this little 75 foot steel baby satisfies my desire for organizational activity, with welders, painters, carpenters, and diesel engine specialists to coordinate.

Having satisfied myself that all is well, I can walk along the waterfront to SN, where I ride the glass elevator to the top floor, where we all work.

9:30 AM – Time for a cup of tea. Sitting too long at a computer is bad for your health, and so I have developed a regular tea habit.

Making my tea, I am ambushed by Matt from the debugger team, who needs to know how to install a compiler that Sony have sent to us. Every console and dev-kit needs a debugger that can give the programmers source-level debugging. It is a fact of a programmer's life that even when you have been programming for a quarter of a century, most of your time is spent finding bugs.

10:10 AM – Work through my emails. One from Andy Howe, one of the original Tomb-Raider crew that I worked with at Confounding Factor. Andy has moved from Bristol to Vienna to work at Rockstar.

There is an email from Havok, who are helping us to optimize our PSP compiler. Running a sophisticated physics system on a hand-held console is an interesting challenge. Other emails are from Sony Computer Entertainment, my accountant, and Vicarious Visions, who have been sending us some compiler tests for the PSP.

10:30 AM – Build tools team meeting. Today we talk about a new assembler parser that will cover a broader range of processors.

The current range of consoles and hand-helds often have four or more completely different processor architectures, each requiring a different compiler and assembler. Most games programmers use inline assembler, where assembly language code is embedded in the C or C++ that makes up the game. With next-gen consoles, the problem of covering so many processors is getting even greater and so we need a fast, testable method of generating new assemblers and compilers.

11:30 AM – Begin writing a white paper on PSP code performance. Code performance is a subject that I have always been passionate about. I also read a paper by Eelco Visser, from the University Of Amsterdam, on scannerless parsers.

The game industry is a fiercely competitive world. Developers who assume that faster console hardware will give them an easier life are usually very disappointed. It is very easy for another developer to sneak in and produce something a lot slicker. The faster the code goes the more art content a game can have, which means that game architectures have to be revised every year to stay in the game. Game technologists are constantly trying out new game architectures and math techniques, and these are the subject of my current book project.

In this case the discussion is about cache-locking. Unlike PCs, consoles have various kinds of single-cycle access memory or lockable caches. Careful application of object file sections to special memory architectures can double a game's performance.

12:30 PM – Hungry, time to pop out for a sandwich. As usual, a bunch of the guys are playing Pro Evolution Soccer in the kitchen. More tea. My wife, Lou, sends me a humorous drawing. Lou is a political cartoonist who uses her art skills to relentlessly pursue politicians all over the world, most recently in South Africa.

2:40 PM – Andy Beveridge, one of the directors, returns. We talk about a product we saw in a magazine. Andy started the company back in 1988 with Martin Day, initially making the “snasm” assembler and other PC-hosted tools for games consoles such as Sega Megadrive/Genesis, the Sega CD and Nintendo's SNES.

The company has grown ever since, and now has over forty employees, but SN has kept its focus on games development tools.

3:15 PM – Talk to Phil, our chief compiler guru and Dominic who I worked with at Psygnosis and is now the team leader. More tea… we are establishing a theme here.

3:30 PM – Answer question about PSP profiling registers. A large part of my time here is spent sorting out the trickier problems that are not handled by the support crew.

Game programmers like to push the limits of the hardware. If programmers take the compiler into uncharted territory, it may eventually break. It is our goal to make sure that the outer reaches are as far away as possible. Often in the very early days of games programming, we would push the hardware until it would literally self-destruct. The first network game I wrote on a “Compustar” cp/m system took out the hard disk, and an “asteroids” game for the Cipher Systems graphics console broke the video memory.

Good game programmers check the code generated by the compiler in time-critical sections to see if the code can be re-phrased to improve the performance. An example is branch-elimination.

A naïve programmer might write:

if( x == y ) pPtr++;

Which uses a branch, and can result in multi-cycle stalls if the branch is mispredicted. Unlike this code:

pPtr += ( x == y );

Which conditionally increments the pointer instead, with no danger of a stall.

6:00 PM – Walk home, watch TV -- we keep sensible hours at work. Tired programmers make bad mistakes that cost a lot of time to fix. Josie and Lou are back from school.

7:00 PM - Continue the research work for my book on console programming.

I noticed that although there were a lot of books on games programming, very few were written by games programmers and none mention the processes required to make use of every cycle available on a games console to create great effects. Games consoles are very different from PCs and require significantly different architectures. Naïve programming techniques found in academic papers do not work well with consoles and usually need to be modified or completely redesigned.

I am currently interested in the Collada scene-graph standard as a common games interchange format. It will form a large part of the book I am researching as it is a common language for discussing games scene graphs. I also hope to have some input into the design of the format as it evolves. Tonight I am refining an XML Schema to C++ translator that will be a key component of the book's sample code.

9:00 PM – Join my wife in the living room and sit and watch TV.

More reading. This time for the Maths MSc that I am taking with the Open University. Learning Maths from books alone is time consuming, but I hope to have finished the course in three years or so. Advanced mathematical methods, non-linear differential equations, fractal geometry and approximation theory are my current study subjects. The only problem I face is my complete inability to do handwriting; I am far too accustomed to using computer algebra systems like Maple.

11:50 PM – Bed.

I like to read and listen to Radio Four, especially the shipping forecast and the world service news before going to sleep.

--

[Since writing this article, SN Systems has been acquired by Sony Computer Entertainment.]

If you are a game developer who would like to be featured in "Day in the Life", please send your submission or inquiries to [email protected].

_____________________________________________________