> Composition over inheritance (especially in Rust, which doesn't really have inheritance - although you can fake it with traits)
This does not require ECS, you can happily have something like
struct Entity {
components: Vec>,
}
(Nor do I think this is a good way of setting up a traditional roguelike)
> Replication; if you want to replicate state across multiple nodes, a good ECS can really help you
I'm not sure what you exactly mean by nodes here, but making something serializable in Rust for easy replication is hardly an issue when we have access to tools like serde.
> Mutability; as mentioned above, you don't need mutable access to everything at all times, and your code is definitely safer if you have explicit mutability control
Addressed above, but while ECS solves the mutability issue it's not a unique way of solving it and bringing it in to deal with that is overkill at the very least.
> Surprising flexibility; Rust EC setups typically let you put anything into a component.
Again, you can do this with regular old components too. This is also an oversold feature of components / mixins / anything like this in general, I think. You can never "just add a component", you need to fix all the issues that come with that, like making sure that gravity doesn't kill your birds.
> For simulation type games, it's great to be able to add a simulation feature and have it apply everywhere.
Yes, but that's not what a turn based tile based game is. Generally you want to iterate over things in order - gravity (if a roguelike has such a thing) gets applied on the player's turn, and only for the player. If you step over a ledge you don't wait for the "gravity" system to kick in and apply gravity to all entities, it is resolved in the same instant for only the entity that has just moved
> It really helps with parallelism.
Sure, although gameplay logic is not what's going to have to be parallel in a roguelike. Building up pathfinding maps and similar is useful to do in parallel, but ECS doesn't really help you with that.
> If you're in a team, it's a great way to break out work between team-members.
Not a particular strength of ECS, and if anything I could see issues arising from the fact that you basically have dynamic typing when it comes to what behaviors an entity has.
> But here's the thing: the systems part is optional.
If you're not doing query-based ECS with systems there's also no particular reason to not use vecs of components within entity structs.
I believe what you're doing here is adding a bunch of complexity to something that could be much simpler, and it really does the language a disservice.
As a final note, in the excerpt about items you have this justification for not using an enum instead of components:
Each item you’re adding provides only one effect. It’s tempting to
create a generic UseEffect component containing an enumeration.
Enums can only have one value—if you want to make an item with
multiple effects, you’d be out of luck. It’s a good idea to separate
effects into their own components in case you decide to create an
item that does more than one thing.
Not only does this violate YAGNI, it's trivial to work around:
enum ItemEffect {
Heal(i32),
Poison(i32),
Explode,
MultiEffect>>,
}
It just feels like you're looking for problems to solve.