Something new

I have recently been spending some time learning LUA language.  I am looking into this mainly as this is a standard language used by game developers for in game scripting.  I picked up this book to aid in my studies.  More to follow on this.

Elegant Memory Management Ideas

In working on a recent project, involving some callback data in a animation with DirectX and interesting solution to a common problem was presented.  In order to describe the solution correctly, I must setup the scenario.

We have an animation that is loaded from say an X file with the DirectX API.  When using the convenient function to load the X file (D3DXLoadMeshHierarchyFromX) the obvious problem is any callbacks you will require for animation sets will most likely not be stored in the X file.  So we clone the controller/animation sets after the file has been loaded and allocate an array for callback keys/data.

The problem comes in about how to release this memory when complete.  As the data stored here can really be whatever we like, it becomes harder to clean up (as its heap allocated).

The interesting solution that was shown to me was to use COM.  Well, not exactly full COM but the IUknown interface.  Basically we just ensure that our context data object derive from IUknown (and of course implement the required fields).  One of the required methods is Release().  As with all COM objects, memory cleanup revolves around a reference count, and when all references are gone the object remove "itself" from memory.  Also, note we will be required to implement AddRef and QueryInterface as part of derived interface.

Note we are registering a full COM object we are simply using the interface provided by COM as a reference counting mechanism to allow our objects to clean themselves up when it is required.

I thought this was a cool way to use some tried and true COM libraries to solve a very real problem.  :)

Building a Better Battle : Halo 3 AI

This presentation was given by Damian Isla from Bungie Studios.  It presents the basic architecture and tools used to build the AI system in Halo 3.  This lecture specifically detailed the encounter logic.

Encounters are the "dance".  Basically how the system reacts and collapses in interesting ways.  The "dance" is the illusion of strategic intelligence.  Designers choreograph the "dance" to be interesting and drive the pacing of the story, kinda like a football coach directs his subjects.

Halo 3 uses a 2 stage fallback.  Enemies start off occupying a territory.  The aggressor (player) then pushes them back to fallback point.  After this they are pushed to the last stand location, after which the player will "break" them and finish the battle.  "Spice" is added on top of this by designers to make the encounter play out in a more realistic fashion.

Mission Designers handle the encounter tasks with the AI Engineers handling the squad (how the AI behaves autonomously).

Halo 2 used the Imperative Method to control AI (Finite State Machine).  The designers were given access to dictate what happen as various events were triggered (ie. enemy starts losing battle).  The primary problem with this model was the need for explicit transitions (n^2 complexity).

Halo 3 took a different approach, using the Declarative Method.  This basically works by defining the end result you are looking for (with reference to AI).  You enumerate the "tasks" that are available and let the system make the decision on how to perform these tasks.

One of cool things about using the declarative method is the ability to set relative priorities.  Example would be guard the door but if you can't do this, then hallway.  Also, it brings the notion of hierarchal tasks (sub-tasks).  Example would be guarding the hallway means guarding both ends and middle.

Funny comment that Halo 3 AI works like a Plinko machine.  This means pour tasks into the system, prioritize them, and then pour enemies in and let the system place them and control their behavior.  This also means it's an upside down Plinko machine ;)  This is because tasks can be activated/deactivated at will and cause the enemies performing them to re-evaluate the situation and "do something else".

The system uses a proprietary scripting language named HaloScript.  This allows designers, who are not programmers, to design and use the system.

Life on the Bungie Farm: Fun Things to Do with 180 servers and 350 processors

This lecture was given by Luis Villegas and Sean Shypula. This was primarily about the server farm and distributed computed system created by Bungie for automated builds of code and content.

Advantages:

• Faster iterations -> more polished games
• Keeps complexity under control

Binary Builds (game and tools)

• Automated tests are run on tool builds only

Lightmap Rendering

• Pre-Compute Lighting in scenes (Photon Mapping and custom algoritms from Hao and crew)
• Bakes the level files (output)

Content Builds

• Compiles assets into monolythic files

Website (bungie.net) Builds

Patches (maintenance items for servers)

Halo 1 -> All assets processed by hand, very few automated tasks

Halo 2 -> More automation (3 servers in farm -> one for each function)

Halo 3 -> Unified systems into single extensible system

The latest iteration, created with Halo 3, did a few new things (rewrite).

