Hey there! As my third year project I am supposed to do an AI engine, not a full one mind you, it just takes care of some parts of it. Anyway, the main aspect of the said engine, or module, is supposed to be that it is easy adaptable to any game... shall we say an AI mod that you can plug into various different existing games.. The problem is I have been doing some research and haven't been able to find anything related to trends in the structure of the AI in games. In order to make it easily adaptable (and by easy I mean, maybe you have a configuration file for the AI module, or you only have to create some Adapter classes between the original game and my AI module.. something in that line of thought) it would be quite usefull to know if there is some sort of trend in current AI engines, obviously I guess.. Seeing as I am not being very successfull in my research, can anyone point me somewhere where I could find any info regarding this? Or maybe you think knowing this sort of stuff about the game isn't necessary and you can point me to new approaches? Any info I could get on this matter would be much appreciated! P.S. If you think it there isn't actually an 'easy' way to plug such a module into different games, I consider that as a quite usefull input as well.. Probably better to change my thesis now than halfway through.. P.S.S. The module is supposed to introduce squad behaviour into games that don't have it, or override the existing (hoppefully mine would be better . Not sure if that insight helps at all, but might do...

I think AI is very domain-specific which is why you won't find anything non-trivial that is 'easy adaptable to any game'. And even if there was a fairly standard way of handling unit AI, there's no standard way of exposing that to the outside world for modification. So I don't think you'll find any of the trends you're looking for.

Possibly the most reasonable approach is to find a game with a good modding interface and a multiplayer or team-based mode, and code for that, while trying to make your logic as independent of that game's particular interface as possible.

Forgive my candour but: No chance!
You could easily spend a year just developing effective team AI for 1 game, never mind a system that would work across several games (even if they used the same engine the objectives/terrain/weapons/abilities would be too varied for a catch-all solution).
The very fact that you are asking this question in such vague terms is a bad sign!
Nice idea, but... Next!

Last year I spent a few weeks studying 'dynamic scripting' or AI scripts that change to reflect changing events in the game - ie if the barn catches fire the farmer's script changes from the 'tend farm' script to the 'put out fire' script.
If a soldier notices that more than half of his unit is dead his script changes from 'attack' to 'retreat' &c &c
It can be much more efficient if NPC scripts are as relevant as possible to the state of the game around them, so you can have more (or more complex) NPCs. Perhaps you could look at something along those lines?

The naysayers are probably right, but I have one constructive idea of dubious value to contribute. Hey, it's better than nothing. ;)

Many games these days seem to use behavior trees to describe what the agents do. My understanding is that they are some very limited version of scripting, but they have the great advantage that it is easy for game designers to edit them without creating messes. This makes sense: If you give them Perl, which is very powerful, they can turn the script into an unmanageable mess in about a thousand different ways. With BTs they have a much more limited way to express behavior, so they don't mess it up. Besides, BTs have graphical representations that designers might find less intimidating than traditional code.

In order to use BTs in a game you need to define actions that the agents can perform and conditions that the agents can check, which have to hook to the right place in the rest of the game. But once those things have been done, the driver that takes the BT and follows it and the BT editor are things that could be reused in many games, at least in principle.

Perhaps Alex can comment on the feasibility of something like this...

Hasn't this already been done? Not the coop part, but multigame/multiengine bot?

I seem to recall 'independent', 'bot' and 'framework' as keywords, but googling it turns up mostly IRC bots. The only game releated project I could find was omni-bot, which might be it.

Quote:

Omni-bot is an artificial intelligence(AI) controlled opponent for first person shooter games. Unlike many bots that are written for specific games, Omni-bot was designed from the beginning to exist mostly as a generic framework with which support for many different games can be made, and most of the functionality can be shared among them.

I guess it's not exactly what you were thinking about, but perhaps worth looking into?

If this were feasible, we would see more AI middleware packages that go beyond simple pathfinding and state machines. The problem with AI middleware as a concept is that you must often design your world around the middleware product and its hooks. Because game worlds, the data they hold, and the inputs they need, vary wildly from one to the next, the idea of having a unified middleware product that addresses them all is a stretch. Pathfinding, at least, has the common model of nav meshes and waypoint graphs. Behavior? Not so much...

What kind of games are you supposed to support? There's an engine called 'zillions of games' that can handle zillions (where zillions = a few hundred) of traditional abstract-ish board games such as tic-tac-toe, reversi, hnefatafl, etc.

Another plausible interpretation is that you need to write a basic agent framework (the sense/act cycle), but that the implementation of the act() method is deferred to each game. It would be plausible but not easy to provide a normalized packet of information to provide to the agent at each tick (nearby geometry/movement options, other nearby agents, game state such as health and ammo). This is where the adapter comes in - figuring out how to represent each game's world in the common format, and how to interpret the output of the act() method in that particular game.

Quote:

Original post by InnocuousFox If this were feasible, we would see more AI middleware packages that go beyond simple pathfinding and state machines. The problem with AI middleware as a concept is that you must often design your world around the middleware product and its hooks. Because game worlds, the data they hold, and the inputs they need, vary wildly from one to the next, the idea of having a unified middleware product that addresses them all is a stretch. Pathfinding, at least, has the common model of nav meshes and waypoint graphs. Behavior? Not so much...

Hmm I dont know. I do not think that it is impossible. A certain amount of ignorance is required to continue my argument but I do not consider my position indefensible.

I am certain that a similar thing as you say for behaviour was stated for graphics engine and in particular 3d graphics accelerators. But these days people all use the same format in their graphics computation, instructions and structures by convention.

While hardcoding specifics to do with a behavourial engine type thing would be unproductive I do not see why for a start, a low level algorithm and structures library and tools for said would fail. And then as is the case with game engines, focusing as necessary on different genres. I think pathfinding has tools only because it has been such a big deal in Game AI for a really long time. Before people would worry about pathfinding and were happy to hand build or script base a Finite state machine. but as more and more complex approaches from the ML community become more common I think such a middleware will become more prevalent.

Do correct any misconceptions as I am interested in learning.

Your analogy to graphics ignores an important point: AI controls and sends inputs to a lot of other game systems whereas graphics is simply an output. This is a big difference.

So certainly there are successful AI Middleware packages: Kynapse, Euphoria. Various games use them (all FPSish high-fidelity games), but as pointed out, they all had to be put in place before the game was constructed. You can't just drop them in to a finished game because of the input problem.

AI is intimately connected with game design which is extremely game specific. Dealing with the intricacies of a specific game's mechanics is work intensive and non-generalizable: shooting guns is not compatible with a game where you weild swords, hand-to-hand combat is not compatible for a sniper game, triggers in different engines are different, different engines have totally different scripting systems to control the game design and the AI, different engines have radically different animation interfaces which the AI controls.

So to "plug middleware in" to an existing game you have to hook it up to all your specific game mechanics and features. That means authoring custom behaviors and interfaces to your derived behaviors or whatever the leaf-end extensible feature of your middleware is. This isn't a hot-swappable feature. And it's something that often takes upwards of several months for your AI team to put in place. Yes, your middleware can work in various games but it'll do so with a common basic architecture that the devs have to customize towards their unique features.

Additionally, you're not going to create middleware that can successfully handle very disperate genres: RTS and FPS games, for instance. The numbers of units in an RTS game require a fundamentally different basic AI architecture than you'd want for a high fidelity FPS game.

But yeah, given that you abandon hope of pluggable middleware that covers everything there are certainly ways that you can be successful.

-me

To paraphrase Ian Millington, there are three types of game AI: hacks, heuristics, and algorithms. I don't think we can do much about hacks and heuristics, but many algorithms should be codifiable in a project-agnostic manner. Ian's book is full of such generic algorithms and the source code is freely available at ai4g.com, so you should check it out.

Sure, games do differ a lot, but we not only conform to graphics but even to physics APIs these days, and both graphics and physics can differ quite a bit between games - it just means that the AI engine must support a wide variety of algorithms. You don't actually have to use them all.