[reactordev]

ECS is different. Systems coordinate entities, entities have components, some of them can be behaviors, some of them are not (vertex data). You would need to provide something that a component can inherit to derive that it’s a behavior. Unity does this by calling it a MonoBehavior (not Mono as in singular, mono as in Mono runtime, the name stuck).

Having an ECBS system: one could model all the permutations as described while keeping code concise, shareable, and non-repeatable. Unity is really an ECBS.

Inheritance vs non is as old as OOP vs functional. Each has their place, each has their pros and cons. Having functional components and behavior traits attached to object inheritance based entity nodes is probably the best of all composition. Entities can get more and more complex with inheritance chains (further classifying what components can be attached), components can include behaviors, data, events/triggers, sub-components. Behaviors (triggering events or waiting for) is where your game logic would mostly reside.

[runlaszlorun]

Aha, thx for the insight. Very helpful. A couple questions:

1) If I wanted to learn more about ECS/ECBS, would Unity be a decent place to learn? I know sometimes the terms get coopted (for example, MVC as a term gets fairly abused at times in web development) so I wasn’t sure if their implementation was a good one to learn from. And while I’m a fan of open source, Unity certainly does seem to be a leader in adoption and available assets, etc and not a bad place to start. I’m not really looking to develop a commercial game, but in addition to my poking around game engines to see if and what might be applicable ideas for a more classic business/personal type apps, I am interested in building something that broadly speaking sorta acts like an FPS or Arma type game but just for the sake of playing around and simulating different drones and drone swarms, etc in a 3D environment and playing with that. Pretty crude is fine, and AAA level graphics aren’t really a huge concern. I think I honestly could prob get pretty far with just a non-graphical, non-gamelike OO design with JS/Python/whatever as a crude simulation. But I’ve heard that standing up something like an FPS in Unity is not too difficult. And I don’t plan on pushing boundaries from a graphics or asset perspective.

2) > Systems coordinate entities Could you elaborate a bit? Systems are the one aspect that for me are hardest to get my head around coming from more standard web/business development. So physics engines would be a system right? But I’m not sure what are other examples.

Thx for the info. And feel free to just refer to links if you know amy decent ones. I’ve been poking around ECS from a far for a couple years now but haven’t really found articles that fill in the gaps for things like systems in ECS. Though I’m sure the fact that I have little context in game development sure doesn’t help… lol.

[skitter]

> Systems are the one aspect that for me are hardest to get my head

In an ECS architecture, the world is a database of entities, which are just identifiers, which have components associated with them. Systems is simply code that query this database and operate on the returned data. For example, if you want burning entities to set burnable entities on fire, you might write a system like this, using Bevy as an example:

    fn fire_spread(mut commands: Commands, burning: Query<&Collider, With<Burning>>, flammable: Query<(Entity, &Collider), With<Flammable>>) {
        for col_1 in &burning {
            for (flammable_entity, col_2) in &flammable {
                if col_1.touches(col_2) {
                    commands.entity(flammable_entity).insert(Burning)
                }
            }
        }
    }

The Commands here exists to defer archetype moves – otherwise what should the query do if you added Burning to an entity while the query was running? And of course in a real game, you might want to use a spatial query so time complexity isn't m×n. You could then run this system every tick:

    app.add_systems(Update, fire_spread)

If you're familiar with C++, I can also recommend you check out https://www.flecs.dev/flecs/

[runlaszlorun]

Awesome, thx.

[reactordev]

Unity is just the loudest, they certainly aren’t the first and they definitely didn’t invent the paradigm. ECS/ECBS is a pretty common construct.

This wiki is the Bible for ECS/ECBS systems: http://entity-systems.wikidot.com/

[skitter]

That page seems to be more about the entity-component architecture (entities are composed of components, which define data and behavior for one aspect of the game) then about entity-component-systems architecture (entities are composed of components, which are pure data; systems can query this database). Traditional Unity, as that site points out, is EC; Unity DOTS is ECS. Not sure why the site would be the bible on the topic either as it only some surface-level information and links (and hasn't been kept up to date much).

[reactordev]

Much like other bibles ;)

Wikipedia has some links to some more recent approaches. The biggest problem (and the reason why you don’t see medium articles about it) is it’s extremely difficult to sell in the enterprise. Even if it is the right architecture. Most developers can’t grok it because of the MVC issue you already alluded to. My biggest advice - crack open VSCode and write one. You’ll learn more by doing. Forget games. Try writing a database. This is what it is really. How do you handle 100,000 objects that interdepend on a web of code? Start basic, arithmetic. Components can add, subtract, etc. end goal is query the scene for Fibonacci sequence entities.

Bonus points for updating (randomizing) values and picking different entities next tick.

Deductions for use of Dictionary<K,V> or std::map

[runlaszlorun]

Awesome, thx!