While I agree with much of what Dicken has to say, and he does make many of these same points eventually, there still seems to me to be a certain tone of "well, the biggest problem is just that we don't get enough CPU to run the *real* solutions." While Dicken does go on to dig into many of the more significant reasons why Traditional AI is largely ignored by game developers, he puts the CPU time argument right up front, and while it's technically not untrue, it seems to me that it is (a) misleading, and (b) counterproductive. Here's why.

Why Misleading?

Even if we had 10x or 20x the CPU we do now, Traditional AI solutions wouldn't be the right ones. In general, these approaches are aimed at finding an optimal solution to an arbitrary problem. But games aren't filled with arbitrary problems - they're filled with very specific, reasonably well understood problems. And they don't call for an optimal solution - they call for a human-like solution. Hopefully a "cool" solution. A solution that tells a story, defines a character, draws the player in and creates a deep sense of drama - the same as you'd get from a good book, or a Shakespeare play. Crazy, you say? Go play Red Dead Redemption again, or Dragon Age, and tell me that that's not where we're going. Two very different games - one based around the FPS genre, the other a more traditional strategy RPG - but both with deep and compelling stories that keep you in the game long after you would have otherwise wandered away.

In other words, we don't want a general problem solver which can, with difficulty, be configured to handle our problem. We want a focused solution which handles the specific needs of our game with laser-like precision, while requiring as little configuration time as possible. Keep in mind that the budget of a game is essentially fixed, so more time spent on building a super-smart AI architecture means less time spent on features and polish. More time making it work means less time making it cool.

If we're going to create that compelling experience - something that computers are very bad at - that implies the need for strong authorial control from a game designer. While some designers also have strong technical skills, and some programmers have killer design instincts, the critical capability here is the deep creativity that will create a compelling experience. More, because so much of that compelling experience really is about the look and feel, animators and other artists are going to need to work hand in hand with the AI programmers, and to understand the strengths and weaknesses of the AI at a gut level. Thus the AI needs to be something that can be understood and at least thought about, if not configured, by a fairly non-technical, artistic personality. Traditional AI... isn't.

Even if we could have it, we also don't want an AI that is going to do *too much* thinking for itself. We don't want to kick the players ass - we want to make him have fun. We aren't looking for a Predator drone - very complex, very smart, and really bloody boring. We're looking for the Terminator. Lot's of style. Lot's of menace. Kick his butt and you're a badass indeed - nevermind that he has to pretty much roll over and let you do it (but all the while making it look good). Or better yet - let's dream big - Romeo. A conflicted teen in a gritty, gang-warfare environment with a bad attitude towards authority, a deep and abiding loyalty to his friends, and an impossible love affair. A character so compelling that we're still fascinated with him 400 years later. Sounds a little like Niko. Or... what was the name of that character in Starcraft? The human scout dude with the cool land rover and the girlfriend who turns into a bug? Yeah, you know the one I mean.

Why Counterproductive?

And that brings us to the real rub. Every time we say "It's not our fault - it's those dirty graphics programmers! If they'd give us just a *little* more CPU, we could do soooo much more!" we shoot ourselves in the foot, because the listener immediately thinks "Okay then, Moore's Law for the win! We'll just wait 5 years, and then the AI guys can have the equivalent of a full CPU today!" Of course, we've been using that same tired excuse for well over 10 years now, and we're getting a bigger share of the CPU than we did back then as well. And yet, Traditional AI solutions still look as bad as they ever did. Hrm.

The real problem here is in the missed opportunity. If Traditional AI is the wrong solution to this problem now, it's still going to be the wrong solution in 5 years. What we need to be doing is not waiting for CPUs to get faster - it's to recognize Game AI as a first class solution to many problems (beyond just games), and to continue to work on finding better techniques in the domain of solutions that do work. If we're making irrelevant excuses as to why Traditional AI doesn't work, it's only going to distract us from doing that.

The Bottom Line

