ES on a Voxel Engine?

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.

1 Like

Thanks for the answer. I’ll make more research about chunk/voxel.

Techniqually you could use one entity per block, but that would be hugely innefficent, so dont do that :slight_smile:
(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.

1 Like

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: https://www.seedofandromeda.com/blogs/29-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?

Hm that is a bit ugly, I would probably do it as a entity,
and add a system that synchronizes all voxellights to the voxeldata from time to time.

1 Like