halvnykterist

Invalid pointer dereferencing isn't guaranteed to cause segfaults, you might just get garbage memory or nasal demons from LLVM handling undefined behavior. That's the key advantage of using integers (or a GC'd language) - it's memory safe.

While lockstep is useful for some games, it was never really a good choice for fighting games due to the fast and timing sensitive nature. Rollback is an improvement over it that adds speculative execution for remote inputs, this is what should be the standard, although Japanese developers have only recently gotten on board with it.

The crucial difference between having a vector of components is in access patterns - in ECS you iterate over entities that have a given set of component, using queries, with entities that have vectors of components you're still iterating over entities. For something like a roguelike you're generally just dealing with one entity at a time, so this is a very important distinction.

That said, I don't think just having a vector of components is good design, you can do a lot better than that. I think the most natural thing to do in most roguelikes is to have an "Entity" type that's shared between players and monsters and has things that you'd expect those things to have, along with an inventory and potentially some kinds of tags governing behavior. Type Objects etc fit nicely into that kind of scheme.

>and Entity enumeration without archetype filtering may eventually become a performance hazard if done too frequently and naively, I'm specifically talking about turn based tile based games, here, so iterating over all entities matching a given set of components is rarely going to be a performance concern. It's far more important to make sure you're efficient when it comes to things like AI routines and pathfinding.

> 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<Box<dyn Component>>,
  }

(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<Vec<Box<dyn ItemEffect>>>,
  }

It just feels like you're looking for problems to solve.

I think the idea that you need something like ECS to deal with mutability everywhere is a misconception. Traditional architectures you'd use in C or C++ are all going to more or less have a tree-based ownership graph, and these translate very well to Rust. Long-lived pointers to things that you don't own are a great way to get UAF errors or similar, and having a collection of entities you can look up by ID is a common pattern to use outside of ECS. > But at the same time it was useful to play with that pattern because it's in common usage in the Rust community. And in doing so it perpetuates it. ECS is a good solution for lots of problems (in particular I don't agree with jblow's take) but parading it as _the_ way to make games in Rust feels a lot like how OOP has been championed in the past. If you're going to teach someone how to make games in Rust, doing with extra patterns that don't add much other than complexity (in this case) doesn't seem like a good strategy for teaching or introducing people to the language.

Debugging in VS actually works pretty well already, the msvc target generates PDB files. It's what I use when need to attach a debugger to something. Actual language support would be really nice, though. Hopefully MS are already working on this.