Artificial Intelligence in games is usually a misnomer. Rarely is it possible to create artificial intelligence that is truly capable of responding correctly to a human player; some AI may be too “smart”, acting instantaneously and without any reason to complete whatever objectives it is given, but it’s also possible to create AI that are not challenging or lack an element of life. Finally, there are concerns with the development side of AI that need to be addressed. The four primary problems with AI are the computing load, task management, player interaction, and vivacity that all need to be addressed.
For the idea of computing load, the old problems with a* pathfinding are always a good starting point. When designing an AI, it is important that a game developer consider all the necessities and practicalities of AI, not just the excellence of a potential playing style that AI can be given. Pathfinding is a traditional bane of AI, though other fields can be similarly addressed. For example, Counter-Strike used to use navigation paths for its bots; this means that they only go along certain paths (minor deviations are possible, of course) and hide in certain places. With little work, the AI can also be upgraded to consider a heatmap or have dynamic learning experiences; if they die a lot in certain places they’ll avoid them, and if they get a lot of kills in a certain place or plant the bomb more often while taking certain routes they can go there more often (side-note: I’m not totally familiar with CS’s AI, but I’m almost certain they don’t do this). These pre-package responses are great to cut down on processing load, and can be found in such things as Finite State Machines (as used in the Arma series) to provide AI that will undertake certain actions in certain conditions. Randomness and prioritization can be used to add a degree of realism and complexity to these events, but they are still “canned” and pre-made. This is usually acceptable, since most game environments don’t support fully dynamic AI (unlike, say, some AI for RTS games such as TA: Spring), and saves a lot of processing power.
Another thing to note is task management. As a developer, you need to know what the AI will do. A simple FPS AI might shoot and run. A more complex AI might shoot, run, and take cover. An expert AI might shoot, take cover, and run or walk depending on whether or not they think they will be heard when they run. If the AI is not built to play the game, they will fail. This goes without saying, but there have been games released that have pitiful AI; if you make a driving game, for instance, the AI should respond to other cars that can run them off the road by trying to keep their distance, ramming the other cars, or really doing anything but waiting to get sent into a spin. AI that never undertake certain actions in the game’s ruleset, no matter how rarely used they are, will likely encounter exploitative bypasses or face early obsolescence. For instance, an AI that never builds nukes may be desirable for a novice difficulty in a strategy game, but it’s also one that will never force the players to respond to the threat of an incoming nuke. Likewise, an AI in a stealth game that ignores lighting and goes for long strolls without a flashlight in the dark is essentially irrelevant or doomed (unless, of course, they have perfect night vision, which will likely annoy players).
Player interaction is another factor. Human reflexes average out at about 225 milliseconds, which means that very fast AI can easily outperform them (if we assume that the AI updates every frame of a game running at 40 frames per second, they’re 200 milliseconds faster than a human). It should be totally acceptable to change AI to use human response times, especially if your game is something like Arma where a realistic experiences is highlighted, although in strategy games or less realistic (or symmetrical) games this may not be as much of a problem. If the AI ever goes over a network, they’ll also be gaining another hundred milliseconds or so in a “decent” situation, and there’s usually a display delay to boot, so you can expect as much as a quarter-second delay in most cases for human response time even with good latency compensation. Of course, another thing to consider is the AI knowledge. With something as simple as running a raytrace from the AI’s in-game eyes to the player’s position (or perhaps the parts of a player likely to be spotted while they are hiding) to see if they are obstructed) you can easily prevent the AI from “cheating” with prior knowledge, without having to worry about the processing power that a fully blind AI requires (for instance, if you wanted the AI to know where the player was but not take a cheap shot at them).
Vivacity is another concern for AI on the opposite side of the spectrum. This is where a developer needs to worry not about the speed and per-case actions but rather on creating a grand facade of realism and life for their environment. Something like Skyrim does this relatively well, though Dwarf Fortress likely holds the throne as far as “living” AI go. Skyrim, for instance, can be mostly emulated in terms of its “AI” by making NPC’s have love/hate reactions to each other, giving them a lawful/criminal streak, and a few basic needs. Radiance stacks on top of this to provide more fun for the player with random quests, but that’s beyond the question of AI; providing the AI with enough interactions to do with people they don’t like (i.e. attack on sight, steal their stuff when they’re not looking, murder them to reclaim said stolen goods) creates a decent environment, but also requires a lot of resources. Fortunately, this sort of AI doesn’t need to be refreshed on a terribly frequent basis; in fact, a tiered system that separates instantaneous reaction, short-term goals, and long-term goals and assigns appropriate priorities is not only more realistic but allows the more intensive tasks (how do I get revenge on the Duke?) to be time-shifted or ignored in high-load environments.
One thought on “Game Design: Creating Immersive AI”
I think the biggest problem with AI in games is that it’s called Artificial Intelligence. Split it up into the algorithms that it operates on but don’t call it AI. For example, behavourial models cover the finite state machines that determine outcome, a decision engine uses a finite state machine to calculate outcome. Physics constraint simulations govern what physical options are available to a decision. Fuzzy logic gives an element of randomness.
Path finding isn’t really AI either because it’s deterministic. If the actor is path finding to a goal, then it should head toward the goal in the best possible way. If it isn’t, it’s not path finding, it’s random walk.
Gaming systems are expert systems at best and it’s right that they are. It’s what you want: the appearance of intelligence but not actually AI. Artificial Intelligence algorithms that learn properly require too much input data before they are useful and quite often fail to learn what you intend them to. You don’t want your algorithm to abstract, nor to process minima of a function space. Processing isn’t really an issue anymore a 100,000 neuron multi-layer perceptron will sit happily in 100MB of memory (with indexes) and learn without processor load. The problem here is training sets.