Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flecs – A fast entity component system for C and C++

flecs.dev

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Flecs – A fast entity component system for C and C++

#81

Post by WorldMaker »

midland_trucker wrote: post #36
grenoire wrote: post #23

To any budding game developers, my advice would be to not rush into ECS and try to accomplish your goals with structs and loops first and understand the fundamentals of how a video game 'works' under the hood. Your game will get done if you work on it, not necessarily if you pick ECS!

As a programmer not part of this world: what's the go-to alternative in this situation? Does ECS not naturally arise from using OOP? Trying to think if you are creating instances of players/physics objects/items how that wouldn't turn into a kind of entity system.

One view on the OOP ECS relationship is that ECS is an exploration of/recreation of/divergence from alternative "natural" OOP systems outside of the "dominant OOP strain" of C++ (and family) (re-)implemented on top of C++-style OOP.

There are hints (and needs) in ECS systems of post-hoc/runtime Prototypical inheritance rather than pre-hoc/design time Class based construction.

There are facets of ECS that resemble concepts like mixins and pattern matching and multi-dispatch and message passing rather than "pure" "C++ VTABLE" dispatch.

Some of these things arise more naturally in other branches of the OOP family tree: the Common Lisp Object System can do some of these things out of the box; Smalltalk and its descendants (even Objective-C) were easier to mold to ECS-like configurations; IO had interesting things to say about this style of OOP; even much-maligned JS' "strange" branch of Prototypical OOP has a bunch of low-level tools that make ECS "less of a need" in JS because there are ways to do them more "naturally".

