working with an ECS is pretty new to me but feels great so far!
So I’m working on a project that is very much dependent (gameplay-wise) on deformable height map terrain. A single level map should consist of one height map of at least 1024 x 1024 up to maybe 4096 x 4096 individual height points. These height points may be adjusted pretty randomly each frame at many locations on the map. The deformed height map should then allow to read actual ground height at a world location for basic collision testing.
I know all this stuff can be done using the JME TerrainQuad system, but I want to do it the ECS way now.
So would it make sense to have a Height Map Component that would store the terrain heights?
The data in it would consist of a single large array of floats representing the height points. Then I could have a Terrain System that would apply the heights of such a component to a TerrainQuad (with LOD) for visual display, a system for terrain modifications and one for collision (the latter two would only work on the component data, not on the quad scene graph object).
Sounds good so far with a clean separation between logic and rendering, but my main concern right now is memory usage and garbage collection. Since components by design should be pure read-only data objects, to modify the height map I would have to copy these large arrays (e.g. 4096 x 4096 x 4 byte float) every time changes are made, probably at many locations per frame!
What’s your opinion on this? Would this still be feasible?
So would you then still consider it OK to rely purely on the data stored in a TerrainQuad object?
I feel like that would be to tightly connected to the scene graph (pure visuals) but on the other hand I could reuse all the functionality already built in like height modification and collision.
Or should I still have a separate terrain data array (maybe in a World Singleton or something) to work on for logic purposes?
Personally, I would represent the world in a way convenient to my “server” (even if you are not running networking it’s good to think this way). So personally, I would steer away from keeping it in terrain quad but it’s certainly the most straight-forward way in your case.
In Mythruna’s case, the world is a giant 3d array of discrete values. How I represent it to the viewer is not relevant to that, really.
Alright, so I now have a central Terrain system that has a single large terrain quad and reacts to terrain modification entity components during update.
It uses JMEs TerrainQuad behind the scenes for now but I may switch to some pure logic solution (e.g. large height array) in the future.