So what's the bottom line? After over 50 years of research, Traditional AI is still barely scratching the surface of general purpose problem solving. My home robot can't do much more than scrub my floors - literally - and it's not even great for that. After more like 10-15 years of serious work on Game AI (the first AAAI Spring Symposium on AI and Computer Games was in 1999, and AI Game Programming Wisdom came out in 2002), we're creating stories like Red Dead Redemption, or Dragon Age, or GTA IV. Even much older games - Wing Commander III, for instance, or Starcraft - had compelling stories and characters worth remembering. What do I remember about the AI? Not a lot - and I'm pretty fixated on AI. But I remember the stories, and the fun I had playing the games. And at the end of the day, that is the real measure of a game's success.

Instead of cowering and making excuses every time we're criticized, we need to stand up and declare our accomplishments with pride. Sure, you can find moments in every game when the AI looks dumb. But the same is true of Traditional AI solutions - they just don't get the scrutiny that Game AI gets, because they don't have millions of players frantically blogging about every little flaw. Games have only gotten better, the AIs smarter, the stories deeper, the experiences more engaging. Compare Assassin's Creed to the original Thief... both amazing games, but how much more can we do now than we could just 10 years ago?

Damian Isla, the founder of this blog, is too modest to promote his own company's game on his own blog, so I'll do it for him! Moonshot Games announced their awesome looking, and awesome playing, co-op side-scroller Fallen Frontier. All of Damian's wisdom about occupancy maps, knowledge representation, and scripting has been put to good use, complemented by a nice implementation of boids and a slick 2D skeletal animation and ragdoll system.

Meanwhile, in the GAMBIT Game Labs booth, I debuted a new experimental game called Improviso, which pairs players online on a film set to create a low-budget sci-fi movie. More info in this press release and blog post. Download Improviso and play today!

And finally, friend of Game/AI, Borut Pfeifer showed off his team's very cool-looking upcoming action strategy game, Skulls of the Shogun.

So anyway, I've started a new research blog to share progress and recap earlier developments, as I head to the finish line of the PhD. You can find it here: http://collectiveAI.blogspot.com.

I will still blog here about game AI in general, and use the other blog to focus on my research. As you can see, I'm all blogged up.

I'm running a workshop on Plan Recognition at ICAPS in Freiburg, Germany and have just released the call-for-papers. I was wondering if you could put something up on AI-blog telling the wider world about it, as we would be interested in receiving work from a more "non-academic" background. I know that Plan Recognition isn't massive in the gaming industry at the moment, but any emerging games/entertainment-related work would be welcomed.

The workshop website is at http://icaps11.icaps-conference.org/workshops/gaprec.html. If you have any questions, just drop me an email.

click here to join.

Reason #1: Making It Work

Machine Learning algorithms typically require four things in order to do their work:

1. You need to define the features that the algorithm should track.
2. You need to specify the output parameters that the algorithm needs to return.
3. You need to define the fitness function, which tells the algorithm how good or bad a particular example is.
4. You need a huge pile of example data for the algorithm to sift through.

So, for example, if you’re writing a learning algorithm that’s going to learn how to drive a car on the highway, the features might be things like:

• The distance from the lines to your left and right
• The presence or absence of cars to your left and right
• The distance from the car in front of you
• Your speed
• The speed of the car in front of you
• Brake lights of the car in front of you

And so on. The fitness function would return high scores when you have a good following distance, your speed roughly matches that of the car in front of you, you’re centered in your lane, etc. The output parameters would be settings for the brake, gas, and steering wheel. Finally, you’d need a whole bunch of data from people actually driving cars, so that the learning algorithm could plug through and figure out how to do it well. For a game, all of these can be tough to find. In particular, the fitness function and the example data can be tricky.

For the fitness function, we can’t even define “fun,” much less measure it -- how are we going to go about encoding a fitness function for it? What about “clever,” “humorous,” or “tricksy?” The characteristics that give our characters their personality, that make them memorable, that deliver the experience we want the player to have, are not things that are easy to encode.

