Open Review

Recast’ing Automatic Annotations for Player Cover in KILLZONE 3

Alex J. Champandard on April 26, 2011

The most common advice for automatically generating annotations is to start with manual annotations instead, then use those to build the runtime behavior. But where's the fun in that? :-) Luckily, that's where AI comes in! Not only does it make things a lot more fun to develop, but it also helps annotate data much quicker and reliably.

In the context of terrain annotations, using automated reasoning can alleviate the burden of the level designers — saving precious time manually defining interaction surfaces for the player or placing smart objects for the AI itself... And that's exactly what KILLZONE 3 does!

Mikko Mononen, famous for his open source work in Recast and Detour, worked with the team at Guerrilla Games to apply Recast to detect player cover locations in the game. Mikko will be speaking at the Paris Game/AI Conference 2011 in Paris this June, and will be sharing more insights about the technology there. In the meantime, here's an introduction to the topic and a few teaser screenshots, so you can prepare your questions!

Automatic Annotations in KILLZONE 3

Screenshot 1: Surfaces used for player cover in KILLZONE 3 at runtime.

KILLZONE 2 allowed its players to use cover, by tapping a button to enter into a safe location behind an object. Then you could lean out from the side or pop up above the cover to watch or shoot the enemy. Since each of these “Lean and Peek” opportunities are in a wide variety of locations, they were manually placed by level designers.

In KILLZONE 3, however, automatic annotations were used to place these surfaces in space. The end-result is the same on the runtime side of things, but in practice the cover locations end up being placed more consistently throughout the level — making the player experience more predictable. Since the game also allows the player to slide into cover as a game mechanic, any improvement in the annotations helps!

User Interface and Toolchain Integration

Screenshot 2: Editing locations used for player cover .

Your probably wondering, if manual overrides are the most important part of an automated system, how was this handled on KILLZONE 3? In this case, the local terrain reasoning algorithms used to place the player cover locations were made available to the level designers as a tool, as you can see in the screenshot above.

Level geometry editing and placement is done in Maya, so the player cover annotation tool is also exposed there. It has its own panel on the right, and can be summoned interactively using a simple click. The level designers can then override the automated results, or customize them as necessary.

Reasoning with Voxels

Screenshot 3: Voxelized representation of a test level with jump annotations rendered.

You may be familiar with voxelization techniques for navigation mesh creation, as popularized by David Miles and subsequently used by Mikko Mononen in Recast. Voxel based approaches have a variety of benefits, in particular robustness and processing performance. This makes them ideally suited to navigation mesh generation, so why not apply those techniques to other aspects of the game too?

Voxels are well equipped to store not only height information of potential cover objects, but also whether they contain holes. Using run-length encoding helps store and process this information particularly efficiently, so traversing areas to check if there's cover available is feasible at (near) real-time rates.

Rising to the Challenge

Screenshot 4: Combat behaviors in KILLZONE 3, vaulting/jumps and taking cover.

KILLZONE 3 uses voxel-based automatic terrain reasoning to create player cover annotations. However, it seems sensible to support other forms of annotations required for both player and AI movement too, for instance:

  • Cover
    • Crouching
    • Standing
  • Vaulting
    • Gaps
    • Obstacles
  • Jumping
    • Down
    • Up
  • Climbing
    • Surface
    • Ledge

The challenge for each of these annotation types is not only to find certain instances, but all of them regardless of their orientation or placement in the level. Also, can each algorithm detect near matches and prompt the user for suggestions or advice, for example if there's a voxel-sized hole in a cover should it be treated as cover by the game?

NOTE: If you'd like to find out more about the solution to some of these algorithms, then join us at the Paris Game/AI Conference 2011 to hear Mikko Mononen's presentation on the topic!

Discussion 0 Comments

If you'd like to add a comment or question on this page, simply log-in to the site. You can create an account from the sign-up page if necessary... It takes less than a minute!