In preparation for the GDC AI Summit (and the inevitable stream of dinner conversations that will be associated with GDC), I have tried to catch up on playing some games and also getting current with papers and interviews. On the later point, Alex Champandard at AIGameDev keeps me hopping. It seems he is almost constantly interviewing industry people on the latest and greatest stuff that is happening in the game AI realm.
A few weeks back, he interviewed Damián Isla about blackboard architectures and knowledge representation. Seeing as I always learn something from Damián, I figured that interview needed to go to the top of the list. Here's some of my notes as I listen through the interview.
Make it Bigger
Damián's first point to Alex was that a major benefit of a blackboard architecture was scalability. That is, putting together a rule-based system that performs a single decision is simple... the hard part is when you have 10,000 of those rules going on at the same time.
In a similar vein, he said it was about shared computation. Many of the decisions that are made are used with the same information. Blackboards, to Damian, are an architectural feature that can decouple information gathering and storage from the decisions that are made with that information. If one part of a decision needs to know about a computed value regarding a target, that information could potentially be used by another portion of the decision engine entirely... even for a competing action. By calculating the requisite information once and storing it, the decision algorithms themselves can simply look up what they need.
This is similar to the approach that I espouse in my book. I don't directly say it, but in a way it is implied. With my approach of compartmentalizing tiers of calculations, many of the individual layers of information that needs to be processed are done so independently of the final decision. The information needs only be collected and tabulated one time, however. The various decision models can simply look up what they need. In a multi-agent system, different agents can use much of the same information as well. While distance to a target may be personal, the threat level of a target (based on weaponry, health, cover, etc.) may be the same for all the enemies. That threat level can be calculated once and saved for everyone to use.
Back to Damián...
He mentioned that at the Media Lab at MIT they used blackboards for many things like logging, testing, and debugging. That is something I haven't necessarily thought of. They also had observer systems running over a network. They shared parts of the blackboard info so that the fully running games were doing everything but thinking.
Alex reiterated that a blackboard is more of an architectural feature rather than a decision process. Damián confirmed that the history of blackboards involved planners but that we are now using them inside reactive systems as well.
Blackboards vs. Lots of Static Variables
At Alex's prompting, Damián suggested that the blackboard is far more dynamic than having just many billions of values specified in a character.h file. In fact, he likened it much more to having one unified interface to all of your game data beyond just that of the character in question.
Do all agents need their own unique blackboard?
I like the fact that Damián's initial answer was a refrain that I repeated throughout my book... "it totally depends on the game you're making." Unfortunately, that is a major stumbling block to answering any architectural or procedural question.
He went on to say something similar to what I mention above... that you have to mix them. There are some pieces of information that individuals track and others that are available to the group as a whole. Visibility of targets, for example, is individual. Goals for a squad, on the other hand, is something that can be shared and referenced.
Direct Query vs. Blackboard?
The most important point Damián made here had to do with "redundancy". If you have a situation that you can guarantee you only need something once, then accessing it directly from a behavior is fine. If multiple behaviors might use the same data, access it once and store it on the blackboard.
The answer to avoiding the redundancy issue was "abstraction". That's what a blackboard represents. It gives that intermediate layer of aggregation and storage. He actually referred to it as "sub-contracting" the information gathering out to the blackboard system. The difference is that the blackboard isn't simply passing on the request for information, it is actually storing the information as a data cache so that it doesn't need to be re-accessed.
One very important point that he made was that there was some intelligence to the blackboard in deciding how often to ask for updates from the world. This is a huge advantage in that the process of information gathering for decisions can be one of the major bottlenecks in the AI process. LOS checks, for example, are horribly time-consuming. If your system must ask for all the LOS checks and other information every time a BT is run (or multiple times in the same BT), there can be a significant drain on the system. However, if you are able to time-slice the information gathering in the background, the only thing the BT needs to do as access what is on the blackboard at that moment.
Incidentally, this is a wonderful way of implementing threading in your games. If your information gathering can continue on its own timeline and the behaviors need only grab the information that is current on the blackboard, those two processes can be on separate threads with only the occasional lock as the blackboard is being updated with new info.
This goes back to my interview with Alex about a year ago where he asked about the scalability of the techniques I write about in my book. My point was that you don't have to access all the information every time. By separating the two processes out with this abstraction layer as the hand-off point, it keeps the actual decision system from getting bogged down.
In order to also help facilitate this, Damián spoke of the way that the information gathering can be prioritized. Using LOS checks as his example, he talked about how the Halo engine would update LOS checks on active, armed, enemies every 2 or 3 frames, but update LOS checks on "interesting but not urgent" things like dead bodies every 50 frames. Sure, it is nice for the AI to react to coming around a corner and seeing the body, but we don't need to constantly check for it.
Compare this to a BT where a node "react to dead body" would be checked along with everything else or (with a different design) only after all combat has ceased and the BT falls through the combat nodes to the "react..." one. At that point, the BT is deciding how often to check simply by its design. In the blackboard architecture, the blackboard handles the updates on what the agent knows and the BT handles if and how it reacts to the information.
Chicken or Egg?
Damián talked about how the KR module and the decision module does, indeed, need to be built in concert since information and decisions are mutually dependent. However, he talked about how the iterative process is inherently a "needs-based" design. That is, he only would write the KR modules necessary to feed the decisions that you are going to be using the information for. This is, of course, iterative design at its very core (and how I have always preferred to work anyway). While you might first identify a decision that needs to be coded, you need to then put much of that on hold until you have put together all of the KR implementation that will feed the decision. If you then add future decision processes that use that same blackboard, more power to you. (None of this trumps the idea that you need to plan ahead so that you don't end up with a mish-mash of stuff.)
As mentioned before, what you put into the KR blackboard is very dependent on the game design. It goes beyond just what knowledge you are storing, however. Damián specifically mentioned that he tries to put as much "smarts" into the KR level as possible. This has the effect of lifting that burden from the decision process, of course.
Are There Exceptions?
Alex asked the question if there would be cases that a behavior engine (such as the BT) would directly access something in the game data rather than looking it up in the KR/blackboard level. Damián cautioned that while you could make the case for doing that occasionally, you would really have to have a good reason to do so. Alex's example was LOS checks which, unfortunately, is also the wrong time to step outside of the blackboard since LOS checks are such a bottleneck. Damián's emphasis was that these sorts of exceptions step outside the "smarts" of the KR system... in this case how the KR was spreading out the LOS checks to avoid spikes.
Another example was pathfinding. He said a developer might be tempted to write a behavior that kicks off its own pathfind routine. That's generally a bad idea for the same bottleneck reasons.
More than Information
I really liked Damián's exposition on one example of how Halo used more than simple LOS checks. He explained the concept of "visibility" as defined in Halo where the algorithm that fed the blackboard took into account ideas such as distance, the agent's perceptual abilities, the amount of fog in the space at any time. This was so much more than a LOS check. All the behaviors in the BT then could use "visibility" as a decision-making criteria. I haven't seen a copy of the Halo 3 BT, but I can imagine that there were many different nodes that used visibility as an input. It sure is nice to do all of this (including the expensive LOS checks) one time per n frames and simply store it for later use as needed. Again, this is very similar to what I espouse in my book and in utility-based reasoners in general.
Dividing up the KR
He described something interesting about how you could have a manager that assigns how many LOS checks each AI gets and then, once the AI knows how many it will get, the AI then prioritizes its potential uses and divvies them up according to its own needs. Rather than having one manager get requests of priorities from all the AIs at once, the first cut would be to simply give each of them a few (which could also involve some interesting prioritization) and then let them decide what to do with the ones they get. I thought that was a very novel way of doing things.
What Does it Look Like?
In response to a question about what does the blackboard data structure look like, Damián acknowledged that people think about blackboards in two different ways. One is just based on a place to scribble shared data of some sort. The other, more formal notion is based on the idea of key/value pairs. He prefers this method because you can do easy logging, etc. For more high-performance stuff (e.g. FPS) there really isn't much of a need for key/value pairs so there may be more efficient methods such as looking up the information in a struct.
He went on to point out that the size and speed trade-off is likely one of the more important considerations. If an agent at any one time may only care about 5-10 pieces of data, why set aside a whole 500-item struct in memory? Also, key/value pairs and hash tables can't necessarily be more expressive than a hard-coded struct. I would tend to agree with this. So much of what the data says is in what it is associated with (i.e. the other elements of the struct) and the code around it.
In Halo, they were on the hard-coded side of things because there wasn't too much data that they needed to store and access. In general, the KR of what you need to access will tend to stabilize long before the behavior.
He also explained the typical genesis of a new KR routine. Often, it happens though refactoring after you find yourself using a particular algorithm in many locations. If this happens, it can often be abstracted into the KR layer. This is the same thing I have found in my own work.
One caveat he added was extending key/value pairs with a confidence rating in case you wanted to do more probabilistic computations. You could iterate over the information, for example, and apply decay rates. Of course, you could also do that in a hard-coded struct. I was thinking this before he said it. To me, adding the manager to deal with the semantics of key/value/confidence sets might introduce more trouble than it is worth. Why not put together a vector of structs that process the same information? To me, this goes to a point of how you can divide your KR into smaller, specifically-functional chunks.
Intelligent Blackboards
An interesting question led to something that I feel more at home with. Someone asked about blackboards collecting the info, processing some info, and writing that info back to the blackboard to be read by the agent and/or other blackboard processors. Damián agreed that a modular system where multiple small reasoners could certainly be touching the same data store... not only from a read standpoint, but a write one as well. This is very intuitive to me and, in a way, is some of the things that I am doing in Airline Traffic Manager (sorry, no details at this time).
Damián confessed that his search demo from the 2009 AI Summit did exactly this. The process that updated the occupancy map was a module hanging off the blackboard. The blackboard itself was solely concerned with grabbing the data of what was seen and unseen. The reasoner processed this data and wrote it back to the blackboard in the form of the probabilistic mapping on those areas. The agent, of course, looked at that mapping and selected it's next search location accordingly. (BTW, influence mapping of all kinds is a great use for this method of updating information.)
Meta-Representation
Damián summed up that the overall goal of the blackboard (and, in my opinion KR in general) is that of "meta-representation". Not that data exists but what that data really means. What it means is entirely dependent on context. The blackboard simply stores these representations in a contextually significant way so that they can be accessed by agents and tools that need to use and respond to that information.
What This Means to Me
I really find this approach important - and am startled that I started using many of these concepts on my own without knowing what they were. One of the reasons that I very much support this work, however, is because it is key to something that I have unwittingly become a part of.
Utility-based architectures describe a whole decision making system that chooses actions based on individual floating-point numbers that indicate value. (At least that's as close to an official definition I can come up with.) Utility in itself isn't new, and you'll no doubt remember using it as a voting or scoring system for specific problems like threat selection, target selection, etc. What's new in 2009 for is:
1. There's now an agreed-upon name for this architecture: utility-based, which is much more reflective of how it works. Previous names, such as "Goal-Based Architectures" that Kevin Dill used were particularly overloaded already.
2. A group of developers advocate building entire architectures around utility, and not only sprinkling these old-school scoring-systems around your AI as you need them.
The second point is probably the most controversial. That said, there are entire middleware engines, such as motivational graphs which have been effective in military training programs, and Spir.Ops' drive-based engine applied in other virtual simulations. The discussion about applicability to games is worth another article in itself, and the debate will certainly continue into 2010!
It's obvious to many people that I am one of the members of that "group of developers" who "advocate building entire architectures around utility". After all, my book dealt significantly with utility modeling. I am also playing the role of the "utility zealot" in a panel at the 2010 GDC AI Summit specifically geared toward helping people decide what architecture is the best for any given job.
While utility modeling has been often used as a way of helping to sculpt and prioritize decisions in other architectures such as FSMs, BTs, or the edge weights in planners, many people (like Alex) are skeptical of building entire reasoner-based architectures out of them. What Damian explained in this interview is a major part of this solution. Much of the utility-based processing can be done in the KR/blackboard level -- even through mutli-threading -- to lighten the load on the decision structure. As more of the reasoning gets moved into the KR by simply prepping the numbers (such as how "visibility" represented a combination of factors), less has to happen as part of the decision structure itself.
Kevin Dill and I will be speaking more about this in our lecture at the AI Summit, Improving AI Decision Modeling Through Utility Theory. I hope to be writing more about it in the future as well. After all, according to Alex, it is one of the emerging trends of 2010!
Back on April 5th, Alex Champandard of AIGameDev interviewed me for about 90 minutes for the Members portion of his site. Our topic was how to use behavioral mathematics (such as I cover in my book) to improve the bots in Left 4 Dead. We cover a lot of interesting information in the interview. Some of the examples refer to things I covered in my Post-Play'em columns on the AI in the game.
He has it posted in audio and video formats (although with me rocking back and forth in my office chair, I look like I'm autistic!). I seriously advise that you check it out. (You will need to have access to the members area to view it.) If you are already a member of AIGameDev, you can find the interview here:
For that thin slice of the industry that may visit this blog that doesn't already know about AIGameDev's new members area, you are definately going to want to jump over there and check out what's going on. Alex Chapandard's pad has been the best place for game AI info over the past year and now he is really stepping it up a notch. As of today, he has started a new members area that will not only have a lot of papers and other research material, he has been lining up a lot of live interviews and workshops with industry experts. Those are conducted online with audio, video and an interactive whiteboard. The few that he has conducted for free so far have been informative. Here's the schedule of what's going on for this fall.
Go check out what's going on over there at the members area launch page. And tell 'em Dave Mark sent you!
Batman and Robin make an appearance in my Developer Discussion column at AIGameDev.com this week. In The Art of AI Sidekicks:Making Sure Robin Doesn’t Suck, I touch on the recent shift towards providing consistent, engaging sidekicks for the player. Certainly there are unique challenges in an AI agent that is so ever-present. To lift a segment from the column:
If we are going to have an AI that's tagging along behind us for hours on end, wouldn't it be better for us to love him/her/it? Let's face it, if you are playing 10 or 20 hours of game content, any form of repetitive AI may have you digging through the manual for scouring cheat codes online in order to find the "slap your sidekick upside the head" control. You can't simply get away with seven seconds... or even 5 minutes of believable behavior. Beyond that, the sidekick needs to be more than just something you are entertained and amused by. You need to be able to depend on it... as if it were your lifelong partner.
The ensuing discussion spurred many great comments. Take a gander at it and chime in with your opinion (or a solution?).
AIGameDev Column: Improving Development Methodology
Another installment of my Developer Discussion column at AIGameDev.com. In Can Beavis and Butthead Improve Your Game Development Methodology, I reminisce a little about the radio call-in show "Rockline". Many of the callers asked the bands how they approached writing their songs... lyrics or music first? I turn that question into one to ask of game developers... and specifically game AI programmers. How do we write our code? Bottom up or top down? Somewhere in between? Read the whole column to see how it all played out.
Yet another entry in my weekly Developer Discussion column at AIGameDev.com. In The Little-Used Tools of Game AI, I continue an informal poll from the 2008 GDC AI Roundtables. We were all asked what types of technologies and algorithms we were using in commercial games.
I used a metaphor of a Swiss Army Knife... lots of cool tools that mostly go unused. Here's a blurb from the intro.
Looking through web sites, books, and the various conferences such as GDC and AIIDE, there is an endless parade of esoteric, seemingly mystical techniques. As perpetual students in our rapidly-changing art, we read and attend with a reverent demeanor of an exploratory scientist. We soak up all the knowledge and ponder the applications and implications. We engage in heady, philosophical discussions with our peers. We exclaim our exuberance and proclaim our allegiance to new methodologies. And then, upon returning home to our individual, pragmatic realities. We resign ourselves to the relatively bland, yet utilitarian knife and screwdriver: Finite State Machines and Pathfinding.
And what of the other tools in the Swiss Army Knife of game AI? What about the planning and fuzzy logic? The lofty towers of neural networks and genetic algorithms? Game theory and reasoning under uncertainty? Influence maps? Minimax plays a killer game of Tic Tac Toe, right? Flocking? We've all seen articles on flocking! Not being used? Wow... there sure are a lot of tools in this knife. We can all see places where they may come in handy. Granted, some of them may be like trying to cut firewood with a 2-inch saw - but aren't some of them truly useful? So why don't we use them in the real world of creating our pretend worlds rather than simply pretending we are going to use them in the real world?
Jump on over to AIGameDev and read the full column. And, since it is a developer discussion column, please take a moment to continue the poll and post a comment.
Alex Champandard, at AIGameDev has posted a nice video analysis detailing some of the complicating issues surrounding the inclusion of destructible cover in an FPS game. He uses video from a recent trailer from the upcoming Brothers in Arms 2. As always, Alex details things rather well. He offers an off-the-cuff solution without getting terribly technical. I can understand why he can't "solve" the problem... it is usually something that is very game and engine specific. Regardless, it shows the issue itself very well.
This reminds me of a conversation that was had at the AI Game Programmers Dinner at the 2008 GDC. There was a brief exchange where we were talking about points of visibility in the games that were represented in the room. Many games tend to use around 6 points... a rectangle representing shoulders and perhaps thighs, one for the center of the body and one for the head. Others may add a few more here or there. I asked Christian Gyrling (Naughty Dog) how many they used in "Uncharted: Drake's Fortune"... his answer? 20. That's a LOT of ray casts. Admittedly, this was 20 points on the player's body to determine if the enemy AIs could see him. However, the result is the same... 20 potential raycasts for each active enemy NPC. Ouch. (Welcome to the PS3, I suppose.)
I would like to think that specialized graphics hardware and simply more processing power will make this approach more cost-effective in the near future.
Is this something that needs to be explored better, however? And what are some potential solutions to find things that are not there, make sure that behaviors fall within parameters, or look reasonable? And most importantly, how do we make sure that we have explored all the dark nooks and crannies of the potential state space at the far reaches of that combinatorial explosion to make sure that our delicate cosmic balance doesn't get sucked into an algorithmic black hole?
In my article from this last week, I touched on the furor surrounding the $100-million behemoth that is GTA 4... and how, even with that massive budget, one of the bigger gripes about the game is the AI.
Sandbox games - or at least free-roaming RPGs - are becoming more and more prevalent of late. With the likes of the GTA series, Assassin's Creed, the Fables, or Saint's Row, the latest cool thing to do is develop a massive open world where the plot is almost reduced to a mild suggestion. But, there are recurrent themes of developmental difficulty in those projects.
Is it possible for us to do a reasonable job on the AI of "sandbox"-style games? If so, how do we go about it?
Please read the full articles and comment over there... there are already some discussions surrounding my typically controversial topics.
AIGameDev Column: Why Not More Simulation in Game AI?
Time again for my weekly Developer Discussion column at AIGameDev.com. This issue is based off of some observations I made at the 2008 GDC. I was curious about how many AI programmers didn't know each others sub-field of AI. Sure, the field is getting bigger and therefore more specialization is needed in things such as animation AI, etc. However, I was concerned about how many people would say something to the effect of "I don't do simulations."
Why aren't people more interested in using "simulation" techniques in the AI of individual characters? It seems to me that the concepts that make up - or at least underlie - simulation would be the spells that we could all cast. Everything we as AI programmers do should be based on the idea of simulating something.
This time, I invoke Chris Hecker and his speculation on whether or not we will find "the Photoshop of AI". To quote from the column:
In his lecture entitled Structure vs. Style, he pointed out that the cusp in graphics presentation technology was when the atomic building block was settled on - that of the the texture-mapped triangle. [However], there is a major component of the game experience that hasn't yet found the spark for it's Big Bang of development such as the one that occurred in the graphics universe. Game AI has yet to find that "one thing" that their world can be reduced to. And, as such, there can be no "Photoshop for AI", as Chris put it. Yet.
If you are an AI developer or even just interested in game AI, please wander over and read the whole column... and then weigh in on the subject. What is that single core component that we need in order for AI to make the leap to the next level? Does it even exist?
Ted Vessenes wrote a nifty little post on his blog where he compared designing and programming AI to being a parent. Here's the opening paragraph:
"Writing artificial intelligence is a lot like being a parent. It requires an unbelievable amount of work. There are utterly frustrating times where your children (or bots) do completely stupid things and you just can't figure out what they were thinking. And there are other times they act brilliantly, and all the effort feels satisfying and well spent."
I have to agree with a lot of the points he makes in his post. I would like to take the analogy one step farther.
I've occasionally made the point about both parenting and AI that your job is to not define what your progeny should do but convey an understanding of why. If, as a parent, you tell your child not to run in the street, they will hopefully carry that lesson into the future. However, they may not apply that same edict to driveways, parking lots or any other places where they could get plowed over by a car. This is analogous to the scripted AI methodology. However, if you explain the why of the situation - i.e. "be careful anywhere that cars are moving because the driver may not see you in time to stop and you could get badly hurt" - then the simple rule can be applied to any situation where there are cars (or even car-like objects). This, of course, maps over to rule-based systems or even planning systems.
However, going back to Ted's point, it is an interesting similarity to put all those rules into place and hope that your little bots realize the appropriate situations in which to use them. I actually wrote a column about this scary process on my weekly column over at AIGameDev.
Anyway, if you are an AI developer, I hope that you are blessed with many children who all grow up to be accomplished in their chosen lives (or deaths).
This time, I touch on the concept of Chaos Theory and how the AI buzzword of emergent behavior is actually cut from the same cloth. They are both entirely deterministic in that they are composed of a finite set of distinct rules - and yet their strength (and weakness) is in that they look complex... even to the point of looking random at times.
But is this good or bad? To pull a brief quote from the column:
So our agent-based models are really an implementation of Chaos Theory. That is, they are both complex systems that result entirely deterministically from relatively simple models. However, as Jurassic Park so elegantly portrayed for us, even deterministic models can spin wildly out of control. There are plenty of examples of very simple systems whose results can vary widely - almost looking “broken†simply because of the interaction of those simple rules.
And that is the rub. That is the beast that waits below the surface to reach up and wrap it’s combinatorial tentacles around our placid simulation and drag it down into the abyss of scathing reviews. And we never know if and when it will strike. Perhaps the name “Chaos Theoryâ€, although not an appropriate term for describing the system itself, was an appropriate one after all for describing the potential results of that system.
Read the whole column over at AIGameDev.com. And please, these are discussion columns. If you have a comment, by all means leave it!
The title of this column, "Does This Mistake Make Your AI Look Smarter?", is a tongue in cheek way of pointing out that there are questions about our AI that are really difficult for us to answer honestly. Skipping over the amusing analogy at the beginning of the column, this is what the crux of it is:
...since the inception of game AI, we have been trying to have our agents make better decisions, not worse ones. We have been trying to eliminate stupid behaviors, not encourage them. We have been striving for more realism, not less… but wait a minute... Isn't this where we might be lying to ourselves? And do we really want to hear the answer if it means we have been wrong all along?
In this week's column, "Thinking Beyond Single Frame Decisions", I wanted to provoke some thought about why it is that AI programmers have often painted themselves in the corner mentality that AI decisions need to be made in a single frame - 20ms or so - even if we have to cut corners on accuracy or depth in order to do so.
As AI programmers, we are forced (or force ourselves) up against the invisible wall of framerates. Our agents must live their lives in 20 millisecond slices -perceiving, pondering, planning and performing must all be arranged in little easily-digestible bites. What's more, they share their cramped temporal quarters with dozens, scores, or even hundreds of other cohorts - all clamoring for the leftovers that the art department has discarded... and all working under the same 20ms edict. If you can't decide what to do in 20ms, it isn't worth doing.
If you can spare the clock cycles, head on over to Alex Champandard's excellent community, AIGameDev.com. Remember to tap the RSS feed to the discussion column and his many other blog feeds! While you are there, spawn another helper thread and jump into the AI forums as well. (Forum registration is required but is quick and painless. If you are an AI programmer, you've dealt with more traumatic experiences than that!)
I have to admit, I am really enjoying writing for Alex and his site. I'm honored that he asked me to be a part of his team.
If you haven't already done so, make sure you subscribe to IA on AI to keep up with the latest news and notes on game AI!
Is it possible for an AI to be both "good" and "fun"?
Take the time to jump on over and read it... and then comment either here or in the excellent AI forums there. (Forum registration may be required to comment... but then if you are an AI programmer, you need to be involved over there anyway!)
AIGameDev.com has a great, in-depth interview with Dmitriy Iassenev, the AI mastermind for S.T.A.L.K.E.R. The game has a very extensive A-life system that lends a lot of depth to the game. In Dmitriy's words:
The gist of the A-life is that the characters in the game live their own lives and exist all the time, not only when they are in the player’s field of view. It eventually runs counter to the customary optimization processes used in games development (why perform operations invisible to the player?). Thus, such a scheme is reasonable to be used only when you know exactly what you want to have in the end. We had the game designers’ requirements to have the characters that could not only live inside a certain level, but move between the levels, memorizing the information they obtained during their existence. Consequently, we have decided that each character should come with only one logical essence regardless of the level he is at; whereas we could try to implement that with various tricks involved.
Read more of this very detailed interview over at AIGameDev.com - the place for the killer AI stuff on killer games!
Just in time for the Super Bowl, here's an interesting analysis on AIGameDev. It covers some of the very unique challenges that are endemic to the AI of football and even sports games in general.
One very interesting link from that article is a pdf file walking through the evolution of the AI in the Madden series since it started in (get this) 1986. That does point to an advantage that the Madden franchise has in its development... they get to iterate every single year. That means they can build upon their past code, get feedback from a massive user base, and tweak to their hearts content. I very much recommend reading through the document.
Another gem from over at what is rapidly becoming our sister-site, AIGameDev.com - this is the result of a discussion that started a few weeks amongst the site regulars.
Of the top 5, I'm the most excited about an increase in sandbox games and emergent behaviors. Really, I see these two as almost interlinked. Sandbox games not only allow emergent behavior to proliferate - they almost require it to do so in order to keep immersion.
Likewise, interagent cooperation was another of the top 5 on the list. Again, this is something that I see as related to emergent behavior. If you leave your cooperation loosely defined rather than pre-scripted, you will see a lot of emergent behavior as a result.
I hope to get more a feel about this very topic at the GDC roundtables and lectures next month. That is always a great way to take the pulse of the industry. Anyway, good stuff on the list.
I hate glomming on to a blog chain, but I'm going to link to AIGameDev's article on an article (which may very well be about an article.) The title is Watching Level Designers Use Scripts to Disable Your Autonomous AI: Priceless - which just about covers it. Alex does a nice job of not just reporting on it, but explaining the mindset and even the things to watch out for.
Regular readers of my other blog, Post-Play'em will know that I talked about the idea of scripts over-riding AI behaviors in Call of Duty 2 in a post entitled Call of Duty 2: Omniscience and Invulnerability. Specifically, this was in reference to one of the behaviors mentioned in the other article where an AI agent takes on a temporary god-like quality of invulnerability until such time as he finishes a scripted event - at which time he is no longer important to the level designer's wishes and is cast back into the pot of cannon fodder so that I can mow him down properly.
Getting back to the initial topic, my thought is that part of the issue between artists/level designers and programmers may very well be that the level designers don't have a trust in the capabilities of autonomous AI agents... or even and understanding of what could be done with them.
For example, with the use of goal-based agents such as those found in F.E.A.R. (related post), rather than a designer saying "I want the bot to do A then B, then C on his way to doing the final action of D." he could simply tell the goal-based agent that "D is a damn good goal to accomplish." If constructed properly, the agent would then realize that a perfectly viable way of accomplishing D would be via A-B-C-D. The difference between these two methods is important. If C is no longer a viable (or intelligent looking) option, then the scripted bot either gets stuck or looks very dumb in still trying to accomplish D through that pre-defined path. The very nature of planning agents, however, would allow the agent to try to find other ways of satisfying D. If one exists, he will find it. If not, perhaps another goal will suffice.
The problem is, while AI programmers understand this concept (especially if you are the one who wrote the planner for that game), level designers and particularly artists, may not have an intuitive grasp on this. They are cut more from the cloth of writers - "and then this happened, and then this, and then it was really cool when I wrote this next thing because I wanted the agent to look smart, and then this..." That is being a writer - and is why many games continue to be largely linear in nature. You are being pulled through an experience on a string of scripted events. (See related post on Doom 3's scripting vs. AI)
So, can the problem of designers trumping AI programmers be solved? It will always be there to some extent. But education and communication will certainly help the matter.
Alex at AIGameDev has a great essay up entitled "Memento, Temporal Coherence and Debugging Planners". In it, he talks about how planning algorithms have the problem of having their assumptions about the world fall quickly out of scope as the world changes. One solution is to continually replan from scratch - which can become quite expensive to do for numerous agents.
He offers a couple of solutions - and the comments on the post have turned into a rather interesting discussion on the caveats and possibilities. Check it out!
OK... I'm liking where these guys are going with this. This is a description of some of the natural behaviors that are being used in the upcoming game, "Warhound". I admit I haven't heard about this game until now, but I'm definitely impressed with what I see here. They don't talk about the AI design/programming techniques that they use (and I don't blame them), but they mention some of the resultant behaviors.
Make sure you click on the video link. It will show you how the AI uses the cover of a large crate to attack the player in a variety of ways.
Thanks to Alex Champandard at AIGameDev for the link.
Movement in a dynamic world - especially with hostile entities and constantly changing safe and danger zones - is a dicey issue in game AI. AIGameDev.com has posted a great article about some work by Leslie Ikemoto from the University of Berkeley that I believe has some great future relevance to the game industry.
Although it is 153 MB, make sure you download the video file that shows the agents in motion. Great stuff!
Once again, Alex Champandard at AIGameDev.com has posted another entry in his Reviews section. This review is on the very novel and groundbreaking AI of the FPS game, F.E.A.R.
As he typically does in his technical reviews, he specifically identifies 29 tricks to use in games. As with "The Sims", a major component is that of "smart objects". Also, how the AI agents in the game use those objects is very impressive. I've only played the downloadable demo of F.E.A.R. but I was impressed quickly by how the agents appeared to work together and with their environment. I would like to play the game further and then re-read this technical review.
As always, make a point of looking at the references section of his post. That is where the meat is.
Alex Champandard over at AIGameDev.com has posted a technical review of the AI for "The Sims". This is a fantastic article listing 21 tricks that can be used, at least in theory, in game AI development.
Please notice that Alex has put references at the end that point you to the source material - which is always good reading.
Although it is 153 MB, make sure you download the video file that shows the agents in motion. Great stuff!