Once we get past that, the next hurdle is that we need learning data from the game in its final state. But the game isn’t ever in its final state. Even after you ship, there will be patches, and DLC, and expansion packs, and player generated content... Every time one of those hits, you need to run the machine learning all over again -- which means you need to gather all of that data all over again. That’s not cheap. And if we make a change to the game -- even a small one -- and don’t relearn the AI, then the AI isn’t going to be able to accommodate for that change.

You might think that you can just throw some learning data together quickly, but in reality gathering the learning data can be one of the hardest parts of the task. The output of your learner will only be as good as the data you feed in, so it's important that you have a large data set which covers all possible cases. Any situation not included in the data won't be learned. What's more, the data set needs to be built in such a way that the AI won't over learn, or learn the wrong thing.

Finally, that late in the project there’s just not time to iterate. As a result, your machine learning needs to be absolutely reliable -- that is, it needs to produce top quality results with no flaws the first time you run it, every time, no matter what. That’s not a realistic expectation of any code, much less of code that’s so reliant on correctly defining the features, outputs, and fitness function, and then gathering a well balanced set of learning data -- rather arcane tasks which are the responsibility of a mere human.

Reason #2: Rigid Behavior

Learning algorithms are designed to find the single best solution that they can. There are two problems with this: the words “single” and “best.” If there is only a single solution, then every time you hit a particular situation, the AI will take the same action. This results in behavior that is rigid, repetitive, and, in the worst case, exploitable. Furthermore, the learning algorithms try to find the “best,” which is to say optimal solution. The absolute shortest path. The perfect, precise motion. The result looks robotic, which shouldn’t be surprising because it is robotic.

Real human behavior is almost never truly optimal, and humans almost never do exactly the same thing twice in a row. Humans are full of small imperfections, small variations -- and those are huge part of making your character feel real, organic, and alive.

Could we build a learning algorithm that keeps a history and intentionally adds some variation? Or could we add small imperfections as a post-processing step? Probably, with sufficient expertise in the domain -- but it’s no longer a straightforward application of machine learning at this point. Either we have a much more complex learning problem, or we have this hacked on post-processing step that may need to be updated and adjusted each time we run the learning. Either way, it significantly increases the complexity of the problem. Remember what we said above -- the learning algorithm needs to be absolutely reliable. Complexity is the enemy of reliability in this case.

Reason #3: Monolithic, Immutable AI with a Lack of Creative Control

Learning algorithms tend to be black box solutions. That is, they give you some mapping from inputs to outputs. The job of the AI, then, is to sense the inputs, look up the appropriate set of outputs, and apply them. It is generally impossible to make any changes to that mapping -- or, in many cases, even to examine the mapping and understand why it is the way it is. If you want to change the AI, the only way to do so is to change the input parameters (i.e. the features, outputs, fitness function, and learning data), and then run the algorithm again.

There are a few implications to this. First and foremost, it takes creative control away from the designers. If they want the characters to exhibit some particular sort of behavior -- perhaps something to make them realistic in some way, or something that gives them some personality -- the only way to do that is to write a fitness function for it. As I said, what is the fitness function for “cool?” Even if it’s possible to encode that, it’s going to take an expert -- which means that the designers are absolutely reliant on experts to do their tuning for them.

Second, the result is monolithic. It is impossible to change just one part of it. If there’s a localized bug -- perhaps a special case where the behavior isn’t quite right -- there’s no easy way to fix that single issue in isolation. Sure, you can hack a fix in that handles that using a hand-coded approach, but that isn’t very extensible, nor is it likely to hold up well the next time that you relearn the AI. At the end of the day, if you make too many of those hand-coded changes you might as well just have written your whole AI by hand to start with.

Finally, every time you make any change at all -- even a tiny little one -- you have to retest the entire game. Even if the change is not to the AI itself, if it could impact the AI then you need to generate a new data set, relearn, and retest. This is a huge task which makes QA essentially impossible.

Reason #4: Nobody’s Ever Done It

