The Recipe for Good AI

I’ve worked on AI in a number of games over the years. Every nugget of wisdom I’ve picked up along the way points to one basic, possibly depressing lesson: creating a good AI is exceptionally difficult. Not only is it tough to make one that simply meets the incredibly low bar of not completely falling on its face – but even if you make a really, really smart AI it doesn’t mean you’ve made a good AI. After all, not everyone wants to be ruthlessly eviscerated by a merciless opponent. Some people are looking to roleplay, or just would prefer the AI keep the gloves on even when it has an advantage. Even those who want a serious challenge wouldn’t enjoy losing every game.

So what is the first step for a designer or AI programmer in this quest to prepare a five-star meal? No matter your task, the answer is always the same: identify your goals.

What Really Matters

Okay, so the lesson of “writing AI is hard!” is neither particularly useful nor surprising, but there is another so important developers must embrace it: all that matters is what players see and believe. Really. That’s it. The AI can cheat, act in or out of character, make dumb decisions, whatever – as long as the player is having fun that’s what counts. Developers are often surprised by which features players get the most enjoyment out of. “Wait, your favorite part of the game is the hats? That only took a day to implement!” Getting the most bang for your buck is important in all aspects of game development, but it’s absolutely essential with AI – the biggest meal of the year calls for the best ingredients money can buy.

AI is just like any other system in that there is zero value in it being well-engineered if the player doesn’t actually get something out of it. It’s incredibly easy to get bogged down in the details of how to solve the myriad of difficult problems that pop up, and never step back and realize you’re spending a ton of effort on a feature that doesn’t really contribute to the actual experience of playing the game. The risk of this occurring is particularly high with AI because much of the time it’s hard to tell if your code is even doing what you think it is, let alone doing it well.

Okay, so you’ve laid down some goals and have vowed to dutifully follow through on them. The next thing our recipe calls for is to identify what can go wrong with a game’s AI. The AI has failed if a player considers it to be either 1) too random, or 2) dumb. The job of an AI developer is to sidestep these pitfalls in any way possible. Let’s first talk about how to make an AI appear rational, and not simply random.



Preventing Random AI

A strategy for making an AI look less random is to actually make it less random. Sure, it sounds obvious, but how predictable or wacky an AI should behave is an important design decision. Perhaps instead of doing a random roll each time an AI unit can attack, a single roll could be done at the beginning of the war to determine how aggressive all of the AI’s units will be. Techniques like this are always worth considering, but in the end the best approach will be dictated by the project goals and what kind of feel the designer wants the game to have.

Another tactic that, perhaps counter-intuitively, makes an AI seem much smarter is to have it explain what it’s doing. Is a leader building up a massive army that he plans on using to crush the human? Have him say so!

I know what you’re thinking, and sure, this gives the player advanced warning and makes it harder for the AI to actually, you know, crush the player. But at the same time it also engages the player, gets him or her to worry about what the AI’s up to, to start coming up with plans, to adapt. When the AI does eventually show up with a big army, the players will then think to themselves: “Ah ha! So the AI was actually planning this for a while.” Players will naturally pay more attention to what the AI says in the future. It also makes the AI appear more intelligent than if it had it simply executed a perfectly-timed sneak attack and never once made a peep about it.

Players have no idea what the AI is doing under the hood, and they don’t even care. It’s on the developers to make sure the fruits of their labor are seen. It can be worthwhile to spend time on “fluff” AI which shows off what the computer knows, even if there’s no actual gameplay effect at work. A few lines of code that generate an illusion of a smart AI will often have a much greater impact than a massive, complex system which results in an actually smart AI.

Of course, the AI can brag all it wants, but at the end of the day once it shows up on the player’s doorstep it still needs to fight competently! Which brings us to our dish’s next key ingredient…

Preventing Dumb AI

Okay, so the AI army has actually come a’knocking… now what? Well, let’s first establish what our priorities are.

It’s much more important for an AI to be not dumb than for it to be smart. What do I mean by that?

An AI is labeled “bad” not when it fails to execute a flawless pincer maneuver, but when it fails to use its full-strength God Unit to kill a wounded one belonging to the human. “This AI is so stupid, a real player would never have let that unit get away!”

Developers should always focus first and foremost on eliminating the number of obvious mistakes an AI makes. It’s awesome if the AI is able to pull off that pincer move, but it’s nothing but a “nice to have” feature until all of the dumbness has been sifted out. If players spot just one stupid move they’ll immediately lose all faith in their computer opponents, and once that happens there’s no going back – the illusion is forever broken.

Okay, so a good AI isn’t dumb – fair enough. What about making it, you know, smart? I won’t go into specific algorithms or anything, but there are a few general principles worth noting.

The key is setting good priorities and following through on them (noticing a pattern?). Focus on making an AI that is generally simple, but strong in a few areas that will really stand out to players. Setting out to create artificial opponents that are unbeatable in every way is a fool’s errand (unless you have five years during which the gameplay rules never change – good luck with that!). The fewer moving parts an AI has under the hood, the easier it will be for a programmer to add new features and improve existing ones.

Build a system that is designed to change – a lot. A game’s AI is one of the pieces that needs the most iteration and you want it to be easy to jump in and change the behavior in ways that are obvious. The more fiddling that is necessary, the less likely it is that developers will be able to – or worse, want to – go in and change things. If opening up the AI code always results in a hearty sigh, it becomes much easier to give up and proclaim “ehhh, it’s fine the way it is!”

