AI Follies: Introduction

By Shamus Posted Wednesday Aug 12, 2009

Filed under: Programming 51 comments

A while back I had a post that criticized the AI of Far Cry, and in the comments Legal Tender asked:

I wonder if you could elaborate further on the super-senses issue with the AI, Shamus?

I don't mean a more detailed description of it but rather what it takes to fix it from a programming point of view.

I remember you wrote a little something about AI behavior. I can't find that post but it left me thinking of…procedural AI? You know, give the AI grunts a set of behaviours and then let them loose on the world.

What can be done about super-senses? I mean, is there a setting, something like AIdetection=1 or AItrackingtrfoliage=1? and then you adjust them to 0.8 so foes will ignore you or can't aim if you are behind obstacles?

I started trying to write a response in the comments, which grew into a post, which grew into a series of posts. I had a post on this back in 2006, where I talked about the problems of having an NPC accompany you through the game. In that post, I said:

People ask why AI sucks so bad? This is why: It's hard, it's expensive, and when it's working right people don't notice because they only notice when the thing screws up. The developer can spend money making the gameworld bigger, or spend money adding lots of detail to some inconsequential NPC just so it doesn't kill immersion.

Developing AI is all about concealing or mitigating AI mishaps and screwups. If you hire a brilliant programmer and he does astounding work, in the end you’ll have spectacularly stupid AI that doesn’t do anything too obviously stupid when the player is looking. That’s the best you can hope for, because that’s the best that you can hope to do with a “mere” 10,000 lines of C++ code and a couple percent of your dual core processor. (Actually, processor isn’t that much of a bottleneck. The check to figure out where a given bullet will go and which of the 1,000,000 polygons in the scene it’s going to hit is going to be an order of magnitude more time consuming than anything your AI coder can throw at it. We don’t really need more AI processing power, because we’ve only just begun to figure out what to do with the power we already have.)

Note that I’ve never written production-quality AI before. I’ve dabbled quite a bit over the last quarter century, like most curious coders, and I’ve made a few simple systems. (Some of my first coding projects way back in 1983 at the tender age of 12 involved AI pathfinding.) But this series is more my overview of the problem and how I’d approach it than a review of work I’ve done in the past. I’m going to be outlining the problem – which is far bigger than a lot of people realize – but not offering any solutions. (If you want the solutions, feel free to send me an overview of the salary and benefits package you’re offering, because we’re going to be working together for a long time. (I’m Kidding. (Mostly.)))

I’m going to be talking mostly about dealing with enemy AI in this series and what a programmer needs to accomplish to reach the lofty goal of having enemies that aren’t obviously complete morons. Let’s assume we’re talking about generalized, dynamic AI as opposed to pre-scripted stuff. Imagine we’re talking about AI to oppose the player in various situations both indoors and outdoors. Ideally, we want the level designer to be able to drop a bunch of enemy AI dudes into the level, click and drag over the group, and say “You lot are all on a team. Work together.” In the end, we want that team to fight in a way that isn’t obviously stupid, unfair, or boring.

I divide combat AI into four distinct parts, in order of descending importance and increasing difficulty to implement: Detection, Targeting, Pathing, Behavior. I’ll talk about each of these in its own post. Later, you see.

Getting Started

If I were developing AI, my first step would be to get as far away from the game engine as possible. AI development is very expensive in terms of experimentation and testing. (Or should be, if you hope to do a good job.) If you’re testing group tactics, you need to test all sorts of situations and behaviors. There are hundreds and hundreds of ways a battle can play out, and you need to be testing a wide variety of scenarios to make sure you’re not just playing whack-a-mole. You don’t want to spend two days fixing the code that lets the AI navigate around buildings only to find you’ve completely broken the code that lets it snipe from a distance, and then spend another day fixing that to find the AI can no longer take turns going through doors.

You need to run a lot of tests, and you don’t want to launch the alpha version of a AAA game engine and sit through a bunch of loading screens every time you want to see the AI do its thing. The game will be very unoptimized and unstable early in development, and you don’t want to deal with long loads and crashes. You also don’t want to have to manually play the level, either. At least, not every single time.

Having a clear view of the battlefield would also help in giving me a nice objective view of things. It’s much more difficult to spot irrational or absurd behavior in a sea of foliage, particle effects, lens flares, tracer rounds, blood decals, and flying ragdolls. This wouldn’t be a problem if I was watching icons battle it out on a sterile “Tron”-style grid. (Aside: Didja see the new Tron Legacy teaser? Whee.)

