Article
i/2008/10/shot1

Everybody Dies, Except the Bots: An API for DEFCON

Robin Baumgarten on October 24, 2008

In this exclusive article, Robin Baumgarten introduces the new bot API for the popular nuclear war game, which will be released in a few weeks.

“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!

Screenshot of DEFCON

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.

AI War Games in Europe

Embodied AI or Game AI?

This was recently a topic in one of Alex’ Q&A sessions [1]. 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).

[1] 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.

Interface Design

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.

DEFCON AI Bots

Network Stability

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.

Debugging Tools

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!

Whoops, there goes London … so much for gratefulness!

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.

Discussion 2 Comments

Jonah on October 28th, 2008

"Let Robin know if you have last minute feedback" This sounds interesting and I'd like to take a look in more detail but unless I've missed something none of the work will be available until Nov 7. Did I miss something and there is a way to offer feedback before this is released or were you just looking for suggestions based on the content in the article? I don't think there's anything fundamentally wrong with the API interface but it's nearly impossibly to evaluate an API without trying to use it. The only concern I can think of from the description is that the API may be exposing a large number of properties which are not always valid; properties which would be elements of children of a non-existent parent in a hierarchical object model. Of course without knowing the object model I have no idea if that's a real concern. I think the article is correct that the debugging tool you provide will have a huge impact on how easily other developers can use your API to create their own bots. Personally I can live without fine grained control of the game's speed as long as "pause" and "go" are available options. I think the ability to inspect (and preferably log as well) the state of both the game and my AI is essential. I'd also like to see an option to easily save and reload the game and AI state so that I can return to a snapshot of the game and test AI response to slightly different conditions, replay some behavior, or change my AI and see how the response to a known state changes. A quick save/quick load covers probably covers most of that but I really want to be able to save AI state information as well. I look forward to seeing more.

RobinB on November 11th, 2008

Yeah, I've fallen victim to [URL="http://en.wikipedia.org/wiki/Hofstadter%27s_law"]Hofstadter's Law[/URL]. The documentation is finished and available on Introversion's page soon. I've uploaded it on [URL="http://www.doc.ic.ac.uk/~rb1006/projects:api"]my homepage[/URL] as well for now, too. The project itself should be available in the near future, as well.

If you'd like to add a comment or question on this page, simply log-in to the site. You can create an account from the sign-up page if necessary... It takes less than a minute!