On Thursday, 21 February 2008 at the Game Developer’s Conference 2008, Dominic Guay, a Technical Director with Ubisoft Montreal, gave a lecture on some approaches to procedural data generation being used in FAR CRY 2 (FC2). The game features a hostile, African environment, which is mostly all natural.
The size of a map for this first person shooter is approximately 50 x 50 square kilometers, which is quite large. Given increasing map sizes, more detail packed into a given area, and the need to author content for ever-increasing complexity of shading and graphical effects, it is no wonder studios are, more and more, exploiting procedural methods to aid in creating content.
Guay began his talk by reviewing the rich history of procedural methods being used in games, mentioning Daggerfall, the second game in the Elder Scrolls series that featured something like 160 thousand square miles of procedurally-generated terrain, Frontier Development’s Elite featuring 8 galaxies and many planets generated using Fibbonachi sequences, and others. He paid homage to the classical use of procedural methods in games of every sort, the lowly particle system.
The procedural methods being used in FC2 include algorithms implemented in game code and in tools, generating content at runtime as well as offline in a preprocessing step. Guay’s talk focused on summarizing the benefits and drawbacks of using procedural methods in FC2.
The first benefit mentioned was the obvious, reduction in production cost/time and improved productivity. With such a large map area, this is crucial to managing the overall cost of creating the game. As an illustration of this, the game includes procedural animation layers, e.g., upper-body animations can be procedurally-blended to produce a wide variety of behaviors that include both a pose and an emotional posture. For example, it is possible, via this procedural blending, to produce a “look at object pose” blended with an emotion layer such as “intrigue” or “afraid.” The AI chooses the goals, and the procedural system produces the animation.
The next benefit is that you can do things that you couldn’t do otherwise. The example given here is the procedural vegetation model. In this case, the studio decided to have the artists create the 3D tree models (to ensure the game has a unique look that would not be achieved by using a middleware product or model library); however, placement and a variety of animation features were done procedurally (akin to particle systems), that could not have been done otherwise (primarily due to the labor cost and time), including: simulate response of vegetation to wind forces (with breakable branches), including gale-force winds; arbitrary destruction (similar to Crysis); burning; and regeneration. They also implemented a simple algorithm to grow vegetation, which was placed into an offline tool. (This growth algorithm amounted to scaling and transforming the artist-built limbs/leaves.)
The final benefit that Guay mentioned was a gain in turnaround time for changes. With content being placed procedurally, according to level-designer rules, it is rather easy for the level designers to change simple level features, such as changing the “area tag” associated with a part of the level, then have the 3D vegetation change automatically to reflect a savanna, jungle, etc., while maintaining 75-80% of the quality level that would have been achieved by an artist doing all of the work manually. Their procedural placement system includes a rich rule system derived around concepts from nature, together with high level controllers based on zones, splines, etc. A level designer can, for example, change the spline curve representing a road, which will change the boundary of surrounding zones, causing vegetation in the zones to be replaced to surround the newly modified road. Very cool stuff.
The benefits were followed by several drawbacks, the first of which was difficulty in retaining artistic control. Their first attempt, for example, at implementing procedural skyboxes (based on a light scattering technique published by ATI), failed because the controls were far too mathematical. They now have fluid dynamics people on staff with expertise in meteorology working on cloud modeling. The basic rule here is to build proof of concept tools early, give them to your artists, and make sure you keep that artist control before you spend a lot of time developing a complete, final toolset or algorithm.
The next drawback, a corollary to the first, was that the pipeline and tools might become too complex. Procedural techniques are, for most artists, a new way of building things. The example here is that most particle system editors have a dialog box, often poorly documented, just packed with parameters that are unintuitive. You need to have the right people to develop the tools and the user interface for the tools, and they need to work together, again, to make sure things are just the right balance. Guay gave some interesting statistics, the ratio of the time they spent building tools vs. the amount of time they spent building the engine runtime code for a feature, listed here:
Vegetation System: 4
Procedural Skies: 0.3
Animation System: 3
Environment: 25
Another drawback of procedural methods is that it can be that everything becomes dependent on programmers, creating a number of risks, including: research and development sinkhole risk; potential quality improvement bottleneck; a risk of frustrating content creators; and, a production schedule/timeline risk. The big example here is that it took them 5 man-months (in 2005) to build a proof-of-concept procedural vegetation system, but it took fully 3 man-YEARS in addition (through 2007) to mature that pipeline.
The final drawback mentioned was a potential testing nightmare, the flipside of quick turnaround for changes. The key direction here was simply, plan ahead.
All in all, an interesting session. I am a big proponent of procedural methods, and have done some work on procedural geometry methods in various industries through the years. But for game development, in particular, one does need to plan carefully.
Southwest Gaming Expo
