Here's a list of the eighteen best, quirkiest, and most informative artificial intelligence bugs available on YouTube we've collected over the past 12 months. In the spirit of AiGameDev.com, you'll find a bunch of tips & tricks to help fix these problems when/if you see them in your own game.
First, a disclaimer. While certainly fun, this is also a difficult feature for me to write; the draft has been waiting to be finished up and published for over 6 months. There are already many video collections of AI bugs on also-ran Game News sites, but the difference here is that I've personally met or worked online with most of the developers behind these games — and many of them read this blog (RSS). I'm hoping the controversial aspect of this article is overshadowed by the useful analysis and the importance of the topic.
The fact is, if you look beyond the sensationalist headline, social media websites are dramatically changing the way games are received by gamers and the community at large. And AI in games is no exception here... In fact, there seems to be increasingly more pressure and scrutiny on the behavior of game characters. Luckily, this new area of social media means there's also lots to learn from!
AI Can't See Until Seen
Game: Half-Life 2, 2004.
A player is carrying a barrel in front of his eyes such that it hides all enemy NPCs in the scene. This in turn causes the enemies to not attack until the player drops the barrel!
Explaining this bug requires a little context. As documented by Tom Leonard (now working at Valve), the sensory system in Half-Life is built to help prevent player frustration, so that soldiers and enemies in the game do not attack the player until the player has noticed them.
In this case, you can use that to your advantage by carrying a barrel, but you could also demonstrate this bug by walking backwards into a room full of enemies!
Since this special case in the sensory system was introduced artificially for gameplay reasons, fixing it also needs to be a game design issue. There are multiple quick fixes:
Add an extra condition to the "ignore player" statement in the sensory system, for example only when the player is under attack or recently received damage.
Remove the "ignore player" statement with a time out mechanism that kicks in after a few seconds. This can provide realistic AI reaction & decision times while at the same time giving the player some leeway.
Going beyond these quick fixes requires a more general "experience manager" that can determine which NPCs should acquire the player as a target based on the current challenge to the player.
Building an AI Sensory System: Examining The Design of Thief: The Dark Project Tom Leonard, GDC 2003. View Online
Your Last Known Position Is...
Game: Hitman: Blood Money, 2006.
An doctor-like NPC was chasing the player who recently escaped from some hospital facility, but does not notice the player changing clothes in front of him. The doctor then abandons the chase, is threatened by the player (now in Hitman clothes) and goes to notify a guard NPC about the last known position of the escaped prisoner. In the process, the doctor NPC runs past the player himself shouting "Run for your life."
Extra: Guards do not react to the player's escape until notified by the hospital staff.
All NPCs in the game have a sensory system which allows them to react appropriately when the player is dressed differently. This allows gameplay features like changing clothes to hide from guards and doctors. However, there's a loophole in this system that's not handled when the player is visible when the clothes are changed.
Extra: The same sensory system means that not all guards are instantly aware of the escape until told, but in this cause the guards do not take into account the player's obvious actions.
The problem is caused by adding a sensory system, which is very useful. However, corner cases pop up due to the additional complexity. These can be fixed with the following steps:
To hide these problems and generally improve the AI, each guard could be built with a default behavior that activates when the player does something suspicious — regardless of his clothes. For example, reacting to the player running or nearby.
An extra flag is necessary somewhere in the sensory system to indicate if the player changed his clothes while visible. If that's the case, this flag would help override the current perceived clothes, and keep the same behavior active.
This flag can be set globally once for the player or, in the spirit of this game, it would be set for each NPC. This would allow the doctors to communicate to guards about the player's false disguise.
Game: Grand Theft Auto San Andreas, 2004.
NPC cops follow the player into the water, but they can't swim and immediately drown.
This kind of situation is one of many special cases that can arise in open worlds, particularly when the NPCs do not have the same abilities as the player. In particular, this bug was caused by the cops either not knowing about the water, or not knowing that they needed a special ability to enter the water. Instead, the cops AI was reactively moving towards the player's position.
This was fixed in subsequent releases, presumably by:
Adding more information into the navigation graph about the type of environment, in this case annotating volumes as water.
Making the cops' pathfinding aware of the water and avoiding it at all cost. The AI would stop before the ledge leading into the water.
When Priorities Go Wrong!
Game: Crysis, 2007.
NPC investigates a burning barrel that was thrown by the player and landed nearby. The barrel subsequently explodes while the NPC is nearby looking at it.
The NPC's investigate behavior is activated when an unexpected sound is emitted by the landing barrel, but the fact that the barrel is burning is not taken into account.
There are two possible fixes, in order of preference:
Have the FreeFromDanger behavior work for burning barrels, and make sure its activation is checked periodically. (Subsumption)
Add a special-case precondition to the investigate behavior that checks if the source object type is not dangerous. (Inhibition)
What Sound Does a Knife Make?
Game: S.T.A.L.K.E.R., 2007.
A player using a knife can completely take over an enemy base without any of the AI soldiers firing a shot back at the player.
There are two things that cause this bug:
The fact that the Knife seems to be treated as a separate case by the sensory system, so it doesn't trigger the usual reaction that you get from a weapon.
The fact that S.T.A.L.K.E.R. supports neutral factions, the player is by default treated as a neutral entity and this status is not updated because of point 1).
The solution to this problem is to first fix the sensory system and its effect on the behavior, so that knife kills are taken into account as other weapons. This can be done by using one common Event type, or alternatively taking into account a death sound.
The second thing to fix would be to make the Stalkers a little more suspicious of the player when entering their base, especially when armed. Also, Stalkers could be given a sixth-sense suspicious behavior (rather than the normal patrol / idle) when multiple nearby soldiers are killed.
Standing Still *Is* A Strategy
Game: FIFA 08, 2007.
An individual AI player on the opposite team remains completely immobile in the middle of the pitch, only playing the occasional idle animation. He remains still even if a human player runs up to the AI individual, puts the ball in his feet, or bounces the ball off him.
Such general bugs are hard to identify without looking at the code itself. Even with the code handy, explaining why an NPC is not doing what he's supposed to do generally is much harder than narrowing down a more specific issue. In this case, it could be any of the following:
- This player no longer has its AI updated because of a game logic bug, and is simply "going through the motions" in a brain dead manner.
- The individual player has found a "terminal" state in the behavior which offers no way out. This is a problem in the logic that's relatively simple to fix once identified.
The AI works for the rest of the team as well as for other games, so this seems to be a very special case. Specific enough that EA shipped the game with it. Once isolated, tracking down the source would be relatively easy by using a logging mechanism to identify this particular problem (if your designer comes up to you with this issue). However, to catch such problems generally you could consider gathering simple statistics for each player, such as distanced moved, passes sent and received, etc. and watch out for anomalies.
The Shortest Path is a Straight Line
Game: Armed Assault, 2007.
At the edge of the map near the water, a squad ordered to move to a point on the other side of the bank decides to move through the water. The individual AI soldiers swim around and eventually reach the shore, from where they can move to the target point. In the video, the player reached that point in 1/3rd of the time.
This bug may be caused by two things:
- The navigation representation does not model the water. This is possible if the world is assumed to be a 2D terrain with sparse obstacles.
- The pathfinder used by squads does not deal with concave areas like near the edge of the map, also caused by similar 2D terrain assumptions.
The easiest way to fix this is to smooth the coastline of each map such that there are only convex land masses. Alternatively, the squad pathfinder can be run through a representation that takes into account the water at an increased cost, such that it is avoided by default.
I'm Invisible: Go Around Me
Game: Company of Heroes, 2006.
An invisible sniper controlled by the player causes the tank to stop and pathfind around him everytime he moves. Yet the tank and the enemies are not aware of the sniper and therefore don't engage him.
The cause of this problem is a mismatch between the game logic and high-level behaviors ignoring the sniper, yet the pathfinding is continuously trying to find a way around a hidden sniper.
There are two ways to fix this, one involved less design and the other more technology:
Remove the sniper cloaking feature! The tanks would attack the sniper rather than try to pathfind around it.
When the sniper cloaks, remove it as an obstacle for enemy units in the pathfinder.
Moonwalking Is Fun
Game: Prince of Persia: Rival Swords (PSP), 2006.
NPC guards are seen on two instances walking into posts and closed doors repeatedly, while the animation keeps on walking.
Extra: Enemy is passive until attacked the first time.
There are two bugs that cause the behaviors to look like this in the end:
The navigation representation isn't accurate enough, either taking into account the characters width near pillars or not updating dynamically when doors close.
The path following isn't capable of noticing lack of progress, and simply keeps on going despite collision problems.
Fixes to either of the two problem areas would solve this, but such navigation problems often take much longer to fix than the usual behavioral bugs. In this case, you'd need to build a more conservative navigation representation (e.g. retracting the edges of your navmesh a bit further to prevent physics problems) or if the system is using waypoints then reducing their effective radius. The second improvement could be to use a simple form of dead reckoning to track the change in movement, and consider planning a new path if the velocity reaches zero over the course of a few seconds.
Who's Your Enemy?
Game: Oblivion, 2006.
An enemy NPC was unresponsive until attacked. The NPC responds to the player once hit with the sword, but decides to target another NPC before dealing with the player. In the end, the NPC ends up running off to his original target.
Extra: NPC moonwalking into a wall as in the previous issue.
The pathfinding issue and lack of responsiveness is the same diagnostic as bug #10. However, the prioritization issue (which seems to be a problem) is caused by the AI only taking into account the most recent attacker, and ignoring the players original attack.
The main way to fix this involves biasing the NPCs a little more towards the player. Having an in-game simulation is a nice feature to have, but this is a game so the NPCs should take the player's actions into account a little more. For instance:
Have NPCs ignore other attacks if the player is the current target.
Maintain a queue of multiple active targets, and make sure to engage the player before moving on.
Which of these you decide to apply as a fix depends on your design, and how "player focused" the AI should be. Even if the NPCs don't engage the player, they should at least acknowledge this.
Where's the Pitch Control on this Mounted Gun?
Game: Crysis, 2007.
The enemy NPC in control of the mounted gun just fires repeatedly in the direction of the player, despite not being able to hit him. There's a dead spot right near the vehicle where the NPC cannot aim the mounted gun, yet still the AI soldier keeps shooting regardless.
The problem is that the behavior of the enemy on a mounted gun remains the same in all cases while the player is in front, even though the player may not be targeted. When the NPC receives damage, however, he dismounts from the gun as expected.
This is another special case that is amplified by YouTube and the fact that this is a sandbox game. The multiple fixes are relatively simple:
Use a simple line-of-sight (LOS) or cone-of-fire (COF) check to determine if the player can be targeted.
Add a minimum radius to the mounted gun behavior such that the NPC dismounts if the player comes too close.
Tell the NPC to dismount if he hasn't done any damage to the player for a certain period of time.
Drowning on Land
Game: Halo, 2001.
A grunt is stuck "swimming" on the floor. The grunt does not respond to player shots, but only to explosions.
This could be due to the fact he's stuck in geometry and playing a falling animation. The reason for being stuck in the first place may be due to collision and/or explosion pushing the grunt into problematic geometry.
This particular bug is a difficult one to fix within the physics simulation, like many other physics/collision related issues. The fact that this bug was also apparently reproduced in subsequent versions of Halo also indicates this is a tough problem.
A behavioral fix could be to detect that a grunt is partly stuck in this state, and run a query on the navigation system to find a nearby position that's not occupied, then slowly interpolating the grunt towards this position.
Are You Receiving My Bullets?
Game: Call of Duty 4, 2007.
Allied and enemy NPCs keep shooting each other from a meter away, and keep missing because of a nearby tree. Bullets of one of the NPCs are actually hitting the tree, but the bullets of the other seem to disappear.
Extra: Both AI soldiers are also unresponsive to player movement.
Four little factors (that wouldn't be too much of a problem elsewhere) combine to cause this particular issue:
The "attack enemy" behavior continues to execute at top priority until the target is dead, regardless of what the player is doing or how successful the behavior is.
The line-of-sight (LOS) check used to determine if an NPC can shoot another does not trace the bullet exactly. (This is usually the case in modern games.)
There's not enough variation in the shooting behavior to break the deadlock.
No feedback is provided to the NPC when his bullets hit a tree rather than the intended target.
Fixing any of the following problems would resolve the issue:
Decrease the value of the "attack enemy" behavior over time as it fails to achieve its goal, or let it time out such that another behavior is chosen.
Introduce more randomness into the shooting behavior as the NPC keeps aiming for the same target. Modeling this kind of frustration as part of the aiming skill would help.
Have the NPC monitor the health of the enemy and inflicted damage to check that the current behavior is actually achieving its intended purpose.
At regular stages before / during the shoot out, fire a tracer bullet to check if the target can currently be hit from the exact position of the gun.
The way I would resolve this problem is to have fixed duration actions for attacking the enemy, then select many of these in succession to guarantee diversity in the combat and also prevent single problems.
What Just Happened There?
Game: Oblivion, 2006.
The player fires an arrow in an NPC's living room. The NPC then accuses the player of stealing from him.
The typical causes for an inappropriate behavior in response to an event / stimulus are either:
An error in the conditional logic to activate a behavior.
There is no behavior for this event, and a default is used.
In this case, it's doubtful that the reaction "You're stealing from me!" is used as a default, so I'd assume that the problem is with the activation logic for this behavior. It might be a simple scripting or copy/paste error, but otherwise having a clear event/situation for "Player picked up an object that doesn't belong to him." would help activate the stealing response.
Also, you could remedy this situation by having the AI check the reaction "What exactly are you doing?" when specific situations like these are found.
Do the Oscillation Dance
Game: Gears of War, 2006.
The enemy NPC is dancing on the spot, oscillating back and forth between two positions. The NPC is also unresponsive to the player's nearby presence.
There are a few instances of the same bug on YouTube also, and this seems to be caused by the navigation system changing its mind too often. The pathfinder is run from one position, calculating a path one way. Then as the path is followed, the path is recalculated causing a different route to be taken.
The actual cause of this oscillation could be due to the way the costs are setup in the environment, which lead to a local "minima" where the bot oscillates. But an alternate explanation is that the bot hits a trigger box / radius when moving in one direction, which causes one behavior to engage. Then when the trigger is exited, the original behavior resumes.
Assuming it's a special pathfinding situation where there are multiple paths to the bot's target, the easy way to reduce the problem is to add a "cool down" factor for changing destinations less often. There's typically no need to decide on a new path on a regular basis, simply monitoring the current path for problems would be enough.
If the problem is due to local triggers engaging two competing behaviors, a similar time buffer can be used to reduce oscillation between the two choices.
Driver, Where Are You Talking Me?
Game: Halo 3, 2007.
An NPC driving in a Warthog keeps bumping into a force field while trying to drive around. However, when the player gets out of the vehicle, the driving / bumping bug stops.
The force field does not seem to be taken into account by the vehicle pathfinding. The AI doesn't realize it needs to move backwards in this case to get out of trouble.
There are two ways this could be fixed:
Have the pathfinder take into account force fields dynamically when doing searches for vehicles.
Detect that path-following fails (using progress measurements) and temporarily disable links in the navigation representation, to prevent problems of unexpected dynamic objects.
I Speak with Dead People
Game: Crysis, 2007.
Two NPCs are in a scripted dialog with each other. The player takes out one of them using a sniper riffle, and the other NPC keeps on chatting away as if nothing had happened.
The root of this bug is the interplay between scripted situations that involve multiple characters, and the dynamic gameplay behavior that's required to interact with the player. In this case, since the shot of the sniper riffle was possibly not heard by the NPCs, the trigger failed to interrupt the scripted dialog since it didn't take into account the nearby death of an ally — very much like bug #5.
The solution involves a similar fix as #5, making sure the sensory system takes into account "entity dead" events as sounds, for example. Alternatively, NPCs near the hit point of a bullet should be informed of the presence of the player, or possibly even informed of the player's position (after the second shot). Above all, your group behavior scripts must be written to be interruptible by the player at every stage — especially if you're working on an open game.
Do Not Open that Box!
Game: Bioshock, 2007.
When a particular box is searched, an enemy is spawned everytime on demand at a similar location. Even if the player is looking at all the access points for that location.
Although the game seems to spawn NPCs out of sight of the player, the problem is the script that spawns the enemy NPCs doesn't take into account how often he performs an action.
This isn't technically an AI issue, it's more of a scripting problem. But, as often with these bugs, it's attributed to AI programmers!
There's a scripting fix and a technical fix that can alleviate this problem:
Add a counter to the script trigger to prevent it from firing more than once.
Beyond checking the line-of-sight from the player to the spawn point, check if the player is looking directly at all the access points of the spawn location.
Summary & Take Away
Generally speaking, there are a few things you should know about game AI bugs:
On their own, most bugs don't take long to fix technically speaking; most ones in this list would possibly take between an hour and a few days to isolate and fix.
Most bugs quickly become a design decision, as fixing bugs may affect other behaviors or the gameplay itself. Towards the end of a project, the AI is often frozen for this reason.
AI bugs are rarely ever show stoppers, and the reason they are not fixed is due to scheduling and production reasons.
As an AI developer, this can be a little frustrating at times — particularly when the reviews come in. However, the fact that a game contains AI bugs reflects on a large part of the team, particularly at the production level. It's possibly one explanation for many AI programmers eventually becoming Lead Programmer, as it's one of the best ways to make sure everything comes together to make sure the behaviors work and the gameplay is fun!
In the meantime, if you're making your own game, this list of bugs also has its lessons to teach:
Spend time playtesting so that you can find out your player's expectations, and cater to those. This is a numbers game.
Consider spending some time tuning your AI for NPC watchers that try to find loopholes in the behaviors and post bugs on YouTube!