Before my GDC panel this year, AI & Designers: Mind the Gap, we did a preliminary e-mail thread as a warm-up. For readers who couldn’t make it to the conference (or to the panel itself), our back-and-forth might give a little taste of what the discussion was like. Of course, some of the questions were only ultimately answered during the panel itself, but it’s still worth a read for developers interested in the topic.

Here’s the cleaned-up transcript:

Soren Johnson: So, GDC – and our looming panel – is about three weeks off, so I figured it might be a good idea to do some pre-panel chatting to help get our ideas rolling. My original thoughts for this panel come from my own experience as a designer and an AI programmer. Essentially, I’ve always enjoyed being able to do both jobs at the same time because there is just so much overlap between the two. If I was only an AI programmer, I feel like I would get frustrated with designs that are impossible for an AI to handle. And if I was just a designer, I would regret not having total control over how the AI performs because that is a core part of the user experience. However, most of the industry separates these two roles, and I am curious how well it works. It seems like one of the two sides would always be dominant, depending on the make-up of the particular companies and probably to the detriment to the game. So, how has this tension worked (or not) for your teams? What are the best ways to manage this process? Any horror stories from past projects? Other thoughts?

Tara Teich (AI Programmer, Double Fine): There were two areas of interest for this topic to me.  The first was the issue of the different mindsets of designers and programmers.  Frequently, the issues I’ve had have come into play because designers and programmers come to the table basically speaking a different language.  A designer asks for feature X and the programmer goes “oh, ok, great” and goes off to implement it.  The result isn’t what the designer was asking for at all!  Basically, designers think of the experience of the player, programmers think of the how of implementation and they’re not always the same thing.

The second was about planning for change.  A good AI programmer will know that designers are GOING to change their mind and will build space into their system for as many aspects of it to be changed or even reversed as possible.  But if the programmer doesn’t do that, every new request from design results in a frustrating complete re-write of the system.

Alex Hutchinson (Creative Director, EA Montreal): My favorite part of the job is collaborating with engineers as I see the overlap between design and engineering as the heart of what makes games unique and special. I also think that it’s the path to getting more than either side could do on their own – my new way of working is basically to very clearly articulate the ‘why’ of a feature, then have no more than a couple pages where I try to work out the actual nitty gritty of the design. My goal with that is to have basically 80% of the idea clearly articulated, then I hand over ownership of the feature to the engineer, and we have regular discussions about it and eventually the goal is that they present it back to me and they’ve not only filled in the remaining 20% but added another bunch of stuff themselves, so we get more (hopefully) than if they’d done it on their own, or if I’d written down a hermetically sealed spec doc.

That said, it also relies on both sides being smart, easy to work with and fond of collaboration not dictation, so it’s based on people IMO.

Soren: Have you, or anyone on the list, experienced much with trying to put the AI parameter tweaking or simple algorithmic mods directly into the hands of the designers? It seems this would go hand-in-hand with building a flexible AI system instead of one overly specialized, like you mentioned. However, something like this was attempted in Spore before I came on-board, and we eventually ripped it out because there were just too many gotchas for the designers to trip over because the interface separating them from the code was too weak. I imagine it could work though, but I wonder if it would be worth the overhead of worrying about all the edge cases that probably will never be hit.

One question I always find interesting is whether a design idea should be judged separately from the AI’s ability to use it. Apparently, DoW2 is having issues with this as their AI doesn’t seem to be able to handle many of the special abilities available in the game that ARE still fun for the humans. With Civ, I was constantly resisting features like this – I avoided paratroops, invisible units (spies, submarines, hidden nationality units like privateers) – because I felt that the time spent on building AI to handle these special cases would be better spent on just the core AI problems. To me, it was just literally a cost/benefit tradeoff decision. However, I’m not sure if I made the right decision as players love these type of units. (and, inevitably, whatever units I cut were added by the looser expansion teams…) So, when does the plus of a player enjoying a tricky feature outweigh the minus of a hobbled AI?

Tara: One of the choices I’ve made on occasion is to just make it look “good enough.”  If you have an element that is really fun in multiplayer, and your game is very multiplayer-centric, then leave that feature in, and just make it look like the AI is utilizing the feature.  I’m not sure what the DoW2 issues are, I’d be interested in looking at the examples, but sometimes something is fun to the player not because it’s effective but because it’s unique.  And just seeing the AIs utilizing that feature and looking like they are “having fun” with it is sufficient from a player experience POV.

