We finally got the slides for my GDC talk up on-line in a format other than the ultra-elitist powerpoint 2007:
http://www.bungie.net/images/Inside/publications/presentations/betterbattle.zip
That ZIP file contains a .ppt and .pdf, so take your pick. Unfortunately you get EITHER the correct fonts (pdf) or the correct animations (.ppt) but not both!
In the meantime, I thought I would take this opportunity to give a little more background on the development of the Objectives System.
First of all, the story of Objectives really begins back at GDC 2005, when a couple members of the Bungie design team saw my talk on (among other things) Behavior Trees. Shortly after we had gotten back to Seattle, we started discussing what the replacement for Halo 2 “Orders” (the FSM-based “Imperative” approach described in the talk) would be. I believe the first person to explicitly suggest an adaptation of the Behavior Tree structure was Jaime Griesemer (he tends to be the forgotten half of the classic “Illusion of Intelligence” presentation at GDC 2002 – everyone remembers the Chris Butcher half, but the presentation was by Butcher AND Griesemer!) – he argued that tasks could be decomposed and sequenced in much the same way that behaviors were, and furthermore the tree structure seemed an intuitive representation to him. As no one had any objections, we went ahead with some UI mock-ups, and soon after that, some prototypes (including the “3 Generators” encounter described in the paper, though it unfortunately never made it into the final game).
Let’s be clear about one thing: I didn’t think it would work. Or to be more specific, it was clear that it could be MADE to work from an algorithmic point of view, I just thought the interface as a whole was going to be too complicated for designers to work with. I didn’t think they’d find it an intuitive way to break down the narrative of an encounter, nor did I think it would be particularly easy to inspect what was going on and diagnose problems. Finally, I never thought they would be willing to “abdicate their decision-making authority,” a process that the system more or less demands.
Thankfully I was wrong, and I guess I mention it in order to try to convince you, in case you’re thinking “no way, my designers would never go for that”, that I said the same thing, and maybe your designers WOULD go for it. Granted, that one of the advantages we have at Bungie is a design team that is VERY technically-oriented (we count ex-mechanical engineers and ex-aeronautical engineers among them. Jaime himself is an ex-physicist). Nonetheless, if your designers can learn a scripting language like Lua or Python, they can certainly learn to efficiently use Objectives.
Why DID Objectives work? Certainly some of it comes down to common sense production stuff: we aggressively front-loaded the system schedule-wise, and we invested some real time in the development and refinement of the UI (if you can believe it, the “Orders” system of Halo 2 had NO dedicated UI work done on it – this system was built on top of our generic “tags” interface, akin to a glorified XML viewer). The fact that the system and UI came on-line so early meant we had LOTS of time for iteration, for training designers, and for developing encounters from prototype to ship.
I happen to think that there’s more to it than that. An interface paradigm is generally not going to be very good unless it matches to some degree or another the mental representations inside the user’s brain, so if the designers in the end found the Objectives system useful, it may be because the system matches to some extent the way they already think about structuring coordinated action like a battle. I think, again, you can contrast it with the UNstructured FSM (“imperative”) approach, which is a headache and a mental hurdle once you get above a certain complexity – the lack of structure very quickly starts to work against you.
And certainly, the encounters built by the various designers on our team LOOKED different, Objectively speaking (heh heh). Some of the designers, like Paul Bertone, who built the space in the video shown at the talk, tend to script the AI rather tightly, while others use Objectives as looser guidelines for how the AI should move about a space. Once again, I think it speaks to the expressivity of the system that it allowed various users to adopt their own very different individual styles.
Most of all, I think Objectives are a reasonably elegant example of “transparent decision-making.” The technique is very simple, and yet it is quite expressive AND it never takes more than a few seconds of inspection to answer the question “why are my guys doing THAT?” That’s going to have to be true of ANY AI system which you put into the hands of your designers.
Posted by naimad at March 3, 2008 08:15 PMThanks, Damian! That was a great read; there's a lot to learn from this. I'll post more thoughts here later.
Posted by: Paul Tozour at March 4, 2008 09:32 AMGreat insights Damian.
I am, however, surprised to hear you thought it wouldn't work out... Especially since your designers already had the experience with the behavior trees, and Facade showed that you could use similar BTs for things that are more "narrative" than the typical FPS monster.
Funnily enough, your talk went completely under my radar until it actually happened. Although, coincidentally, I've been discussing the process of applying planners (and other forms of non-scripted AI) to level design every chance I get :) The topic came up at the AI Panel at the GDC in France late last year too...
Anyway, nice work!
alexjc
AiGameDev.com
Ha ha. Good observations, Alex.
First of all, the designers that typically have dealt with behavior trees in the past have been our gameplay designers, not the mission designers, a different group of people with different tools. So the gameplay designers’ familiarity with behavior trees could not be leveraged for Objectives.
Even so, authoring the structure of the tree is not really considered one of the day-to-day activities of a gameplay designer. Yes, they will do some initial character set-up (and usually different characters will share a vast amount of common structure), but the vast majority of their time is spent in tuning the behavior parameters that control the behavior tree (e.g. at what damage_threshold does the cover_on_damage impulse activate?) The notion of crafting a completely new Objective hierarchy for every single encounter was a novel one to us – we’ve never explored tree structure as the designers’ PRIMARY means of expression, if that makes sense.
And once again, behavior trees have never been about crafting narrative. Behavior trees’ REAL job – to provide a set of priorities on what to do in all situations – seems in some ways diametrically opposed to their use in the Objectives system, where an experience is meant to play itself out after a while – stated otherwise, one has an “end” to it, and the other doesn’t. It was not clear to me that a structure designed for the one could (or should!) be adapted for the other. That’s why I didn’t think it would work!
I might be mistaken, but didn’t the “narrative” part in Façade come from the sequencing of the dramatic beats, a planning approach? Or did they use some kind of behavior tree to impart sequence as well?
this is awesome stuff. It's definitely the next logical step, to move beyond AI control of individuals and even squads, and onto AI control of entire scenarios (battles).
Re-iterating Alex's comments, I definitely see some crossover between this approach, and some of the "drama management" stuff in academia. I think you are correct, Damian, that Facade uses a planner of some kind, but there are a number of similar projects with various mechanisms of narrative control. It's only a matter of time before we're having the same debates about scenarios that we currently have about characters -- behavior trees vs planners vs FSMs, etc. And the "best" is most likely a hybrid of two or more approaches, or maybe the best depends on the focus and gameplay style of the particular game.
I had a thought while looking over your slides. These days one of my interests is in semi-automated authoring of AI, based on gameplay data. When I read the WIRED article about Halo3's playlab and metrics, I was drooling over your tools and infrastructure for capturing gameplay data. I wonder if these systems could be leveraged in any way to capture patterns of gameplay in co-op games, and generate fragments of behavior trees that might be useful to designers. A little crazy, but fun to ponder.
Jeff
One word that keeps coming up in this thread and others like it, regardless of the problem space or technology being discussed, is "hybrid". I have to wonder if, when we are either exploring or trying to perfect an approach, we tend to get a little monolithic (sorry Jeff, truly that isn't a pun) in our thinking. That is, we might subconsciously be trying to "solve" the problem with this one new magic bullet - whatever it may be.
One easy example of this was the rise of A* as a pathfinder in games. While it was great at what it did, people then started noticing that it was a) tied to the grid, and b) kinda silly looking in dynamic environments. Solution to the problems were numerous - one common one being "make more nodes!". However, it wasn't until we got out of our A* evangelism and said "maybe reactive steering is still good for something" that we decided that the best (and most "human") solution was to glue them together. (I include hierarchical pathfinding in this as well).
The same can be said for all the main technologies: FSMs, FuSMs, BTs, GOAP, RBS, etc. They each have their uses, sure, but for the most part, none of them is the magic bullet that will solve all issues. What's more, those uses may overlap. A particular problem space may actually REQUIRE you to use a hybrid system.
What if the transition weights for your entire planner or BT were determined by a finite state that you happened to be in at any one time? Or the result of your planner put you into a particular finite state for the moment and that state determined the thresholds for your FuSM on a related problem? I'm combining things willy-nilly here, but I could easily craft hypothetical scenarios where these sorts of things may occur.
Even something as simple as the balance between autonomous agents and scripting is something that is, by definition, a hybrid.
I guess my point is, while it's good to explore a particular technology or method, we shouldn't exclude other "lesser methods" in the process. We may not be replacing things... we may be extending them.
Posted by: Dave Mark at March 6, 2008 10:29 AMAs I remember, there's definitely some centralized logic for keeping the "beat" of the narrative in Facade. But I can't remember it being anything close to a planner. Probably just a scripted sequence or something...
Speaking of generating behavior trees, there are a couple of papers about learning HTN plans. It's fascinating stuff, but there's not so much being done in this area. I'll see if I can dig them up and post them in the forums...
alexjc
AiGameDev.com
I find the presentation fascinating, especially for the fact that the designers enjoyed working with a system like that
I am surprised though, that it's taken us so long to start using this technology in FPS games. In the RTS world, this is essentially one of the first problems you have to solve, if not for the single player campaign (which often exhibits the same degree of designer control as other game genres), for the multiplayer computer opponents.
Once the AI has decided strategically what objectives it wants to accomplish, it then uses a resource distribution system that works pretty much like what Damian described. I'm sure the guys working on Halo Wars are doing this already :-)
It's interesting that we're seeing some technologies cross the genre barrier. I am just wondering when the Halo enemies are going to use influence mapping to recognize their "fallback" and "last-stand" positions... :-)
Posted by: Sergio at March 6, 2008 09:35 PMThere have been a lot of ways that the lines have been blurring between RTS, FPS, and RPG. I actually welcome the addition of this sort of thing in the FPS and RPG genre.
As for using the "Objectives" system in an RTS, it should be fairly simple. One advantage of an FPS is that you don't have to deal with random maps like you normally do in an RTS. Therefore, you don't have to do the dynamic influence map processing to determine fallback and last stand positions that are being tagged manually by designers in an FPS (like they did in Halo 3). You could still use Halo 3's model in an RTS-like environment, but you would have to build a toolkit to not only flag the rally points, but also create (or at least modify) rulesets for when to fall back to those points. In fact, I would actually like to see an RTS that did a better job of collapsing their defense when necessary. (e.g. castle defenses with multiple walls, etc.) Definately something to ponder.
Posted by: Dave Mark at March 6, 2008 09:53 PMThat's interesting Sergio -- do you have any references for this kind of technique in an RTS? I can definitely see that some sort of distribution of units/squads across available tasks would be necessary, but that the task structure should be designer-defined seems ... unintuitive, given the likely vast and unpredictable decision-space of an RTS! Again, I don't think the distribution algorithm itself is what is interesting here, I think what is interesting is that it was turned into a designer tool, and the designers were invited into the decision-process.
Jeff: oof! Learning trees ... that sounds like a fun idea -- I just have no idea how to do it! :)
We have done some thinking about how to leverage all the playtest data that we're getting back from those guys at the MGS labs, cause you're right, that's a tremendous amount of really high-quality data! And I agree with your implied approach, of doing some amount of learning/analysis offline, rather than trying to ship adaptive enemies in the game itself -- at least it seems like a good first step. I think the most interesting thing to cull from that data initially, though, is going to be player-behavior information. If we could learn a couple of encounter-specific player-strategies and then train up (and ship) a classifier of those strategies, I bet the designers could make some really cool encounters where the AI seem to react to a higher level of player intentionality than we've seen before ("the player is sniping us from the ridge" as opposed to "the playing standing at point x,y,z, and shooting").
That, however, is probably a subject for a different thread!
Posted by: naimad at March 8, 2008 02:35 PMNo, I don't have any particular references, sorry. I used that particular technique for the RTS Praetorians a few years back, but it was only for the skirmish mode, in which the AI itself was generating the tasks, based on some high level, hard-coded, rules. The single player campaign was scripted in the same way that shooters generally are.
So I agree with you, the human factor is the take away from your presentation.
Posted by: Sergio at March 9, 2008 06:36 PMI saw your lecture Damian and was impressed with the time and design you were able to structure this around, as well as the way it reads so well within Halo 3. One of my big concerns has always been if anyone would even notice. I've been on several projects researching a less battle specific and more procedural version, but keep getting stymied, primarily by UI needs, Streaming, and script control demands. I'm pretty positive about the long term impact of this tech, particularly in enabling denser, re-traceable gameplay spaces, reducing production times, and making worlds more layered yet manageable. But it really fits specific kinds of games well, and I haven't been fortunate enough yet to see one through to publication. I've been planning to speak on the topic once I have, but there's been too much ill luck in the pre-production draw, unfortunately. This kind of technology requires a level of accomplishment in core design and general AI that few teams have been able to tackle.