How Do You Organize Your AI Source Files and Libraries?

Alex J. Champandard on February 12, 2008

One thing that’s obvious from looking into the AI source code of different game engines is that there are many ways to structure a codebase! Certainly, a sensible engine structure is a basic requirement to build a game, but anything beyond that is a matter of personal preference.

This week’s developer discussion on is about how you organize source files when you’re building AI into a game. Regardless what language you use (C++ or Java, and even Python), feel free to share your experiences by posting a comment below.

Stand-Alone Libraries

As games and their engines become bigger, a bunch of files thrown together ad-hoc are more likely to cause problems. Using libraries, or structuring the files within folders helps. Here are some of the tradeoffs:

  • A library enforces a certain layering and preserves a healthy structure to the codebase. It can help divide responsibilities among programmers if necessary, and facilitates quick automated testing.

  • On the other hand, it can be a pain to write separate AI code with many static languages like C++ or Java since the AI is very much tied to the game itself. You end up with a choice of type safety with bulky software design patterns like the visitor, or using casts everywhere…

Which do you prefer? Any horror stories to share? This raises the question about where to put the AI library if there is one, or the AI files otherwise…

Game vs. Engine

Nowadays large AAA studios seem to have separate engine and game teams. Even smaller games are sometimes organized around a reusable engine. But there are many possible places to put the artificial intelligence:

  1. Should the AI code be exclusively part of the game project? F.E.A.R.’s SDK includes pretty much the whole of the AI as part of the game code. The engine is kept separate though.

  2. Do you think the AI instead belongs partly in the underlying engine? Call of Duty 4’s engine and its technological ancestor Quake 3 keep the AI partly separate from the game DLL.

  3. A few years ago, you would take it for granted that some AI code was necessary in the game itself, beyond just engine support. But with advances in data-driven engine, is this still the case?

So, where do you personally draw the line between the engine and the game?

Join the Discussion!

You can either post a comment below by clicking here or leave a message in the forums too. Be sure to share your experiences regardless of the language you use!

Stay tuned for next week’s discussion also to win a copy of BioShock signed by the AI team, courtesy of 2K Boston who have an open position for a Senior AI Programmer.

Discussion 2 Comments

Brobst on February 12th, 2008

Ideally I think separate components for engine, animation, AI, and gameplay should be best. Animation control and AI tend to get lumped together, but I see them as very different problems. Gameplay code shouldn't care whether a character is AI or player driven, it only sees actors moving around and interacting with things. It would mean more work up front, but in the long run the gains in modularity and testing should pay off. I say should because I honestly don't have direct experience. I would also hope that a good sensory system would be enough to insulate the AI from the engine. The more defined this interface is the easier it would be to hook the AI up to a different engine, as long as the same kind of queries could be called.

Andrew on February 14th, 2008

I've mainly worked modding games which use heavily scripted AI - which is insanely useful for modders! Games with their own scripting language (eg; Neverwinter Nights) or which hook into LUA (like Dawn of War) can "outsource" the AI, just like any other data, making it modular and much more independent from the engine. Good hooks into the engine can be used by normal scripts too - I think Civilisations action code (like "do this move action for this unit") all works for campaign scripts too since it is run through the same python. Helps speed up work too; the independance affords resistances against crashing (since the scripts run in their own environment), with easier and faster debugging (no recompiling of code, since it is done either fast, or at run time, and logging can be done to the engine console or in game, very easily). Being able to keep the game running, retool the AI when the game is minimised, then opening it again to see changes when the level is restarted, or the "AI reload" command is invoked, is very useful. I see the benefits of hardcoding it, either in a DLL or core engine file - the speed increases are dramatic, like in Half Life 2, engine data can be easily accessed by the NPC's directly rather then through an interface, and classes/code layout can provide easy ways of creating multiple AI types. It can get messy though - the structure of some source in the SDK's as noted is not very standardised, with AI logic spanning multitudes of source files, includes and folders. I agree that animation, senses and whatnot could be coded up separately too (or should be). I don't see many bots with animation code directly hardcoded in it, or at least to a level where it's not abstracted even a bit, so it's not that bad in most games you can mod. Not sure about others though, no doubt it's also entirely different on handhelds where AI needs to work with limited memory, or even can just be simple because of simple mechanics.

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!