The AI Summit earlier this year featured a discussion panel about the tensions between design and programming — and particularly AI. Since AI is such an integral part of gameplay, innovation on the technical front must be matched in equal measures in design and methodology. This session looked into prototyping workflows, methodology and interaction, as well as tips and tricks from experienced designers and coders.
Participants: Alex Hutchinson, Soren Johnson (moderator), Joshua Mosqueira, Tara Teich, and Adam Russell
The Design of Game AI
Soren started the discussion by asking how much we design for ourselves (as players), compared to how much design for the AI. Alex replied by saying that good AI is built to be beat. Tara, however, pointed out that AI must still look smart and not seem like it’s being defeated on purpose; this is a tough balance from a programmer’s perspective.
Josh continued emphasizing the perception of intelligence to the player; in Company of Heroes adding speech made a huge difference in the perception of intelligence. Adam talked about designing the pub AI in Fable from the wrong perspective, without the player being in the simulation. Alex agreed with this, that the view of the player should be used to design the behaviors.
“rand() is often good enough; don’t write too much code.”
Tara pointed out that simulation is indeed cool, but we tend to get drawn into it too much as engineers. Soren asked, “What is the AI for?” and explained how the design of AI features in Civilization was driven by their use in the overall design. Tara talked about how rand() is often good enough; don’t write too much code.
Adam discussed the self-indulgent aspect of building game AI: it’s often a game in itself! Alex thinks you must design games in a systematic way, with optional special cases (these are interesting and memorable); a game needs regularity or it will collapse under its own weight.
How to Train Your Designer
In reply to Soren’s question about how to train designers to be more systematic, Alex replied that good designers often learned appropriate lessons the hard way. In the end, you need people that are headstrong and who can make compromises at the same time.
Tara thought programmers often try to find a system of how to do things, whereas by nature designers just try to create. Here programmers have a certain responsibility to keep designers in touch with feasibility and to tell them if their ideas won’t work in practice. Out of experience, Alex pointed out the problem of programmers knowing something is wrong but wanting to prove it to you by trying it anyway.
Foto 1:Tara Teich
On the other hand designers also should be able to think like programmers, in Adam’s opinion, who mentioned Michael Mateas work and “procedural literacy” in this context. Continuing along both lines of the argument Joshua said that an approach from two different directions and a certain amount of friction which comes naturally with it can help improving the result, especially for small teams working closely together like scrum teams.
Agreeing with Adam that thinking like a programmer is very useful, Alex mentioned that it helps if you to ask for appropriate features — and explain yourself better! You can spot a clear sign of misunderstanding if the AI programmer will talk to everybody else but the designer about a problem. In this case it often comes down to the information given by the designer being incomprehensible or the programmer not knowing how to deal with it. For him one solution to this problem is not to design a 100% but to clearly communicate the idea and reason behind a feature. If a programmer understands an idea well he might even come back with more than you asked for in your original sketch. There are a though some “reported cases” of the exact opposite approach — meaning designing a meticulous 150% — working well with certain programmers who like to fix systems.
In response, Adam then asked if the solution for finding the middle of the spectrum between micromanagement and freedom lies in group dynamics and production processes.
For Tara, the crux lies partly in relationships; to be a good AI programmer you have to interact well with others. Besides, what is true for designers also applies to programmers... There needs to be a bit of a designer in you for designers to trust your abilities in this regard. Adam added that tools programming is all about the interaction with the one you build the tools for. He recalls a question Robert Zubek brought up in a conversation, asking if in consequence AI programmers are only tools programmers. Although Adam sees a tendency towards AI programmers building more and more tools for designers who then craft highly authored and scripted narrative events, in the end he hopes for the AI to push design forwards as well and not settle for only making tools.
Screenshot 1:Company of Heroes
Replying to Adam's original question, Joshua repeated his statement that it’s better to approach things from both directions. As an example he mentioned his collaboration Chris Jurney on the squad AI in Company of Heroes and their fair amount of exchange and interaction. Chris brought a lot into it as well — even if that meant not doing everything Joshua asked Chris to do, in Joshua’s opinion the end result was better than if he had had his way a 100%.
In response, Tara pointed out that the amount of possible input from an AI programmer also depends on the genre of the game. Although there is a certain ownership of the system by the programmer in strategy games, the situation in first person shooters can be very different up to a point that the story is completely scripted and designed. Overall she thinks that metrics are important and more specifically laying down some ground rules what designers can do and choose from to keep them within the boundaries of feasibility.
Alex agreed and added the role of artists into the equation, as theye bring in their own set of rules of what is possible or not. As an example when dealing with cover objects he mentioned that you have to consider that e.g. a car with only one meter in height is very challenging for artists to say the least.
Foto 2: Alex, Joshua, and Adam
Soren then moved on to the next question for the panel on how to make sure AI programmers get the feedback they need. Remaining on the topic of feedback in general he also mentioned in a side note the responsibility of AI programmers to give feedback to the players and show them all the cool stuff they’ve got in their code. Alex explained a take-away from his experience playing Call of Duty where he saw things on his 4th playthrough he had never seen before. The lesson is to make sure cool stuff is not only discovered by a small minority of players. People who play a game a lot — be it players or designers — already know where to go for the cool stuff but those playing a game only once surely missed it.
Adam confirmed that lot of AI programming is becoming about presentation these days. Coming back to Soren’s first question he inquired on how the relationship between programmers and designers should work and if AI programmers should stop thinking design.
As an answer, Alex stated that ideally it’s a relationship where both sides want each other to succeed. If an AI programmer / designer relationship was only about services it would fail. It needs to be a collaborative debate, even if that sometimes means forcing both sides to discuss and work together.
“Be careful with programmers’ tendency to optimize things - the AI always doing the right thing is just not fun.”
Soren remained on the topic of relationships with the question about what traits do programmers have that can cause friction. In Joshua’s opinion you have to be careful with programmers’ tendency to optimize things and to approach everything in a very logical way. There is the danger that you end up with too much optimization were the AI always is doing the right thing — which is just not fun anymore. Adam endorses Joshua adding that the question of how to make plausible mistakes — like a human — is a challenge for AI in a traditional sense. We don’t have a good model for making the right kind of mistakes at the right time.
Alex continued, the AI should give the player just enough time to think about how he can deal with a certain situation and then respond to that in an interesting way. For Joshua the challenge especially in RTS AI is to make sure that the player understands exactly what the AI is doing and why so that he can respond to it appropriately.
To Cheat or Not to Cheat
Moving to the next topic Soren asked about how the other panelists felt about cheating AI and how programmers and designers work together to figure out how to cheat “well.” Tara emphasized two things to avoid: first the AI should not cheat when it could achieve the goal also without, and second if the AI is cheating the player should never be able to tell that it is doing so.
One way of reducing crossover inside the code is that the larger and more complex an AI system gets the more you should design it in modules as Adam explained. Also having a semi autonomous animation engine that can be controlled by the AI or the player so that one level of AI doesn’t know anything about the other layer can prevent the tendency of programmers to use cheats.
Alex commented that sometimes cheating can be a design question which can be more easily accepted by the player. Tara added that in this case cheating has to be done within the rules of your game, and Alex emphasized the need to be coherent in terms of applying the same game rules to the AI and the player.
“Don't get caught!”
The most paramount rule to follow for Joshua is: “don’t get caught” and Adam continued that there is a lot of cheating which is perfectly valid such as a NPC that should not die or respawn continuously. Cheating gets problematic if the AI is fighting against a player strategically or tactically and is using information it should not have.
Soren explained that it’s all about the user experience and that players often don’t remember when good things happen to themselves but even more if they happen to their opponents. He used Puzzlequest as an example where the developers assure that no cheating is taking place but some players nevertheless are convinced of it. A consequence for him is that sometimes you should cheat against your own AI so the player’s perception is balanced.
A player’s perception is reality, Adam said, and it doesn’t matter if the AI really is cheating or not — if the player perceives it as cheating the AI might as well be. Going back to Soren’s example of Puzzlequest Tara adds that this is especially true if a game’s result depends so much on luck as it does in this game. It is almost better to restrain the AI so it can’t go from almost losing to winning just “by luck” in order not to create a frustrating experience. Alex counters that this is a slippery slope and that rubber banding is to be avoided. If there is no challenge and if the game is too easy it quickly gets boring and looses the sense of achievement for the player.
If You Could Turn Back Time...
Moving on to the last topic of the panel Soren asked about the panelists’ past project experiences and what they would do differently now.
Tara once worked on a project where the design was made without programmers present — which was a big mistake. She recommends that programmers should be involved in the process already in the early stages of development when designers are thinking about what’s possible. Being aware of programmers having a tendency to say no to too many things Tara suggested that programmers rather observe and give feedback on how things would interact at a system level.
For Adam a major mistake and a failure in the process occurred when he was working on Fable: the team creating the village AI and the town live simulation had almost no interaction with the scripting team working on the quest narratives. This created a particular collision when as a part of a scripted encounter you were supposed to talk to people in a town which were thus not part of the village simulation. These specific NPCs where in idle and stayed at the same place the whole day whilst the rest of the town’s live moved and buzzed around them.
Screenshot 2: Fable Town Life
In the trenches sometimes the obvious escapes you, is Joshua’s take away from his work on Company of Heroes. For the Squad AI they had a well working process set up with iterative loops and a good interaction between designers and programmers but when it came to the strategic AI these processes were not applied at all.
Alex biggest regret in Spore was that they did not take in account the things the player cared about early enough. Instead they tried to be too authentic about how they solved some problems. As an example he brought up that the planet the player exists on is identical from the creature, avatar kind of game, to the space RTS part of the game. They could have avoided the nightmare of having a sphere as a battleground for the RTS game by focusing more on the customers’ experience and custom built those stages instead. In the end they solved a very difficult problem nobody actually cared about.
Open Floor Questions
In the open questions part of the panel Neil Kirby mentioned that by exposing the AI to the player via spies or intelligence you could cheat in behalf of the player. Alex added that, while this talk did not cover all the means game developers have to communicate what is going on, like animation, AUI, art, audio etc., the more you can show about your AI the better the experience for the player.
Answering Dave’s question about if the solution to the gap would be a hybrid like an “AI designer” Alex mentioned “object engineers” at Maxis who were scripters designing objects which are the heart of the AI in the SIMS (the objects advertise to the SIMS what to do). In action games it is the level designer who is interacting with physical spaces and who is asking features from the engineers trying to manipulate the AI to use these spaces. Adam in turn knows an AI programmer who got fed up with the problems he had with designers and he moved more and more into design – now being a lead designer at Lionhead. Programmers there loved him for “thinking in their space” – in retrospect a very successful career switch. Also Soren agrees that these hybrid roles pop up more and more.
Photo 3: Soren Johnson
The next one stepping up to the microphone was a designer who, while working well with experienced programmers, was having troubles with inexperienced ones and was wondering how to best encourage them to come and ask questions if things are unclear. Tara advised him in this situation to go to them, stop by their desk and check with them directly.
The last question of this session asked if there was a difference in the programmer/designer relationship if it’s about collaborative AI (e.g. sidekick)? In Alex opinion social AI is a very different aspect that will become the future in games. Competitive AI is all about feedback, interacting with other characters and winning whereas social AI like SIMS and Animal Crossing has hardly any feedback, a very different problem space. Players don’t fail as much whilst being much more inquisitive and playing a lot more with the AI. When Adam was working on a companion AI system it was driven by the AI programmers partly because companions are around for a long time and close to the player. This means that there is a lot of unpredictability involved and that the player can observe the AI for a long time in different situations. As a consequence the AI design is dominant as there is less of “make the AI do this here and then that here” but much more of a general system.
Don't design a 100% but make sure the programmers clearly understand the idea and reason behind a feature.
As a programmer lay down some ground rules what designers can do and choose from to keep them within the boundaries of feasibility.
- Make sure cool stuff is not only discovered by a small minority of players.
If you have to cheat: never get caught by the player!
Taking in account the things the player cares about at an early stage can save you a lot of trouble.
To make sure you are and stay on the same page with your programmer/designer stop by their desk and check with them directly.