Procgen

Chaz Pratt11/3/2009

overview

• What is procgen?

• What we tried?

• What worked?

• What didn’t?

• Try again?

background

• Procgen is a production system• L-Systems, Shape Grammars• Symbols and rules• Rules operate on symbols to produce more

symbols• Give up eventually• Procgen goes a step beyond generating

geometry by abstracting gameplay objects into symbols and populating a level based on user specified design rules.

what we tried

• Oct – Dec 08

• Lua implementation, C++ integration

• Runtime random arena levels

what we shipped

procgen overview

• Rule Set: Objects, Variables, Rules

• Conversion to a Lua table

• “Instance” these tables and generate.

• Resolve the object list

• Play what you have made

rule set

rule set tunning

• Variables in the rule set are meant to provide a high level method for tweaking the fun of a level while the rules define the theme or core of what the level will be like.

• In rcf2 the variables were adjustable via the excel config spreadsheet so there was no need to adjust the rule set every time a tweak was needed.

• Two instances of the same rule set with different input parameters can produce very different levels

lua table

• Each rule set is formed into a Lua table containing tables that hold the needed components

• Identifier, Object Types, Object list, Variables, Rules

• Each rule is a Lua function that takes a rule instance table and an object to modify

lua table

instancing

• Using Lua coroutines (threads) two identical rule sets could be running at the same time

• Rules sets can be recursive or run concurrently so each evaluation of a rule set uses a its own table

progen:run

• The actual procgen engine was written in Lua• Each rule begins at the front of the object list and

executes on each object.• If the conditions of the rule are satisfied it may remove,

alter or use this object to generate new objects.• These objects are added to the front or end of the list

depending on the rule• Objects appended to the list will also be evaluated by the

current rule.• When the rule reaches the end of the list the next rule

begins. If no rules are left, the generation process terminates.

progen:run

procgen:resolve

• Each object in the list has a unique type that is explicitly defined by its name.

• During resolution this name is used to find a corresponding resolution function which will be called to add that object to the game

• If no function is found that object will silently fail to take form in the game.

• Type Floor will search for ProcGen.FloorRes( gen, obj )

• Resolution generally results in calling a C function that creates the specific object in our engine

what went right?

• Procgen was able to create in some base form all elements of gameplay attempted in ratchet: platforming, enemies, hazards, grind rails

• Simple arena challenges could be laid out in a day or two.

• Highly structured variability.• Had the ability to duplicate nearly all of the

final challenges found in the final game.

what went wrong?

• Everything else?• Time and resources – extremely limited

support, rcf2 over budget. . . something had to be sacrificed

• Dynamic creation of objects that are expected to be set up in tools

• EVERYTHING IS A MOBY• Lighting, Nav, Colision, etc

mobies

• The basic geometry never evolved past a 1m cube scaled for collision and using igFXUtil to draw sufaces

• No easy way to make static gemoetry• Jigsaw puzzles of mobies• Very restrictive Moby limits• For procgen to be utilized at runtime we need

an engine that better supports the creation or spawning of static geometry.

Other dynamic objects

• Path, Volumes, Clues – intended to be added in Luna• Outdated or broken spawning functions• Navmesh – our engine needs a way to dynamically

spawn navmesh if there are going to be dynamically created components of the world.

• More use of dynamic lighting and spawning lights from code would be a plus (not fully explored)

• If it is used by gameplay there needs to be a convenient and fast way to spawn it at runtime.

future applications

• Generate parts of the game that we want to be highly variable such as in rcf2

• Create an ip that supports a primarily generated game

• Use this tech to generate worlds offline that can be tweaked afterwards and saved

• Use this to create flexible expansions of our tools to accomplish redundant task. ie crate stacks

???

• Questions?