• Unified codebases, implemented single cluster.
• One farm
• Updated code to .net (C#), easier to develop/maintain

Stats

• Over 11,000 builds (exe/dll)
• Over 9, 000 lightmap builds
• Over 28,000 other types of builds
• Halo 3 would not have shipped in current form without the farm.

Interface for users (developers)

• Had to be easy, simple with "one-button" submit operation
• Even if users are developers they still don't want to know what is going on behind the scenes

Architecture

• Single system/multiple workflows
• Plug in based
• Workflows divided into client / server plugins (isolation from each other)
• Server schedules jobs (messages clients)
• Client start jobs and sent status and results back to server
• Server manages state of jobs
• All communications via SQL Server
• Incremental builds be default
• Between continuous integration and scheduled (devs run builds ad-hoc and there is a scheduled nightly build)

Symbol Server used (Debugging Tools For Windows)

• Symbols registered on server

Source Stamping

• Linker setting for source location
• Set at compile time
• Engineers can attach to any client from any client as long as they have Visual Studio installed.

Lightmapper was written specifically for the farm

• Chunks job parts to clients
• Merges results

Simple SLB

• Min / Max configurable
• More clients used to support workload if clients are mostly idle

Cubemap farms

• Used XBoxes and PCs for rendering and assembly.
• Pools of Xbox Dev Kits
• No client code on Xbox
• Few changes for Xbox Support

Implementation Details

• All C# (.Net)
• Object serialized to XML to start but switch to binary serialization later (speed and mem benefits)
• Downsides (memory bottlenecks, forced GCs, should have been more careful with memory)

Beyond Printf: Debugging Graphics Through Tools

This lecture was given by Dave Aronson from Nvidia and Karen Stevens from Microsoft (graphics tools division).

Main toolsets

• Windows - PIX
• Nvidia - FXTools

Use GPU & driver counters for basic performance related issues.

Shader Perf 2.0

• Test opt opportunity
• Integrated to FX Composer
• Regression analysis
• Its in Beta 2.0!
• SDK Available

FX Composer for authoring and debugging shaders.

Use PIX for:

• Game Assets (textures, shaders, vertex buffers, index buffers, etc)
• API (DirectX)

Use Nvidia tools for:

• Driver related items
• Hardware specific items

Link dump:

http://developer.nvidia.com/PerfKit

http://developer.nvidia.com/PerfHud

http://developer.nvidia.com/ShaderPerf

http://developer.nvidia.com/FXComposer

GPU Optimization with the Latest NVIDIA Performance Tools

Lecture given by Jeffrey Kiel from Nvidia with an instructor from Full Sail giving a demo.

Optimization Techniques

• System -> CPU to GPU and multithreading
• Application -> game code
• Microcode -> lowest level (tied very closely to hardware)

Optimizations should start at the higher level and work way down. Microcode optimizations can be benefital but will only work with certain configurations (good for consoles, not for PCs).

If GPU is > 90% utilization, should look for a GPU bottleneck first, if lower then CPU (app code, driver, etc) should be looked at.

PerfHud (tool from Nvidia).

• In version 6 of this tool, no special driver is needed (retail drivers have instrumenation hooks already in place).
• SLI Optimizations can be discovered with this tool
• API Call Data Mining (both in tool and export to own data analysis offline)
• Shader Visualization / Texture Visualization
• Hot key mapping to trigger user defined options (for debugging).

The demo shown was Marble Blast Ultra (pc version). There were optimizations shown.

Next demo was with Crysis.

• Programmers should start putting PerfMarkers in their code now. These will help later.
• API Time Graph is a new feature in beta
• Perf hints (single and SLI) are given
• Subtotals in Frame Profiler
• Break (_int3) on draw calls (new feature)
• Support for 32bit apps on 64bit OS (was not previously supported natively by driver)

There were some OpenGL tools discussed.

Environment Design in HALO 3

Lecture was given by Mike Zak from Bungie.

Typically there are artists, who manage geometry, and designers, who manage gameplay. Bungie has titled an architect as the "glue" between these two. This is the role Mike fills at Bungie (as well as a finishing artist).

Pre-production model

• Broad Timeline of level and game
• Napkin sketch
• Concept Art
• Whiteboard

Aspect 1 : The Hook

• Promenant features in the rooms
• Don't create mazes for player to get lost in
• Force orientation without using force :)
• Should obviously be easy to grasp and navigate
• Suggest a tactic by geometry, lighting, etc (no force)

Aspect 2 : Scale

• How large should the level "feel"
• Engagement ideas/planning

Aspect 3 : Combat Elements

• Fronts
• Layers
• AI Blinds

Aspect 4 : Movement Elements

• Player Shortcuts (make the player feel like he discovers ;))
• One-way paths
• Ninja paths
• Vehicle flows

Mike then shared some concept art, geometry and finishing art with us. Link to presentation will be posted next week.