• What is procgen?
• What we tried?
• What worked?
• What didn’t?
• Try again?
• Procgen is a production system
• L-Systems, Shape Grammars
• Symbols and rules
• Rules operate on symbols to produce more
• 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
• 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 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
• Two instances of the same rule set with different
input parameters can produce very different
• Each rule set is formed into a Lua table
containing tables that hold the needed
• Identifier, Object Types, Object list, Variables,
• Each rule is a Lua function that takes a rule
instance table and an object to modify
• Using Lua coroutines
(threads) two identical
rule sets could be
running at the same
• Rules sets can be
recursive or run
concurrently so each
evaluation of a rule
set uses a its own
• 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
• When the rule reaches the end of the list the next rule
begins. If no rules are left, the generation process
• 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,
• 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
• 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
• Dynamic creation of objects that are expected
to be set up in tools
• EVERYTHING IS A MOBY
• Lighting, Nav, Colision, etc
• The basic geometry never evolved past a 1m
cube scaled for collision and using igFXUtil to
• 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.
• Generate parts of the game that we want to
be highly variable such as in rcf2
• Create an ip that supports a primarily
• 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