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!