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

71–80 of 90 posts

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

#71

Post by CapsAdmin »

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…

Apart from memory layout benefits, I always felt ECS is a bit like giving dynamic language capabilities to a statically typed language.

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

#73

Post by ajmmertens »

sowbug wrote: post #65

I read the front page of this site, and I still have a general question about ECSes. For what it's worth, I'm developing a DAW (digital audio workstation) in Rust. It seems that ECS helps compose "things" (an entity) out of groups of data (each a component), and then operates upon combinations of those components (using systems). My domain is organized around behavior (many musical instruments implementing a Rust tra…

The way you frame the question already suggests a solution, and one that indeed doesn't fit ECS that well. That doesn't mean you couldn't design a DAW using ECS, but you'd have to redesign how it works.

For example:

- create custom components for different instruments

- create systems for specific instruments that match the necessary components

- write the result to a common component (e.g. "ChannelOutput")

You could then add components for EQ, effects, routing, ... and introduce systems that match those. The advantage of this approach would be that you end up with a bunch of loosely coupled systems (for instruments, effects, mixing, ...) and an in-memory representation that's cache & parallelization friendly.

One other datapoint would be that Unreal's animation sequencer uses an ECS design, which has a lot of things in common with a DAW.

Glossing over lots of details here, you can't of course design a DAW in one paragraph.

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

#74

Post by pphysch »

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

EnTT is quite nice because it's more than just a ECS (if you want), it also includes libraries for a variety of other features like resource management. It's more of a "game engine" library, which is fantastic for projects that don't need to muck about in a "game studio" like Unity/Unreal (e.g. for games or simulations that don't require traditional level design).

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

#75

Post by sowbug »

ajmmertens wrote: post #73
sowbug wrote: post #65

I read the front page of this site, and I still have a general question about ECSes. For what it's worth, I'm developing a DAW (digital audio workstation) in Rust. It seems that ECS helps compose "things" (an entity) out of groups of data (each a component), and then operates upon combinations of those components (using systems). My domain is organized around behavior (many musical instruments implementing a Rust tra…

The way you frame the question already suggests a solution, and one that indeed doesn't fit ECS that well. That doesn't mean you couldn't design a DAW using ECS, but you'd have to redesign how it works. For example: - create custom components for different instruments - create systems for specific instruments that match the necessary components - write the result to a common component (e.g. "ChannelOutput") You could…

Thanks (and thanks especially for responding to what should have been a Stack Overflow question). I do see potential for certain ECS systems that span instruments, like DCA, effects wet/dry, routing, and mute. That makes sense. Your suggestion for component/system per instrument was what I felt ECS was asking me to do, but the libraries I investigated seemed to contemplate dozens but not hundreds of components, and that's where I began to think I was putting the cart before the horse.

I had an epiphany a while ago that a modern interactive DAW is a video game, except parts of it run at 44,100 fps. And even the "except" part is misleading, because games have sound as well. That opened up my mind to game development as another domain to steal designs from.

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

#76

Post by ajmmertens »

pphysch wrote: post #74
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

EnTT is quite nice because it's more than just a ECS (if you want), it also includes libraries for a variety of other features like resource management. It's more of a "game engine" library, which is fantastic for projects that don't need to muck about in a "game studio" like Unity/Unreal (e.g. for games or simulations that don't require traditional level design).

The same goes for Flecs:

- it has tools like https://github.com/flecs-hub/explorer that work with any Flecs project

- it has builtin support for hierarchies/prefabs and more (https://ajmmertens.medium.com/building-games-in-ecs-with-ent...)

- it has optional support for systems/scheduling

- it has an optional reflection framework

- it has an optional DSL for describing assets/scenes, with an online playground to try it out: https://www.flecs.dev/explorer/?local=true&wasm=https://www....

- and a lot more: https://www.flecs.dev/flecs/md_docs_Quickstart.html#autotoc_...

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

#77

Post by indigoabstract »

pphysch wrote: post #74
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

EnTT is quite nice because it's more than just a ECS (if you want), it also includes libraries for a variety of other features like resource management. It's more of a "game engine" library, which is fantastic for projects that don't need to muck about in a "game studio" like Unity/Unreal (e.g. for games or simulations that don't require traditional level design).

Yes, I think I like the overall EnTT design, but I've only toyed around with the ECS part, to learn how to use it. I still haven't entirely figured out when it's best to use an ECS and when to use a scene graph and if it makes any sense to use both at the same time in a project.

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

#78

Post by moahe »

Carbonhell wrote: post #26
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…

If I understood correctly, you are referring to applying some sort of tag component to a set of entity to be able to query it in a separate system. Am I correct? For cross system data flow, I think a mechanism similar to what Bevy does is the way to go. A specific event bus where the developer can send any type of struct, which can also allow passing a set of entity ids. I have briefly used it for my project and I th…

That's my understanding as well.

IMO it would be interesting to consider all static components, i.e. you don't add/remove components at runtime.

If you do want "tags", have a TagsComponent (statically added to all entities that can have tags) and modify the values in it.

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

#79

Post by pphysch »

indigoabstract wrote: post #77
pphysch wrote: post #74

Earlier quoted context omitted.

EnTT is quite nice because it's more than just a ECS (if you want), it also includes libraries for a variety of other features like resource management. It's more of a "game engine" library, which is fantastic for projects that don't need to muck about in a "game studio" like Unity/Unreal (e.g. for games or simulations that don't require traditional level design).

Yes, I think I like the overall EnTT design, but I've only toyed around with the ECS part, to learn how to use it. I still haven't entirely figured out when it's best to use an ECS and when to use a scene graph and if it makes any sense to use both at the same time in a project.

IMHO most games should use both. Think of the game as a 2D table, with Entities on one axis and their Components/Systems aligned on the other axis. Some operations go (densely) along the Component axis, like updating your physics simulation every frame. But many operations go (sparsely) along the orthogonal Entity axis, resolving events and other game rules involving many tiny sets of entities. These are orthogonal operations with different optimizations and I don't think there is one architecture to rule them all. However, I think an ECS like Flecs or EnTT is a good core to build off of.

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

#80

Post by indigoabstract »

pphysch wrote: post #79
indigoabstract wrote: post #77

Earlier quoted context omitted.

Yes, I think I like the overall EnTT design, but I've only toyed around with the ECS part, to learn how to use it. I still haven't entirely figured out when it's best to use an ECS and when to use a scene graph and if it makes any sense to use both at the same time in a project.

IMHO most games should use both. Think of the game as a 2D table, with Entities on one axis and their Components/Systems aligned on the other axis. Some operations go (densely) along the Component axis, like updating your physics simulation every frame. But many operations go (sparsely) along the orthogonal Entity axis, resolving events and other game rules involving many tiny sets of entities. These are orthogonal o…

Agreed. Especially the ability to split an object into multiple components/traits and have an operation run automatically for every component type appeals to me. It just seems elegant and 'good design', similar to 'composition over inheritance'. I think the strength of the scene graph is in the explicit parent-child relationship, where it applies, but I probably need a deeper understanding than I now have to mesh them in the right way.
Post reply on HN