generational-arena VS protobuf-go

In my experience it is often easier to use indexes instead of copying Rc's. If you want to mutate the graph, then look in to slab and generational-arena

Regarding ECS: yes, but in a deflationary sense. The game has entities, stored in something very similar to GenerationalArena, and it has "systems", which are just functions that operate on these entities. The components themselves are just fields of the Entity megastruct. Having an ECS in the narrow sense doesn't really make a lot of sense for this game, because a lot of its rules are dependent on each other, and there's very little chance to extract parallelism. Also, even the current largest levels have less than 10k entities, so simulation performance is not a bottleneck yet.

If you cannot inplace construct the slice-dst on heap and your slice is too large to be copied, then I think there are two solutions: - Using Box>, this adds another level of indirection but avoids the copying - Use an arena like slotmap, slab, generational_arena or concurrent_arena to store the Box<[u8]>. It still needs heap allocation, but it allocates in chunks, thus less fragmentation and performs better.

I think this is less of a good fit though: the word "arena" doesn't imply iteration is possible to me. I think arenas also conventionally will reuse previously-released handles (unless you implement akin to a generational arena), so the term might be a bit misleading in that regard.

Might wanna check out https://github.com/fitzgen/generational-arena / https://github.com/ArnaudValensi/vec-tree/blob/master/tests/tests.rs.

This is far from the only arena allocator written in Rust.

From the same author, a zero-unsafe arena allocator: https://github.com/fitzgen/generational-arena

There are many, many arena implementations available with varying characteristics. It's disingenuous to act like Rust requires the author of an arena library to write "unsafe" everywhere.

If someone wants to adapt it to create computergames, then it would probably be useful to find a way to introduce generational generational indexes

Protocol Buffers: https://developers.google.com/protocol-buffers

ProtocolBuffers’ OneOf message addresses the case of having a message with many fields where at most one field will be set at the same time.

That's definitely the bigger thing. I think something like Protocol Buffers (Protobuf) is what you're looking for there. Output the data and consume it by something that can handle the analysis.

These protocols prevent an O(N x M) explosion of code that have to solve for many cases. For example, since JSON is an almost ubiquitous format for wire transfer (although other things do exist like protobufs), if I had N data formats that I want to serialize, I only need to write N serializers/deserializers (SerDes). If there was no such narrow waist and there were M alternatives to JSON in wide usage, I would have to write N x M SerDes for wire encoding my data.

So, I thought this at one point, too. But it turns out that methods is a type alias to an unnamed type, so there's no package level privacy issues: https://github.com/protocolbuffers/protobuf-go/blob/v1.26.0/...