After a while, i’m able to get back to my voxel engine and so, I was reading the full code in order to remember and refactor somethings. But then I noticied it got a bad design on the voxel generation, the way I used to manage chunk generation is very bad designed (high dependency) and since I last developed it, I read tons of articles and books about game design, so now I know it is really bad (also lots of Singleton-Managers).
So I started to search for a design-pattern to help me to solve this problem and I found ES very interesting. I’ve read the full wiki and tons of posts on Zay-ES section, and i’m ready to try it, but I think I didn’t fully understand the concept behind it (the hardest part to use ES is to change the way we think on development) but I know it’s mainly data-driven, so Components are basicaly “Data Holders”.
TL;DR; Now my question is: Since the core of voxels spin arround Chunks (model) and those chunks are represented by Geometry (view) how I’m suppose to implement ES on those kind of game? I mean, most of trouble in developing a Voxel Engine is how to handle the voxel storage (compress it, retrieval, node traversal, etc) and all those “problems” lays on “Model” which is where ES would help, so should I have just a ChunkComponent for each chunk (entity) and a ChunkSystem/AppState to compute each chunk(entity) and later just render the geometry?
Sorry if my post is too long, but since I’m a little confused, it’s also hard to ask the right question.
Short answer: a chunk or a voxel are not really game entities. I wouldn’t implement them in an ES. It doesn’t really solve your data storage problems either because you have a lot of data that needs to be managed in a non-ES way.
Personally, I’d just pick some chunk granularity and store them to disk… page them with something like my Paging library or roll your own. The ES would be for everything else.
Techniqually you could use one entity per block, but that would be hugely innefficent, so dont do that
(the entity id alone is larger than a proper storage requires for a block, not to mention that you loose stuff, like fast neareast x searching ect)
For my spaceships I use a entity wich has the raw voxeldata added to it, this works however only, because the typical spaceship is very small in total storage size. For a real world this will break fast. All more important voxels than hull are done as full entities instead.
I’ll start by refatoring my code and applying best pratices (like remove Singletons) where is possible. But what about a, for example, torch that modifies the voxel lighting? I use baked lightings strategies, where each voxels holds a byte for lighting (normal and sun), as sugested here: SoA - Fast Flood Fill Lighting in a Blocky Voxel Game: Pt 1
Those torchs and others objects should be an entity with a LightingComponent or VoxelLightingComponent, so I would have a LightingAppState that get those components and add the lighting, right?
