Docstoc

PowerPoint Presentation - Insomniac Games

Document Sample
PowerPoint Presentation - Insomniac Games Powered By Docstoc
					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
• 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?

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:9/24/2012
language:Unknown
pages:20