I don't think commercial dev teams are likely to come up with major innovations completely spontaneously, within the space of one project. However, I also don't think we're going to see a commercial breakthrough come directly from academic work. As Malcolm Ryan recently suggested over at GTxA in this post:
http://grandtextauto.gatech.edu/2005/07/20/new-dissertations-on-interactive-art-character-and-narrative/#comment-67850
...there's a tendency for academia to either move too rapidly onto the next system before applying it to a finished product, or else get buried in one system for 10 years + and never *finish* the applied work :) Facade is a wonderful exception to both these patterns.
I think "how it's all going to play out" is that some *tiny* amount of the huge volume of academic work will influence some *tiny* amount of the huge volume of commercial dev teams, and those commercial teams will manage to get some *tiny* amount of a real innovation into a real commercial title.
Surface changes at the consumer end will take an incremental form. Progress in synthetic characters / interactive narrative is rarely if ever truly 'revolutionary' because the work is not based on a small set of highly explicit assumptions that might suddenly change. Any genuinely useful 'system' in this field is deeply embedded in the specific domain in which it was developed.
The more general the technique, e.g. A* pathfinding, the less it has to do with expressive content (character, story). The more something has to do with expression, e.g. ABL, the less portable and concise it will be, and the less separable from specific applications.
Posted by Adam at July 30, 2005 04:21 PMThis is going to be a gigantic rant, but please bear with me.
--------
It became very clear at the AIIDE that AI has more or less risen to the challenge of the current standard game genres, and that's no longer where the interesting challenges are. We generally know how to do AI for all of the different platformer/ RTS/ FPS/ TBS/ RPG/ MMORPG/ racing/ fighting and all the different genres of sports games. With sufficient development resources, we can make good-to-great AI for any of these.
The question now is, what can we do that we couldn't do before? How can we build on the current game genres and build new kinds of game experiences that don't fall into one of the existing ruts?
That, for me, is the single biggest thing holding us back. There is a huge amount of tunnel-vision in the industry: make a successful game in an existing franchise and there's very little incentive to break out of the mold.
--------
To a large extent, that's understandable. Business is business, we're all subject to market forces, and pragmatic businesspeople are loath to take unnecessary risks. I understand that.
But the problem is terribly exacerbated by the fact that very few designers in the industry (with the notable exceptions of Will Wright, Peter Molyneux, and a handful of others) really think of AI at the design level -- or have much respect for AI at all.
The process has always been: design your game, and then hire an AI programmer to make your NPCs move and shoot. So we've ended up with lots and lots of games that have lots and lots of moving and shooting.
I'm exaggerating, but only a little.
And meanwhile, the AI field is growing in so many different directions at once that it's fragmenting into dozens of different subfields. And we just pick a handful of cherries from that harvest and run for the hills.
So I think a big part of the problem is that AI development usually happens far too late in the development process. The game gets designed without AI in mind, and then AI too often gets tacked on at the end when it should be one of the fundamental drivers for the whole project, influencing many of the key design decisions.
We end up with a game where each AI has a grand total of 5 seconds between introducing itself to the player and lying dead on the ground. You can't do anything interesting in 5 seconds.
Or we end up with a game so heavily scripted (due to a fear of AI or an irrational desire to crossbreed games with movies) that there's no room for AI. The little Nazi on the hill fires 3 times, runs 10 feet, and then gets shot in the chest, regardless of what you do as a player.
There's also a school of thought that "the AI developer's job is to make tools for the designers." As if designers can go for years of development designing in an AI-free vacuum, and then we hand them some magical tools and so they can add "AI" to the game.
Certainly, tools are a big part of our job, but there's no way to begin designing the tools until the design team knows what they want from the AI.
Developers are getting better and better at beginning AI engineering efforts earlier in the dev cycle, but the really interesting stuff won't happen until AI becomes a part of game design.
Far more of the AI development needs to happen in the design phase.
--------
Planning is a great example of what I'm talking about. The AIIDE made it clear that we're at the point where real-time planning in games has become a lot more realistic and a lot more useful (and here I'm specifically considering planning *outside* the realm of drama managers and narrative generators, insanely-ambitious or otherwise).
I want to use Battlefield 2 as an example because it's such a perfect example of a game that involves massive amounts of planning. I've come to realize that a big part of the reason I enjoy Battlefield 2 so much is that it evolves shooter gameplay far beyond the simplistic fast-reflexes and map-analysis of games like Quake and introduces all these elements of vehicular combat and tactical reasoning.
Reflexes are still a big part of the game, of course, but the best BF2 players are the ones that can quickly evaluate the current combat situation and construct and modify complex plans in response.
Here's an example:
I'm playing the Spec Ops kit in Battlefield 2, and I'm on top of a 4-storey building. An enemy tank appears below me next to my flag, and there's a jeep and a TOW missile launcher station nearby. I drop some C4 packs off the roof of the building, but the tank maneuvers away. I drop off the roof of the building using the parachute, hop in the jeep, and circle around the building to the stationary TOW missile launcher and take out the tank.
Unfortunately for me, the driver had already exited his tank shortly before I hit it with the TOW missile, and now he's now firing at me from a prone position. I notice that he's lying near the C4 packs I dropped earlier, but he's
going to kill me if I don't get away quick. So I run around the corner, push the C4 detonation button to kill the driver, and then run up and capture the flag.
It sounds complicated, but that sort of thing is just a 15-second slice of a typical piece of BF2 gameplay.
The full sequence of actions is:
-drop C4 packs
-jump off roof
-deploy parachute
-enter jeep
-drive jeep around the back side of the building (to take cover from the tank)
-exit the jeep
-use the TOW missile launcher
-turn the TOW launcher 180 degrees
-fire the TOW to take out the tank
Then, when I realize the tank driver exited the tank in time and is firing at me, I replan and get this:
-run behind the corner of the building to take cover from the tank driver
-detonate the C4
-run to the flag and capture it
I doubt the Battlefield 2 designers were seriously thinking about planning systems when they were designing their game. But I think it illustrates my point: change your perspective on game design so that you see the player as a planning system, and then you can ask the question, "How do I build forms of gameplay that make interesting use of that planner?"
--------
AI needs to be one of a designer's fundamental tools, and for so many designers, AI is just this big black box.
Frankly, when I look back at the 11 years I've been in the industry, I'm appalled at the near-universal lack of understanding of even the most basic aspects of AI on the part of designers in the industry (my current employer excepted, of course!)
There's this huge misperception in the industry that you can draw a neat line between the fundamental, tried-and-true AI techniques every game uses (state machines and pathfinding) and the exotic academic techniques that aren't really useful for games (neural networks and genetic algorithms).
We stand on this side of the line and say, "all that neural network stuff is fine for you folks in academia, but we need stuff that works in real-time, and that's understandable, and that our designers can tune and tweak and play-balance."
Which is all well and good, but meanwhile, there are all these other techniques -- agent-based systems, planners, voting systems, decision tree learning systems, A-life techniques, blackboard systems, HMMs, SVMs, Go-Cap, Bayesian belief networks, and so many more -- that we leave on the table because most designers don't even know they exist and/or have no idea how to apply them.
Posted by Paul T at August 1, 2005 06:16 PM... very few designers in the industry really think of AI at the design level -- or have much respect for AI at all.
The process has always been: design your game, and then hire an AI programmer to make your NPCs move and shoot.
Funny, I was just going to write a big long rant here about how not many AI people seem to think of / respect design (present company excluded) at all. Which probably means that there needs to be a lot more communication between the two disciplines. Wait, not even probably. There does need to be.
A number of AI programmers I've known have approached AI from a design-agnostic point of view. They view quality in terms of technical excellence - algorithm efficiency, elegance. In other cases they have a distant and arbitrary "realism" goal in mind, and work towards making "believable humans", etc. Whether or not the design calls for any such thing. Which gets into my main point.
I'm a designer, but in recent years I've learned enough about programming to be able to implement my designs. I consider design to be the most inclusive (most inclusive != most important, btw) discipline in game development. Design cares about rule design, mechanics, but it cares equally about art style, usability, experiential implications, technological underpinnings. All of these things affect the final piece. So when I see all the incredibly talented people in AI wandering off into a corner by themselves, stuck on figuring out ways to spiff up run-and-shoot behavior that's already been pretty much perfected, I am sad.
Likewise, I am very happy when I see AI people who realize just how much their work impacts design. Future advances in AI will march in lock-step with advances in design. Likewise, if the gears of progress grind onward as stubbornly as they have in recent times, non-academic AI folks working in the industry are going to find the well pretty damn dry in subsequent draws of the bucket.
From my perspective, the level of technical education among designers is pretty sorry. And from the outside looking in, the depth and frequency with which some AI folks think about design is depressingly low. There needs to be more communication between these disciplines. This blog is a very reassuring step in that direction. Keep up the good work, folks.
(sorry, a bit incoherent at this hour - it's past my bedtime!)
Posted by chmmr at August 1, 2005 08:56 PMHallelujah! AI and design working more closely together, god yes. Re: AI not understanding design, this is SUCH a pertinent point I just had to post.
Many many AI developers are either fairly hardcore programmers who got into the AI side of gameplay programming, or else (more likely nowadays) AI academics who moved into the games industry. BOTH these camps tend to have their own interests in 'better engineering' or 'more complex AI' that *have nothing to do with game design*
Just look at the contents of the AIGPW books! General architectures, FSMs, Navigation, Flocking, Learning, Animation control, etc etc. Almost NOTHING in these books moves into the difficult middle-ground between AI and design.
I'm thinking especially of scripting here. How many teams have one or two 'AI guys' building some cool technology in the corner, and then a 'scripting team' who are working closely with design using 15 year-old processes in their scripts? If we stop seeing game AI as a thing-in-itself, then obviously scripting preauthored events is as much a part of 'generating NPC behaviour' as an A* algorithm, and the two pursuits must be much more closely related, or even merged.
All this is why I think a lot about team organisation and its effect on what we produce. I'm very interested in the notion of a 'Lead Technical Designer' who sits between traditional Design and traditional Programming, with a team of TDs under them implementing content. The idea is to separate design-related AI content (driven and mostly implemented by the TD team) from low-level AI algorithms (driven and implemented by the Programming team), and create a bridge between progs and design. Of course, in many ways this is just a 'Scripting Team' or a 'Level Design Team', nothing new there maybe, but my emphasis is different.
I want low-level AI developers to see Technical Design as their clients, and TD to see themselves as users of the low-level AI. The result hopefully is AI systems less concerned with hardcore AI and more concerned with supporting player experiences, and Design/Scripting less concerned with 'stand here - shoot' and more concerned with handcrafting powerfully procedural scenarios.
How does this compare with other people's organisational experiences?
Posted by Adam at August 2, 2005 03:44 AMWow, great points!
> chmmr:
> From my perspective, the level of technical
> education among designers is pretty sorry.
> And from the outside looking in, the depth
> and frequency with which some AI folks think
> about design is depressingly low. There needs
> to be more communication between these
> disciplines.
Amen, hallelujah, etc., etc.
> Adam:
> How does this compare with other people's
> organisational experiences?
I'm not sure whether or not I'm on board with the specific process you're proposing, but this kind of specialization of job roles is clearly a good thing.
From my perspective, putting "scripting" and "level design" with AI into a single "technical design" banner may not be the best idea. These terms often mean somewhat different things from one company to the next, but I tend to see them as very discrete specializations. These are the definitions I'm most familiar with:
-"level design" strictly refers to creating and fine-tuning the physical game world.
-"AI" refers to generating NPC behavior at a non-trivial (i.e. non-scripting) level.
-"scripting" only refers to designers using tools to create gameplay experiences outside of AI.
Within your AI group, you may then have a certain divergence of job responsibilities, such that some of your AI developers are more oriented toward tools and R&D and others are more oriented toward working closely with designers to help iron out the design and perform requirements analysis.
Posted by Paul T at August 2, 2005 07:50 AMGreat points all around, I must say!
Kind of a side note/bit of anectodal evidence of AI/Design misunderstandings.
I gave our AI programmer quite a shock today by suggesting that making the AI in our sports game quite "transparent" (giving feedback to the player about the AI's current "emotional state") is actually a *good* thing for game design. Rather than having AI which runs around with its own agenda, the team mates become an extension of the player, reacting in predictable ways so that the player can make intentional plans with their behaviour in mind. It's a pretty manic game, so we'll see how it turns out in time. I think it makes sense, but it's often quite a shock to the "Game AI needs to be realistic" school of thought.
The analogy we love to use here is that just because you have girlfriend who you just can't figure out doesn't mean her reasoning isn't sound. Everything she does seems random, but still, you really enjoy trying to figure her out. The reason you never can is because there's not enough information there to do it! She is perplexing and thus compelling, because you want to grok her patterns (not a euphemism). Even if you manage to figure her out, there's no reason for her to get dull. She'll always surprise you with something logical, but new. And before anyone says it, no, my girlfriend is not a robot. If only! I'd do a robot. ;_;
Even when you figure game AI's patterns out, there's still joy in interacting with them: manipulating them to your own advantage, or taking them on in combination with other AI or contexts. Serious sam's creatures are all pretty simplistic, but you put a bunch of them together, and it's like a crazy combineable puzzle, with many different solutions!
I guess a preconception in AI is that AI controlling humans should be human-like, when actually, that level of complexity becomes percievably random to all but the most ardent player. And at that point, it's fairly useless to someone who wants to manipulate the AI as an extension of their own abilities - distracting guards in a reliable way, for example. Realism is often not what a game design needs from AI.
This is the kind of thing I can make AI coders aware of, and talking to our AI graduate, I have a crap load to learn about the use of AI. Some of the knowledge already crosses over, however. The most interesting parts for me have been about emergence and local minima and such. You start to grasp the ways in which you can actually *wield* emergence, rather than treat it like some kind of black magic.
What's the rule? Inspiration can come from anywhere! Knowledge is power!
Posted by Aubrey at August 2, 2005 08:16 AM
"I'm very interested in the notion of a 'Lead Technical Designer' who sits between traditional Design and traditional Programming, with a team of TDs under them implementing content."
My definition of design is such that I find it very difficult to distinguish between AI and Design. AI defines the rules governing behavior for game entities... design comes up with the game's rules... how can design not be involved?
"How does this compare with other people's organisational experiences?"
None of the companies I've worked at really seem to understand this too well. One project I worked on, the level designers were left spinning their wheels, building empty maps with essentially no gameplay (short of basic navigation) for the better part of a year until the AI programmer got the enemies working.
The place I'm at now, I'm not sure exactly how much the AI programmers think about design. None of the designers are very technical, which I hope I can change.
I'm kinda uneasy about talking about this stuff across disciplinary lines, because when I talk about how AI is a subset of design, I feel like I'm telling the AI programmers that I'm after their job, or that design is much more "important" because it's inclusive of so many things. When really that's entirely a matter of interpretation.
The game industry is full of people insisting that their particular contribution to the development process is the most important one, that everyone else is just there to implement their grand amazing vision and take care of the annoying details. Design has considered AI an "annoying detail" for too long.
I'm sick of it all; I just want to see more communication between the departments, because holistic thinking, top-to-bottom conceptual coherence is only getting more vital as games get more and more complex.
Posted by chmmr at August 2, 2005 08:23 AMI've been relatively lucky in that I was able to forge a good working relationship with the designers from the very beginning on the title I work on. Working together we've been able to craft the gameplay and AI to compliment each other, and while AI has not always been working for much of the project, all things are done with an eye to how the two can compliment each other. I would say that the majority of my tasks have not been to figure out what is better than an FSM (and to be honest, I think there's quite a lot you can get out of an FSM if you stop thinking about it literally and get creative with it), and instead working on data mining our game or crafting algorithms to give complex behavior with simple and understandable feedback to the player. I don't think we'd have nearly the high quality of gameplay if the AI group was not working with the design group to make sure that both parts were always complementing each other, and the bonus is that many AI techniques fit in nicely with creating strong gameplay.
The day I became a happy AI programmer was the day I realized that people had more fun figuring out patterns than working against a "human" opponent that is more random and always reacts "intelligently." The reason for this is because most humans are extremely patterned themselves. Given a small enough subset of interactions with an environment (say, a game controller) you can easily find the patterns in the noise and then code thos patterns into your own AI. As long as you keep your AI close to it's patterns (I like to say they stay in character), people will anthropomorphize your drones much more than if you actually tried to make it realistic or to give it a large set of actions to stochastically pick. This works even in a one on one environment (fighting games), not just in a one on many environment like in Serious Sam.
As for scripting, I would say that it has great relevance to AI because you can use AI techniques to enhance scripts such that the characters involved do not always have to react in the exact same way. Say, for example, you have a script that shows a squad of soldiers walking next to an explosive device. As that device goes off, instead of having a scripter define the exact behaviors every single soldier takes, you could instead have the designer set up the goals he wants to the script to achieve (the medic helps the wounded, the communications officers calls for help, etc) and leave the exact implementation of those goals to the AI team. Suddenly you have a script that can play out in a number of ways, and even change the makeup of the squad (say the player puts together his own squad and you want them in the script) and still get a great script. Ut requires less work from the designer and relies on the fact that behavior is the baliwick of the AI group. The drama of the moment could even be completely changed by the same script depending on if the squad is comprised of all green recruits, or all grizzled veterans, and the bonus part is that the drones all stay in character! This should be the goal of all AI, and one I would say I have yet to see realized in most games.
Posted by SL at August 2, 2005 12:51 PM> [Aubrey]
> I gave our AI programmer quite a shock today by
> suggesting that making the AI in our sports game
> quite "transparent" (giving feedback to the
> player about the AI's current "emotional state")
> is actually a *good* thing for game design.
Not only is that a good thing -- it's absolutely essential! Internal AI state is far more useful to the player when it's made transparent to the player, such that the player can get some sense of the AI's behavior pattern or its internal cognitive model.
A huge part of the AI in the Thief games, for example, is broadcasting internal state (disclaimer: I worked on AI for the third Thief game, but the ideas I mention here have been a part of the Thief series from its inception).
In Thief, you're essentially playing a big game of hide-and-seek with the guards, and you spend a lot of your time creeping around and trying to hide in the shadows. So while you're sneaking around, the guard NPCs are continually broadcasting their thoughts, and making their internal state as clear as possible:
(idle state)
"Dum da dummm dummm ... Not much goin' on around here, no sir ..."
(entering alert level 1)
"Hey! What was that? ... I thought I heard something ..."
(entering alert level 2)
"Hello? Is anyone out there?!?"
(entering alert level 3)
"ALL RIGHT, COME ON OUT, YOU TAFFER!!!"
(back down to alert level 0)
"Oh, well ... I guess it was nothing."
A lot of action/platformer games have a very similar concept, where enemies will specifically play a big, obvious "telegraph" animation before attacking the player. Once the creature has done this once or twice, players quickly pick up on the association and can use the telegraph to predict the attack that will follow and take the appropriate countermeasure (dodging, switching to a different weapon, or attacking a critical body part, for example).
Posted by Paul T at August 2, 2005 12:55 PMhttp://www.antifactory.org/cgi-bin/wiki.pl?Perceivable_Consequence
Many damn solid designs (and some of my favorite games) are best at this - Castlevania, Doom, Thief, etc
Posted by chmmr at August 2, 2005 01:53 PMPaulT wrote:
> -"AI" refers to generating NPC behavior at a non-trivial (i.e. non-scripting) level.
> -"scripting" only refers to designers using tools to create gameplay experiences outside of AI.
These definitions admit that scripting creates some NPC behaviour, but suggests that it is 'trivial' (unlike the AI behaviour). Fair enough I guess. Certainly this is the general approach within the industry today. However, I feel there are two major problems with most people's application of this view.
First, scripts are to provide "Gameplay experiences outside of AI" which are in many cases involve "NPC behaviour". This weakens the contribution that AI systems can make to *all* aspects of NPC behaviour.
Second, this sort of scripted behaviour providing "gameplay experience outside of AI" often means 'narrative-related behaviour' of some kind, as opposed to general rules which span the entire game. Such behaviour is certainly not "trivial", as other threads on this blog and at GrandTextAuto will attest :)
My original point about a separation between AI and Technical Design was really just to suggest that scripting should take advantage of AI, and AI should remember that its general systems always manifest themselves within a scripted scenario*.
SL wrote:
> As for scripting, I would say that it has great relevance to AI because you can use AI techniques to enhance scripts such that the characters involved do not always have to react in the exact same way.
This is a nice example of the kind of stuff I'm talking about.
* - Note, obviously none of this is meant to apply to all genres or all games universally.
Wow, take a week off to write a couple aigpw3 articles and look at the fun you miss.
Too interesting to not add my two cents. Bungie, I'm happy to report, is a place where the line between design and AI is blurred in all the best ways. For some time, I've considered myself a programmer/designer, since even the most detailed specs remain far vaguer than an actual implementation. Consequently, it's up the AI programmer ultimately to decide on what at the lowest level feels right, looks right, and is just fun. Meanwhile, the rest of the organization appreciates the role: AI sits in on all character brainstorming meetings(including, for example, concept art review, to head off implementation nightmares and to point out fruitful directions) and a good deal of the mission and story meetings. So far from the experience of being involved too late in the cycle, AI is never UNinvolved.
At the same time, we are blessed with some extremely technically-inclined designers: not only are they WILLING to dive into implementation details (how EXACTLY does this HFSM work? Where is the tree stored? What are the conditions on the blah-blah-blah behavior?) they DEMAND to. And the magical tools that we talk about -- the development of which IS a huge chunk of my time -- are designed by both AI and design together.
The Ai-as-the-black-box syndrome is CLEARLY rampant, and yes, it is distressing it seems a lot of designers don't yet realize that AI is one of the most important tools in their toolbox. I'm not sure I'm disappointed they don't know how genetic algorithms work or what bayes nets are -- *I* know what they are, and I'M not sure how I would necessarily apply them to games. But that (or "if", I should say) they don't realize the degree of design-expression a solid AI engine might afford them is cause for concern. It's sort of like saying "wow, I didn't realize the rate of fire on this gun was really a design issue!"
Posted by naimad at August 2, 2005 09:40 PMAh! Thief was going to be my other example. The Barks are especially priceless in that you don't even have to SEE a guard to know what they're thinking! And when you DO, the animation gives parrallel signal regarding a guard's alert state.
A simple rule of thumb we use here when scripting: never let AI do things that the player can't. It really only applies very specifically to the game we're in pre-production on, but there are good reasons: by using actions that ARE available to the player, you are teaching the player that they are able to perform the actions in the script (moving, shooting picking up and dropping items etc.). Showing one interesting possibility which the player may have overlooked ought to encourage the player to be creative about their approaches, as for far too long, games have taught players to stroll down a corridoor and LIKE it - "Fake Interactive Fiction" as Mark Barrett puts it. The collory is that showing AI doing something that the player cannot will agitate the player to some degree - "Nice cutscene, but why can't *I* do that?".
You can still perform (non-trivial! :D ) narrative devices, but your available language simply becomes that of in game possibilities. I believe that this helps to keep the game world consistent. "This is the world, and these are the tools, and no-one is allowed to arbitrarily step out of these rules. Time to get creative within this space".
I think I'm going to be going off track at this point... sorry.
The other nice thing about scripting by stringing together base vocabulary is that so long as the AI is adaptive enough (can figure out and get from A to B, and knows how items are utilized), these cutscenes can play out anywhere, rather than tying them to specific locales. The player may choose never to visit these places, and so a useful training tool is lost! Ideally, you can get the scripts to spawn wherever a player is currently facing, rather than manipulating them into looking in the right direction, HalfLife style.
Posted by Aubrey at August 3, 2005 05:06 AM
'It's sort of like saying "wow, I didn't realize the rate of fire on this gun was really a design issue!"'
Sadly, at some places, that's considered an Animation issue :(
Posted by chmmr at August 4, 2005 10:07 AM> Sadly, at some places, that's considered an
> Animation issue :(
:O
!!!!!!!!
Posted by Paul T at August 4, 2005 10:15 AMOr there's the always confidence boosting "I really don't know if this'll work, but try it anyhow!"
Posted by Aubrey at August 5, 2005 04:48 AMGood news: we've been linked to from GamaSutra (http://www.gamasutra.com/php-bin/news_index.php?story=6136).
Bad news: the author sums up this comment thread as follows:
"The responses are various, but generally focus on the thought that AI doesn't need to innovate; it just needs to find better applications amongst the games yet to be made. An interesting first thought from Lionhead's Adam Russell suggests that AI innovation is going to be hard to come by in the near future since neither commercial teams, nor academic researchers, are producing much that pushes the discipline forward. It is perhaps artists to whom the AI programmers must look for their future, since it is only through their work that AI will find new challenges to fulfill."
:O
What the hell ...?
FYI, the GamaSutra editors were kind enough to edit their summary of our blog. Thank you Simon Carless!
Still, though, it's scary to think some readers may have been led to believe that these comments indicated that we don't believe AI needs to innovate, that neither commercial teams nor academia are doing anything to push the discipline forward, or that we need to turn to artists for interesting AI challenges.
For the record, I don't believe any of that, and I don't think anyone else here does either.
Posted by Paul T at August 5, 2005 11:04 AM