In terms of Soren’s earlier question about just handing the knobs and tuning parameters to the designers, I’ve found that to yield mixed results for similar reasons that you cited.  Too many knobs means they have to completely understand the underlying mechanics of the system instead of just being able to tune in the harder/easier dial that they really wanted.  I found for RTS games they really liked to give input on which units the AI would build and in what order, which type of battles the AI would prefer to fight, but the specifics of how to fight that battle, which builder should create the unit etc was up to me. Fun. 😀

Adam Russell (AI Lecturer, Derby University): Sorry for the delay in responding! I too am fascinated by the complex interplay between game AI engineering and gameplay design. I agree with you Soren that it’s very difficult to separate them cleanly and that’s what makes it such a fascinating area for me. As a programmer, I loved being given the chance to influence the game design through my AI architecture even though I couldn’t pretend to be a true game designer. The key issue for me is if both “sides of the fence” are in fact contributing to the game design (for example an 80/20 split as Alex suggested), how do we reconcile or align their contributions so they’re not pulling in different directions or contradicting each other? One way of looking at that is as shares on a linear spectrum of design scale: “Designers plan down to this level of granularity, AI fills in the rest of the details.” But both AI and design must consider game-spanning features in their own different ways, so the scales sort of conflict.

Another way of looking at it that I find very appealing is if we try to make the contributions orthogonal to each other: “Designers request diverse experiences of these kinds, AI builds a systematic infrastructure that knits it together into a logical whole.” Then for me it becomes about what representations the AI should offer to design, and the AI almost becomes a foundation or a space in which the design can move. Of course, that space should ultimately be built for the design, so there is kind of a circular process here. Design lays out the themes that give rise to the AI foundations which then defines a space within which they can do design.

For me this all goes back to Tara‘s point about the disciplines speaking two different languages. It’s frustrating but good that they speak two languages, because that gives them orthogonal concerns which can coexist. But it’s an ongoing challenge to keep the experience designs anchored in the AI framework, and the AI framework driven by the need to deliver key experiences. In my view both sides must give up ownership of certain issues which are best answered by the other. AI programmers must give up the desire to reduce everything to one generic system of moving parts (because this undermines the uniqueness of the experience design), and game designers must give up the desire to control experiences down to a very high level of granularity (because this undermines the robustness of the underlying AI frameworks).

I suspect this problem is less acute in strategy genres than in my area of action-adventure character AI. It seems that strategy designers are reasonably close to the mindset of AI programmers because they think in a very holistic way about game mechanics, whereas a lot of action-adventure designers have pretensions toward recreating experiences from linear media such as film, which conflict badly with AI systems (e.g. “make it so that they always do this when the player enters the room at that moment”).

On the other hand, that similarity of mindset in the strategy genre might be a recipe for trouble, given what I said earlier about the need for orthogonality? I don’t know because I really have no development experience in the strategy genre.

Josh Mosqueira (Creative Director, Ubisoft Montreal): The DoW2 examples are, I think, legacy from the same issues we had on Company of Heroes (both games use the same tech). Ability use was something that always dogged us, so much so that for CoH we scripted all that behavior into the missions. For MP, it was tricky. When to pick it, how to use it without being too effective. In the end, we lived by a Tara’s mantra… it doesn’t need to be perfect, it just need to be good enough.

Now, whether to keep or axe a feature based on how well the AI can use it… that’s a tricky question. Speaking purely as a designer, I’ll always err on the side that having cool units and abilities like paratroopers and invisible subs add to the gameplay. I agree with Tara, as long as the AI looks “good enough” when using these units I think it’s a win-win. Then again, I take a very player-centric POV. I rather have as many cool toys as possible.

Now a question… what designer/programmer assumptions do you guys run into all the time while working on AI?

The one I do quite often is that the AI should be “hard” and punishing.

