Jump to content

  • Log In with Google      Sign In   
  • Create Account

GDC 2011



AI Roundtable

Posted by , in Programming 02 March 2011 - - - - - - · 533 views

I am sitting now at the AI Roundtable, between Mike Lewis and Dave Mark. These guys were part of the crew running the full AI summit, which I unfortunately missed. Roundtables are something I discovered late at last year's GDC, and I think they might be some of the best events. It gives you more of a chance to engage directly with people, instead of just sitting through lectures.

* Dave Mark is discussing using real life as a model for building AI, by reflecting on how we make decisions in real life.
* How do you make complex AI stuff in the background (eg emotions etc) actually useful and visible to the user/player? Some games do it explicitly. Animation can do a lot as well. Ambiguity can be used so that the player simply makes up their own ideas about what is happening. Maybe the subconscious feel of the game is enough.
* It's dangerous to avoid doing AI because characters are only on screen for a few seconds. Maybe less characters could be on screen for longer, doing more interesting things.
* A lot of discussion about emotion. Candidly, I don't see the point...I don't want characters who get sad and angry and scared, really. I want characters who aren't stupid. That's the cure modern games seem to be missing...but I haven't played shooters in a long time.
* Talking about heavy animation blending in order to enable variety in how characters act and behave. It's difficult for me not to plug my company at this point, but we just don't have a product yet.
* The best designers are programmers. This is obvious to me. These non-tech people who want to still design the nuts and bolts of games need to get lost.
* More discussion about really enabling designers and junior programmers to build AI. Small scope custom scripting languages, designing around the designers, or teaching them code concepts. I'm imagining separate water fountains for coders and designers.
* Interesting suggestion -- go learn to use an appliance from a foreign country, with a language you don't understand. This is how designers feel about the tools engineers give them.
* Still more discussion about designers. I've never worked with a game designer, per se, so I don't have much perspective on the matter.
* Are designers like puppies? You have to train them just right or they leave a mess, from the sound of it.
* Another interesting way to approach AI, keeping compute power in mind -- use really stupid AI for characters until they actually become directly relevant to the player, and make up the rest from there. Not degrade existing AIs, but take uninteresting characters and promote them to much more detailed creations.
* Some games, making the enemies too smart isn't helpful because then you just lose. It's better to have them play out patterns that are complex and interesting but learnable and can be learned. I'm not sure I agree with that -- depends on your market.
* When is the last time someone reviewed a co-op game and said the co-op AI was good?


SPU based Deferred Shading in Battlefield 3

Posted by , in Programming 02 March 2011 - - - - - - · 1,370 views

Waiting right now for Christina Coffin's talk on SPU based deferred shading in Battlefield 3. I hear they use DX11 compute shader heavily on the PC side, so it'll be interesting to see how they leverage the SPUs.

* Previous DICE games were forward rendered, just a few lights. Mirror's Edge, which they SHOULD be making a sequel to, used pre-rendered radiosity lighting. Goal of Battlefield 3 was to really expand the lighting and materials, and DICE picked deferred.
* Their PS3 implementation uses 5-6 SPUs in parallel with the GPU and CPU.
* GPU does the initial G-buffer fill, and then passes it off for shading by the SPU. Still waiting to see what that means. Are they using SPUs as fragment shaders?
* The framebuffer is sliced into 64x64 tiles, use a simple shared incrementing counter for sync.
* SPUs compute 16 pixels at a time, in SoA format at full float precision
* The GPU is still busy on other shading while the SPUs eat through the deferred shading
* About 8 millis real time on 5 SPUs for deferred shading while GPU does other stuff, equals 40ms total max compute time contributed by the SPUs.
* Light culling is done in two stage tile hierarchy, after whole-camera and coarse Z in light volumes
* A branch is used to skip all 16 pixels if the attenuation makes them unlit. This is a net win despite the branching cost.
* The SPUs are very even pipe heavy due to all of the FPU action, so complex functions can be replaced with a look-up table using strictly odd-pipe instructions, can decrease 21 cycle functions to 4 in case of complex functions.
* There is still a pure GPU based implementation of the shading pipeline that maintain visual parity, in order to facilitate debugging and validation.
* SPU job code can be reloaded into the live game, enabling bug fixes with quick iteration.
* My good friend Steven Tovey gets a call out at the end of the talk! He loves SPUs, so if you meet him you might wanna wear a dust mask.







PARTNERS