Welcome to the third part of this Procedural Generation (aka ProcGen) classification series called “Many faces of Procedural Generation”. To see the previous part click here.
In this post we’ll talk about determinism in ProcGen, which makes sense especially for run-time generation (load and real-time). Procedural does not mean random. Even if you use some kind of (pseudo) random function, if you use the same seed, you’ll get the same results. Here is how you can classify it:
Deterministic generation: When, given the same inputs, you can get the same output. If you are dealing with a large amount of generations, you may need to do some testing to ensure that you do not get any unexpected results or get an outcome that doesn’t interfere with the game’s objectives. A good example of deterministic generation is the Universe of the much expectedNo Man’s Sky, where it’s always the same Universe being generated for everyone (with 18,446,744,073,709,551,616 (18 quintillion) planets, that’s a lot of testing). Another is the 96kb 3D game.kkriegerin the generation of all its content.
Deterministic at load-time generation: When you get a deterministic generation only after you’ve loaded the game level. Basically, once you get the initial random inputs the generation becomes deterministic. A few examples of this are the worlds inMinecraftand the level layouts for Rogue-like games such asThe Binding of Isaac.
Non-Deterministic generation: When you cannot determine the outcome of the generation. Even if you can vaguely predict the outcome generation (because of probability functions), with Non-deterministics you never know for sure. Stateless. An example of this are the obstacles of infinite-runners such asTemple Run.
Hope you guys enjoyed this part of the classification system and check out the previous parts if interested. Let me know if you have any comments or other considerations that I missed 🙂
ANNOUNCEMENT: The project Sceelix – 3D ProcGen Engine – that I’ve been working on with some friends for the last year has finally come out! Woohoo! Check it out atwww.sceelix.com. Trial version available 🙂
Welcome to the second part of this Procedural Generation aka ProcGen classification series called “Many faces of Procedural Generation” series. To see the previous part click here.
In this post I’m going to introduce a new concept:
ProcGen purity: This concept is a scale mainly used to compare the methodology’s contributions to the final resulting product in different ProcGen strategies. This is important to have in mind because ProcGen can complement a game designer’s work in many ways.
Here are a few strategies used by game designers to explain the relative generation purity:
Half and half generation: When you procedurally generate part of the content and produce manually the remaining content. For example, if you are creating a 3D city or forest, be it in real, load or design time (check my previous post), you may want to create the meshes procedurally and use manually produced textures. This would stand somewhere in the middle of the purity scale.
Placement generation: When you (manually) produce most of the content and depend on ProcGen methods to place on set. This can also include basic transformations such as rotations and scalings. For examples like below that you have manually modelled 3D cars that you just want to scatter copies of it randomly on a parking lot (could also randomly apply tint and change the car’s direction) this is a good method. This strategy is also popular to randomly spawn enemies. You could also use external data from a database to define the placement. This strategy stands in the low end of the purity scale.
Pure generation: When you produce all your content procedurally. Meshes, Textures, sound, behaviors… If the 2004 german game .kkrieger is not 100% pure ProcGen it is very close to it (load-time ProcGen). So much so that its only 96kb in size (compression is a result of ProcGen) but once it is loaded it goes up to over 300mb in you task manager. Take a look for yourselves if interested (download here). This is at the top of the purity scale.
These are just a few examples of ProcGen strategies and combinations.
But remember, you should only use ProcGen if it makes sense to you and complements your work (not replace it).
Hope you liked this post! I still have more parts to these series. Let me know what you guys think! 🙂
ProcGen can be used in different ways for lots of different reasons. Because of this, and to know what we are referring to, classification systems can be adopted to characterize these different types of use. In this “Many faces of Procedural Generation” series, I’ll show you some ways you can classify ProcGen.
In this post, I will outline the ProcGen classification system I use to describe when the ProcGen content is generated.
Design-time generation: When you generate the content beforehand and include the result in the game being developed. You may change anything that needs tweeking, giving you more artistic freedom. This method is used in some open world games, like for instance Ubisoft’s “Assassin’s Creed: Unity” to create their city blocks and other specific environments. Check out this video from 5:05 on this:
Load-time generation: When content is generated before the game, level or sub-level is played. Very popular with roguelike games like “Dungeons of Dredmor”.
Real-time generation: When content is generated while the game, level or sub-level is played. Very popular among infinite runners such as “Temple Run”. Also used in “No Man’s Sky” to create their massive open world.
I’m not sure how many parts these series will have but I’ll post part 2 soon! Hope you liked it and feel free to let me know what you guys think! 🙂