I have no idea how AI coders work these days, but I would write something exceptionally lightweight. A simple program that moves 2d sprites around a simple “maze” of arbitrary shapes. Ideally, I’d want a program that can launch directly into the battle in a second or two. It would be able to run in accelerated time and fight itself while I watch and analyze the action. I could then iterate on that thing about twenty times faster than someone loading up (say) Crysis every single time they want to see the AI work. Once I had it polished to a mirror shine, then I’d integrate it into the game.

No development approach is perfect, and this one wouldn’t be without faults. But I think this would let me make the AI as smart non-stupid as possible without pushing back the release date until (insert Episode 3 joke here).


From The Archives:

51 thoughts on “AI Follies: Introduction

  1. Of course, by testing in a different environment than the one you’ll be eventually running in you create possible integration problems. Assuming both the real and test environments run on top of the same engine code and present different views, then that would work well. I guess it depends on what you consider “good” AI in games – I personally think AI that can create plans of attack and use tactics in groups (like distracting from the front whilst the other bit of your team flanks) to be really good AI

  2. Rehtul says:

    Great, another series :)

    Wouldn’t it be simple enough to set up scripted scenes for the AI to go through, instead of trying to react to each scene in a special way?

  3. JKjoker says:

    Shamus, you mention that AI programing has no need for a lot of cpu power, but what about the use of in-order chipsets on consoles instead of the out-of-order chipsets used on PC ?

    a developer said some time ago: “Gameplay code will get slower and harder to write on the next generation of consoles. Modern CPUs use out-of-order execution, which is there to make crappy code run fast. This was really good for the industry when it happened, although it annoyed many assembly language wizards in Sweden. Xenon and Cell are both in-order chips. What does this mean? It's cheaper for them to do this. They can drop a lot of cores. One out-of-order core is about four times the size of an in-order core. What does this do to our code? It's great for grinding on floating point, but for anything else it totally sucks. Rumours from people actually working on these chips ““ straight-line runs 1/3 to 1/10th the performance at the same clock speed. This sucks. ”

    AI might not use that much processing but with so many characters moving about on the level and the x3-x10 multiplier it will start to stack up

  4. Shamus says:

    Rehtul: That was how it was done in the late 90’s-ish. I wrote about it here:

    Short answer: The more complex the gameworld gets, the more scripting works ends up falling on your level designers. The more complex the battlefield, the more hilarious the various failure modes will be. (Like, if you dash around to the other side of the room, the back guys will stand in FRONT of cover, or catch each other in the crossfire. This might be amusing once, but in a rigidly scripted world it means tricks like that will work over and over again. Fixing those issues boils down to writing AI.

    Okay, that wasn’t such a short answer.

  5. Ingvar says:

    JKjoker @ #3:

    I think that is fundamentally a challenge for compiler writes, not for coders. It should, on the whole, be possible to push the silicon logic that determines what can (and cannot) be done OOO from the chip into the compiler optimisation and instruction scheduling module(s).

    But, since there’s not been a MASSIVE need for it, as-is, the compiler-dev effort has been spent in other parts of the compiler, where there’s been more bang for the buck.

    1. Shamus says:

      JKjoker: Honestly, I don’t know. I’ve never done any console development and I’ve never worked with those sorts of processors. And the question itself is about low-level stuff that’s really outside of my area of knowledge in general.

      I will say that the geometry work scales right alongside the AI work. If we have a single AI dude, the CPU will be spending a ton of time animating his polygons, checking line of sight, and performing collision checking on his geometry. It will be spending a tiny bit of time having him making tactical decisions. If we expand that for one guy to fifty, the geometry work expands as well, so AI will still be a small slice of the overall load.

      As for how this will be impacted by OOO processors, I have no idea.

  6. Zel says:

    I agree that most AI we see in game are stupid, but this may be a deliberate choice. When designing enemies, it’s actually quite easy to make them tougher than an human, because they know all the rules : a FPS enemy sniper will shoot you down as soon as he sees you, and he won’t miss since he knows your distance from him, your current speed, orientation, etc… and the exact algorithm to place the bullet between your eyes.

    But give some game this AI, and it will be labeled unfair immediately. The AI has to be dumbed down so that the player can still defeat it. When pushed a little too far, this gives you highly trained soldiers that can’t seem to shoot straight or see 10 meters in front of them, but at least you can kill them.

    Just look at FF12, where you can parameter your character’s AI much more than what is usually available. There’s nothing complicated, just 10 or so if then else tests, and it’s enough to make your guys able to play the game by themselves, boss included.

    I think the AIs are designed to be stupid, because otherwise the games wouldn’t be any fun. I wouldn’t be suprised that the major part of those 10.000 lines of code for the AIs are ways to dumb them down or limit their abilities to make the game “fair”. The problem, as you mentioned, is to make it seem like they’re not stupid, as it’s not fun bashing morons either. You have to make them smarter but not deadlier, which is quite the difficult task.

    1. WJS says:

      Anyone who looks at a cheaty omniscient murderbot and decides that the best way to make him less unfair is to make him stupid is a moron. This post implies that they could make smart AIs, but given the choice between making them less omniscient and making them stupid game devs all pick the stupid option (in both senses). That they just don’t know how to make them smart is the generous interpretation of the situation.

  7. LazerFX says:

    Ingvar @ #5:

    Compiler writers? On an advanced game engine? You want to get as close to the ‘iron’ as possible on something like a game engine, so that you don’t lose speed – and the only way to do that is to write the hard-core logic, graphics, etc. routines pretty much in either assembly language or very low level language – at times, even C/C++ is too high-level, even with tricks like Duff’s Device and pointer logic and such. You’re going to be doing tricks with data manipulations that mean you’ve _got_ to know what you’re doing, how the hardware will run it, and what’s going to happen next…

    So – no, this isn’t really an issue for compiler writers, as for the engine devs. That said, it’s not an issue for the AI writers, or for the level designers, or anyone else who can work at an abstract away from the actual technical issues.

  8. JohnW says:

    Can/Does an evolutionary algorithm play any part in this development process?

  9. Factoid says:

    I wonder how simple the development environment for AI coding can really be? I mean pathfinding through a 2d maze is not quite the same as pathfinding over a 3d landscape with 3d obstacles.

    Maybe the thing to do is develop your AI within a more fully fledged 3d engine…something open source like the Q3 engine. That would be passable as a “low res” version of your eventual environment and you’d have a ton of free maps to work with and the environment is very fast and very stable on modern equipment.

    Also wouldn’t the AI coder have to do at least a little bit of work in the actual engine? Won’t the level designers need that code in order to iterate THEIR designs? They’ll at least need something to make bad guys move around on the map and shoot at the player during testing.

    Maybe something like a simple scripted AI is OK for an alpha, though. Beta is really where everything should come together and just be tuned to perfection.

    1. Shamus says:

      Factoid: Yes, you need to be able to navigate a real 3d environment, but for the purposes of pathfinding I’d abstract all of that away into a series of nodes. It might look funny in a 2d display (two points that appear next to each other that are inexplicably not linked or related, because in 3d space they’re on different floors or whatever) and I might eventually expand my Tron world to show 3d space, but the goal would be to keep it all as fast and as abstract as possible.

      1. WJS says:

        Well yes, but pathfinding has been pretty much a solved problem for a long time now. I knocked off a simple pathfinder for fun in javascript a while back. Most of the tasks you want an AI to do are too complex to be simulated on a simple grid.

  10. Deoxy says:

    Individually decent AI has been done, and it’s not incredibly hard, really… the average MMO monster usually has something that isn’t too bad, for instance.

    FPS does make it a bit more difficult, in that there are so many more possible states to deal with (getting useful cover without blocking your line of sight, for instance).

    Detection radius (with reasonable modifiers), variable skill level with weapons (adding a random variance minus a set value that is higher for higher-skill troops, for instance), morale and retreat… these have been done, and I think it’s mostly laziness that they aren’t done more often. (I’m not saying I know how to do it, mind you (though some things are pretty obvious), only that I’ve seen it done well more than once over the years, though perhaps not all in the same package.)

    The real difficulty is group tactics. Flanking, feints, ambushes, traps, etc. Working together as a group. This requires an overall guiding AI (some kind of central command – basically, a RTS AI) or some kind of AI-to-AI communication method. The guiding AI really only seems appropriate in certain conditions, and even in those conditions could seem very unfair to players**. I haven’t seen AI-to-AI communication even attempted other than the extremely simple “alert” mechanism, where they all (or all nearby) see what one sees, which sometimes is a mild improvement and other times a horrible, horrible detriment, depending on implementation and a few other factors.

    **Actually, I think a game that put a HUMAN player in a “guiding AI” role over other human players could be all kinds of nifty, at least with actual teams (pickup games would probably have a high SUCK ratio). I think that’s been attempted in some shooter MMO, but I don’t know how it turned out.

    1. WJS says:

      Seriously? MMO AI as an example of good AI? Don’t they just stand there and play an attack loop at you?

  11. Nathon says:

    JKjoker: Speaking as someone who’s been bitten hard by processors reordering my instructions (look up eieio on PPC. It’s real, useful, and has a funny name.) superscalar processors are great for people with crappy compilers. I don’t think it really adds much when you’re compiling for consoles, since you know exactly the architecture for which you’re compiling. Scalar processing also helps with power consumption, since there are a lot fewer transistors to power per instruction cycle. I’m not going to make any predictions, but I like my scalar processors.

  12. Robyrt says:

    I like the rapid prototyping idea of just running the AI through a top-down view of your levels and having it fight each other. I’m worried that this might result in “cardboard storefront” AI which is unable to react to a player doing anything unexpected, which of course every player does.

    With the example of the guys that crouch in front of cover if the player is on the other side, a simulated AI battle would never have discovered this. So your initial coding time is faster, but debugging may not be any quicker.

    1. Shamus says:

      Robyrt: I certainly wouldn’t rely only on AI vs AI for testing. You’re right that you MUST test against a human. I was actually thinking of “saving” input from a human-played scenario that produced unwanted behavior, and having it replay that activity until the correct AI behavior is observed.

      1. Shamus says:

        And if I’m spamming my own comments more than usual it’s because this topic is very exciting to me, and it’s taking a constant willpower save to keep from running off and actually doing this stuff, so talking about all these little details is a welcome salve. I’m actually really happy will how many people have joined in with the armchair AI design already.

  13. SireCh says:

    another possible problem with using an “external” world, is that the AI can have good results on it, but suck in the real game. e.g. pathfinding usually needs a good amount of fine-tuning.

    The big problem I think is that in general the tools available for game developers are archeological compared to other developers. There is C++ (very low-level for things like AI), lack of automated testing (the 3d engines don’t really play along well with this), and of course the crisis-oriented scheduling (you need the beta before X, you can’t miss christmas). No wonder so many games flop.

  14. RibbitRibbit says:

    An aside: someone once told me that Diablo gameplay was done this way. Meaning, the dev team did everything with 2D shapes (colored squares, I believe). Once they had their gameplay fast and intuitive in 2D-Colored-Square-Land, they merged it into the game engine proper.

  15. Panzagl says:

    NERO has an evolutionary/training approach to AI. Lot of fun to play with:

  16. utzelgrutzel says:

    One important thing to the player is feedback. As you said […] when it's working right people don't notice because they only notice when the thing screws up.

    That’s why you need to show how good the AI works. A funny example is FEAR, which is generally praised for a good AI: The enemys call out for reinforcements, but can’t actually get them.
    A good article about the FEAR AI can be found here, the whole site is a very interesting read!

  17. Ideally you’d want every part of your code to be seperated from the rest of your code. That’s just good programming practice, and isn’t specifically about writing AI. Having an interface that handled map nodes, character positions and line of site checks would be a start, so that you can write a simple implementation, which can later be replaced with the full game. Nodes can start out being points on a grid, and can later be generated as part of the level design, so long as the interface stays the same.

  18. mos says:

    There’s a great programmer’s website dedicated to AI: AI GameDev. They’ve got a really interesting templated C++ AI library that you can gain access to if you just sign up to the site or forums or something (I joined the site a few years ago, and it’s gone through some changes since then).

    This is my absolute favorite article there.

  19. karrde says:


    About AI, group tactics, and human players interacting in groups…I’ve been told that the game “America’s Army” is designed to work this way.

    That is, each player is part of a team, and the team is supposed to work under the directions of a leader. I don’t know if any AI was used at all, or if the game is only a multiplayer/online type game.

    EDITED TO ADD: Wikipedia claims it is mostly about team-based tactics, and has been used for simulation for squad-based tactics by portions of the U.S. Army.


  20. Superkleinpaste says:

    Hey Shamus, Have you looked at the game Prototype? railroaded plot, repetitive missions and retarded overdone and expected “baddass” dialog aside, I am personally impressed with the AI.
    Like you said, when it works, you do not notice it.

    But the battle AI will regularly kill surprise me with sudden changes in tactics, ability to call in reinforcements, each unit detecting me, setting up a line of fire, and blasting my face with a rocket. They are also pretty good about running/changing tactics when they survive my first hit, using different weapons, and so forth.

    Just wondering if you perhaps have seen it.

    It’s also a pretty quick game if you ignore the extras.

  21. Kdansky says:

    Prototype has good AI? Everything just shoots at you and follows you around if you walk away. That’s about it. Sure, that qualifies as “does not screw up”, but on the other hand, everything they do is exceptionally bland and oftentimes very scipted.

    Great first article, I can only nod my head in agreement.

  22. Legal Tender says:

    Well, blast me!

    I do believe I’m about to get my question answered and no mistake.

    Seriously now, this sounds very interesting Shamus. Thank you.

    I’ve never had much to do with programming but I’m learning lots just by reading your posts and the comments to them. Whee, edumacation!

  23. Tacoma says:

    I think coding good AI requires that you code a decision-making process and a set of values that the AI entity holds. Things like
    “how much do I value my own life”,
    “how much do I need resource X right now”,
    “how much am I willing to travel from my home territory”.
    These will be intrinsic to each AI from creation and will change as it experiences things.

    Then you need it to remember environmental experiences like
    “how difficult is it to recover from minor injuries”,
    “how hard is it to find resource X”,
    “how often does that creature carry resource X”,
    “how dangerous do i know that creature to be to me”,
    “how many friends do I have nearby”,
    “how much do I trust each of those friends to help me against that creature”,
    “how much do I trust each of those friends to save me if I’m injured”,
    “how much do I trust each of those friends to share the prize with me fairly”

    Each of these will start at “unknown” possibly with a standard level of trust for those of the same group and mistrust for those of other groups, outright mistrust for those of other species.

    You don’t need to drag across a group and tell them they’re a group. Give them a group affiliation (You are a member of the Resistance) and their internal AI data will tell them how to behave around both Resistance members and Empire members.

    But of course the AI will have to make decisions on who is Empire and who is Resistance based on uniform and mannerisms. There would be obvious mistrust for non-uniformed folk, and the parameters for experience would be thrown out of whack if Empire members began posing as Resistance members to attack them. As it should.

    Point is, you need perhaps several thousand personal value fields for each AI, and sensory qualities that make several attempts at a task rather than automatically succeeding. If the AI hears gunfire, test whether he can identify the gunfire. Is it friendly? Is there more enemy fire than friendly? Are they using miniguns while the AI is equipped with only a pistol? What about all those other dynamic decision-making attributes like current health, risk aversion, other objectives, etc.

    So if the AI wants to advance, it needs to predict where the gundfire is coming from based on light flashes, impacts, and sound. I can look down a street in an FPS and hear gunfire down a side street, and know which side it came from. The computer should be able to figure the same out. When I look down the street I map out the places I cannot go (that is, the walls, light poles, etc.) and potential cover from the direction of the fire (bench, mailbox, stone wall). I look around and see if there’s any other ways to get to the gunfire, choosing the smaller and less-direct ways over wider and more-direct ways.

    The pathfinding doesn’t need invisible lines in the road and through all the buildings for the AI to chug along. It needs to view the environment, make decisions based on its internal values, choose a course of action, and decide based on the environment how it will accomplish that.

    Every few seconds it will need to re-evaluate, considering that if it decides to flee it will likely continue to flee, though moving forward may break into an escape. Every bullet it burns off, every wound it takes, every friend nearby who leaves, every enemy it kills, will influence whether it wants to stay in this battle. If it trusts its friends it will help them. If it hates its friends it will betray them.

    This would be horrible to code, but once it worked you wouldn’t need to code AI again except to keep up with people changing their prgramming languages. You’d have AI libraries that, due to their expense, would require that game programmers conform to them rather than the other way around.

    And I think it would be best to start with simpler AI, such as dinosaurs or something. Because adding in the human element, not to mention conversation, is a whole extra thing.

    Although a conversation AI could easily become a diplomatic AI, or a dating sim. Rather than the output being a choice to fight, sneak, flee, parley, etc. the output would be an attempt to convey meaning. If the meaning to be conveyed is “I don’t agree with that” then the AI would spew out the text it associates with such a meaning.

  24. Dev Null says:

    The 2D TronWorld approach sounds perfect for testing pathfinding and at least simpler forms of behavior / teamwork, but I’m not sure how well it works out for your other two categories: Detection and Targeting. And since the behavior has to depend on detection at least to a certain extent, you’ll have to model detection somehow in your TronWorld that almost certainly won’t map to how it works in the final game, just to have something to test with.

    Not saying its impossible, mind, just that its an additional hurdle to this approach. A minor one, probably. I imagine I’d just do something like hard-code a detection range and probabilty in TronWorld, then tweak the parameters and see how the AI copes with different values.

    1. WJS says:

      That’s pretty much what I though. Making an AI that dives for cover when you shoot at it is easy. Making one that can recognise what “cover” is, without requiring tedious and expensive population of marker nodes by your level designers (and what if they forget an area, or drop one in the open by accident?), that’s the real challenge. I don’t think it would work in the oversimplified world described. Using an older 3d engine like Q3 was suggested above, and that seems like a good idea to me; it’s fundamentally the same kind of world, so patterns you develop should translate to your actual game engine pretty well (assuming that lighting-based stealth isn’t prominent, heh-heh).

  25. Of course, we’re all making the assumption that the game developers actually CARE about the AI. In my experience, it’s usually the last task on the list.

    “Okay let’s get the graphics done. How are the levels coming along? Are the controls working? Who’s doing the music?”

    It’s only when they finally get to QA, do they start to ask about the AI. And by then, it’s usually too late to make any really effective changes.

    AI is tough to write, but it’s not harder than optimizing the physics of a 3D engine or anything like that. It’s simply not a priority and there is a budget/time limit.

  26. Deoxy says:

    That’s a pretty good concept, but it’s WAY WAY WAY overkill for most games, and it would burn amazing amounts of processor and data bandwidth for any large number of AI entities.

    For an FPS, there’s no need to worry about team-switching. Detection can be MUCH simpler than what you laid out. “trust” is largely a non-issue (unless being teamed up with human players, but that’s a larger issue as well). Etc.

    For games other than FPS, many of those things can be abstracted and/or predetermined because there’s no nearly as much “real-time” stuff going on.

    Now, if you want some kind of NPC AI for an RPG, well, some of what you’re talking about is relevant, but that’s a bigger effort than just making decent combatant AI, where many of the questions you asked are predetermined.

  27. Daemian Lucifer says:

    Its not true that good AI goes by unnoticed.Both F.E.A.R. soldiers and alyx vance got high praise exactly because they had such good AI.

  28. droid says:

    Brainworks is a Quake3 mod that makes the bots as smart as possible (though adjustable) yet smart in the same way that a human is smart. On the blog you can read about how it was built, but most of the effort is spent hiding information. For example, the bot gets a signal from the API that something has happened, and it has to check whether or not it should know it, etc.

  29. Dhauzimmer says:


    Re human ‘guiding AI’: In my misspent youth I used to play a game called Allegiance which was a team-based spaceflight “sim” with RTS aspects – on each team one player was designated “Commander” and spent most of the game looking over a stragetic map, placing bases from which the other players could launch in various spacecraft to attempt to destroy the enemy bases. It was definitely an interesting game to say the least.

    You’re absolutely right about pick-up games generally sucking. In the real world, most human players don’t give a four-letter-word about orders or instructions coming from some other guy on the other side of the internet. Everyone could pull up the strategic map themselves when not in-flight and make up their own mind as to where to go to and what to do. The end result was that the role of “commander” frequently devolved to just trying to make sure that your team had the right tools at the right time for the skills of the particular pilots you have, and hoping they’d organize themselves enough to be where they needed to be all at once. Any team that could get even remotely organized would stomp all over a pick-up game.

    Incidentally, there were a few AI-controlled craft that the commander directly ordered about – the mining craft collecting money, the constructor craft to build bases, etc. The AI on them was well-known for being phenomenally stupid – by not running when faced with too many enemies, by being spooked too easily in other circumstances, and requiring sphexish alignment with docking bays before getting under cover (allowing enemy craft to ram them out of position, forcing them to start docking alignment all over…).

  30. Blake says:

    “The pathfinding doesn't need invisible lines in the road and through all the buildings for the AI to chug along. It needs to view the environment, make decisions based on its internal values, choose a course of action, and decide based on the environment how it will accomplish that.”

    Trying to get an AI actor to view the environment would require either rendering the entire scene from that actors perspective and then trying to get it to understand what it sees (rendering would kill the frame rate dead and trying to get it to parse the scene would require supercomputer-like AI skills), or having them cast a heap of rays from their eyes to see which polygons they hit and try to internally build a map of what it sees (not quite as intense as the last option but ray casting is still very expensive and you wouldn’t be able to handle more than a few active actors in the entire game.

    Trying to make an actor discover the world around it is completely unfeasible as the processors aren’t strong enough to do that as well as render anything for the player and even if they were it’d take a year minimum to be able to get it to see anything reliable and then after that you’d still need to actually write the code to make it know what to do with its environment.

    “I think it's mostly laziness that they aren't done more often”
    I can assure you that is most certainly not the case. Most projects have people working on AI for its entire lifetime and in that year or so they only have time to focus on one or two extra things. Each ‘skill’ the AI has impacts on every other one they have and the amount of work required increases exponentially with each thing that is added.

    AI is one of the hardest things to code because it’s not so much about technical skill as it is design, time, creativity and each persons subjective view of what the AI should be doing.

    Having said all that, Shamus, so far your methodology seems spot on, I look forward to seeing what ideas you can come up with.

  31. This looks to be another incredibly interesting series, I can’t wait for the next post.

  32. Nick says:

    I never understood why “dumbing down” was a way to make AI easier, can’t you relate real human skills to the AI?

    eg. Weapons skill: elite soldiers fire in a random spot within a 1 degree arc, novice soldiers have a 3 degree arc. Movement: this one is kind of obvious, elite soldiers move faster over uneven/sloped terrain than novice soldiers. Cover: elites can crouch smaller and prefer bigger objects to hide behind.

    1. WJS says:

      I hate it when people occasionally trot out the bullshit “People say they want smarted AI, but they don’t really. They want AI they can beat.” Uh, like those are all that closely related? Ignoring the condescending “You don’t really know what you want”, it shouldn’t be at all hard to take a smart AI bot and make him beatable without turning him into the typical drooling idiot AI. I can think of a number of ways you can hobble him without making him “stupid”.

      Reflexes and aiming, for example. These already need to be turned way down to bring a computer on to the same level as a human, just turn them down a bit more. As well as short-term reflexes, there will also likely be times an AI has to make a decision a bit more complex than “the player just appeared in front of me, shoot them”, such as the player making a noise to distract them. Add a bit of hesitation there too, and you’re making your bot easier to outfox while simultaneously making it more realistic. (A human guard is much more likely to hesitate for a second or more than to immediately go barrelling off after a sound)

  33. Stringycustard says:

    I’m about to jump into the scary world of AI dev now. I’m coding up a game in Flash that will have a few enemies. It’s an custom-IKengine-driven platformer with dynamic shadows and a camera that works more like an FPS than a sidescroller. Before AI is even added it’s gonna be killing the CPU and Flash is horrendous at recursion (i.e. try not use it ever, unless you can spam it over a few frames, so pathfinding will be fun). I’m looking forward to it, though. Hopefully, even if there’s just one enemy at a time I’m hoping to make it semi-believable.

  34. Steve C says:

    @23 karrde: I used to play America’s Army years ago. That game has no AI. All the characters are player controlled.

    The reference to “simulated tactics” is having real people use tactics on a simulated battlefield, that’s all. There is tiny single player intro with NPCs in it, but they do not have any AI beyond “Did player shoot me while I was talking to him?”

    America’s Army’s only claim to fame is that it’s a free first person shooter based on the Unreal Engine.

  35. Teron says:

    @mos: That article is very interesting. However, if you wanted to implement a fields ased AI in a more complex RTS, such as age of empires you would need to implement many different fields, e.g. resource for harvesters, and have the reaction vary by the need for the resource, and have different fields for different types of units, for example long range units would gravitate towards the centre of groups of short ranged units as protection, and to implement that properly it would need to have a small repulsive field to make a space for it to be in the group, but attractive at longer ranges, and for attacks units would compare the number/ attractive strength of units nearby with the attractiveness of the enemy units to decide if the field would be used as repulsion because the enemy is too strong, but if they were near harvesters a base they would be attracted to that so they would stay to put up some defense… and that’s only scratching the surface.

    If what the article said was implemented in a complex RTS, an oversight AI would still be needed to form task forces and designate units with roles, such as harvester harasser, which would cause it to use the harvester attractiveness field. The oversight AI would also be used for deciding which units to build, and also balancing it against a human opponent, so it is not too effective.

    However, the building could probably be implemented by having separate fields that do not attenuate with distance for each unit type, to build countering units.

    Right, that’s far too much thinking for one day, and would be very hard to implement, especially with the oversight AI although the fields would hopefully make the oversight AI simpler.

    EDIT: spelling mistakes in my ramble

  36. UtopiaV1 says:

    This is truly interesting stuff, and as i’m studying games programming (third year now, yay!) this is useful feedback from the gaming community. If i get to do AI for a big budget game (unlikely though seeing as though my strong-point appears to be graphics work), can i have permission to steal… sorry, “borrow” your intellectual property?

    Also, tron legacy trailer looks fun!!! Who’s this joseph kosinski that’s directing it though? He’s come out of nowhere (except he did the live action trailers for Halo and Gears of War)… Still, he looks solid… better than micheal bay *spits*.

  37. Segev says:

    This is a bit of a tangent, but one of several things that crossed my mind. I work with Computational Intelligence (which is not really the same thing as AI, and probably would be a post in and of itself, but suffice it to say it focuses on learned behaviors for specific tasks), which isn’t always HELPFUL when discussing actual AI, but is always an interesting perspective (for me, at least) to view AI discussions from.

    One of the big complaints I often see with allied AIs is “they get in the way” or “they use my healing items too soon!” or “they don’t heal me enough!” The best approach I’ve heard of (and the results are still mixed) is letting the PC control at least %-chances of certain behaviors. “Use healing items on me when I am at X% of max health,” for instance, is a valid PC-controlled parameter for some AIs.

    There are a number of learning algorithms that can serve as classifiers, which are a way to approach behavior-selection. If you can codify certain behaviors or sub-behaviors as classes that can be selected in various combinations, a neural network or fuzzy logic system could be used to choose which are chosen at any point in time. Apply, then, a learning algorithm with a few weak fitness parameters based on what the developer thinks “good” results are, and a massive sledgehammer of a fitness parameter that is in the player’s hands.

    While it might be frustrating to have only a ham-handed way to communicate your displeasure with your NPC minions (er, sorry, “allies”), I think many players might find it somewhat cathartic: Have a “praise” and “scold” button, which the player may use at any time, which instantly feeds back to the AI being praised or scolded with a signal that adjusts the fitness of the action. If it’s one you want them to do more of, it says “good! Do more like that!” This will strengthen current behavior patterns. If it’s one you don’t want, it says “no! Bad AI! Stop that!” and it weakens current behavior patterns in favor of others.

    If nothing else, being able to press the “backhand” button every time an “ally” NPC does something freakishly stupid would be something a number of gamers would probably appreciate.

  38. Deoxy says:

    There are several things that well-done AIs have done for years that I mentioned. NOT doing those things decently is a bad AI.

    If there really is someone dedicated to AI for the whole project, and we get AIs like most that hit the market, it’s either laziness or incompetence. I was trying to be nice.

  39. froogger says:

    Interesting, but three (3) parentheses?! You the man! (really!)

  40. superkleinpaste says:

    @kdansky : dude. They can find me. They can usually hit me when i refrain from superhuman feats of flight and running. Sometimes they manage to call in reinforcements before I kill everyone. Mostly, I was just wondering if shamus had seen it.

    It is true that they tend to be pretty scripted, but for how many individual AI they can have running at once, with apparently no lag in gameplay or their strategy (no matter how scripted), I find it impressive.

    Also, in that game you are supposed to be a superhuman, entire military destroying, helicopter karate-kicking, tank-eating badass. the AI is good at playing the “oh crap shoot it before it’s my turn”. Honestly, pretty realistic – if a squad of the USMC was hit with that, they would compose themselves within seconds, shoot at me, and die. not much can beat a being like Alex Mercer when he isn’t asking to be shot over and over again. With rockets.

  41. Tacoma says:

    @Blake: (on processing requirements for rendering the world for every AI entity)

    You don’t need to render everything. The AI doesn’t care about textures, just the material type and where the object is. So you end up defining the game world in terms of objects and polygons and such for the AI, not actually rendering it with graphics.
    The AI would load the local world segment in stripped-down format, but then would reference its coordinates and direction of view to determine what it could see. So the AI effectively knows the whole world segment and everything in it, but acts only on what it should be able to see. It’s kind of like a top-down RPG player seeing the whole map but pretending he can’t see what’s on the other side of a building. As long as the AI acts only on what info it should have, we don’t care about all the info it actually has.

    This is just one way to go about it though, a way that an admittedly poor programmer thought up in a few minutes. I’m sure the smart folks who do this for a living can come up with something thirty times better at least.

    And, finally, at this point I don’t even want my graphics to be as good as they are now. I don’t WANT Crysis. I don’t want to see any bloom whatsoever, or pixel shading, or vertex shading. I want programmers and artists to eke out the absolute maximum they can out of 128mb video cards, then make the game bigger and wilder so it barely runs on a 1gb card. THAT to me would make a better game. We are gaining the ability to model some solid AI here, or create seamless load-screen-free worlds, or actually get some use out of voxels (I would love to see a voxel-based Dwarf Fortress MMORPG but we are many moon away from that one). Instead we waste time playing dress-up with polygons.

  42. sealgrave says:

    At some point in the last 11 years the formatting seems to have disappeared from this post.

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply

Your email address will not be published.