200 likes | 209 Views
Procgen. Chaz Pratt 11/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
E N D
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
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 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
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.
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?