AI Roundtable Moderator's Report

Steven Woodcock

swoodcoc@concentric.net

Wednesday, March 17^th

My first session of the conference was attended by 35 people, a huge increase of previous CGDC first-session turnouts (25 in 1998, 29 in 1997). Every seat was filled and a few attendees had to take wall seats. A quick survey revealed that five of these attendees counted themselves as "newbies", a surprisingly small percentage when compared to previous years. (This was a trend that held true throughout the conference; it is apparent that industry interest in good game AI is increasing rapidly.)

I began by discussing why we had scheduled "topic specific" sessions for Thursday and an "AI for Dummies" session for Friday, then invited anyone who was interested in coming to our Second Annual AI Programmer's Dinner (scheduled for Friday the 19^th). With this bit of business out of the way, we got down to discussing AI topics of interest. Over the course of the hour the topics ranged widely:

• Neural networks and genetic algorithms-useful or just hype?
• How do the game industry's AI solutions compare to academia AI?
• Does good AI enhance the value of gameplay?
• What games had really good AI this year?
• 3D pathfinding.
• Influence mapping.
• Behavior.
• Voice recognition in games-anybody doing it? Is it worth the cost?
• What issues are AI developers facing? Got enough CPU yet?

Discussion on these topics was most interesting, no doubt due in part to the large percentage of experienced developers present. A number of remarkable points were brought forth by the group at large:

