Generating terrain for a video game is almost always done by hand, by artists, over a long period of time, sometimes even going to the lengths of placing each blade of grass that the player will see. This visual design and implementation of large scale AAA video games is the vast majority of their development budgets, spanning tens of millions of dollars that we obviously don’t have.
So we don’t do it that way. We can’t compete with it. Instead, we (like many other indie game companies) cut corners by making the game world generate itself procedurally, writing algorithms for the placement of trees, grass, rocks, rivers, mountains, glowing ruins and evil monoliths. Seriously, we have an algorithm for evil monoliths.
The Gray Man can be found among the giant horsetails on only the blackest nights when even the moon itself hides itself away from What Which Walks. No, this is something far more sinister than a quick asset scale test render in Maya.
David and I have been arguing since the last post on game terrain about the “binning” of our biomes into the 9 categories. His argument being that it’s an unnecessarily simplistic system for such a potentially rich environment. My argument was, of course, that at some point the simulation is growing so intricate that we’re spending time where we shouldn’t be, and that we’d be far better off improving the game-play than the terrain, but if we’re doing things right, the game-play will be pretty heavily influenced by the terrain, so a certain amount of this makes sense.
So I have capitulated, may the internet have mercy on me. Here’s how the system works right now. (If you don’t think that math functions are cool, this might be a little dry. Sorry about that!)
{ read this article }
