Mega-Struct as an alternative
-
What I've heard:
-
Performance:
-
Unnecessary:
-
Entity update is usually a very miniscule thing in the frame, and if you separate the world into chunks, the goes down even harder.
-
-
Particles:
-
It's usually a complete separate thing than entities.
-
-
-
Flexibility:
-
If you put everything an entity might possibly have into a mega-struct (CoP), you get the flexibility.
-
Use a big table of flags, explicitly turn on/off paths of execution.
-
"streams of execution, instead of streams of data".
-
Don't think of "doors", "levers", "guns", etc; do put things inside this mental model, just think of paths of execution.
-
ECS already does that by default, but his suggestion is do that while using a mega-struct, thinking in terms of paths of execution.
-
-
-
-
(2026-01-12) Caio:
-
Performance.
-
Indeed not an actual concern by looking at Tracy; most of the frame is spent doing other things.
-
And indeed, many games will not hit the entity count where having an ECS model makes a difference.
-
It's sure good having the option for easy optimization with parallelism/SIMD, but if you are trying to be efficient with your time, probably entity updates will not be this first thing in your code you'll be optimizing.
-
Tho, simply just having a dense packed array with your data in it, simple gives you the benefit of faster code due to less cache misses "basically for free"; sure you have to interact with the component system and there's a little bit of wasted memory, but I don't think both of these compare to how wasteful and convoluted a Mega-struct can be. My point is: coding like the processor want us to code and thus making performant code being the base line is sure great.
-
-
Flexibility:
-
I disagree. After working with Mega-struct for some months, I see a lot of annoying things happening for having an insane branched-out code: having to manage a lot of different states and code paths, separating behavior based on some enums, or simply holding to SO MUCH DATA that will never be used by that specific entity at any point during the whole game. All of this creates a lot of operational error, literally me just doing wrong things just by how convoluted the branched out code can be; forgetting to initialize vital structs, forgetting to turn on some behavior or turn off other behavior, etc. As there's a lot of different paths of execution, is not trivial to change the behavior of one entity. Adding new behavior or data in a specific can be quite demotivated, as now you have to go through a gigantic file, going through the scope of a bunch of things and have to constantly think whether you forgot to set up something inside that big pool of random code. One way to think about these issues is by considering how similar having to manage so many branches and states is to a State Machine; if you have worked with a complex State Machine before, you know how easily things can get out of hand and how maintenance complexity grows.
-
I'm currently implementing ECS in my engine, and I laugh at how easily it was to make the main character behave like an NPC: I commented 1 line that added a specific input move component, and added 1 line to add an AI move component, that's it.
-
-
In conclusion, having the option for easy optimization is sure great but probably not very useful in most common games, but when it comes to flexibility I don't think a Mega-struct beats the clarity and peace of mind an ECS code brings.
-
Obviously, Mega-struct is the absolute winner when comparing with OOP; I just thought I mentioned.
-
Godot - Why isn't ECS-based?
-
TLDR:
-
"Godot as an engine tries to take the burden of processing away from the user, and instead places the focus on deciding what to do in case of an event. This ensures users have to optimize less in order to write much of the game code, and is part of the vision Godot conveys about what should constitute an easy to use game engine ".
-
-
ECS is a design pattern commonly used in video games (although not very common in the rest of the software industry) which consists of having a base Entity (a container object) and Components that can be added upon it. Components provide data and the means to interact with the whole world. Finally, Systems work independently and act on every similar component.
-
This design became common in game engines and libraries in the early 2010s. The main appeal (besides architecture) is that component data can be placed in contiguous memory, improving cache access.
-
This is a common form of data-oriented optimization.
-
Architecturally, ECS aims to replace inheritance , by favoring composition, similar to how interfaces or multiple inheritance works in OOP.
-
The key advantage in ECS is that components are dynamic (can be added or removed at runtime).
-
Godot does composition at a higher level than in a traditional ECS.
-
One of the biggest advantages of ECS is the Systems (data-oriented) part, which allows running through a lot of similar components' data organized in linear memory.
-
This brings huge performance improvements over the way Godot works with nodes.
-
-
Most (if not all) technologies that utilize ECS do it at the core engine level, by serving as the base architecture and building everything else (physics, rendering, audio, etc.) over it.
-
Godot instead keeps those subsystems separate and isolated (and they fit inside of Servers ).
-
I find this makes code simpler and easier to maintain and optimize.
-
-
To put it simply, nodes are just interfaces to the actual data being processed inside servers, while in ECS the actual entities are what gets processed by the systems.
-
As I understood it: Nodes seem to create a layer of abstraction over Systems, because they are very low-level.
-
-
In other words, Godot as an engine tries to take the burden of processing away from the user, and instead places the focus on deciding what to do in case of an event. This ensures users have to optimize less in order to write much of the game code, and is part of the vision Godot conveys about what should constitute an easy to use game engine .
-
These are generally games that need to process game logic on dozens of thousands of objects, where data-oriented optimizations become necessary, as the amount of pages moved into CPU cache increases by several orders of magnitude, severely affecting performance (and battery usage on mobile devices).
-
City builders (lots of things going on).
-
Sandboxes (lots of tiny things need processing every frame).
-
Some strategy games (while not the majority, some can use thousands or tens of thousands of units at the same time).
-
Other AAA games with lots of content going on.
-