I've been working on a procedural terrain generator for fun. Voxel-based. Just big chunks of 16x16x256 sections. Like minecraft.
My goal is create a function that will take any 3D integer coordinate and output a particular type of block for that coordinate... be it air, granite, dirt, etc.
The constraint, however, is that the only knowledge the function has is the coordinate; that is, it has no knowledge of adjoining blocks.
The second constraint -- (because one can never trust floating point) -- is to have the function (and the requisite RNG) use only integers between 0 and 100,000 with no calculations that involve fractions. This constrain is to guarantee that with a given seed, the same terrain will be generated on any system. Rolling hills and mountains and caves and all the typical minecraft kinda stuff is trivial. But, I'm trying to get my magical black-box function to create buildings with walls, windows, etc. that's trickier.
Why no fractions? If you are worried about loss of precision caused by floating-point numbers, you can use exact fractions. For instance, there is "mpq" in GMP (for C), the "fractions" module in Python's stdlib, or you could hand-write a small fractions library yourself.
Agreed. It's a sort of silly constraint. Not truly necessary. But, there are other aspects of the project that make it much easier to completely and utterly do away with floating point.
Generating constructions is very different from generating terrain, so I'd probably try a 2-step process where the building generator can be seeded by the terrain relief. But it's not trivial for sure. See also https://github.com/mxgmn/WaveFunctionCollapse#higher-dimensi... because it's relevant and looks awesome :)
The fact that all of the illustrations in the article update when you generate a new terrain is neat attention to detail :) Good article, thanks for it and for open sourcing your code!
I love this. Recreating old games makes you really appreciate the techniques and effort put into even the small things that one often takes for granted. Doing it yourself is a great way to learn real-world applications of abstract math/compsci algorithms.
I hope others build on this in the future and add the worms gameplay mechanics. One of my favorite games when I was younger.
This is great! About 6 years ago I created a worms destructible terrain using canvas. Still up on my website all these years later, no promises on code quality though :)
WebGL (three.js) based. Keyboard input, arrow keys + space to fire. (no use on any mobile device)
Terrain operations are done on vector svg-like objects, not pixels or polygons.
Physics is also done in vector space.
Terrain is converted to polygons just before rendering.
Was kind of fun :) With the right terrain the physics let you drive your tank round and round in a loop with centripetal force.
- perlin noise: https://en.wikipedia.org/wiki/Perlin_noise for generating terrain bumps
- flood fill for painting terrain on top of noise : http://lodev.org/cgtutor/floodfill.html#Scanline_Floodfill_A...
- convolutions with webgl shaders https://github.com/phoboslab/WebGLImageFilter
- dilation filter
- "closing" in image processing https://en.wikipedia.org/wiki/Closing_(morphology)
- deciding in the hqx algorithm for anti aliasing https://en.wikipedia.org/wiki/Hqx
- texturing
- halton sequences for even distribution of worms https://en.wikipedia.org/wiki/Halton_sequence
- sine wave for water
all done in the browser.
github repo at https://github.com/juliango202/TerrainVer