It’s crucial to get the AI performing simple tasks competently as quickly as possible. Once the basics are in place, complexity can always then be added. AI is one of the very few areas of game development where doing too much design can be harmful. The design itself is rarely the problem, but spending too much time on it before anyone sees in-game results often leads to superfluous complexity and a diminished focus on the high-level objectives.

Advanced AI techniques like neural networks and genetic algorithms are incredibly powerful and can do some amazing things – unfortunately, they’re terrible for most games, especially those which undergo significant iteration (and typically, the more iteration you do the better). To emphasize my point from above: the simpler an AI is, the more likely it is to work and to be easily improved. When the development team has less control over what’s going on it becomes much, much harder to achieve focused, narrowly-defined goals.



The Designer and the AI

The odds of your AI entrée being a hit with any complex game (particularly those in the strategy genre)  is dramatically reduced if the game designer and AI programmer aren’t the same person.

At its core, the AI is just one gameplay system among many. Do you want a non-designer making the plan for one of the most important and salient features in the entire game? A designer needs to spend significant time and effort establishing what the goals and focus should be for all systems – the AI is no exception. Simply handing off this to a programmer is usually a recipe for disaster. The job of a programmer is to write code that is efficient, robust, and easy to maintain – it’s a designer’s job to ensure the in-game experience is fun. Those goals do not naturally align. When no direction is given, programmers will typically architect and code a system just like they always would.

That’s not to say a game is outright doomed to failure should the game design be done by one person or team, and the AI by another. However, this does require both groups to be extremely organized and vigilant. The design team needs to make sure that all goals for expected AI behavior are clearly outlined, just as they would do with any other system.

Even so, designing an AI presents significant challenges that other gameplay systems lack, which is why it’s often preferable for the game designer and AI programmer to be one in the same. There are a number of problems that AI simply cannot solve in an environment where an answer is needed within seconds, at the very most. There are some tasks computers naturally excel at, and others that it finds nearly impossible – managing multiple scout units simultaneous is a piece of cake… building and launching a three-pronged, multi-theatre invasion in exactly 27 turns is, uh, not. While not always feasible, when the individual designing the AI also understands the technical limitations and opportunities in play it’s much more likely a project’s AI goals will be achieved.



Being an AI programmer is a tough job. The results of one’s work are often nebulous, and when they’re not it’s usually because of some big, obvious problem. But that grey area also leaves plenty of room for creativity and interesting problems to solve. A splash of unwavering focus on the end goal and a pinch of avoiding getting bogged down in complexity for complexity’s sake should ultimately make for a rather tasty dish. Good luck in the AI kitchen!

– Jon

Categories Design Thoughts

9 thoughts on “The Recipe for Good AI

  1. Could one summarize: The naive idea of taking a finished game design and then writing AI as a set of independent algorithms that “solves” the game is both impossible, given commercial constraints, and undesirable, given player psychology?

  2. That’s a good way of putting it. AI is not something completely divorced from the game – a layer that just sits on top of everything else. It needs to be woven into the design, so that the two work together instead of compete with one another.

    – Jon

  3. I’m embarking on my first game/AI developing experience soon, and I have bookmarked this article. Such a concise and elegant summary!

    Thanks for writing this.

  4. I often get email from people looking to get their first job in the game industry asking me for advice. What are companies looking for in candidates for entry-level programming positions? How come it’s so difficult to land a job? I can’t answer for the industry as a whole, but I can certainly tell you what I am looking for when trying to fill an entry-level programmer position.

    1. That’s a good question, and one that’s tough to answer…

      There’s no doubt it’s difficult to get an entry-level job in the games business, and that holds true even for programming. Making a game is a huge amount of work, usually under a barely-feasible schedule. Developers are looking for people that can hit the ground running and will know how to solve the complex problems that pop up while building a game. Bringing in entry-level folks and training them up is often seen as a luxury that can’t really be afforded.

      That being said, there’s definitely hope. The advice I always give anyone looking at getting into the industry is to make your own game or mod, or the piece of one that is relevant to your discipline. If you’re a designer, make scenarios or maps. If you’re an artist, make some paintings, models or levels. If you’re a programmer, make your own engine, or even a simple game. But you really need something to show off. Game companies get tons of resumes from recent college grads, and the simple fact is that most of them are not equipped to help make a game. If you want to separate yourself from the crowd you have to show that you CAN help make a game.

      – Jon

  5. Are you happy with how the AI turned out in Civ V? Was there a team working on that or was it just you? I ask because the results seem really polarizing among that games fanbase – where some people want the AI to try and win, and others want it to roleplay, and yet neither side seems totally happy with the end result. How do you decide what path to take in that regard?

    1. I’d like for all of the games I’ve worked on to have a better AI, and Civ 5 is certainly no exception. We did have a team working on it – I did a lot of the high-level strategic and diplomatic AI, another engineer was focused on the combat AI, and third member of our team wrote the Worker AI.

      Philosophically, we leaned in the direction of having the AI behave more like a player trying to win, rather than staying in character the entire time. Because Civ caters to such a broad audience, it’s a huge challenge trying to find a happy medium between the two ends, and we’d no doubt make some changes if we were to do it again.

      Ultimately, the complexity (and ironically, the flexibility) of the system made it difficult to teach the AI specific things – in the end it was okay at pretty much everything, but had trouble with some of the tougher tasks it needed to perform. My experiences resulted in me becoming a major evangelist for simpler, more manageable systems. That won’t automatically make your AI better, but it does remove a lot of the unnecessary barriers that get between the AI programmer and the end goal. It’s incredibly easy to over-engineer something, thinking that you’re helping when you’re really not. That’s definitely a trap I’ve fallen into!

      – Jon

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

search previous next tag category expand menu location phone mail time cart zoom edit close