Comment by nextaccountic | Hacker News Reader

Comment by nextaccountic | Hacker News Reader

Parent Full thread

But why? This looks like the mother of all boilerplates. And for what purpose?

Also: just having stuff in an array or vector invites you to the ABA problem. You need a generation counter in there too, or else the array indice may get reused if something is deleted and another thing is reinserted at the same index. But that's yet another boilerplate that would easily be overlooked if you had to do everything manually.

Also: you seem to be saying this with C++ in mind. Do you think that applies to bevy_ecs too?

Modern Bevy has relationships to make sure that if an entity has a component that refers to another, it doesn't become dangling. It works a bit like foreign keys in databases. I think this makes ecs much more usable

(as an aside, there is a whole host of analogies between ecs and relational databases. entity archetypes are tables, entities are rows, components are columns, and systems are queries). Nobody tells people to just write their database from scratch though)

> You need a generation counter in there too, or else the array indice may get reused if something is deleted and another thing is reinserted at the same index.

It's really sounding like you're pretending not to know what your program does, which is one of the core OOP ideas that DOD refutes. In OOP you have an array of Shape and you pretend not to know which shapes your program implements, so the only way to draw them is to call ->draw() on each one. And you pretend you don't know anything about the lifetime of a shape so you use smart pointers everywhere to extend it as long as needed. In DOD you assert that you do know what shapes are available and what their lifetimes are.

I certainly don't know "what my program does" if it's a game where, at every frame of the simulation, thousands of entities might or might not be created, deleted and recycled depending on player inputs.

Can you describe a superior replacement for generation counters?

If you don't know what your program does, DOD asserts that you are a bad programmer and you should first figure out what your program does before continuing.

Sounds like you're writing a game engine, not a game?

You don't seem to grasp that handling individual entity state has a cost that has to be minimized and amortized.

A generation counter offers a good deal in many common cases: for the fixed small cost of incrementing the generation counter when an entity ID is assigned a trivial test, also fixed cost, can disambiguate successively recycled entities that share the same number and tell which one is current.

This adds up to work proportional to the number of distinct entities plus, assuming obsolete references are eliminated, work proportional to the number of references to entities, which is clearly very good. Do you recommend a different way to solve the same problem? There is at least one obvious one.

This is such a good explanation of OOP vs DOD

As I recall the reason for managing blocks of data this way was memory cache efficiency.

> This looks like the mother of all boilerplates. And for what purpose?

Isn't most programming? Isn't struct Particle {vec3 position, velocity;} also the mother of all boilerplates?

Reply on news.ycombinator.com