It’s an attitude I get often… that only “hard AI” is fun. I get this from designers and programmers. Whenever I say, “the player should be able to predict the AI” the reaction is “where’s the challenge in that?” To which I answer that while we may think we don’t want predictable AI, we need to give the players enough cues so that they can make “smart” decisions to beat the AI (without making them too transparent). I love Halo for this.  Why do we always want to punish the player to prove our AI is smart?

This is something I spend a lot of time working on, understanding what the function the AI serves in the game. For me it has to be more than just challenge because if that was just it, then the Gombas in Mario Brothers, or the waves of Space Invaders are all we need.

I like to think that AI is our greatest tool to control the dramatic pacing of the game, but if you ask me, it’s our greatest storytelling tool. No, I am not talking AI actors but using AI to craft a proper intensity curve that has the right peaks and valleys to create an experience where the player feels like a bad ass (the peaks), and when he’s scrambling and being reactive (the valleys – which make the peaks that much sweeter).

Basically, the AI should be seen as the players’ “event coordinator” or “party planner.” In other words, it’s not the cut-scenes or powers that make a game fun, it’s the AI. AI is in charge of the player’s morale. When people talk about their game experiences, say with Half-Life 1, everyone remembers when they first time they run into the marines and how they used cover. The “oh shit” moment defined the player’s narrative of the sequence. Powerful stuff.

Maybe I feel this way because I’ve worked on too many games were the AI is brutal towards the player and it’s a knee jerk reaction. I’ve been guilty of being too hard on the player.  But part of me does think that for AI to evolve we need to shift its function from being only about challenge and obstacles.

For example, take this great article on Game AI: http://www.bit-tech.net/gaming/2009/03/05/how-ai-in-games-works/1. There is nothing in there about what the role of AI in games is.  Granted,  the article is about “How Game AI Works” but this is something I always find I run into. We tend to focus on the details (effective use of cover, believable reactions, smartness) that we lose sight of the real intent – fun.

Which brings me to the topic of collaboration. Not being a programmer, I won’t pretend to know how best to design an AI. What I focus on is trying to convey to the programmers what the intent for the AI is, how does it add to the game experience and what things I want to be able to tune to control the intensity curve. I know that for every variable I get to tune, there are dozens of knobs that the AI programmers have to implement and tune themselves, which is why I like focusing on how the AI impacts the player’s experience. How should it react, how should it challenge the player, how does it look smart without being too smart.

Alex: Yeah, I agree with the drive toward punishment as being a big problem – often people seem to confuse AI that will ‘destroy you’ with AI that is ‘good.’

I know that Sims 3, for example, is working on a big system where AIs can form long-term goals, such as ‘own a mansion,’ then build a plan, then step through all the behaviors that lead up to that goal. So the sim will pick up the paper to get a job, go to work for X period, buy only essential goods, save their cash, get promoted by working hard, focus only on important relationships, and then eventually buy the mansion. And when you describe it to a player it sounds amazing, but the problem is it’s essentially invisible to the player – they won’t see this glorious narrative, they’ll only see a few outcomes. My argument is you could have either scripted it, or made it semi-random and to the player, it’s the same system. The AI engineers obviously argued with me on that, but unless you’re going to invest in a strong system for showing the player the plan and the execution of the plan, it’s not interesting IMO.

Similarly, in action games, engineers are arguing with me at this very moment that they should do the ‘smart’ thing, and take cover appropriately, never expose themselves, sprint to new cover when their cover is breached and what that would essentially do is remove any chance for the player to win in a fun manner. If I flank an enemy, I want him to react in shock, show me that he knows his cover is breached, and then essentially let me shoot the crap out of him. If he flees and I miss him, I am no longer having fun.

I think the essentially point for me, as Josh points out, is that AI is there to support the player experience, not to be ‘good AI’ whatever that means, in and of itself. 🙂

Josh: That’s one of the issues I have with working on AI… if the player cannot see how the AI works, then it doesn’t really matter how “smart” it is. I hear you on the cover deal, Alex, I am having the same arguments here.

As a former infantry sergeant, I know the smart thing to do is to move from cover-to-cover and use concealment. Thing is, if a player cannot “see” all that fancy leap-frogging, then it doesn’t matter. It’s just frustrating. This is why I always argue we don’t want “smart” AI, we want reactive AI. The AI needs to react to the player in a way where the player can, by mastering the game, predict the AI’s reaction and feel like a bad ass when they flank and AI position. A common thing I get is for an AI programmer to show him some cool behavior using a top-down camera, but then when I ask to see it from the game’s default POV, I have to break his heart and show him that I can’t see it so I cannot appreciate the clever cover-seeking AI.

