Random idea: procedural content generation library
So, I'm just wondering... how possible would it be to write up a library that had all sorts of procedural content generation functions? It seems to me like some kinds of procedural content are fairly common in games -- particularly terrain, mazes, dungeons, etc. Wouldn't it be cool to write up a library of functions that generated all of these things (given particular parameters, or perhaps a config file) and then returned a data structure containing them, so that your program could use that data however it wanted? It could start out with a fairly simple parametric maze/dungeon/2d terrain generator and eventually expand into world generation, with sub-generators for each biome (kind of like we're seeing in the latest Minecraft).
Is this something people have considered? Would anyone find it handy?
Bart
It could be handy. Minecraft, for example, implements some known noise and fractal algorithms to generate much of its landscape.
A general library would be good, especially if it took advantage of existing, well-researched algorithms. E.g. I could write a maze-generator, but I'm sure someone out there has published a paper on why one specific algorithm makes the most efficient and interesting mazes.
I have some Java code to generate random fractal landscape on an hexagonal mesh. This can easily be tuned for a square grid.
Some random trees (fractal algorithm too) :
I can rewrite the code in C++, eventually start a library, but I will need help for the specifications.
In general I'm interested in a liberal licensed lightweight C library (not C++) with atomic operations - but I still have a lot of PCG evaluation to do - WIP not ready for standardisation.
If such a library existed, I would excitedly check it out. But I haven't much thought about procedural generation, so I don't know what I would want from the library.
And Tartos, that's gorgeous. Is the terrain just a fractal heightmap textured based on height and angle?
Wow, that looks like really sweet code there.
Before we talk specs, let's chat a bit about it and maybe solidify some informal thoughts on where this would eventually go. Here's what I'm imaginging this eventually being like (and mind you, this is serious pie-in-the-sky stuff... there are steps in this direction that would be very useful libraries in their own right):
I hope I'm at least kind of making sense. It will require being able to handle a lot of different algorithms and methods of partitioning data. But the neat thing is that, depending on how far zoomed out you are, you could tell it how many iterations to go, and then store some of the really basic stuff in memory and generate the other stuff on the fly when the player is close enough to see it.
Also, I realize this is ungodly ambitious, but it would also be super awesome. :)
Bart
Yeah, a terrain generator is probably a huge library in itself. But I figured someones probably done similar work already, and sure enough I found a couple of free bits of software:
1) Mercator ( http://www.worldforge.org/dev/eng/libraries/mercator ) is a library made as part of WorldForge, an open MMO framework. It's designed for sharing procedurally-created worlds with low bandwith usage.
2) Fracplanet ( http://www.bottlenose.demon.co.uk/share/fracplanet/index.htm ), a tool for generating fractal planets, probably not too different from Tartos's work above. At least, it doesn't look as nice as Tartos's work.
One more note on our hypothetical library: I'm personally less interested in on-the-fly generation than I am in pre-generation. As bart mentioned, Daggerfall was bland; I would rather take a generated world as a base and adjust as necessary to make it interesting for a game. This is sort of what the guy who makes Love (quelsolaar.net) does (not for terrain, but with lots of other procedurally-generated content).
My only concern with this idea is the difficulty in the API. Making the library useful to people across multiple game engines will be the tricky part. I think a thorough discussion of output formats will be a crucial.
for example if we want it to be able to export XML maps we need to decide how much variability in formatting we should allow. (to accommodate various use cases)
[I love the idea by the way]
I would not only consider output files, but also output callback functions.
I think perhaps it would be better to collect the algorithms instead, with perhaps pseudo-code. A C/C++ library would be useless to someone wanting to use Google App Engine to power the game, or XNA on the XBox 360 Indie arcade, or to someone using the free version of Unity, and so. You get the idea. Of course along with the algorithms and specifications, people would be free to create implementations of the library in their language of choice.
Or if that level of flexibility is not a concern, I'd say choose a 3D engine, like Panda3D, and write the API so you know it works with that, but still flexible enough that someone using a different engine could adapt it.
*checks post dates* ah, I see enthusiasm has already died down a bit on this idea ;) it is a tad ambitious.
Sounds like collecting information about algorithms would be a good idea. I had to surf the web up and down to collect bits and pieces on how to make effect or material x and y. And had to try a lot to find good parameters, functions and chains of functions. That's why I agree to collect "func'lets" and howto's (vs building uber-libs). Especially because Procedural Content Generation is (for me) the art of chaining meaningful functions. There are gui-tools for creating procedural textures - these provide the raw functions - but not the knowhow and best practices to make great things.
Maybe we should split this into a low-level and a high-level PCG-lib (library as in code AND books) for both parties. :)
I think perhaps it would be better to collect the algorithms instead, with perhaps pseudo-code. A C/C++ library would be useless to someone wanting to use Google App Engine to power the game, or XNA on the XBox 360 Indie arcade, or to someone using the free version of Unity, and so. You get the idea.
I'm going to go out on a limb here and say that even though it might be useless to a subset of people, there are plenty of people who could get use out of it. I'm not claiming that pseudocode isn't a good idea, but there are a lot of very heavily-used C++ libraries out there, many of which have bindings for other popular languages, like Python.
I wrote a random map generator in a warcraft 3 map once, not nearly as low level I know, but still, it was awesome :)
The DungeonHack guys have implement random terrain generation in Ogre3D, it might be worth leveraging off their code.