I've quietly made my LayerProcGen framework public:
https://github.com/runevision/LayerProcGen
It's a framework (C#) that can be used to implement layer-based procedural generation that's infinite, deterministic and contextual.
Nobody else have tried/tested it yet - if you're up for taking it for a spin, let me know how it looks; what's clear or confusing, if you think there's low hanging fruit improvements I could make, etc.
#ProcGen
The value of layer-based generation is not just the implementation, but also a certain way to *think* about how to define spatial dependencies for large-scale generation.
I've put a lot of effort into the documentation and its illustrations (examples here), which explain the high level concepts of the framework as well as the details.
https://runevision.github.io/LayerProcGen/
Procedurally generated open-world games tend to use "the functional approach" which essentially requires embracing sandbox gameplay.
LayerProcGen points the way towards making open-world procedural games based on "the planning approach" instead, which is normally only seen in "finite space" games such as rogue-likes.
#ProcGen
@runevision (Psst I think you meant "functional" on the first one and not "planning" on both.)
Really curious about this stuff!
@runevision I love your thought process on this, and every diagram has me thinking "yes!"
It's the proper route to emergent surprises for the player
@runevision It was for world generation. Each layer “zoomed out”, forming a kind of pyramid or cone if you rendered and spaced them out a little: just like many of your illustrations!
Managed to revive a bad old prototype. The “levels” on the right are the layers. Each hex depends on a group of closest hexes from the next layer. https://old-gamedev-experiments.pages.dev/worldgenerator/
@runevision For my PhD thesis, I created a multi-layered grid generating / caching system that you could think of as the dual of a quad-tree with the grid coordinates on the odd values rather than the evens. No two LODs share the same boundary which let me amortize updates across the different levels as you move. Also, objects of any scale would be fully contained in a single cell of some detail level. I didn't get around to implementing anything using the latter.
@runevision I got a job offer and ran out of time, so I focused on implementing the functional terrain. Your implementation is much better fleshed out than mine would have been.
My idea was similar to yours in that coarse levels would place towns and the paths between them which would influence the terrain generation of the finer levels they overlap. Likewise, I intended to generate watersheds that would force the land to descend as needed.
Your implementation easily subsumes mine.
@Sythelux Cool! I'm very curious to hear how it goes in Godot. I've tried to make as much as possible non-Unity dependent, but some non-core things were difficult. Details here:
https://runevision.github.io/LayerProcGen/md_UsingWithoutUnity.html
I'd be open to including Godot-specific parts and wrappers (similar to the Unity ones) if someone wants to implement it, and we can find a good way to make it work in the repo.
@runevision how did you do the upm branch is it simply branched out and then files moved around or is there some file referencing magic going on? because I would do something similar in Godot with their addon system.
btw I can't promise anything, but this framework looks really well thought through so I'll at least start to make something and we see how it goes.
@Sythelux It's a separate branch (with no shared history) where the files are moved around according to this python script:
https://github.com/runevision/LayerProcGen/blob/main/upm_release.py
Currently I run the script and check in the result manually on my computer for each commit, but I might automate it with a GitHub action at some point.
And yes, there could be a separate branch for delivering to Godot as well using a similar approach.
@runevision I got one half of the SimpleSample done with no changes in the base code. I had to make an InterOpGodot of course and an extra Godot for the commons files, but that was pretty much it so far.
I had to realize that you had the exact same idea with threaded loading, but your implementation is better.
I'll try to port the TerrainSample as well and then I see if I can add it to my Digital Twin project.
my branch is here:
https://github.com/Sythelux/LayerProcGen/tree/godot
Thank you for the clean work.
@runevision I got the second half of the Simple Samples as well!
I pushed it. Feel free to check it out. I'm very happy this was possible ~
@runevision thank you! and I do try to get terrain to work. I'm actually sitting in the Godot Chat rn, because Terrain3D is missing C# bindings and there is a proposal for Godot to generate C# Bindings for any GDExtension itself, but I can't seem to find how. Since no one is answering me currently I will fall back to create a makeshift binding with only the functions I need exposed.
But yes the whole Terrain API might be completely different from Unity, but I wanted to figure that out anyway.
@lw64 Right, it's designed with that in mind; check out the "using without Unity" page:
https://runevision.github.io/LayerProcGen/md_UsingWithoutUnity.html
And also check out @Sythelux's work on getting the framework and samples to work in Godot:
https://phanpy.social/#/mastodon.gamedev.place/s/112497970064705346
@runevision @lw64 I'm on good track with that, but it will work differently from unity in Godot. I don't have burst and Unity.Mathematics package, so I'm currently building a slow version with Godot Native Array to get a hang on and then maybe switch to the GodotServers pattern (I can tell more about it, if you want).
The Simple Sample is enough to get started and even make your own sample for whatever else so the "framework works in Godot", but the Terrain Sample will take me a while longer.
@Sythelux @runevision I am a contributor to Terrain3D, and in the next version there will be also foliage/instancing features available, but they are already on master, and ready for testing afaik.
The Godot native array thing is about the internals of the framework, right?
ah cool. If you are contributing to Terrain3D could we talk about the C# bindings? The current approach is okish, but the maker of DebugDraw3D (https://github.com/DmitriySalnikov/godot_debug_draw_3d) found a way to generate C# Bindings from code. It would be cool if that exists for Terrain3D as well.
for the arrays I just realised I have to remake that part again. I was using Godot.Collections.Array<T> (the native arrays I thought), but really need to use T[] arrays in C#
@Sythelux I think you mean proton scatter, but that works of course too.
Actually I never written C# code, but it shouldn't be too difficult ;) I can look into your port if you want :)
@lw64 C# can be difficult, when it is a bit of a mess.
I submitted the latest version you can take a look and should even be able to run it. You won#t see anything as it is a heavy WIP, so it is getting stuck somewhere in the code when executing, but the skeleton is there.
Per "Gimmic" Johansson
Rune Skovbo Johansen
Anders Stenberg
Nick Ludlam
mikeful
Joni Korpi
Steven Dollins
Syd
flaeky pancako
James Jarman
Richard Griffiths
brian
Foxis The Cookie Dragon
Lorenz