Back in 2002, at the AI Roundtable at GDC, and we took a survey of the room to see what people thought was going to be the most exciting upcoming technology over the next 5 to 10 years. This was back when most people were using non-hierarchical FSMs or simple scripting, we were getting at most 10% of the CPU, and most games didn’t even have a dedicated AI programmer (to say nothing of a full AI team). Almost unanimously -- there were a few dissenters, including myself -- people said “machine learning.” It was the bright new technology that was going to change everything for us.

Last year, again at the AI Roundtable at GDC, somebody said “well, what about using machine learning to create your AI?” The whole room groaned. -- and then we proceeded to have a discussion much like this blog post.

The point is, all that hope and excitement has worn off. After 7+ years of trying, we still have no good examples of learned AI. Sure, there’ve been a few niche examples of learning in games. Creatures. Black & White. More recently, Galactic Arms Race. But in all of those cases it was a specialized use of machine learning -- it wasn’t the core algorithm.

It’s not for lack of trying. Academia has attempted it. Game companies have attempted it and the abandoned it before shipping. There is even a middleware company (AI Live), populated mostly by PhD’s -- very smart folks -- dedicated to building machine learning techniques for games. They have had some success with motion recognition, particularly on the Wiimote, but I don’t know of any games that shipped with their learning approach as the core AI.

Reason #5: It’s Not Easier... So What’s The Point?

The whole point of machine learning is to save effort and cut costs -- and yet, a recurring theme through all of the above is “even if you could do it, it would be tricky.” If it’s cheaper and easier to build the AI by hand, then that pretty much takes the wind out of the sails on machine learning. In my experience, given all the challenges, it is absolutely cheaper and easier to build the AI by hand. And until that changes -- until somebody not only manages to pull off a learned AI, but also demonstrates that it actually saves development time and money -- machine learning is going to be dead in the water.

At the same time, despite the difficulty and expense of creating game AI, we continue to throw all of that work away at the end of each project, and start fresh for the next game. Sure, we may retain a few tools – a scripting language here, a behavior tree architecture there – but the bulk of the work, the actual behavior, is tossed on the scrap pile.

Code reuse has been applied successfully in other areas of game development. We don’t typically build a new renderer for each game. We don’t typically reinvent our physics engine, or change the code that controls animation in any fundamental way. Sure, we’ll extend what we’ve got, add new features – maybe better water effects, maybe a new blending technique that allows us to generate better facial animation – but I would argue that the fact that we retain the bulk of our old code is precisely what allows us the freedom to really dig into the areas that provide the most bang for the buck. We’d never have time to focus down on getting the God rays, ripple distortion, and the atmospheric particle effects when swimming underwater looking just right, for example, if we had to rebuild the renderer from the ground up each time we built a game.

What’s more, there are middleware companies that have been building libraries of reusable code for years – building a solid product, whether it is a renderer or a facial animation system or just a tool for making really good looking trees – and then iterating and improving on it while continuing to sell it for use in hundreds of games.

My article in Game Programming Gems 8 discussed one potential approach to code reuse for Game AI, but here I’d like to discuss a different (although perhaps complimentary) approach. The insight driving this approach is that while there is AI middleware as well, generally speaking, with the exception of path-planning middleware, it hasn’t really taken off. It seems to me that one of the reasons it hasn’t taken off is that it’s providing code reuse at the wrong level of granularity. What you get with most of the AI middleware packages is a development environment in which you can build your behavior. In other words, you get a fairly standard reasoning architecture (typically either an HFSM or rule-based architecture) plus some tools. The problem is that building the reasoning architecture is really only about 20% of the job. The other 80% - the hard 80%, the 80% that requires endless iteration and polish, the 80% where your AI succeeds or fails – is using that architecture to create the actual behavior for your characters. What we need

On a side note, as I mentioned above, one area in which AI middleware companies have succeeded is path planning – a domain where they’re controlling behavior, not just providing tools for specifying it. A subtle difference, perhaps, but an important one.

