@Cervator and I have been discussing moving the world gen code into a separate project called gestalt-worldgen. The original thread is here: http://forum.terasology.org/threads/entity-system-code-in-engine-and-gestalt.1599/#post-13921. I started this thread so we could have a focused discussion about how to implement the move.
To be clear, the goal is to move out the idea of WorldFacet, FacetProvider, WorldRasterizer and the glue between those like WorldBuilder. Moving this out would be useful to others creating voxel games. I'm actually creating a game in jme3 right now so I would immediately benefit and verify the usefulness of such a move.
Here are some things that I have identified so far that need input from the main developers:
To be clear, the goal is to move out the idea of WorldFacet, FacetProvider, WorldRasterizer and the glue between those like WorldBuilder. Moving this out would be useful to others creating voxel games. I'm actually creating a game in jme3 right now so I would immediately benefit and verify the usefulness of such a move.
Here are some things that I have identified so far that need input from the main developers:
- Region3i is in the engine module and is heavily used by the world gen stuff. It seems that it would fit nicely in TeraMath. The package name could stay the same.
- WorldRasterizer needs CoreChunk to be able to call setBlock. To set a block you need Block, BlockManager and maybe other things which brings to light that we need a world-model to represent the world. They can probably all be interfaces and for example the Block interface doesn't have to have a getMeshGenerator() since it's not needed by WorldRasterizers. Any interfaces that get created for world-model could be implemented by their concrete counterparts in engine. For example, the new org.terasology.gestalt.world.model.Block interface would be implemented by the existing org.terasology.world.Block class in engine.