Andy Thomason has worked in games since the ’70s when computers were made from straw and beeswax. He currently works in Bristol, UK developing industry standard console development tools and is a Games Programming lecturer at Goldsmiths college in London.

The smell of fresh blood

What are the most irritating things about graduate coders fresh from university? The constant questions about simple programming matters or their lack of math skills or just their personal hygiene?

I guess that this will depend on where they came from and how practical the course was. A large number of computer science courses are very theoretical and don’t really prepare students for the harsh reality of bum-on-seat coding. The programming languages they teach on some courses can be irrelevant to anything but the most eclectic computer science PHD if they teach programming at all. I’ve seen CVs where the computer science course taken consists of linear algebra and calculus with a few weeks of programming in LISP tacked onto the end – no doubt highly respectable, but utterly useless for games.

My own university experience was similar as a physicist although I can now say that everything was eventually very useful, even the bits about operating nuclear reactors – well maybe not, but it makes great party conversation.

So, what are the things that game studios most want in a coder? Well it turns out that a recent survey by Aardvark Swift [2] – a U.K. Based games recruitment agency – shows that C++ and Math skills are the top two requirements. I guess this is hardly surprising, but it implies that games studios are willing to train “on-the-job” for the other basic skills like 3D geometry, Graphics APIs, Middleware, Audio and so on. This is obviously going to cost the studio, which will probably not have engineers dedicated to teaching.

My experience of “training” at games studios has been the odd one day C++ course, maybe a version control course and some management training involving building rafts and getting covered with mud in Wales, hardly a preparation for deferred rendering, GPGPU pipelines and parallax mapping.

Small wonder then that every day we get code through the developer support at my day job that has too many divides and algorithms copied from ten year old websites that have more if statements than a Rudyard Kipling poem.

Send us your students

These days, I am partly to blame as I am helping to run a MSc course at Goldsmiths in London to convert mundane programmers into games programmers.

What we are teaching is primarily coding and math. We are focusing on OpenGL, especially GLES2, shaders being essential to the process. Although we teach a little DirectX, it has become a little less relevant with the rise of mobile devices and with consoles switching to GLES variants.

In particular we find that GLUT is an excellent teaching aid, check out [1] for some simple glut examples. The students get to build a Collada-based game engine from scratch which this year we named “Mammoth” [3] after its unsubtle size – all first game engines are too big!

We have some great students who have mostly worked in web development and other industries for a few years or come from good universities in Scandinavia or elsewhere where industry connections are a high priority. We would like to see more Asian students as the subcontinent and China are destined to be the power houses of coding in the future.

What is the stuff of games?

GLUT/GL provides quite a simple system for building 2D games as well as 3D games. My main complaint with coding samples is that they are usually too complex. There is a real difference between a “sample” and a “demo”. A sample is usually quite short with little or no framework support. The ideal sample is twenty to a hundred lines long in a single file. I hate to compliment Microsoft, but their API documentation is very good with nice, neat samples for many of the calls.

I am also pleased to see that the samples that come with console SDKs have improved considerably. There is a place for demos, however, as they inspire deeper understanding once the basics have been mastered. But as documentation for APIs, they can be very tedious to pick apart.

You can build the following sample on Windows with “freeglut” or natively on Linux and Mac.

// complete OpenGL triangle example.
  #include "GL/glut.h"
  class triangle
    static void display()
      static const float vertices[] = {
        0.5f, 0.5f, -0.5f, 0.5f, 0.5f, -0.5f
      glVertexPointer(2, GL_FLOAT, 0, vertices);
      glDrawArrays(GL_TRIANGLES, 0, 3);
    static void reshape(int w, int h)
      glViewport(0, 0, w, h);
  int main(int argc, char **argv)
    glutInit(&argc, argv);
    return 0;

One of the courses we teach is “Tools and Middleware” which is a general meander through the asset pipeline and associated libraries. We can get a long way with building games using standard components such as Havok and FMOD. There is also a good selection of open-source tools such as OGRE, Bullet and Blender.

We found Collada to be a very useful teaching tool for graphics and physics as the files are relatively readable and describe many of the processes of game asset production. However, Collada is quite complex and the data it describes could be a lot simpler.

As a hard-core programmer, I have generally avoided scripting languages, but LUA proved to be very useful in prototyping games. It can be much more readable than XML for data and allows for live game tweaking by replacing functions and data. You probably wouldn’t want to use LUA for time-sensitive computation. LUA has grown on me as I used it, especially as it supports co-routines which simplify the process of building state machines for AI and gameplay. I would love to build a more formal game asset specification using LUA, rather than XML.

For all our good natured intention, it is still up to the students to learn the basic stuff of game programming, which is the math and C++. We have all had to do this, most of us informally by spending many hours hitting the keyboard. In the case of our students, the process was helped along by project work, which represents the largest proportion of student time. Other courses filled in the basics, such as Physics, Animation, Business and AI.

We did do some work with Shaders, GPGPU, SIMD intrinsics and so on, but technologies are a very fast-changing thing and we all need to keep abreast of them. Ironically, although I have written compilers for many targets, I have not had they chance to use them as games creation tools, an so this has been a bit of a voyage of discovery for me, too.

Finally, the thing that gives the course its pragmatic core is that many of the students get out to do a short internship with a games studio. This quite often leads to job offers. A substantial group of our students walked straight into jobs in the industry last year.

Make your voice heard

The games industry is a very fast moving place. There are a few places where you could all help to help us to build the perfect coder.

First, I’d like to compile a list of interview exam questions. Many studios these days insist on an exam to test the coding and maths capabilities of their new recruits. I’ve promised our students that I’d set some sample exam questions so that they can be prepared for the onslaught. The Aardvark-Swift “search for a star” competition was very useful in this respect as the initial phase consisted of sitting an exam with questions supplied by a leading game studio. Any contributions are welcome and I will share the results.

Second, we would like to get some industry feedback on the knowledge that game studios would most like to have their new recruits possess. We know about Math and C++ skills in general, but there may be things that you would have liked from a fresh recruit, but had to take time out to explain.

So let us know how you feel about games education and where we all want to take it.

Andy Thomason
a.thomason at

[4] /2011/04/01/stories-of-universities/