[eigenbom]

It's a problem, but I'm not sure it's a big enough problem to seek out an alternative architecture altogether.

Bullets probably would be simple structs in a shooty game, not full blown entities.

The next step beyond that simple approach is to store the components outside the entity. E.g. using SoA that Jon's new language has support for.

In my game (http://moonman.io) i use an approach similar to that in the bitsquid engine, with static polymorphism and crtp and other nonsense. It works but i admit is probably overkill.

[Ace17]

> Bullets probably would be simple structs in a shooty game, not full blown entities.

Why not?

You still need to render bullets, to load/save them to disk, to synchronize them over a network ; some of them move by themselves, they physically interact with the rest of the world, play sounds, and have animations. And actually, many other entities also inflict damage on collision (spikes, forcefields ...).

So from the point of view of your game low-level internals, there's nothing very specific about bullets.

BTW, the same applies with powerups, doors, monsters, spikes, moving platforms, ... But some bullets might have a locked target, some powerups might disappear after a while, some doors might need a key to be open ... these behaviours are typically not shared between game object types ; I might be wrong, but having a new component/array for each of them also seems overkill.

> The next step beyond that simple approach is to store the components outside the entity. E.g. using SoA that Jon's new language has support for.

For one second I thought you were talking about "service-oriented architecture" :-)

[eigenbom]

You could definitely make them full entities, it would depend on your use case. If you're making a bullet hell shooter then maybe bullets need to be handled as a special case. Either way best not to get caught up in ideology or finding a perfect architecture, just do what works for you and your game.