While this is very true of action games, it’s also true for RTS games. It wasn’t until we added a ton of barks (about 20K lines) to the Squad AI system for Company of Heroes did people really start to appreciate it. Before speech went in, a common comment was “the AI looks too chaotic, not sure what they are doing.” Then when we added speech, the reaction to the same system was “Man, that’s cool, they’re covering each other and, look, that guy is trying to lay down suppressive fire.”

It’s all in making sure that the hard work that goes into AI can be appreciated by the player.

Tara: The one place where a lot of that smart cover behavior is successful is when you have friendly teammates.  When you’re in the lines with them and you see them doing the leapfrog behavior, that’s great.  But you’re totally right, without dialog for them to say what they’re doing, to the player it still probably wouldn’t parse well.

Soren: I definitely appreciate the limits of “hard” as opposed to “fun” AI. The thing is, they both have their place, depending on what type of game you are making. For symmetrical strategy games, the game should still be fun/challenging once players have mastered the systems. Many strategy games fall down on this front (listen to Tom Chick talk about how Empire: Total War loses interest once the player masters the mechanics here) as the challenge for the player is just learning how to juggle multiple plates, not actually engaging an AI as an equal player. On the other hand, I was painfully aware from developing Civ that we don’t want our AI playing cutthroat games like a human would (i.e. being willing to backstab the player at any time just because it suited them). It’s a tough problem, but at the very least, I think it is important that they AI be able to handle all the game options in a symmetrical setting because strategies are often good or bad only relative to the choices of your opponents. (If the AI never uses submarines, I don’t need to build any cruiser to see them.) Of course, for asymmetrical games, like most shooters, the purpose of the AI is quite different, and it is irrelevant if the AI can use all the abilities the player has.

Josh: Excellent. Controversy!

Well, not really since I agree. It’s a conundrum, especially for symmetrical games as you mention. The AI needs to be deep enough so that it provides the right challenge for your 5th, 50th and 500th game.

How do you all handle how saleable you want the AI to be? Granted, not so much an issue in action games, since most AI does not live for more than 30 seconds and you can use tuning to handle challenge, but you’re right, for strategy game this is a balancing act.

On CoH we tired (and failed) at making the AI more “efficient” and ruthless as a game went on, but that didn’t work out. It was too obvious you were playing an AI, because human opponents, even our hard-core professional players didn’t play that way.

Tara: Could you elaborate on what you mean by “efficient and ruthless” and why that was a failure?

I worked on real-time strategy AI for about 5 years, so I’m curious to hear your perspective on it.  My philosophy was always to make the AI as hard as I could make it because it still wasn’t gonna be as good as a human.  Then add difficulty levels that crippled it on the easier levels and give it some perks on the higher levels because making a non-cheating AI that’s better than a human… well, I don’t think we’re there yet.  Partially because it makes no sense trying to encode things by writing complex AI that players figure out from intuition when we can just “cheat” and get the answer in one line of code.

Soren: Let’s phrase the issue a different way – especially in light of our specific topic of designers and programmers. What was the reason that the CoH AI ultimately failed? Was it a lack of AI resources or time? A flawed development approach? Or was there anything about the design that was out of step with what the AI programmers could reasonably accomplish? And if so, how much of the core game experience would you be willing to change if it meant a more robust and interesting AI?

It’s ok if the answer is “not much” or “that wasn’t really the issue”, but I want to take a stab at figuring out how to prevent the AI ultimately failing in future projects. How could the designers and programmers collaborated better in this case so that a better conclusion could have been reached? Or is this problem just intractable?

Alex: There’s also the secondary issue of all the other departments – as hinted in Josh’s email, I think bad animation or bad audio can also kill the AI. You could have a strong design and a great implementation, but if it isn’t communicated then it’s going to fail. In several recent focus tests (and this is more applicable to action games than strategy games), I’ve seen people say the ‘AI was bad on this level’ and the problem was actually a bad or missing animation. Players often confuse and overlap the feedback with the function.