“How about a nice game of chess?”
If you’d opt for total thermonuclear war instead, too, then you surely know DEFCON. It’s a real-time strategy game by Introversion where you control a nuclear superpower in its struggle to lose the least people when the cold war becomes hot. If you’re interested in AI — and I take that for granted, given that you’re reading this — you might have been wondering how difficult it is to build your own WOPR or Skynet. Well, wonder no more, soon there will be an AI interface that allows you to build your own AI overmind and launch first strikes against the feeble bots of your foes!
For the last three months, I was in the lucky position to get paid by the British Government to write the AI API for Introversions computer game DEFCON. Now, as many of you are game developers, that might be nothing special, but for me as a PhD student, thats a welcome opportunity to have a peek into how the gaming industry works and what real code actually looks like.
In this article, I’ll describe what design choices I’ve made and what difficulties arose while working on this project.
In the Beginning…
Thanks to the increased interest of the UK Government, or at least the Technology Research Board, in the creative industries and especially games industries, Introversion Software has received a grant to collaborate with Imperial College London to create an AI API for DEFCON. The indy developers have published four games so far and are still quite a small company with only 9 or so employees, which made it easy for me to understand what was going on and get hold of the right people when I had a problem during this project. Now, as I don’t want to let this become one big advertising article, I’ll focus on my work instead.
The money provided by the TSB for a “creative industries feasibility study” allowed me to write an Interface for DEFCON. It is not one of those epic build-up and resource management games, but instead, you have a small fixed army from the beginning that battles it out in a thermonuclear war.
Unfortunately, my education didn’t involve a proper C++ course (universities really like Java and such nasty little things as Prolog), so my only protection was a C++ book when i dived into the source code. Most of the time, that is no problem, but when it comes exotic constructs such as functionoids, variadic functions and template classes, I had to spend a day or two looking hard at any help my book and google spilled out for me. However, the code of the game is really well written and structured, so I found my way around without too much difficulties.
Having never written an API before, this project was quite an adventure. Careful planning with a month without writing a single line of code helped me a lot in figuring out what to do. I found the following topics most important and/or challenging.
Embodied AI or Game AI?
This was recently a topic in one of Alex’ Q&A sessions . Usually the difference manifests in the goal of the software: Do I want a realistic AI or a fun AI? At first glance, there seems to be no difference. However, it is often much more difficult to make a realistic AI fun instead of just ditching the realism and cheat the way to maximum enjoyment. A realistic AI is embodied, which means, it has the same abilities as the player: A fog of war hides opponent activities, targets and positions of opposing units are largely unknown. In the case of games (especially RTS games) it is often much easier to let the AI see everything. Soren Johnson gave an interesting talk about that at this years GDC, in essence the Civilization 4 AI has to cheat to be challenging. Writing an embodied AI that can beat good players proved just too difficult.
For researchers, however, the situation is often a bit different. They can use games as simulations for real-world scenarios. If you want to simulate a robot, and then construct it in the real world, cheating gets you nowhere. Embodied AIs are also better suited to be used in competitions, where advanced algorithms are pitted against each other.
In this project, I address both the interest of academic researchers and game developers by providing the optional choice between an embodied AI and a game AI. This means that the sensory system can be switched between embodied and full information mode. We’re in talks with the organisers of the 2009 IEEE Symposium on Computational Intelligence and Games to create a competition for DEFCON (similar to this years UT Bot competition, although the prize money wont be that high, I’m afraid).
 Editor’s note: The audio and slides for this part of the Q&A will be released shortly in the AiGameDev.com Insider’s area, join here free.
How elaborate should the interface be? In RTS games, a sensible way to store information is in a hierarchical object structure: there are general objects, and derived objects such as flying objects, naval objects, gunshots and so on. A conceptually straightforward way to get this information to the bot (linked in through a DLL) would be to just forward read-only versions of these objects to it. However, there are a couple of complications here. It requires a complex object structure that accurately mirrors the object structure in the main program, objects have to be copied, created and destroyed in the right places at the right times. And if you decide to use Java, Lua or Python in your bot, the whole object translation game starts again. So I went for the opposite: The interface is as simple and small as possible. It virtually only sends (vectors of) numbers. The slightly higher number of required get- and set-functions (one for each object attribute) is easily compensated by simplified error checking and less possibilities for memory leaks.
Another concern was the network. DEFCONs network code heavily relies on deterministic local computations, which means that it only sends commands (such as “move to this location”) over the network and everything else is calculated locally, i.e., path-finding, hit probabilities, movement and so on. Although this reduces network traffic, it is very easy to produce desynchronisations by careless programming. And what do you do when packages are delayed or lost? There has to be some mechanism that checks for time-outs and notifies the bot of any delays. This doesn’t have to be complicated, a simple state-machine did the trick for DEFCON.
This is an important part of game development, and judging by several threads in the AiGameDev.com Forum (free sign-up and introduction required) an often not sufficiently existing part. As I’m still developing the debugger, the feature list for the first release is subject to change. Full control over the game speed (including pausing and instant replays), lots of visual highlighting (drawing paths, targets, lines of sight, displaying all object attributes on a mouse over) and a console that plots out all commands and information there is, with easy tagging and filtering capabilities are desired features, and I’m implementing most of them. Let me know if you have feedback, the development process is not finished yet!
When, Where, How?
The initial release will be available from Introversions website after the 7th November 2008. This page also contains links to other resources such a paper on a learning bot for DEFCON and a mailing list for updates on the API development.
I’ll add Java, Lua and Python support via dlls that integrate the particular languages. Also, the original AI from DEFCON will be ported, which can serve as a good starting point for modifications. This bot has a really lightweight AI with a very linear finite state machine that is quite predictable and not much of a challenge for experienced gamers, so don’t expect too much from it. But that’s where you come in to show the rest of the world how a real AI should look like!
Let Robin know if you have last minute feedback, and what you think about the design of this API and post a comment below.