So why aren’t we reusing AI behavior? It seems to me that it boils down to two reasons. First is the perception that AI behavior is extremely game specific. That there’s so much that is unique about each game that it’s impossible (or at least inadvisable) to share behavior between games. Even for two very similar games (say, for instance, two WWII first-person shooter games), it is essential to customize the behavior for each game, to give each game the unique feel that is what makes it cool.

The second problem is that it’s not clear that we know how to do this behavior sharing. What would we be saving? Finite states? Behavior subtrees? How would the game interface with those objects, and how would they interface back into the game?

So let’s take both of those problems in order. First, the issue that each game is a delicate flower, pure and perfect, and wholly unique from every other game that’s ever been made. Honestly, that’s bullsh… erm, I mean, I respectfully disagree.

So as random examples, let’s take the last two games I worked on. The most recent was Red Dead Redemption. This game was not a standard space-marine-fighting-demons Doom-style shooter. It was set in the early 1900s, with era-appropriate weapons. Nevertheless, it had characters armed with pistols, rifles, shotguns, grenades-like weapons, and occasionally even machine guns. The various weapons had variations in how much damage they delivered, optimum range, rates of fire, and so forth. The characters could do things like fire, duck behind cover, and reload. There were first aid kits that would restore your health. Common team tactics such as using suppressive fire and flanking an opponent were viable (though not necessarily used by the AI). Any of this sound familiar?

The game I worked on before that was Iron Man. Again, this was not a standard FPS – in fact, it was quite a bit more of a departure than Red Dead. Nevertheless, the vast majority of characters had weapons like missile launchers, machine guns, or rifles. They could use cover. They could reload. They could use team tactics.

Both games focused on things other than high quality AI opponents for tactical combat, and honestly both struggled during development to create good combat behaviors for their characters. That’s not to say that the end result wasn’t good – I’m proud of the result in both cases – but significant time and money could have been saved during development if we’d had an existing library of FPS behaviors as a starting point. What’s more, having that library would have allowed us to spend our time polishing and tuning the behaviors we wanted specifically for that game, rather than reinventing behavior that has been commonplace for years. I think this is the most important point. Having reusable behavior would not decrease your ability to customize and tune the behavior in a game, it would increase it. The time normally spent rebuilding basic functionality could instead be spent on customization. Those resources could be dedicated to the aspects of the game which make it unique, rather than being expended on aspects of the game that are, honestly, fairly generic.

The ability to find a common core of behavior isn’t unique to shooters. How many strategy games have a handful of resources, a rock-paper-scissors approach to combat, and technologies that improve the units in fairly similar ways? How many fantasy RPGs have tanks, healers, and DPS? How many games have background characters that just need to act in generic and believable ways? Again, the details aren’t the same from game to game, but the general shape of the problem is. A general solution could, in theory, get us 80% of the way there, and let us focus on the last 20%, rather than spending all of our time rebuilding that first 80% - or worse, the first 60%.

This brings us to the second problem. It does us no good simply to *want* to reuse behavior. We also need to *be able* to do so. Despite a decade of attempting to do so, we have not yet agreed on common standards for game AI. There is no equivalent to the texture-mapped triangle, or the animation skeleton, that we can rely on being the same in every game ever built. What’s more, there’s no evidence that there will be a general solution to that problem any time soon. Game AI is just not something that lends itself to standardized solutions.

With that said, the general shape of an AI is pretty standard. The AI accepts data from the outside environment – often called “sensing.” It then processes that data – often called “thinking” – and selects one or more things to do – often called “acting.” My suggestion would be to share the entire core of the AI – the “thinking” part – and provide interfaces to the game engine which specify what the AI expects to see on the sensing and the acting side.

As an example, on the sensing side our shooter AI would want to know things like the position of the character, its enemies, and its allies. The position and size of any cover locations. The priority for taking down each enemy, and for protecting each ally. The weapons it has to choose from, their ranges and damage characteristics, magazine capacity and current load, and the amount of ammunition available. It could then process that information and return actions such as “crawl to this position,” “shoot at this target,” or “reload your weapon.”

