nak@lucent.com

Wednesday’s RT showed a serious shortcoming with Moscone West – a notable lack of small spaces. My room was longer than a basketball court and tall enough for model rocketry. One of the "walls" separating me from another such room was a thin, sonically transparent, six-foot tall curtain. I’m sure that next year CMP will exploit the small spaces offered by the Hilton and things will be better. I was very lucky; the round table on the other side of the curtain was moderated by my co-moderator Steve Woodcock. We decided to combine to one group. That decision got made before we started. We would have made it differently if we had known how popular the session was! By the time all of the late-comers walked in, we had a lot of people. My count was 50 people, exactly the right number for two roundtables. I tried to make sure that everyone got a chance to speak and Steve took notes at the easel. For topics and longitudinal data, I will defer to Steve’s report. As a group, fifty can sometimes overwhelm the RT process, but that did not happen here.

We did ask the attendees to put on the back of their evaluation whether the session should be one hour or two. We have been asked in the past to extend the length, but were hesitant to alter a formula that so many people find value in. We also wanted to make sure that CMP heard these requests so that they would know as well. We look forward to reading what people wrote.

I heard of a room cancellation on Thursday, so with CMP’s blessing, we moved Steve’s RT down there. My session had 41 attendees. This year’s question on the number of full time AI programmers had an interesting distribution. The response range was:

0.5, 1, 1.5, 2, 2.5, 3, and 5.

All of these had 1 vote each except 1.0, which had five votes. This distribution echoes that of last year. Most games have one full time AI developer.

Designer controlled AI was hot topic. Echoing the rest of the content pipeline issues, "many artists, few engine programmers," we are seeing a split between the people who write the code that makes the AI possible and the people who get to say what the AI does. It used to be that the person who coded the AI was also responsible for putting in all the behaviors and triggers that made the AI part of the game. Level designers now have another aspect of game play to design. Unfortunately, not all good level designers make good AI writers. There may be a split between a technical and creative designer. It is clear that what once was in the hands of "the AI person" now needs to be in the hands of many in order to get content out the door.

Data driven AI was a similar hot issue. People are trying to get their hands around the numbers that control AI in interesting ways. Sports games especially need to make virtual players not only look like the real players, but act like them too.

Learning and QA came around again. Learning is happening in AI more and more, and AI that learns after QA is the next frontier. Few have made the leap of faith and allow their AI to learn after QA, but there are a lot of penguins gathering at the edge of that particular ice floe.

In a related note, it was pointed out for shooters that good AI helps QA. The virtual players run around and do intelligent and interesting things just like players. At least they are supposed to. Consequently, they test just like players, but far cheaper. In this case, a great AI makes for great automated testing.

Hot off the talk from the Cell processor, multi-CPU AI came up. Making sure that the flames were well-lit, a representative from intel was there pointing out that multi-core CPUs will start shipping in the middle of this year (2005). The march of technology will soon make them common in high end and then every PC. It was suggested that say with eight processors, each could do an agent by itself. Wiser heads pointed out that having those processors compete for the same kind of data would strangle them all since memory bandwidth is scarcer than cycles. Having the AI task be pipeline friendly and the sub-tasks cache-friendly is a far bigger win.

Many AI tasks have been restartable and multi-threaded for quite some time now. With multi-core CPUs, this method simply runs a whole lot faster. It used to be that AI was not allowed to reduce frame rate and lost any competition for CPU to graphics. With GPUs being faster than the CPUs that feed them, and with more than one core for processing, AI and everything else that used to lose out to graphics might now be able to compete for the spare core or cores (4 core chips coming soon) that don’t have graphics saturating them. Or some enterprising game engine writer will figure out a really great split for graphics that allows it to saturate all the cores on a chip.

Complexity is an issue. Coding in this environment has pitfalls that people who write multi-CPU operating systems and databases have lived with for many years. That is to say that the complexities can be managed and conquered by the right staff. And to say that even they sometimes get tripped up by nasty subtle interaction bugs. This goes on to point out that those programmers who lack such experience are candidates for relearning that painful history in the most expensive ways possible. The game industry is not noted in its history for learning from the history of the rest of programming – remember compiler versus assembly wars?

The overly long room put a small cramp in our style, but we did our best to overcome it. We had a reasonable mix of beginners and experienced hands. Between the loudness of the Level99 party the night before and the poor room acoustics; I had a hard time hearing people at the other end of the room. I circulated in the middle so that everyone got some "face time" and felt included. Steve will have the notes of what got asked, I was busy making sure questions got answered and that people got their turn to talk. My apologies to those I had to ask to speak up.