Live data from Hacker News

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

flecs.dev

41–50 of 90 posts

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

#41

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.

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

#42

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.

no it doesn't. most OOP approaches to game dev end up with some kind of mixins or components that carry methods (like Unity). I think the future of game dev may end up being immutable and event driven actually... but I’m yet to see anything beyond a prototype.

[dead]

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

#43
I have a sort of off-topic question. The marketing for this claims not using STL containers as a selling point. Does anyone know what makes STL containers unsuitable for this use case? Clearly they're not a one size fits all but I'm intrigued to know why you market an unknown container based API over a tried and tested one?

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

#44
post #43

I have a sort of off-topic question. The marketing for this claims not using STL containers as a selling point. Does anyone know what makes STL containers unsuitable for this use case? Clearly they're not a one size fits all but I'm intrigued to know why you market an unknown container based API over a tried and tested one?

Start here:

https://youtu.be/6hC9IxqdDDw

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

#45

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.

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 ECS incurs massive overhead compared to basic arrays of structs. If your language allows structural typing then ECS seems to me as having little benefit.

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

#46

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.

A collection (e.g. an array or a hash map) that stores things. Maybe more than one collection like that, different for each type of entity: monsters, items, etc. (Separate code paths to handle these different types of things.)

Keeping indexes/keys for references, and loops over these collections can do a lot without any upfront complexity of an entity system.

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

#47

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…

I really love ECS. I’ve shipped games with my own spaghetti mess of classes and poorly thought out inheritance (at least it feels that way) but ECS and composition just is much nicer for incrementally adding functionality without thinking about the big picture too much. I love that I can think about just one small feature I want to add instead of the overall grand design.

This might be bad design (no idea) but I’m working on an item system for a game right now. I have Item and ItemHolder components. If it’s a player, they’ll have an InputController component, which lets them use the Item in the ItemHolder, otherwise there is an AIController component that let’s an NPC use the item.

I have a system for handling every piece of functionality that can be defined in its smallest form, which makes it incredibly easy to add or remove functionality to any entity.

Also, performance is great. I have the mindset to not prematurely worry about performance until profiling now.

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

#48

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.

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

#49
post #2

Any idea what a game loop would look like for an ECS engine that only renders a new frame when some animation is running or when the user is manipulating the camera, but not otherwise? Let's not argue "why". Most obvious would be saving battery.

I wrote a game engine that did that, because it was for a very simple, largely static scene. You would implement it almost the same as a standard Windows GUI -- using an event handler loop that marks the screen as "dirty" and needing a refresh if it has changed. Where it would immediately break down is ongoing animations. If you stopped moving your mouse, then animations would stop. Of course, you can set up the even…

> I'd be happy if games simply paused rendering when minimised. Some games do this, some don't.

Yes, please.

It drives me nuts to have GPU fans spinning when game is minimized, paused, in the loading screen, turn based and no inputs, etc.

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

#50
post #34

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!

Yeah fully agree, ECS is the microservices of gamedev these days. I've worked on AAA games that used it, and shipped games as a solo dev without it. If you don't know why you need it, then chances are you don't need it. Just keep it in mind as one possible architecture pattern for when your code base starts to experience growing pains is my advice.

I don’t have any intention of writing a game, but my lay understanding of ECS is that it sort of treats your world as an in-memory columnar database for better cache locality: if you’re updating the positions of a collection of entities, you only need to loop over a collection of contiguous `position` structs—you can get a lot more of these in a cache line than you would if the entire entity was a struct containing a position field among many other fields which are irrelevant to the updatePosition operation. How far off am I?
Post reply on HN