• A number of developers (roughly 20% of the attendees) are using neural networks in their games. Most are training them during the game's tuning phase and then "freezing" them upon release; one developer of an upcoming sports game is hoping to integrate unsupervised learning in the released product. Genetic algorithms appear to have little use outside of a-life sims such as Creatures.
• We were fortunate to have two academics in our audience, one a physics major dabbling in AI and the other a formal AI professor . Both were adamant that the game industry is light years ahead of academia in terms of producing practical, working AI solutions to some very tough problems (this was also echoed in Dr. Laird's excellent last-day lecture, Developing an Artificial Intelligence Behavior Engine). The game industry lacks the formalism and requirement for a "perfect" solution often necessary in the academic world, but the pace of innovation is at least an order of magnitude faster.
• Surprisingly, none of the attendees felt that any game released during 1998 and early 1999 had particularly interesting or outstanding AI implementations. Half-life and Unreal were mentioned for their better 'bots and scripting capabilities, but nothing really seemed to "hook" the attendees as games had in previous years.
• Developers facing pathfinding problems in a 3D environment were all basically solving the problem in the same fashion-with a network of "nodes" defining viable paths through the environment, against which some form of modified A* algorithm was run. Everybody agreed that A* was the king of pathfinding solutions….
• …with one interesting exception when one developer discussed his usage of Influence Maps for rapid pathfinding. His results to date were encouraging, though not in the A* speed range, so he was reluctant to discuss too many details. This revelation led to a general discussion of the use of Influence Maps in games, together with an explanation of what they were for several attendees who had not heard the term before.
• Perhaps the most astonishing finding coming out of this roundtable was that none of the developers present felt they had "too little" CPU available. This is in startling contrast to previous years, where AI developers often complained of fighting the graphics developers for CPU cycles. Most felt that this was, quite simply, due to the faster hardware now available…5% of a 300 MHz Pentium III is a heck of a lot more horsepower than 5% of a 13 MHz Pentium I. Most developers seemed to think they were getting anywhere between 5% and 15% of the available CPU, and everyone thought the percentages would only increase as hardware got faster.

Thursday, March 18^th

My second session was billed as being a "theme" session focusing on wargames and real-time strategy games, and it was packed to capacity. A whopping 44 people arrived for the session and we had to turn away several after the roundtable began due to lack of space; seven people rated themselves as "newbies". Several people had to stand throughout the hour, though nobody seemed to mind it due to the extremely energetic nature of the discussion. The room filled up so quickly that we began 15 minutes early…….topics were suggested almost immediately and our discussion went non-stop until we ran out of time. This session was the most difficult to control because of the sheer pent-up energy that seemed to infuse everyone present; these people really wanted to talk to somebody about their AI issues!

Our topics ranged all over the map, but the most significant were:

• How does an AI plan an assault?
• Learning.
• How do we handle changing technology in a strategic game such as Civilization?
• How do we build an AI that can plan strategically?
• How do we make our AIs "seem real"?
• Pathfinding and Influence Maps.

The level and energy in the discussion was amazing; Eric has used the term "horse race" in his report and it's an apt description. Developers were tripping over each other to speak, and every comment raised three or four more. Some of the comments coming out of the above topics included:

• Developers are using a variety of methods to determine if an assault on a given target makes sense. Some are using Monte Carlo techniques to play out the attack 100 times; if the attack is successful the majority of the time, the AI goes ahead and makes the attack "for real". Others use table lookups or algorithms to calculate the probable outcome of the attack based on known units, terrain, etc. This discussion then led into a discussion of
• learning. One developer noted that they were doing localized assault planning by continually building a data file that describes how well other such attacks have fared historically in previous scenarios. The proposed attack was compared to this database and, if it succeeded most of the time, was carried out. A windowing algorithm discards "old" lessons so the learning file doesn't become too large. The developer reported that this approach resulted in an AI that gradually tailored itself to the user's style of play…a feature that has much appeal with AI developers!
• Games in which there are technological advancements that alter unit capabilities can present thorny problems to the AI developer. At some point, technological mismatches between units (i.e., cavemen attacking a destroyer) simply become impossible to win, mandating that AIs be built to keep pace with technological advancements within the game. A variety of methods were discussed to achieve this; most seemed to involve automating some flat percentage of an AI's research budget to advancing technology. A few developers admitted that they simply cheat…if the AI is too far behind the player to make a good opponent, he "steals" technological advances as needed!
• Building AIs that can plan strategically remains a major problem. Many present felt that most games focus too much on optimizing the tactical while ignoring the strategic. Some were of the opinion that strategic level optimization wasn't really necessary, as the player will often ascribe "meaning" to random acts on the part of the AI if said acts weren't blindingly stupid to begin with.
• Pathfinding, a perennial topical favorite, cropped up again in this session, though the focus was mostly on identifying and dealing with highly restrictive terrain (such as bridges or mountain passes). Most developers simply "marked" these terrain features by hand in some fashion to make the easy to identify, though this greatly complicated things when the AI had to deal with randomly generated maps. Many developers also handed off traffic control on such terrain features to a specialized "traffic cop" agent in order to avoid bogging down individual unit AI with the details of crossing a bridge politely.

Friday, March 19^th

Our third day featured our specialized "AI for Dummies" session. Originally proposed to Miller Freeman for a panel format, it was billed as a roundtable (obviously not the best format for this kind of presentation). Due to the relatively low turnout that always marks the last day of the conference (we had only 33 or so attendees), Neil Kirby and I combined our sessions while Eric led a spin-off roundtable of AI experts. Of our 33 attendees, fully 25 identified themselves as "complete newbies", and several were producers or other non-programmer types. We had four or five experts in the session, which greatly helped our Q&A format. Neil conducted most of the moderation while I took real-time notes and offered various references, web pages, etc. where more detailed answers to various questions could be found.

Being a Q&A style of session aimed at developers new to game AI, we tended to discuss topics in a broader, more instructional style. Some of the questions we fielded included:

Q: How do I calculate the CPU my AI is using?

A: Several tools are available to calculate CPU usage, including Intel's Vtune and the Windows timeGetTime() and QueryPerformanceCounter() timers. Most console platforms had some form of debugging tool that could compute CPU usage as well.

Q: What are threads and how are they used for game AI?

A: Conceptually threads are independent programs that share memory space with the main program. Many developers use threads in order to make the AI more independent of, and less intertwined with, the rest of the game. They're very good for ensuring your AI and your game physics are in sync.

Q: How do I avoid doing lots of physics or AI calculations on objects or units that aren't anywhere near the player?

A: Your graphics guys have had to worry about not wasting processing on distant objects for a long time. Ask them how they do this quickly; the same techniques can be used to partition your AI processing.

Q: How do I handle the conflict between game designer and AI programmer?

A: Good question! Designers need to understand that the AI developer needs a fairly stable game platform before he can really focus on building a good game AI, while the AI developer needs to realize that the designer needs to see behavior early in the game's development so he can modify the design as necessary if things aren't working out as envisioned. "Bad" features that are very difficult to implement need to be identified as early as possible in the development process. The best thing the AI developer can do is to build incrementally rather than trying to add every feature at once. The best thing the game designer can do is to clearly define what he wants the AI to do, and give the developer time to actually do it.

Q: What technologies/methodologies are AI developers using to build game AI?

A: Everything, though the most commonly used techniques are rules-based, finite state machines, and fuzzy state machines. Techniques such as neural networks, genetic algorithms, etc. are all great in theory but not often used in practice (and certainly shouldn't be attempted by someone new to the field). Several developers present suggested that books on game theory, dynamic programming, and probability theory could be very useful at generating ideas for fledgling AI developers.

Q: What kinds of games are hard to do AI for? What kinds are easy?

A: It's never "easy". RPGs are often the hardest to develop good AI for, due to the need for believable "conversational" AI; developers would do well to steal ideas from MUD "chatter'bots" and the classic Eliza program. Real-time strategy games are also tricky due to CPU restrictions. Sports games are tough because if you get anything wrong, 100,000 angry fans will write in to let you know. Boardgames with known, fairly simple rules (chess, Risk, etc.) are fairly simple by comparison, as were nearly any turn-based games (you get tons of CPU).

Q: Is cheating okay?

A: If it makes for a better game and the player can't catch you doing it, yes!

Conclusions

Attendance in all our roundtable sessions was up significantly from the 1998 CGDC sessions (236 vs. 190), indicating an upswing in interest in good game AI across the industry. The variety of topics and depth of discussion increased significantly from last year, driven in part by the apparent easing of CPU restrictions for most developers (thus allowing them to indulge in more detailed approaches). The roundtables seem to have become a very popular GDC feature.