The end result is a core set of behaviors which, while genre-specific, would still be applicable in a great many games. For instance, the combat AI that I described above could not only be used in most FPS games, but also many RPGs, and even to control individual units in some RTS games. In order to reuse the behavior you’d first implement the wrapper which handles interfacing the sensing and acting steps to the game code, and then you’d go into the core of the AI and tune the existing behaviors to match your creative vision.

Shooter AI is one extremely common area in which reusability could work for us, but it isn’t the only one. A similar approach could be taken for high-level strategy AI, for sports games, for the background characters that fill out the world, or for any other area that seems widespread enough to be worth the effort.

Of course, all of that is easier said than done. The key challenges seem to be:

* Building a core set of behaviors which provide the basic functionality that’s desired in a large set of games. Obviously this behavior set will grow and change over time, but we need to start by getting the basics implemented.

* Providing the means to add and remove behaviors for specific games, as well as the means to tune the decision making process used to select those behaviors.

* Similarly, providing the ability to add and remove sensor data and actions from the external interface so as to be able to customize the AI for each game.

Put that way, this seems like a large but solvable problem. Sure there’s significant work there – but there was significant work to build shared libraries for physics, or for rendering, or for network code as well. And once that work is accomplished, hopefully we can get over the hump of constantly reimplementing the basics, and on to the challenges of achieving behavioral photorealism.

Very exciting stuff! I'm seriously tempted to sign up.

Here are links to the webpage, flyer, and announcement video on YouTube.

CALL FOR PAPERS

The ICAPS 2010 Workshop on Planning in Games
Toronto, Canada
May 12 or 13, 2010

http://www.cs.ualberta.ca/~mburo/icaps2010-pg

************************************************************************
CALL FOR PAPERS
Agents for Games and Simulations
Workshop@AAMAS 2010
May 10-11, 2010, Toronto, Canada
http://people.cs.uu.nl/dignum/AGS10/
************************************************************************

The debate is between those who favor hand-generated content (which I’ll dub the “artists” for the purpose of this post) and those who prefer computer-generated or procedurally-generated content (which I’ll dub the “proceduralists”).

In the animation world, the proceduralists (who are generally engineers) will argue that modern games have characters who are expected to be as reactive as possible to the world around them, while at the same time those worlds become more and more complex. On top of that, we want our characters to have as much variety as possible in their actions, so that they feel “real.” For instance, we don’t want a bartender just to stand there. He should polish the bar, clean glasses, and clean up after departed patrons. He should serve drinks. He should gossip with his patrons. He should laugh when he overhears a joke. He should pinch the waitress’s butt. And so forth. The end result is a combinatorial explosion in the number of actual motions that need to be made by our characters. As a result, we’re reaching the limits of what can be done with keyframed animation (where each motion needs to be created in advance, whether by an animator or through motion capture, and then shipped with the game). Even something as simple as pointing at somebody is impossible to do with purely keyframed animation, unless the exact position of the target is known in advance.

What’s more, because we’re limited in the amount of hand-generated animation we can ship, keyframed solutions tend to look mechanical and repetitive, as a limited set of animations are played over and over. Coming back to our bartender example, it’s doubtful that we can ship all of those different behaviors that I mentioned, along with enough variations on each behavior that they aren’t repetitive, if each version needs to be completely pre-generated.

On the flip side of the debate, the artists will make very similar-sounding arguments to support the opposite point of view. Given the level photorealism expected of a modern game, they’ll say, we can’t afford to rely on the computer to create our animations for us. Procedurally generated animations such as ragdoll and IK tend to look mechanical and artificial exactly because they are created in a mechanical and artificial way. If our games are going to look and feel “real” then we need the sense of character and visual fidelity that can only be obtained either through hand-generated animation or, better still, motion-captured animation which is then touched up by an animator. What we need is *more* keyframed animation, along with simple techniques (such as blending) that can allow us to combine them without losing quality.

