Stop requiring Layer child classes

[oli-obk]

How interested were you in trying out/seeing the Rust design I discussed in https://hachyderm.io/@oli/113454444732941322 which only requires Chunk child classes, and merges LayerDepenency into Layer?

I could create a PR (with the full knowledge that it's highly likely to get closed and not merged), but it would be a major breaking change.

It could be quite annoying to review as it would be a large diff, but I'll try to keep it structured into small commits.

A few details:

• Chunk would not be generic anymore
• Effectively Layer would disappear, only LayerDependency would exist, but at that point, I renamed LayerDependency to Layer.
• AddLayerDependency would be more like a static field on Chunk returning the list of LayerDependency objects
• ChunkW and ChunkH would be moved onto Chunk (and made static, so they can't be changed at runtime by accident)

[runevision]

Hi! I appreciate being able to have this discussion at all. It's cool to see others take an interest in the architecture and to put their own spin on it. Broadly speaking, I think layer-based design architecture can evolve in the procedural generation community and I'm curious to follow that happening.

That said, the chance I'd accept a PR for a major re-design into my own LayerProcGen repo is very small.

I have a shipped game (The Cluster) that's based on the current design and has tons of layers/chunks. In that sense I know the current design has been proven to work for a full real-world use case and is okay to work with. A completely different design would be new to me and take a lot of effort to even evaluate properly (like rewriting my game to use it, to give it a proper real-world test).

I think it's okay for different versions of the layer-based infinite procedural generation concept to live in different repos and then people can choose the version they like best and base their games on that. And of course different repos can inspire each other and cherry-pick features/ideas/fixes from each other. I think this is more manageable and maintainable than aiming to have my original repo encompass every potential good new idea or change.

What I would like to do is add a section to the documentation about various forks and ports of the project with a few sentences about each on how they differ from the original. I will do this for your Rust version, and if you decide to make a C# repo that includes your conceptual changes too, I'd of course link to that one as well.