TGC 2009

TGC 2009: Highlights From the Programming Front


As I walk away from the first day of the Triangle Games Conference, I leave with a new found and deep respect for what game programmers and designers do to make the games we love. It’s not all magic and voodoo, although there is a bit sprinkled in, that creates the engines and the games they drive. Only methodical researching, planning, designing and programming make a game a true success.

Every single element, world object, and NPC movement in a game must be designed and programmed. As players become better and smarter so must the AI behavior of enemies they battle and game environments that contain them. All game developers are constrained by time, energy and budgets – 3D Realms being the odd exception. Developers must continue to push the boundaries of gameplay and the design. These sessions bring the conference’s theme “Innovate or Die” into clear focus.

Taking Cover: Mechanics and AI Systems for Cover in Games

The first session of the day was given by Allan Campbell (Lead Gameplay Programmer), Clarence Simpson (Senior Gameplay Programmer) and Edward Rowe (Gameplay Programmer) of Vicious Cycle. Their latest title, Eat Lead: The Return of Matt Hazard, is a next-gen game for Vicious Cycle and required more advanced AI and cover systems than previous games. In previous games they used a finite-state machine to handle enemy movement and combat, but with this came the problems of being time consuming and the code not being reusable. A new cover point management system was needed.

They explored several options for their new cover system, including the STRIPS planning system used in F.E.A.R. and behavior trees used in Halo and Spore. They ultimately settled on an approach called HTN Planners, short for Hierarchical Task Network. This system had the advantage of planning for long-term events, was easy to design, breaks down tasks, and is modular in design. It works by breaking down a goal into tasks.

The goal’s parts are broken down into compound tasks, methods, and primitive tasks. The example they gave for a compound task was “make dinner”. You don’t simply make dinner, you have to break it down into smaller steps. The method, a way to break down tasks, would be “make soup”. Primitive tasks are actions that can be executed. In this example, a primitive task would be open cabinet and turn on stove. The main advantage of the HTN planners is events and tasks don’t have to happen immediately.

New Methods of Procedural Modeling for Games

Paul Merrell, a fourth-year PhD computer science student at the University of North Carolina at Chapel Hill, spent the second session speaking about his work with Procedural Modeling for games. Procedural modeling is a technique for generating 3D models and textures from a set of rules. The models produced can range from buildings, cities, or spaceships to more organic models such as trees and landscapes. The advantage of this technique is it’s easy to use and models can be built very quickly.

In the example Merrell gave, a game world builder could design a single or many buildings that would serve as the rule set or “mold” which the rest of the city would be generated around and from. The new buildings in the generated city would not be exact clones of the original but instead have minor to major variations. Entire cities could be generated with interesting layouts and designs a world builder may have never conceived. The software tool Merrell built that uses the procedural modeling technique can also be instructed to set boundaries to where the city can grow such as in the shape of a wheelchair logo. It can also be instructed to build symmetrical cityscapes.

Merrell wasn’t aware of any game developers that are using this modeling technique but he believed they should be. He believes the rapid construction of cities could save developers a lot of time and money. Some of the attendees had concerns with his modeling technique. They expressed concerns that the cities generated may not be interesting and fun to the gamers who traverse them or even worse, that they couldn’t be traversed at all. It should be interesting to see if Merrell can improve his tool and if developers will utilize this technique as virtual worlds become more vast and complex.

Innovative Gameplay using Time Travel & Time Manipulation

After an amazing lunch at Café Luna, provided for free by the TGC, it was time to listen to Chris Hazard of Hazardous Software speak in-depth about his upcoming game Achron and the mind-warping mechanics behind it. Achron is an RTS where players and units are able to jump to different points in time. Players are able to monitor a time graph to see events in the past and future to anticipate and counter their opponent’s moves. Hazard said he conceived of the idea back in 1999 and has been working on the game’s engine for the last several years.

Games utilizing time are not exactly new and Hazard listed six different ways games have integrated it: Story only, time zones, time loop, reverse time, fixed jump back and free-form. Achron uses free-form and is the first of its kind. Time manipulation and tracking is a very CPU and memory intensive process. Consumer level computing power has only recently caught up to Hazard’s idea.

The man has obviously spent a lot of time thinking about time. Let’s all hope the release of his game doesn’t cause some sort of temporal rift in the fabric of spacetime. Check out John Funk’s day one wrap-up for his thoughts on Achron and Hazard’s presentation.

Designing Organic Systems

The last session in the game tech track was presented by Patrick Sebring, Lead Technical Designer, of Atomic Games. His session covered ways developers can make games feel more natural to the player. Common gameplay elements include pattern recognition (timing /rhythm), motion based (jumping), visual (puzzle/shooters) and audio. Developers can make their games more interesting and less prone to exploit by introducing random elements.

When introducing random elements into a game a developer must do so carefully. Simply using the programming language’s “random” function does not necessarily translate into random a experience for the player. Developers must take into consideration how the random function is seeded. Is it based on the Operating Systems’ clock or game’s internal clock? If a developer is not careful and the random function is seeded by a game’s internal clock the seemingly random experience may in fact not be. A smart player will be able to exploit this. He suggested using shuffle array methods as a good solution to this problem.

Although introducing randomness into your game can be a good thing, there are a few places you want to avoid it. Some obvious but funny examples include a random user interface and physics engine. The whole idea is to keep players on their toes by making gameplay fresh and unpredictable.

About the author