This debate is far from over. New research is presented at conferences like SIGGRAPH every year that suggests ways to animate. With that said, it seems like in the end the truth will lie somewhere in the middle. Currently, the most forward-looking animation technologies that are actually shipping in games seem to be Spore and Euphoria. Spore, as most people know, is a game in which the player has extensive control over the appearance of his creatures, up to and including controlling the number and position of appendages, and the game has to animate whatever it gets. Euphoria is an animation technology from Natural Motion, which has been used in games like Star Wars: The Force Unleashed and Grand Theft Auto IV. It enables characters to interact in realistic and dynamic ways with the physical world. The interesting thing is that, as best I can discern, both of these products rely heavily on a mixing keyframed animation with procedural techniques.

Lately, I’ve been coming across a similar debate in the AI community. Ironically, most software engineers working in the games industry are actually the artists in this debate, while the proceduralists are largely academics. The arguments are more or less identical. The proceduralists argue that given the incredible complexity of modern games, as well as the desire for characters who are highly dynamic and reactive, it is unrealistic to think that we can rely on techniques like Behavior Trees, utility-based AI, or hand-crafted planners to create the breadth and depth of AI that we want to see in our games. Instead, we should be looking into solutions that use machine learning, or player modeling, or more general planners, or robust reasoners with strong psychological models and large ontologies, or any of a host of other techniques to generate as much of our behavior as possible.

The artists will argue that after roughly half a century of AI research, none of those techniques has been shown to be able to create the quality of behavior that we want to see in our games. They’ll say that we’re not trying to solve any hard AI problems here – we’re just trying to create characters who look and act in believable ways, and to avoid artificial stupidity, and we can do that if we just put enough care and attention to detail into our hand-crafted solution. And in saying that they’ll ignore the fact that we haven’t yet managed to achieve that either – or at least haven’t managed to achieve it very often – despite the ever-increasing size of AI teams and CPU resources available.

So I don’t have any good answers in either debate, except to say that both animation and AI in a dynamic, photorealistic environment with a large enough behavior set to generate believable characters are really hard. But I do wonder… is the solution in terms of AI going to look something like Euphoria or Spore? That is, rather than sitting in our well-defended camps and throwing stones at one another, should we be looking for techniques that blend hand-crafted AI with some sort of procedural techniques? And what would such a solution even look like?

EDIT: Alex Champandard has agreed to host an extended version of this on AiGameDev.com. This will probably happen sometime in November. I will post a link here when it's made available.

A few close collaborators and I have been toiling away under the radar for a couple months now, and I'm now really happy to be able to tell everyone a little bit about what we're working on.

The short answer is, a new studio!

Me and my ex-Bungie colleagues Michel Bastien and Rob Stokes are now officially Moonshot Games.

The three of us have been incredibly inspired by the indie/downloadable/small games market for a while now, and strongly believe that some of the coolest, funnest, most original work being done in the industry is coming from small outfits that can afford to be different and take risks. So here we are.

No word yet on first projects or anything ... all in good time! But until then, check out our new site:

http://www.moonshotgames.com

And make sure to facebook-tweet your blog-digg! Or whatever the kids are calling it these days.

I know, I know -- I've left the industry to get an MBA, so what am I doing giving a talk on game AI?

I don't really have time for it, but I'm still on the Program Committee and I couldn't turn down an invitation. I've had a lot of big things kicking around in my head for years, so it's great to finally have a chance to let them out.

The talk is "Game Design: An AI Perspective." I couldn't resist the urge to make it rhyme with Will Wright's brilliant lecture from AIIDE '05 (yes, it's kind of incomprehensible with just the slides and no audio, but trust me -- you should have been there!)

I'm also going to be talking a bit about the emergent gameplay design paradigm that's been a slowly growing undercurrent in game design for the last decade or so. Emergent gameplay sometimes works amazingly well. At the same time, there's something missing, and I think the theory is incomplete to the point of being dangerous.

So I'll be talking about that a bit and seeing if we can't put "emergent gameplay" in what I think is a new context.

Hope to see y'all there!

-Paul