This book seems to be discussing distributed object systems, which is a sense of the word "component" that has little or nothing to do with the sense used by game developers in reference to the ECS architecture. Distributed object systems are designed to enable an object-oriented design philosophy to be used for a system which spans multiple address spaces or machines. The entity-component-system architecture is a methodology for organizing data layout and program functionality, usually within a single address space on a single machine, where the data associated with a given entity is spread across multiple components or subsystems and associated by index relations (much like a relational database), rather than being all grouped together in one place (as encouraged in OOP).

These two concepts (distributed object systems and ECS) are designed to solve different problems, they are generally used in different scenarios, and they apply at different levels of system organization. There is so little resemblance between the two that I have to conclude someone calling them "sides of the same coin" is either completely unfamiliar with one of them or is being deliberately misleading.

As an example you could say that Scheme is more object oriented than Java or vice versa and there would be valid, typically cultural reasons for each.

In terms of ECS what kind of happens is that, yes, you have a model of an entity and can think of that as an object, but that is a projection of a set of components or a relation. You're not really talking to the entity as a whole all that much anymore. And it's not just "it satisfies this set of interfaces" either. Your systems literally define data transformations, each on a focused set of related components that matter to a system, which seems kind of the inverse of hiding data behind object interfaces.

Sure he might have lot's of valuable experience but every video I have watched of him was like a 1 hour rambling opinion piece which could be 3 minutes of actual content.

His video reaction to the rustconf ECS video had some good points but they were very nitpicky and not really justifying the length of the video at all.

> Because it is far more complicated, thus takes far more work, than what you actually need to do. That work has a large opportunity cost. https://twitter.com/Jonathan_Blow/status/1427378984145154048

To me this has more nuance than, “you ain't gonna need it”. I don't think “concrete implementations” would do all that much to strengthen his argument that unnecessary complexity gets in the way of shipping for indie devs:

> Even 10% friction more than I ever had would have killed me. I wouldn't have been able to make the things I had. Even 5% more friction would have been really bad. https://youtu.be/4t1K66dMhWk?t=3635

And…

> I have, several times, built games where I barely managed to finish. … I've just experienced that too many times to increase friction. I need to decrease friction. https://youtu.be/4t1K66dMhWk?t=3072

And again, in relation to entities rather than Rust's borrow checker:

> If you are trying to focus on the way your entities are set up, you are mis-directing your effort and that's going to make it harder. Try to solve the problem that makes your game interesting. What is it about the gameplay that makes it interesting … that users can see? Focus on that, solve those problems. https://www.youtube.com/watch?v=w7W3xM2tzRA

On what he uses instead of ECS/components in his engines:

> One struct per entity type, with a base struct that is common to all of them. https://twitter.com/Jonathan_Blow/status/1427376307453665280

It can make up for it in other ways, but in my experience, Rust is poorly-suited for Roguelike architecture specifically.

For myself, I go at it from a baseline approach: effects are one of the fundamental building blocks of the game. As much as possible, if something in the game does something, I try to do it through effects. This includes skills, spells, weapons, armor, commands, AI, systems, etc.

If everything does everything through these effects, you can make anything do anything in response to anything without having to special code it.

I don't make it that flexible for various reasons. But I think it's a good place to be philosophy-wise for something like a MUD.

As an example from the video, there is an Attack, Use, and Defense class that Items use, with specific attributes assigned to them (armor, dodge bonus, min damage, max damage, etc). With effects, you might have a list of effects that trigger on wear, on attack, on activate, etc.

A common effect is a damage effect. You could make an item that damages someone you hit with it (typical weapon), damages you when you wear it, or damages a target when you activate it. But you could do this with literally any effect you programmed for any spell or command. You can make an item heal you when you wear it. Or provides a heal over time when you wear it. Or heals your target when you hit them with it.

You can even combine them. I could make an item that, when worn, transfers everyone in the game to the wearer's location and kills them. I could do the very same thing for a spell. Or when someone enters a tile. Or a command. Etc.

I can do this because there is an admin command that can transfer everyone in the game to a location. It does this by effects. I have an admin command that can insta-kill anyone. It does this by effects. I can assign these effects to any place that uses effects.

I arrived at this solution because, when working long term on MUDs, I found myself coding the same thing over and over for different subsystems for different content creators. Ultimately my mantra turned into "non coders shouldn't need coders to build new, cool things" and this is how I went about doing that.

    struct Entity {
        components: Vec<Box<dyn Component>>,
    }

    struct Entity {
        pub position: Option<XY>,
        pub sprite:   Option<SpriteId>,
        pub scripts:  Vec<ScriptRef>,
        //...
    }
    
    fn render_world(entities: &[Entity]) {
        for entity in entities {
            if let Entity { position: Some(xy), sprite: Some(sprite), .. } = entity {
                // ...
            }
        }
    }

You absolutely can have an entity structure containing a vector of dynamic component types. It can get quite messy when you start having a lot of component types. When your entity runs, it has to look at the data in its components. That either means that component is a big enum (no need for dyn and Box there), or component is a trait and you're going to be doing a bunch of dynamic casting to find out what components an entity has when it ticks. Either can work (as can having an Option for each component type, which replaces the dynamic cast with an `if let`). Ultimately, there's not a lot of difference between an entity iterating its components and calling methods on components (or branching based on the components it has) and running a query to retrieve the components you want and acting on them. It's not that different from a NoSQL database (everything in a node graph) vs. a relational database (tables keyed to an identifier) - both work, each has their strengths and weaknesses. (I also really didn't want to try and teach dynamic casting early in the book!)

Some specific points from your reply:

By "replication", I meant network replication. You can get the same benefits by tracking changes within an entity/component, but it's really handy when a single storage system does that for you. Not that useful to a traditional single-player roguelike, but a nice tool to have.

> 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

That very much depends upon what you're creating. (Nox Futura is a Dwarf Fortress like). In the gravity example, it was solved by remembering to exclude the Flying component from the gravity query. The roguelike example in Hands-on Rust actually runs the player and monsters in different phases, but re-uses a lot of systems in the process. Matching on the turn state and executing systems isn't all that different to matching on the turn state and running tick functions on the entities included in that turn - especially if you have an energy cost/initiative type system breaking out the moves (the tutorial I created does this). Both Hands-on Rust and the tutorial effectively use message-passing for chaining events together.

> 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

You have the exact same problem with a dynamic vector of components.

> 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.

It mostly boils down to preference. I find Query<(MonsterAI, Position, LikesToEatPlayers)> easier to work with than having each entity iterate a component list, query the type of each component and then act accordingly.

> As a final note, in the excerpt about items you have this justification for not using an enum instead of components:

Again, we're solving the same problem in similar ways. There's really not a whole lot of difference between matching the enum and iterating MultiEffect and querying if an entity has components. Either way, you have code that says "oh, it explodes" and makes a boom.

In other words, we both prefer different ways to accomplish exactly the same thing. Neither of us is right or wrong, there's plenty of ways to skin a cat. Hands-on Rust is as much about teaching Rust and gamedev in general as it is roguelikes in particular; if you want a big, working roguelike - the tutorial ( https://bfnightly.bracketproductions.com/ ) does that.