Content

The procgen rabbit hole, what I have learnt so far (programming)

A part of Articles.  submit an article

posted by owen on Tue, 16th Aug 2016 at 3:10 pm .

I've been experimenting with Procedural Generation for the past year mostly programming in C. I keep forgetting to write down the lessons I learn and the discoveries that I make so this article is a random list of things that I found while venturing down the rabbit hole that is #procgen.

#progen can be anything but definitely not random

Many people think that #procgen is about generating lots of random environments/stuff that you stumble through with the chance of seeing something awesome - its totally not - it is more like controlled variety. Procgen is not much fun if the developer/artist is not sure of what the output is going to be. Which is why most applications use some form of "noise function". In my case I am using simplex noise to generate my landscapes. Having predictable output allows you to do cool stuff like placing plants and buildings and doors without having them pop up at unusual place. Procgen is controlled chaos.

Avoiding game breaking #progen

I see a few people complain about the repetition of certain things in #NMS such as the ships. The thing with the player ship in that game is that it is an essential part of its gameplay, it would be very annoying to the player to buy a ship only to realize that it has a broken shield OR the flight controls are #procgen wonky OR its design violates the games physics. Ending up with a broken ship that cannot fly would be almost game ending in a situation when u can only have one ship at a time.

In contrast you can have hazardous planets in the game ‎since a planet is one of many that the player can choose to visit or leave at little cost. This is why more focus is placed on variety in planets rather than space ships. If NMS was roguelike then maybe you could have a few game ending scenarios but I think they chose not to grief the player. Bottomless pits, over powered animals, death mushrooms etc.

Procgen has to be learn-able

There has to be some kind of underlying system in any procgen project. Imagine a #procgen mario kart game in which every level you played was totally different and every kart had different handling, 3 or 4 wheels etc. The player would never be able to gain any level of skill or mastery. Eventually the player would become frustrated. So there has to be a balance between apparent randomness and solid game play systems that function well inside the procgen world.

Real Time #procgen requires lots of work

I had to re-write my terrain engine 4 times so far because in order to get good results from your program you have to be in control of almost every single aspect of your #procgen work flow. If you render your #progen ground using a particular function and another to place the trees you will end up with floating trees, trees below ground and trees in lakes. All elements of your procgen code must come together in a harmonious soup. This is why alot of developers write custom engines. Maybe they are just control freaks but the last thing you want to do is code yourself into a OOP corner like this dude. You have to be willing to throw everything out and make it better-simpler. Learn from your past experiences. Keep your code modular.

Realism is less important than wonder

Sometimes you have to bend the rules a bit to make a procgen system work. As you can see in the recently released "No Man's Sky" - having gigantic planets very close together will not be good for the health of the planets but it makes for cool sci-fi book covers. So if there is a chance that your game or code would be more interesting but less physically accurate then I would suggest you go for it.

Teraflops matter but not so much

The faster the hardware you use to run #procgen the more stuff you can do. With infinite power you can have millions of levels of details and generation passes. However having a million blades of grass on screen does not really make your game more fun or believable. Since my hobby programming platform is the Nintendo Wii (clocking in at a max 729 MHz CPU and ATI 243 MHz GPU) I am always balancing #procgen with graphical fidelity. I can probably pull off 200 lowpoly trees but I would rather drop it to 100 so I can keep hitting 60 frames a second. Frames per second matter more to me than anything else.

The Wii has 2.7GB/s bandwidth compared to the PS4 which is 176B/s. It would be cool to have all that extra bandwidth but a faster computer wont help you write better code. Sucky code will still be sucky at whatever speed the computer is running at. The more processing power you have the easier it is to hide bad code but bad code reveals itself sooner or later.

Being able to maintain focus

Anyone who has been programming for a long time knows that it is easy to go off the rails and start writing unecessary code for things you do not need - edge case tools or APIs for APIs. Distractions are magnified 10x when you start a #procgen project. The chance of not finishing your project goes up exponentially the more stuff you add to it. Better to keep your targets small if you want to finish something before you go broke or die. Such is life. In my case my landscape engine only does land and water bodies using a simplex-noise hieght-map hence caves are IMPOSSIBLE! But I am not going to waste my time trying to make caves because even if I only get the landscape 50% functional I wont even need caves for anything. Screw caves.

Bugs, Bugs and more bugs

In #procgen a small bug can make a big difference. I am constantly searching and looking for ways to do more with less code. The first few versions of the landscape engine was sampling the simplex noise 40k times per frame. This was because of a bug in my code which was doing more work than it needed to do. Once this was fixed I could move on to do other things with the extra CPU power that I gained.

Bug hunting is at the top of my list (not the same as over-optimization). Unit testing wont help you in this case sorry, "new code" cannot be unit tested. Even in a case where you know exactly what you want to write there maybe conflicting issues that force you to choose sides.

Conclusion

Procgen is a fun excursion but it is not easy and it might waste your time if you are not good at problem solving and functional coding. Stick to your strengths.

Further reading

Articles
Procedural Content Generation in Games - a bit long winded

Long Videos
Reset Button: The biggest game ever
A Behind-The-Scenes Tour Of No Man's Sky's Technology
Flow in Procedural Generation
PROCJAM 2014 - Procedural Doesn’t Mean Random: Generating Interesting Content
How Grids and Patterns Work Together
Reset Button: Megatextures



permanent link, visited 154 times, Post your comments on this article. .

comments

    Comment list is empty. You should totally be the first to Post your comments on this article.


comment