Greetings all, A few months ago, I was afforded the opportunity to pick the brain of the man behind the AI we love so much. This is an in-depth look into the mechanisms and challenges of creating game AI for the Battlefield series. Battlefield SinglePlayer Q. & A. with DICE â€“ Tobias Karlsson October 31, 2006 Please introduce yourself and give a brief overview of your work in Battlefield titles. My name is Tobias Karlsson. After I had completed my M.Sc. in Computer Science I ended up at DICE more, or less by chance. At DICE, I started by designing the AI for Battlefield 1942, and then implemented it together with two colleagues. I then moved on to work on the AI for Battlefield 1942: The Road to Rome and I was the lead programmer, as well as the AI programmer on Battlefield 1942: Secret Weapons of WWII. I then went on to be the lead AI programmer for Battlefield 2, and for the start of Battlefield: Bad Company. After that Iâ€™ve helped finish Battlefield 2142 and now Iâ€™m architecting the AI for an undisclosed title. There are many different types of artificial intelligent systems: expert systems, rule/case based programming, heuristics, neural networks, fuzzy systems, hybrid systems, genetic and evolutionary algorithms, etc. Why was a Reactive AI system chosen for Battlefield, and what similarities and differences does Battlefield AI have with other game or non-game artificial intelligent systems? It is common to divide different AI solutions into two general categories, reactive and planning (also known as proactive) systems. The different approaches to AI mentioned above are either reactive or proactive (though some systems may have parts that fit both categories). Reactive systems react to perceived changes in their environment and choose actions that either are getting them closer or that are preserving their goal state. Proactive systems try to create a plan for reaching their goal states first, and then use this plan to select the corresponding actions to execute. The problem with planning systems is that if circumstances change enough, the plan will be invalid. A plan necessarily contains some predictions about the future, and if it turns out that these predictions turns out to be inaccurate, the plan becomes invalid. In an environment such as the one found in the Battlefield games, the world is very hard to predict, especially for any length of time. Also, the world is very complex, which means that either the predictions need to be very short term, or risk missing vital information. Also, as a general rule, the reactive systems are much less CPU intensive. Given this, choosing a reactive approach came pretty natural. The BF game AI is mostly reactive, but there are parts of the system that arenâ€™t or are a mix of reactive and planning systems. The pathfinding is a classic planning system, using the ever popular A*-algorithm. The strategic AI (or SAI for short) is purely reactive, and has no sense of the future (which may sound like a contradiction for an AI dealing with strategies). The Battlefield AI is based on an architecture called supersumption. I donâ€™t know how rare this is, but game AI is frequently based on Finite State Machines (FSMs for short). In my experience, this is an architecture that is efficient for small systems, but soon becomes difficult to expand and maintain. Supersumption is an architecture that is used in the MIT synthetic character group, but these systems aims at much more complex, and docile AI than that of Battlefield. Battlefield AI consists of a number of components and layers: bots, behaviors and weights, knowledge, AI templates, sensing, pathfinding, SAI, strategic areas, strategies, etc. In which of these (and why) does the BF AI developer spend the majority of his/her time during development? During testing? All systems that you mention have taken a considerable amount of time to develop, but the most time intensive tasks are the low level systems (like basic steering of vehicles), and the behaviors (including their short term plans). How does a bot see the Battlefield? This is a difficult question to answer. The botsâ€™ senses are quite different from ours. To begin with, the sensing the bots is aimed to introduce uncertainty, rather than the opposite that is true for biological systems. In the game, we could always cheat and provide the bots with perfect information about the world. This is also the easy way out. Most players, however, would consider it to be unfair, and hence not feel that the game was as fun, if the bot always knew exactly where the player was. Consequently, we need to provide some kind of simulation of more human senses. This is done by doing raycasts from the botâ€™s eyes to the position of the enemy (within the botâ€™s frustum) that we want to test if the bot sees. If the bot sees the enemy, the bot will remember the location off the enemy and which point on the enemy the bot saw. The bot also updates its teamâ€™s common knowledge data base. The bots of Battlefield 1942 were sometimes accused of being irresponsive, and sometimes ignoring the player. To minimize these problems in Battlefield 2, we allowed bots in the same squad or same vehicle to share this information, and we also allowed bots to look at enemies outside their frustum whenever they got hit so that they would respond faster when under attack. Why are sensing and pathfinding different systems? Sensing and pathfinding has two very different purposes, and hence the outputs of the different systems are very different. The same thing goes for how the output is calculated, and what data is needed to do this. The output of the sensing system is whether a bot can or cannot see a specific vehicle or soldier. The output of the pathfinding system is a sequence of positions that the bot needs to traverse in order to get from its current position to its goal. The navmeshes of Battlefield 2 does not contain the information to correctly check visibility, and they have no code support for doing 3 dimensional raycasts. Instead the navmeshes contain only information regarding pathable surfaces. The fact that one edge on a polygon in a navmesh isnâ€™t connected to another polygon only means that it is not valid to try to path across that edge, it says nothing about the reasons for this (there could be a wall, and abyss, or the end of the combat area). The navmesh is much simplified compared to the detailed collision meshes that the raycasting of the sensing use. What makes Battlefield pathfinding so resource-intensive that it must be statically generated prior to game runtime? This is hardly unique to the Battlefield games. Most games, if not all games, use precomputed pathfinding data. Anyone that has tried creating a navmesh for a Battlefield 2 map knows how long time that take. Doing the same calculation in real time is hardly feasible. Battlefield maps are also much larger than maps of most games. A soldier occupies an area of about 0.1 m2 while the maps can be over 16 million m2. The Battlefield maps are also highly complex in certain areas, which mean that the precision needs to be correspondingly good. How will game AI pathfinding systems cope with the advent of many-body physics and deformable/destructible environments? This is a huge problem that faces many AI teams in the industry. The answer is either that we donâ€™t know yet, or we will cope poorly. As mentioned above, the standard solution for pathfinding problems in the industry has been using the A* algorithm on pre-computed navigation data. The more complex and detailed the levels become, the more time and CPU-power is used to compute the navigation data. It is reasonable to assume that recomputing the navigation data in real time will not be feasible for most systems in use today. Battlefield 1942 allows for up to 64 bots. Battlefield 2 allows for up to 108 bots (maxed squad members). Battlefield 2142 allows for 108 bots plus and additional 256 autocontrollers. Are these increases a simple issue of available cpu and ram resources, or is this a more complex situation involving the game enginesâ€™ capabilities and limitations? The real limits for the number of bots in the Battlefield games are arbitrary from the AIâ€™s point of view, but rather limits are set in the game. Also, the number of bots you can comfortably simulate varies greatly from system to system, and it has turned out to be very difficult to sell the idea that the performance of the AI can vary much in the same way as the performance of the graphics. The more bots on the battlefield, does Battlefield AI complexity grow linearly or exponentially? Why? The complexities of different parts of the AI grow differently. Many systems, like a botâ€™s pathfinding, are unaffected by the amount of bots. The cost of constructing a path is independent on the number of bots in the world, so the total cost of constructing path grows linearly with the number of bots wanting to construct paths. Other systems, like the sensing system, are dependent on the number of bots. When a bot check what it sees, it checks against all other players to see if it sees them (there are lots of early outs, but the principle is true). All bots need to check all other bots, so the total cost for sensing grows quadratically with the number of bots. A common criticism of Battlefield AI by mainstream players/reviewers is that the AI is not challenging, that bots are too predictable. Is there any validity to this criticism? What, if anything, needs to change or be addressed that would most greatly impact this perception? AI is probably the most unforgiving discipline in game construction. Anyone knows what a valid behavior is, and is well adapted to spot players that behave badly compared to that norm. Even the most powerful computer of today cannot compete with a human brain in a general competition. Sure, they can perform complex meteorological calculations and beat grand masters at chess, but the â€˜simpleâ€™ act of seeing and through that comprehending the world at a near human level is something that is far beyond the reach of todayâ€™s computers and programs. A game AI that runs a on a fraction of the CPU of an ordinary home computer cannot even begin to compete with humans. We know this, and instead of trying to make an AI that is the intelligent in the true sense of the word, our goal is to make the AI that is the most entertaining there is. Granted, the Battlefield AI could be much more entertaining (and smarter) than it is, but as with all projects we have a limited amount of resources, and the needs of the AI are weighted against the needs of all the other systems that make up the game. To make a long answer short, yes the criticism is valid, and it will always be, there is always something that can be done better, and in the case of the Battlefield AI, there are a lot of things that will be improved for every new game. At the same time though, I feel that the criticism is sometimes too hard. I have, for instance, yet to read a review of Battlefield 2 that acknowledges the significant improvements of the AI that were made over the AI in Battlefield 1942. And I also have yet to see anyone acknowledging that making an AI for Battlefield is an extremely difficult undertaking. In Battlefield, there are huge maps, a vast array of vehicles of very different types, and yet the AI is compared to other game bots tactical infantry games and flight-sim pilots. The first thing I would like to do with the Battlefield AI is to make it use cover. The lack of self preservation that is currently prevailing in the bots is their most obvious weakness. A more general skill, and somewhat related to the covers, I would like to give the bots a much better special awareness. How are bot behavior weights derived? Is this type of weighting exclusive to Battlefield AI, or common among game AI, or comparable with non-game AI systems? This is mostly a process of trial and error. You spend a lot of time testing and retesting situations in which you like the bots to behave in a certain way. You keep on tuning them until you are happy with the results. As for other AI systems, I donâ€™t know to be honest. I assume that weights are pretty common whenever you want to compare different behaviors in the way we compare them, but they would make little sense for other kinds of systems. While map strategy syntax and construction appears fairly straight forward, the â€œwhyâ€ is much more elusive because of the multitude of variables â€“ strategic areas, landing zones, neighboring, choke points, water ways, squad behavior, etc â€“ which must be taken into account. Please provide a brief analysis of a formidable map strategy set - not necessarily a technical description, but more an evaluation of the reasoning for the conditions, prerequisites, modifiers, and strategies. The first step is to create the strategic areas and their relations. Once this is done, I consider the different plausible scenarios of the map. Almost all maps will work well with a standard strategy that runs most of the time, one strategy if the team is dominating the map, and one strategy if the team is being dominated. This setup will make the map play decently in most circumstances. If this turns out to be too stiff and repetitive, it may be a good idea to add one or two more strategies for the normal situation on the map. These strategies aims to create situations where one team may concentrate on one flank, one spear head attack, or spread wide to try and capture badly defended areas. Once I know what I want to achieve, I write the strategies and add flags to the strategic areas so that I know that the strategies only will activate when I want them. The same thing goes for the modifiers. If I want the bots to attack a certain strategic area, I make sure that the flags for that strategic area are unique so that I can add modifiers that guarantee that that strategic area is the one with the highest temperature. end
This article was written on an older version of FileFront / GameFront
Formatting may be lacking as a result. If this article is un-readable please report it so that we may fix it.
There are no comments yet. Be the first!