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

61–70 of 90 posts

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

#61

Post by ajmmertens »

pjmlp wrote: post #25
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!

Indeed, golden rules of game development, finish the game, game design matters more than tech, either make an engine or a game.

The opposite also applies: don't reinvent the wheel if you want to get something done.

Existing game engines like Unity/Unreal already have builtin solutions for entity management, but if you're (for whatever reason) using something that's more custom you can avoid having to reinvent entity management by using an ECS library. Similar to how you'd use libraries like SDL/bgfx/sokol for graphics.

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

#62

Post by meheleventyone »

ajmmertens wrote: post #61
pjmlp wrote: post #25

Earlier quoted context omitted.

Indeed, golden rules of game development, finish the game, game design matters more than tech, either make an engine or a game.

The opposite also applies: don't reinvent the wheel if you want to get something done. Existing game engines like Unity/Unreal already have builtin solutions for entity management, but if you're (for whatever reason) using something that's more custom you can avoid having to reinvent entity management by using an ECS library. Similar to how you'd use libraries like SDL/bgfx/sokol for graphics.

This is true to a point if you need a general purpose entity management framework that will scale to whatever but a lot of games in the "make a game not an engine" vein don't need that complexity. Adding a dependency can save time but can also be its own rabbit hole.

One of those things where discussing theoretical stuff doesn't help because "it depends". :D

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

#63

Post by [deleted] »

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.

[deleted]

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

#64

Post by capableweb »

jbluepolarbear wrote: post #54
stephc_int13 wrote: post #39

Earlier quoted context omitted.

I've spent a few months working with ECS/DOTS with the Unity Game Engine, their implementation of this style of architecture end up being very complex in comparison to the old fashion GameObject workflow that made Unity popular in the first place. Everything is MUCH more difficult to implement, I won't go into details but from my experience the time spent to achieve a similar result is about 5x-10x what it should be.…

As a game dev that’s been using Unity ECS in production for over 2 years, it’s a very underwhelming implementation. Sure it’s fast if you design a game with Unitys intentions, but Unity has never made a game and what they made isn’t what game devs need.

> but Unity has never made a game

This shocks me the most about how Unity operates. That they haven't figured out that dog-fooding their own main product is absolutely essential, especially since every single competitor of theirs does so very successfully as well.

How can you build something great for a specific group of people if you don't know what they are going through?

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

#65

Post by sowbug »

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 trait or interface, such as MIDI), but the data constituting each instrument is totally different. So the behaviors are the same, but the data is different. It seems that ECS isn't a fit, which is a shame because the implementations I've seen offer cool features like easy parallel processing, querying, and so on.

Is there a design pattern like ECS but for common behaviors instead of common data? Or am I being dense and not seeing how ECS actually is a good fit for this situation?

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

#66

Post by vouwfietsman »

JoeyJoJoJr wrote: post #45
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.

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.

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

#67

Post by moahe »

ajmmertens wrote: post #61
pjmlp wrote: post #25

Earlier quoted context omitted.

Indeed, golden rules of game development, finish the game, game design matters more than tech, either make an engine or a game.

The opposite also applies: don't reinvent the wheel if you want to get something done. Existing game engines like Unity/Unreal already have builtin solutions for entity management, but if you're (for whatever reason) using something that's more custom you can avoid having to reinvent entity management by using an ECS library. Similar to how you'd use libraries like SDL/bgfx/sokol for graphics.

This. Some people prefer fully-featured large engines (even for small games) and some prefer a set of libraries to mix and match.

I'm happy that a really cool option with a C API exists.

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

#68

Post by vouwfietsman »

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.

No actually the ECS approach is more or less the exact opposite of (naive) OOP. In (naive) OOP you design objects for your domain, like an enemy, or a bullet, or an explosion. In ECS, you define abstract entities and compose data (and potentially behavior) on top of them, so there's no single "enemy" object, there's an entity that composes AI, geometry and sound effects to make it behave as an enemy.

In general, for large systems, this is a great way to achieve decoupling, where the naive OOP approach would get you stuck quickly.

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

#69

Post by vouwfietsman »

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…

> 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 practice to me.

Indeed it is. The idea of components is to decouple systems. Where systems generally operate on few components, and own a disjoint set of components. It is not a communication channel, just like any other database should not (primarily) be used as a communication channel.

You can combine an ECS with any number of different patterns to make your communication work: events, agents, messagebus, you name it.

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

#70

Post by ajmmertens »

JoeyJoJoJr wrote: post #45
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.

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…

> but still ECS incurs massive overhead compared to basic arrays of structs

I actually know of quite a few projects that use ECS as the foundation for a low level rendering library precisely because it lets you iterate over a bunch of plain arrays, but with more flexibility.

The overhead of an ECS depends on many things, but if you have lots of entities with similar components, the overhead per entity can be quite small.

Post reply on HN