Certainly, though, in C++ and closer-related derivatives (even Java and C#) ECS isn't as naturally a pattern, which is why it often has need for strong "frameworks" and why there are often multiple, competing ones to pick from.

Re: Flecs – A fast entity component system for C and C++

#82

Post by ajmmertens »

tourgen wrote: post #51
oneshtein wrote: post #35

Earlier quoted context omitted.

You can do both. Here is tutorial for Rogue-like game with ECS in Rust: https://bfnightly.bracketproductions.com/rustbook/chapter_2....

Here's a rogue-like game written in straight C, with hard-coded arrays, structs, and defines. https://github.com/tmewett/BrogueCE component systems are useful when you have no design doc, or a design doc written by new-hire monkeys. Or when management has no idea what the goals are.

Or if you want code that's easier to extend, read and don't want to do your own memory management.

Here's a bit of code from that project that generates a monster: https://github.com/tmewett/BrogueCE/blob/master/src/brogue/M...

It just allocates an object per monster, followed by initializing a long list of members that presumably just gets longer as more game systems get added.

The same code in ECS would look a lot simpler, and probably perform better/have better cache locality.

Re: Flecs – A fast entity component system for C and C++

#83

Post by worldsayshi »

stephc_int13 wrote: post #41
strictfp wrote: post #20

I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense. But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practic…

When working on game, the control flow must be as easy as possible to follow and modify. With the ECS implementation in Unity DOTS, this is absolutely not the case, the control flow is mostly managed behind the scene, and multi-threaded, the simplest things are transformed into a puzzle of cascading interactions.

This is not the obviously simplest solution but can the control flow be extracted from the ECS model to be visualised separately somehow?

Re: Flecs – A fast entity component system for C and C++

#84

Post by stephc_int13 »

worldsayshi wrote: post #83
stephc_int13 wrote: post #41

Earlier quoted context omitted.

When working on game, the control flow must be as easy as possible to follow and modify. With the ECS implementation in Unity DOTS, this is absolutely not the case, the control flow is mostly managed behind the scene, and multi-threaded, the simplest things are transformed into a puzzle of cascading interactions.

This is not the obviously simplest solution but can the control flow be extracted from the ECS model to be visualised separately somehow?

I think that ECS can work and be relatively simple, if controlled from the game loop and not by a "magical" black box.

Re: Flecs – A fast entity component system for C and C++

#85

Post by HelloNurse »

brigadier132 wrote: post #48
grenoire wrote: post #23

To any budding game developers, my advice would be to not rush into ECS and try to accomplish your goals with structs and loops first and understand the fundamentals of how a video game 'works' under the hood. Your game will get done if you work on it, not necessarily if you pick ECS!

I completely disagree. How games work is simple. It's a simulation run at some frequency and the simulation can be affected by player input. Sometimes there is a synchronization step with a server and that is more complicated. ECS is a pattern that results in better performance and more maintainable code. There is no reason not to use it.

Better performance and more maintainable code are never the only concerns. For example, achieving a running prototype quickly with some ported/adapted non-ECS engine from a previous project might be more effective and efficient that starting from scratch with a better ECS architecture.

Re: Flecs – A fast entity component system for C and C++

#86

Post by HelloNurse »

indigoabstract wrote: post #72

This looks pretty well polished and maintained, I wasn't aware of it. So far, I've used an alternative ECS called entt: https://github.com/skypjack/entt https://www.libhunt.com/compare-flecs-vs-entt?ref=compare

Flecs and EnTT clearly position themselves as each other's rather friendly competitor, with significantly different design choices.

Re: Flecs – A fast entity component system for C and C++

#87

Post by JoeyJoJoJr »

vouwfietsman wrote: post #66
JoeyJoJoJr wrote: post #45

Earlier quoted context omitted.

In 2D games it is often times some kind of object hierarchy (scene graph, display list, nodes) imposed by the engine/library, which never plays well with ECS IMO. In these instances I think it is better to just inherit from a carefully thought out god object (yeh yeh I know). If you are using a low level rendering library, or immediate mode library, you can more easily define your state however you want, but still EC…

> ECS incurs massive overhead compared to basic arrays of structs This is a weird take, an ECS can have its components listed as a basic array of structs as well. None of this is mutually exclusive.

I should have wrote array of “entity” structs.

The reason I say ESC incurs more overhead is because I find it involves a whole bunch of access patterns to add, remove, update, and query the data. Comparatively arrays of entities mostly just involves basic loops.

Re: Flecs – A fast entity component system for C and C++

#88

Post by vouwfietsman »

JoeyJoJoJr wrote: post #87
vouwfietsman wrote: post #66

Earlier quoted context omitted.

> ECS incurs massive overhead compared to basic arrays of structs This is a weird take, an ECS can have its components listed as a basic array of structs as well. None of this is mutually exclusive.

I should have wrote array of “entity” structs. The reason I say ESC incurs more overhead is because I find it involves a whole bunch of access patterns to add, remove, update, and query the data. Comparatively arrays of entities mostly just involves basic loops.

Still a weird take, as the ECS approach makes it much easier to do AoS vs SoA which is actually great for access/loop performance.

I'm sure there's examples where a non-ECS approach beats out an ECS approach. But to say that ECS incurs more overhead generally is just plain false.

ECS are obviously more efficient for traversing a subset of your entity data if that subset resides in one small component, simply because the total span of bytes accessed is lower and the cache hit rate is higher.

I would be more inclined to claim the opposite: that ECS systems are generally MORE performant than arrays of entities, but you can really only be wrong when making general claims like that.

Re: Flecs – A fast entity component system for C and C++

#89

Post by deterministic »

Experienced game developer here: if you are just starting out wanting to learn how to make games then 1000000% focus on gameplay and not technology. Almost all developers I know who starts working on games end up basically just working on engine technology and never get an actual game done. I used to be one of them so I talk from experience! :) Nowadays I just use Unity and focus on the actual hardest part of making games: coming up with fun enjoyable gameplay that isn’t just a clone of somebody else’s game.

Re: Flecs – A fast entity component system for C and C++

#90

Post by mananaysiempre »

WorldMaker wrote: post #81
midland_trucker wrote: post #36

Earlier quoted context omitted.

As a programmer not part of this world: what's the go-to alternative in this situation? Does ECS not naturally arise from using OOP? Trying to think if you are creating instances of players/physics objects/items how that wouldn't turn into a kind of entity system.

One view on the OOP ECS relationship is that ECS is an exploration of/recreation of/divergence from alternative "natural" OOP systems outside of the "dominant OOP strain" of C++ (and family) (re-)implemented on top of C++-style OOP. There are hints (and needs) in ECS systems of post-hoc/runtime Prototypical inheritance rather than pre-hoc/design time Class based construction. There are facets of ECS that resemble con…

Do you have any references you could give on this? I think I have a fair idea of all the object systems you listed (and a couple of others). Every time I read about ECS I feel like it should be explainable as some flavour of OOP much as you say here, and I could express something vaguely ECS-shaped in either Self/Io- or CLOS-style OOP, but that’s still a far cry from showing that ECS is such OOP.

In particular, keeping a single object’s state in several separate memory regions seems atypical (prototypes—or Self’s “traits objects”—are usually stateless even if the system doesn’t force them to be); and I can’t think of any way to map iteration over all objects that have parts of a specific kind, often mentioned in expositions of ECS, to a conventional OOP concept (looks relational if anything).

Post reply on HN