Trying to make conway's game of life (3D) (Struggles with entities exchanging information)

[dense vine]

I'm still stuck on square one.

I'm not sure how to proceed with structuring this.
My current thought is to create a grid that is an entity/entity-archetype, which holds say 64^3 render mesh components, or blobassets (alive or dead). It also holds a regular matrix to track the state of the grid. Then I'll just change the approriate render mesh based on dead/alive.

But, if I want to have more grids, they must communicate with each other, and exchange information (fill in if there's alive neighbor cell)... How do you do that?
I want to eventually expand this one into fluid/pressure simulation, so I want to be able to do the neighbor check by matrix convolution.

[marble tendon]

Entities don't exchange information because they don't act. Entities are just pieces of data stay there in the memory. System is the one gives meaning to the entities. System dictates how entity data is transformed and represented. Think of system as a domino artist and each entity as a domino piece, or a puppeteer and his puppet.

Basically, your system determines which entity is neighboured to which entity, which entity is considered alive or dead. Systems read, transform and write back into the entity data storage (chunk) to give a sense that entities are "alive".

[mild cave]

Conway's is unfortunately not a game that's super good to use with entities, since it's always going to be primarily optimal to have them stored as a grid of on and off positions.

[heavy totem]

Just an idea but you could have your own component that represents a position inside YourChunk and your own YourChunk component that defines a position of a whole chunk (sort of like voxel world chunking system). You could have a dynamic buffer of visible chunks ( grids) that you update when your camera moves. In an ISystem you could query this DynamicBuffer and if it holds 8x8 Entities and you are trying to access the neighbour outside the grid you would just access the YourChunk that is in the direction of the entity ? I have never done this in ECS so it might be a stupid idea 😅

[mild cave]

You could always look at the dots community challenge for inspiration: https://itch.io/jam/dots-challenge-1/entries
Though most people there made 2D game of life

[dense vine]

I was thinking something similarly I think, but you can't really access data this way. so I'd have to create new entities, and a bunch of flags, and a whole load of different archetypes to make sure the right data goes somewhere.

[dense vine]

But they need to exchange information? If two entities collide they must resolve. Both entities need to be aware of the collision, but you can't access the data when you detected the collision, so you can't make them aware of what needs to happen.

[dense vine]

I looked through that video, and I think I'll look through a couple of implementations

[marble tendon]

You're mixing the code's point-of-view with the user's. Collisions are resolved by systems or jobs. What needs to happen is determined by your systems. The entities are there just to hold the data.

You're still thinking in OOP which certainly won't help you in ECS. They are totally different.

[dense vine]

Yes, sure, but you're still running into issues. Like if you do spatial partitioning. You cannot access local data, you have to basically run through all the entities to first look if they're in the right partitioning. I guess you could maybe try to make sure each partition is of exact chunk size, but that's going to break whenever you add more remove data from an archetype.

[marble tendon]

To look up a cell for its alive/dead state, you can build a hashmap before running the propagation logic. For this approach, yes, you have to iterate over all entities. But by using a job you can split it up into multiple parts running parallely.

Another approach is using component lookup. But it could lead to random access which can destroy cache utility if the neighbour entity is from another chunk.

[marble tendon]

I don't get your point about spatial partitioning though?

[dense vine]

I think what I wanted was "IJobEntityBatch"

instead of being forced to do foreach every time (Or not, doesn't seem to be much different at all, still limited to yes/no if component exist, rather than value)

[marble tendon]

We have IJobChunk, could it be what you want?

[marble tendon]

Rather than add/remove component upon state change, you should use IEnableableComponent instead, because this kind of state change happens frequently.