Procedural Generation

[ColdDog]

I thought you folks might like this article... It seems basic enough for me.

Procedural Generation: Pros and Cons

Originally posted at procgen.wordpress.com In this article I discuss the pros and cons of using procedural generation (ProcGen). This typ

www.gamedev.net

 

[Printimus]

I think if it is done with the right parameters and the right realistic goals in mind, great things can come from this as seen with the ArcCorp Planet.

 

[Michael]

Expected something slightly different, but not dissappointed. All those mentioned arguments sound pretty logic to me.

 

[Lorddarthvik]

Great article, good overview for those who already understand how proc gen works! Very useful for us in this line work.

I would add one more point through:

TroubleShooting (+/-): having something manually modeled and placed means you can just go over the object and most likely find and fix the problem in minutes. Let's say you have a forest using 3-4 different kinds of manually modeled trees, scattered around using a simple scatter tool. If some of the trees are facing upside down, you can easily check your manually modeled trees if they have their axis flipped or something. It would take 10 seconds to fix, and would look just as good as a fully procgend forest.

The same can apply to proc-gen, or not at all. You could be bashing your head against the wall for days, just because you missed an extra dot or something in the generating algorithm.

Back at my old place we once had an issue with a simple object generation script that took 2 days to fix, and you would never have guessed what the issue was:
The script was copied over from an open library, then modified for our needs. It should have worked perfectly, but even the unmodified script would throw a fatal error on the first stop.
Every line of code had to be closed with a ;
The ; used in the original script while looking the exact same ; that we typed, was actually using a different code to write that character!! We spotted this as we re-wrote the code line by line, trying to find the error. Replacing all the ; character with our ; fixed it, and the script ran perfectly! We could have modeled and scattered the stuff we needed by hand over the 2 days used for troubleshooting, but it was worth it in the end for faster modification of the generated geometry.
This is the kind of shit you have to deal with in ProcGen on even the most simple levels, so it's very case dependent if it's worth using it or not.

 

[Radegast74]

Great article, good overview for those who already understand how proc gen works! Very useful for us in this line work.

I would add one more point through:

TroubleShooting (+/-): having something manually modeled and placed means you can just go over the object and most likely find and fix the problem in minutes. Let's say you have a forest using 3-4 different kinds of manually modeled trees, scattered around using a simple scatter tool. If some of the trees are facing upside down, you can easily check your manually modeled trees if they have their axis flipped or something. It would take 10 seconds to fix, and would look just as good as a fully procgend forest.

The same can apply to proc-gen, or not at all. You could be bashing your head against the wall for days, just because you missed an extra dot or something in the generating algorithm.

Back at my old place we once had an issue with a simple object generation script that took 2 days to fix, and you would never have guessed what the issue was:
The script was copied over from an open library, then modified for our needs. It should have worked perfectly, but even the unmodified script would throw a fatal error on the first stop.
Every line of code had to be closed with a ;
The ; used in the original script while looking the exact same ; that we typed, was actually using a different code to write that character!! We spotted this as we re-wrote the code line by line, trying to find the error. Replacing all the ; character with our ; fixed it, and the script ran perfectly! We could have modeled and scattered the stuff we needed by hand over the 2 days used for troubleshooting, but it was worth it in the end for faster modification of the generated geometry.
This is the kind of shit you have to deal with in ProcGen on even the most simple levels, so it's very case dependent if it's worth using it or not.

LOL....I had the same problem one time copying over a script. I guess the original code wasn't in Unicode or whatever...the ";" or whatever it was *looked* like a ";" but really was something entirely different. It was pretty funny...after I got over the urge to throw the whole damn computer out the window. My god, troubleshooting that was a nightmare. You expect bugs, but not something weird like that!

 

[ColdDog]

The ; used in the original script while looking the exact same ; that we typed, was actually using a different code to write that character!! We spotted this as we re-wrote the code line by line, trying to find the error. Replacing all the ; character with our ; fixed it, and the script ran perfectly! We could have modeled and scattered the stuff we needed by hand over the 2 days used for troubleshooting, but it was worth it in the end for faster modification of the generated geometry.

I run into issues all the time with stuff "like" this. I have never used Procedural Generation, but I am always going between a windows editor and linux. Sometime linux hates my tabs so I have gotten to the point that I just copy and paste my code into a linux editor so it has the proper encoding. Some languages or not as forgiving as others so error handling and documentation is very important.

 

[Radegast74]

Great article, good overview for those who already understand how proc gen works! Very useful for us in this line work.

I would add one more point through:

TroubleShooting (+/-): having something manually modeled and placed means you can just go over the object and most likely find and fix the problem in minutes. Let's say you have a forest using 3-4 different kinds of manually modeled trees, scattered around using a simple scatter tool. If some of the trees are facing upside down, you can easily check your manually modeled trees if they have their axis flipped or something. It would take 10 seconds to fix, and would look just as good as a fully procgend forest.

The same can apply to proc-gen, or not at all. You could be bashing your head against the wall for days, just because you missed an extra dot or something in the generating algorithm.

Back at my old place we once had an issue with a simple object generation script that took 2 days to fix, and you would never have guessed what the issue was:
The script was copied over from an open library, then modified for our needs. It should have worked perfectly, but even the unmodified script would throw a fatal error on the first stop.
Every line of code had to be closed with a ;
The ; used in the original script while looking the exact same ; that we typed, was actually using a different code to write that character!! We spotted this as we re-wrote the code line by line, trying to find the error. Replacing all the ; character with our ; fixed it, and the script ran perfectly! We could have modeled and scattered the stuff we needed by hand over the 2 days used for troubleshooting, but it was worth it in the end for faster modification of the generated geometry.
This is the kind of shit you have to deal with in ProcGen on even the most simple levels, so it's very case dependent if it's worth using it or not.

LOL, this **just** happened to me! I wasted 45 min trying to figure this out...I spent the first 30 min ignoring the error message, doing my usual tricks to get things to run...then spent 10 min reading the error message...then spent 5 min really, really reading the error message and noticed then there was an "invisible" character that was causing my routine to bomb.

 

[August]

Great article, good overview for those who already understand how proc gen works! Very useful for us in this line work.

I would add one more point through:

TroubleShooting (+/-): having something manually modeled and placed means you can just go over the object and most likely find and fix the problem in minutes. Let's say you have a forest using 3-4 different kinds of manually modeled trees, scattered around using a simple scatter tool. If some of the trees are facing upside down, you can easily check your manually modeled trees if they have their axis flipped or something. It would take 10 seconds to fix, and would look just as good as a fully procgend forest.

The same can apply to proc-gen, or not at all. You could be bashing your head against the wall for days, just because you missed an extra dot or something in the generating algorithm.

Back at my old place we once had an issue with a simple object generation script that took 2 days to fix, and you would never have guessed what the issue was:
The script was copied over from an open library, then modified for our needs. It should have worked perfectly, but even the unmodified script would throw a fatal error on the first stop.
Every line of code had to be closed with a ;
The ; used in the original script while looking the exact same ; that we typed, was actually using a different code to write that character!! We spotted this as we re-wrote the code line by line, trying to find the error. Replacing all the ; character with our ; fixed it, and the script ran perfectly! We could have modeled and scattered the stuff we needed by hand over the 2 days used for troubleshooting, but it was worth it in the end for faster modification of the generated geometry.
This is the kind of shit you have to deal with in ProcGen on even the most simple levels, so it's very case dependent if it's worth using it or not.

.csv files and punctuation in the source data, and blank rows from a hard return...