Conference Keynote

Working at Thinking about Playing Or A year in the life of a Games AI Programmer
S. L. Tomlinson, Warthog plc.

As an AI programmer working in the Games industry I have recently been asked to advise on Games courses at a local University.  It was then that I started to realise that the non-games industry AI practitioner may have a very different perspective to one working on Games projects. This paper therefore looks at some of the typical tasks a working AI programmer may be involved with. What kind of technology do we use, and what to we not use, and why ? It is primarily directed at a student audience, although others may also find it interesting.

The first thing to understand is that an AI programmer in a typical UK games company does not spend much of his/her time actually doing AI. On a typical project an AI programmer will often also be involved with core maths, collision physics, vehicle dynamics and animation systems, as well as simply getting the AI objects to think. This will be illustrated with a case study of the authors personal experience on Mace Griffin: Bounty Hunter. The situation is changing though. As the games’ buyer becomes more technologically aware and demands more immersive experiences (and therefore more complex games) programming teams are getting larger, and individuals more specialised. But for the same reason the way AI is dealt with is changing. Many projects now have a significant number of ‘designers’ who are responsible for building and balancing the game levels. Thus the AI programmer must provide an increasing level of access to his system. The boundary between what is in-game AI and what is scripted can vary enormously across the industry and between game genres. A first person shooter for example may be heavily story-lined and require a large amount of scripting. In a formula 1 racing game the AI may still be more autonomous, but needs to appear more realistic on the track.

As well as a general ‘day in the life’ component, this paper will look at a number of more detailed cases to illustrate some of the technical tricks of the trade. On earlier consoles a lot of behaviour was dealt with using “smoke and mirrors”; it may have looked clever but was actually very simple. This theme is still relevant today however, since it allows us to fit more into the still limited AI budget. This leads to questions: can we cut corners on our path-finding for example? Often the problem is not to find the best solution to a problem, but rather and adequate solution that still looks good in the game. Writing the AI to optimise execution performance is also an important tool in maximising the players experience and so will be discussed, including platform specific and non-platform specific code design tips. There will also be a general look at how games are structured and how this affects the AI programmer.

The paper will conclude by discussing sources of material and advice, with a brief look at one of the most important issues for any programmer working in the Games Industry – how to secure an endless supply of Pizza ! This will be followed by ample time for questions and discussion.