m |
m |
||
Line 22: | Line 22: | ||
* '''The Outro Problem''', or, Who is responsible for shutting down the currently running behavior when you want to switch to a new one.<br/><blockquote>A lot of systems just punt, and hope the animation state machine and/or blender will fix the problem, or just ignore latency and correctness. '''This will never result in high quality behavior and movement.'''</blockquote> | * '''The Outro Problem''', or, Who is responsible for shutting down the currently running behavior when you want to switch to a new one.<br/><blockquote>A lot of systems just punt, and hope the animation state machine and/or blender will fix the problem, or just ignore latency and correctness. '''This will never result in high quality behavior and movement.'''</blockquote> | ||
* '''The AI↔Anim Problem''', or, How and what do the AI and Animation systems communicate? The challenges:<ul><li>similar but not identical states</li><li>wide bidirectional interface</li><li>combinatorics are deadly</li><li>proceduralism can’t compete on quality</li></ul>I do not think the solution looks like these fancy GUI based AI/Animation control things where you hook together bubbles with lines that the middleware people and large game company internal technology departments love to make. They make for nice toy-problem-demos, but really just push the problem elsewhere and make things more complicated without solving the core problem. | * '''The AI<span style="font-size:150%;font-weight:bold;">↔</span>Anim Problem''', or, How and what do the AI and Animation systems communicate? The challenges:<ul><li>similar but not identical states</li><li>wide bidirectional interface</li><li>combinatorics are deadly</li><li>proceduralism can’t compete on quality</li></ul>I do not think the solution looks like these fancy GUI based AI/Animation control things where you hook together bubbles with lines that the middleware people and large game company internal technology departments love to make. They make for nice toy-problem-demos, but really just push the problem elsewhere and make things more complicated without solving the core problem. | ||
Finally, I claim these two problems are really a single underlying challenge for game development, namely: | Finally, I claim these two problems are really a single underlying challenge for game development, namely: |
Latest revision as of 21:35, 27 March 2011
"Doing AI without making games is like writing graphics code but never rendering an image."
I gave a lecture at the 2010 AI and Interactive Digital Entertainment Conference titled SpyParty, A Game About AI...plus some ranting.
While I talk about the challenges of SpyParty a bit at the beginning as a framework for talking about AI in games, the core of the talk is this statement: Game AI is Game Gesign. So, it follows that researchers need to actually make compelling games to really do successful AI research. This is a somewhat controversial statement, made more so by me telling the audience of AI researchers that their work so far has not been very relevant to games. Then I try to explain why, and how to fix it.
Tech Stuff
The middle of the talk is about various technological challenges I've faced making Spore and SpyParty. I talk about:
- Feeding the player's control through the same pathing system the AI goes through, which is really important for SpyParty.
- How hard it is to find games that use IK in interesting and subtle and human ways.
- The current SpyParty AI system,[1] called Situations. Situations are sort of like Sims interactions, but multiple can be running at the same time, they're layered, and resource-based. I don't like the resource-based solution, but I don't know a better way to do it yet. I think this system will let me ship the game, but it's going to be close. I'm hoping to improve it a lot this year.
- I'm a big fan of C switch-statements for low level AI, since they're so clear and explicit. I talk about how the Behavior Tree system was still C switch-statements at the lowest level.
- I mention the Tower of Tuning, from Advanced Prototyping.
Then I talk about the two biggest open problems in game AI and animation:
- The Outro Problem, or, Who is responsible for shutting down the currently running behavior when you want to switch to a new one.
A lot of systems just punt, and hope the animation state machine and/or blender will fix the problem, or just ignore latency and correctness. This will never result in high quality behavior and movement.
- The AI↔Anim Problem, or, How and what do the AI and Animation systems communicate? The challenges:
- similar but not identical states
- wide bidirectional interface
- combinatorics are deadly
- proceduralism can’t compete on quality
Finally, I claim these two problems are really a single underlying challenge for game development, namely:
Sadly, computers and computer languages suck at dealing with things that happen over time. No, I don't think you should go make a new language to "solve" this problem. I think we don't have the conceptual framework for how to solve the problem yet, so you'd just be wasting your time until we figure that out.
Design Stuff
"You look here, and you're like, what the hell is this 0.0005 doing here? This is game design. Whether this is a less-than or a less-than-or-equals sign is game design. The rubber hits the road here."
"AI programming is game design. The lack of recognition of this fact, and the failure to embrace it, explains why the AI Research community has had almost no impact on the game industry at large."
The last third of the talk goes into why I think AI researchers need to make games, and I don't mean little throwaway games that only their grad students play, I mean games that are put up for download, and are playtested, and are compelling.
I make this claim based on a chain of reasoning that starts with the idea that the behavior of the AI, and its tuning, is game design. Then I mix in some Frank Lantz and his ironclad proof that "games are the aesthetics of interactive systems", the idea that "aesthetics are the opposite of science", and then I hook it all together, to the audience's dismay.
In this section, I also talk about...
- Jaime Griesemer's Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3, the best damned talk at GDC 2010.
- You want to write checks you can cash, creatively and technically, but you want to write the biggest checks you possibly can. John Carmack was the master of this for a decade.
- I claim: "There is so much gameplay lying all over the floor in human behavior."
- There's a section of Q&A after the last slide. Hear me tell Noah Wardrip-Fruin that text games are a way harder AI problem than are graphics games with characters, and that he should load up Maya! I also sort of insult all the AIIDE StarCraft Competition people.
- I urge AI researchers to step up to this challenge, since the graphics researchers certainly aren't going to help us reach our potential as the preeminent art and entertainment form of the 21st century.
The Actual Stuff
Here are the synced slides. The first few slides are the same as Design, Games, & Game Design (feat. SpyParty), and the talking over those slides is similar but slightly different, so if you want every nugget in the talk you should listen, if not, skip to slide 6 (12:40 in the talk):
This talk is a sibling to a few of my more general talks:
- A Game Developer's Wish List for Researchers - I outline how researchers in all technical fields can be more relevant to games.
- Structure vs Style - I mention The Photoshop of AI in this talk as well, sort of.
- Potential Unreached - I talk about the Seinfeld and Friends analogy.
- ↑ And I use the word "system" very loosely.