ProcGen: pros and cons

In this post I discuss the pros and cons of using procedural generation (ProcGen). This type of analysis is a good way for you to understand when you should use it and it varies depending on what you want to do. Some case examples in my previous post here.

The root cause for some of these arguments in favor or against might be the same. Here are a few of the most common pro and con arguments:

([+] for pro, [-] for con, [+/-] for depends)

  1. [+/-] Efficiency: How fast we can design our scenes? Whether ProcGen is more efficient than manual content sculpting, really depends on what you are doing. If you want to model a single 3D building, for instance, then maybe ProcGen might not be as efficient as the manual method. On the other hand, if you are to create 10, 50 or 100 buildings for a city then you could reconsider. In short, ProcGen can have a larger overhead than manual modelling but after you “break even” timewise, ProcGen can become infinitely more efficient.
  2. [+/-] Cost: How much time and money does it take to create? When it comes to the cost of using manual vs ProcGen, efficiency plays a big role when you consider the saying “time is money”. Another factor that influences cost is whether you create your own ProcGen system or use existing solutions such as SpeedTree, Houdini or Sceelix (shameless plug). Although you need to pay for the licenses, it may compensate the time your team saves.

    from Sceelix
  3. [-] Control: The ease to define certain designs and properties. When you want to create content with total control and specific details your best bet is to create the content manually. For your time, wallet and sanity’s sake.
  4. [+] Monotony free: If you have to create 100 3D buildings by hand, that can be a very tiresome and repetitive job. This is a point commonly made by game designers in favor of ProcGen.
  5. [+] Scalability: The ease to create small scenes as well as large. Once you determine the properties and parameters of the content you want to generate procedurally (which generates the overhead previously mentioned), the time it takes a PC to generate any amount of content depends solely on the limitations of the PC. Basically, from making 10 building to 100 can be a matter of seconds.
  6. [+] Compression: As you may remember from the high ProcGen purity game from my previous post, a whole 3D first-person shooter level fit into a 96kb executable because all its content (3D meshes, textures, sounds) were generated procedurally. When the game loaded up it used up over 300mb of RAM.
  7. [+] Paranoia: Is this tree distribution random enough? Or the number of branches and sub-branches for that matter? Aaahhh… ProcGen can give you more peace of mind in that sense, if you feed truly random seeds to a properly bounded system. Testing is always important specially if generation is at runtime.

    Printscreen 131021993101893786.png
    from Sceelix
  8. [+] Consistency: The guarantee that elements follow the same style and working principles. Almost in the opposite side of the spectrum from the previous point: Do these trees look like they’re from different planets? If you have a well rounded ProcGen system or tool specification, you can better guarantee greater consistency between content of the same type than if you did them manually. If you don’t, it can be a problem. Again, testing is important.
  9. [+] Reusability: Being able to make the most out of your work. Some ProcGen systems have a high reusability factor. Changing a few parameters could generate a whole new set of content. This also brings value you should consider, if you decide to create one. The more you can reuse it, the better the investment is of creating or specifying one.
  10. [+/-] Manageability: The ease of controlling the resulting output. If you are talking about creating large quantities of content, ProcGen can give you centralized control over the overall result. If you are dealing with small quantities, manual creation will give you more control. Some ProcGen tools also give you more control by giving you visual languages (normally node-based) with parameterization.
  11. [+] Adaptability: change to obey the rules you defined in your system. If you make a building double its original height, then the number of floors could automatically double. If the ProcGen system you use is well developed, you may change one of its parameters and the resulting output will adapt to meet the constraints you have in place.

    from Sceelix

These are the broad strokes. There are also some general considerations you should have when you use procedural generation, but that I’ll leave for my next post.

If you remember more arguments beyond the ones I mentioned, or have any feedback, let me know 🙂

Subscribe to this blog here:

Join and Invite others to the slack on ProcGen! sign

Join and invite others to the facebook group on ProcGen!

My twitter account:

3 thoughts on “ProcGen: pros and cons

  1. There are 3 other important problems for using PCG in a game production pipeline.

    The first one is the fact that in a real life production environment, the complexity of many different systems and data comes together, and it becomes a lot harder to use a PCG approach that is able work external around constraints and additions, simply because expressing them in a PCG’s syntax and semantics is impractical or impossible. As an example, consider the case in an RTS where a PCG generates beautiful terrain including AI maps, collision maps, etc. You can include balancing considerations and generate maps for PvP, tournament sets etc. During game production, everything (including the design and balancing) will constantly be tweaked and changed. Your PCG has to be able to factor in ALL these changes,or it will generate maps that are simply unfair or unplayable.

    The second one is a more positive thing and has common grounds with the first few topics you discussed: PCG’s are ‘perfect’ (in theory, in practice the lod’s still may need remapping of UV’s and/or stylistic changes) for generating LODs very early in the development, thus making room for other ideas and technology. Rather than being an afterthought to speed up rendering performance, it offers the accelerating force that your game design idea needs in order to be realizable.

    The third one is a philosophical point. To some extend, you can look at Spore as a model to explain it. Spore wasn’t hugely successful, but it contained a very funnily animated, powerful, ingenious and working creature creator where people could simply build their creatures and let them loose. This system could also spew out creatures you’d never have thought of, all within well-defined and constrained game-play limits and balancing checks. The game’s onset idea was ambitious, because it wanted to use PCG to bring a very rich and colorful lively world to the player and immerse them in a fantastic experience. The end result turned out not so great. One of the reasons for this (imho), is that the role of the developer has moved from building the game experience itself into building a rule-box that builds game experiences or at least marshals their validity. The developer-player relationship becomes detached, to the extend that the game experience itself becomes a more pointless execution of what’s in the rule-box. If you think this argument is too superfluous, just look at all the wall-jumping, speed-running, inverse-solving replay videos you can find of gamers trying to twist a game’s logic or exploit a bug and put it in their own rule-box. Which is not to say developers can’t be creative given these considerations, but the amount of required oxygen for that is a lot lot higher than the break-even point you’re describing.


    1. Hey!
      The 1st and 3rd points are considerations I’ll talk about in my next post. I didn’t mention your 1st point specifically here because that could be considered a control problem in a run-time implementation case. Thank you for the feedback 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s