next »

[Francisco RA]

Originally posted at procgen.wordpress.com

This entry is about considerations and aspects you should think of when you are implementing  procedural generation (procgen) systems, beyond the pros and cons presented in the previous post (here).

Some of these could also be considered pros or cons and, in fact, some of you commented that. The main difference is that these are more case specific.

Here we go:

• Define objectives: If you are dealing with runtime (real or load-time) procedural generators in a game, you need to create rules in a way to guarantee that the game objectives are not compromised. The right rule set and logic can sometimes be tricky to fine tune and narrow down.
• Testing: As part of guaranteeing the previous line, runtime ProcGen systems require you to thoroughly test its results. The more freedom you give your ProcGen system to create content the more you need to test it. You really want to make sure the resulting content is plausible, so that nothing weird is generated or something that stops you from completing the game’s objective.
  
  
• Perception: The question is: do all these trees look alike? Is this room memorable? Or will the user distinguish similar type content? If you want them to, you should make sure you know what aspects and details help you to achieve this perception. GalaxyKate brought this to my attention and you can read her interesting post on it (and her experience on spore) on her Tumblr here.
• ProcGen by necessity: There are some types of games that require you to use ProcGen systems, like Infinite runners and Roguelikes, or games that learn and adapt with your inputs and gameplay. There are also other good to have situations like creating special effects or textures (like with Substance).
  
  
• Prototyping: If you have a ProcGen system or tool, it could help you to prototype game levels that require content in scale, like open-worlds. If you are using ProcGen at design-time you can use the resulting content as your starting point.
• Rewarding: Another thing you need to worry about is the sense of reward, if the generated content somehow influences it. Normally, you’ll want the game to give you a sense of accomplishment, be rewarding and fun. Again, testing is important. Tanya Short from Kitfox Games talked about it at GDC 2015 (below).
  
  
• Replayability: If you have a runtime ProcGen system that guarantees a good variation of your game experience every time you play it, that can increase the game’s longevity, meaning people would take longer to get bored of it. Gives it a sense of novelty that can, at times, surprise even its creator.
• Discussion value: You need to manage this value properly. Runtime ProcGen, depending on the cases, will give you less walkthrough material (sometimes more) to talk about with other gamers. This mainly because each player will have a different experience. On the other hand, there are other things you can discuss. Minecraft gives you a lot of creative power which you can share with others. Infinite games, for instance, use the point system to allow gamer comparison.
• Art perfection: It’s not easy to get ProcGen to produce art like a human artist would. It can be difficult for (random) runtime ProcGen art to satisfy 100% of the time. This mainly because it can be difficult to test all possible outputs and, if you decide to change one little variable, you can define a whole new set of outputs.

I hope you guys enjoyed this list. Let me know if you have any comments or other considerations that I missed

—

Subscribe to this blog here: eepurl.com/bSgft9

Join and Invite others to the slack on ProcGen! procgen.slack.com sign up: bit.ly/procgenregistration

Join and invite others to the facebook group on ProcGen! bit.ly/procgenfb

My twitter account: twitter.com/grillher

[oahda]

How come you didn't post this one until today? Saw it several days ago on the blog. o:

[Francisco RA]

I forgot, to be honest 
Sorry for only replying now but I was notified of your message.

[gimymblert]

well I will post all your post in the procedural dump archive, first link in my signature

[Deckhead]

I don't know if this is an implementation consideration, but it avoids us programmers from needing to develop artistic skills or engage an flakey artist.

E.g. From my own procedural space engine. Nothing but code, no textures or anything.

[gimymblert]

You confuse execution with art, artist understand thing way more than putting a texture together.

It doesn't avoid from developing artistic skills, quite the contrary, now he must understand and think like an artist, ie the whole process before putting the pen down about legibility, composition, mood, rythm, style, meaning, etc ... ie "Art"

[Deckhead]

I'd argue that a programmer, or really any human, has those abilities innately. It's the mechanical skill with the brush that non-artists lack.

[gimymblert]

I'm not so sure, we have innately like we all have the ability to dance, but between trained and non trained there is still a chasm that need to be appreciate. Programmer art is not bad because execution is bad, it's generally the judgement that is damning!

[Deckhead]

But then there are those who are naturally good artists, yet only need to strengthen their mechanical skills. By this token I'd argue that programmers are artists in a sense, especially those who program their own engines etc. Therefore, they have the gift and ability to create visual art with depth and meaning, but lack mechanical skill