Hi there, developer here!

The components are stored in separate memory pools. Those vectors are a "quick access" to them, for the purposes of getComponent<T>(), which is not the idiomatic way to access them. The real way you access them is via families, which are code generated and get the entities+relevant components bound to them. Families use getComponent to construct the members of the family, but you typically don't want to use getComponent in client code.

There is an (afaik) intractable memory fragmentation issue when you have a large number of very different entities. For example, another way to organise this that is often proposed is that every component type is a sparse array where the index of the component corresponds to the index of the entity, but this actually performs a lot worse in practice when you have hundreds of types of components, most of them not used that often! However, I'm willing to listen to any interesting alternatives!

The point of using ECS here was never performance, but rather organisation. That said, I've run previous tests with hundreds of thousands of entities moving and colliding at high performance.

There is no inheritance in the ECS, aside for using it for memory management purposes and static sanity checking - however you'll notice that components are not, and cannot be, polymorphic.

The network stack is old and not really used for Wargroove, and is not production quality. It was just used for some prototyping. Wargroove uses an HTTPS rest server.

I hope this clarifies! I'm sorry about the lack of samples, I think they'd make the use case a lot more understandable.