Відео

A single struct to represent all entities (or as I call it -- actors) is exactly what I've settled on after two ECS/OOP shipped games and one in the making. For the player, I simply have a special additional global struct to hold all that extra data; it's not part of the actor struct. The most straightforward and simple actor architecture I know. Compared to ECS, which is, in my experience, heavy, verbose, and slow to get going, with questionable benefits.

Maybe you should remove the word Engine from your title. Your approach might work, because all you care about are the specific entities of your game. But as soon as you want to come up with a more generalized approach that actually works for a variety of game types and is reusable, you will need some form of composition, since a general use "Game Engine" doesn't know about the entities you need. Also you are not force to implement your own ECS you know. There are actually quite a few out there that are very good.

Very good video

I disagree with your reasons for why ECS is good, its just good because its simple.

bro, i cant hear anything, its a lecture for ants

Why would I watch a video that opens up with some dumbo having 4k lines of code in a single file

forced implementations shuggg. forced motivation is not there.

This might have been the best video about software developement in general I have seen

Good argument!

The problem in this video is the rant about games while the title promised a rant about game engines. Games and game engines are not the same thing! I agree that a lot of games probably won't need ECS, so you shouldn't go through the hassle of implementing it. But in something like a game engine, your systems HAVE to SCALE. An engine is supposed to allow you to make any game, which requires crazy levels of flexibility and your solutions aren't for these kinds of applications, clearly. Otherwise a great topic for a video.

Dude be like: "I don't need ECS for my 2D 8 sprites game". Good for you lol.

This was pretty well spoken brother! Lots of great advice here!

I partially agree, though I won't detail my reasons. Context is crucial. ECS can either streamline or complicate your project, depending on your objectives. I find ECS beneficial for networked games requiring deterministic simulations, as it centralizes data management, simplifying netcode. It also facilitates writing tests to guarantee consistent game logic replication. However, ECS isn't suited for every game type.

Big benefit of systems almost nobody talks about is testability - having well-defined dependencies means having well defined interface and responsibilities, and this makes maintaining solid automated test suite so much easier than most alternatives. Other takes on composition (say, dependency injection) cover that case, but come with their own drawbacks - in case of DI, it's often mix of memory fragmentation and performance overhead from multiple levels of indirection. With a bit more complex take on systems (having update systems limited to updating one component only, and having all other updates go through event system) I got level of testability I'm personally happy with - everything can be automatically tested both in isolation and interconnected, without unnecessary overhead (a read-only rendering system doesn't need to be loaded at all for automated tests of game logic etc).

So much complications when your project is simple 2d game. You could make exactly same game just using Game maker or Godot and think more about content than how to reinvent the wheel.

Your implementation is simply a simple (bad performing) unpure ECS implementation, regardless of what you want to call it. What part of a pure ECS is it that you don't agree with? that you find opinionated? Memory locality? Branchless iteration? Fast querying? You must be referring to... implementation details? I don't see how complex implementation details can be "opinionated" if it brings objectively positive, (or at least non-negative) features, such as performance, higher level composability (entity relationships), debuggability (a good ECS library will provide introspection API to get an overview of the world) etc. Your point about simplicity and API surface also makes no sense, Pure ECS never prescribed a complex API, an ECS being pure is about the implementation details, which has nothing to do with the surface complexity of an API. The library flecs has a very simple base API, you can choose to use "addons" if you like, but that is not an argument against pure ECS. Being too lazy to implement a good ECS or too stubborn to use a well-tested and high performance ECS library does not make it a worse solution to your problems. What is crazy is that you don't even argue against the composability and systems part of ECS, otherwise you would be proposing Inheritance based game objects. So really your only problem with ECS seems to be... Implementation details? Casey and Jonathan are great programmers, for sure, but their narrowminded dogmatism against perceived implementation complexities and using other people's code is not doing you or their other fans any Favours. @joshuamanton

PERIPHERY MENTIONED RAAAAA

I totally agree. There are so many andies out there.

Any particular reason you need to play your voice in fast forward? This makes this hard to understand and painful to listen to.

It's a little quiet

I get your point but you don't need ECS, it's mainly a middleware system that is incorporated for your editor portion of the engine to allow users to create more modular workflow, improve accessibility and to cater for a wider use case, but you can absolutely just create a game built directly off of the engine, It's just going to be very tightly intertwined.

Honestly, I think it's worth warning anyone watching this video to take it with a grain of salt. The author makes a few good points, but misses others, and exudes a lack of experience. I think the biggest thing missed here, and the real reason people should use some sort of ECS or derivative (if their project meets some scale/effort criteria), is the organizational benefit. Having systems with strictly defined inputs, and the ability to perform fast and robust *queries* on the game state, is worth its weight in gold when a code base starts to grow. Performance should be a second or third class benefit one should expect. Remember that a properly implemented ECS is, essentially, a very fast and very specialized in memory column oriented database for your game data.

I hate your idea. This whole child-parent tree thing is just a convoluted OOP solution. The benefit to having components is they can be used across various entities and systems are entity-agnostic, it's not about "compression". By having a bunch of Hero_entity etc. you've just invented objects.

How did you get access to Jai?

Haha! Love the Periphery you were listening to on Spotify. Didn't realize they had new tracks out! Is Zagreus a reference to Hades (game)?

Great video, you've put it nicely what I had on my mind about ECS. Subscribed. And hello from the Jai world.

So basically your arguments are very specific to your needs and your requirements. You didn't really objectively answered why is concept of "component" and "system" bad, as bad as you need to remove them from engine. Making a flags for each state of entity and then iterating through all entities and checking each state is already a waste of performance and memory usage. Of course, it depends on "scale" of your game and systems. But overall, for bigger projects its much worse than you think. Such separation as "component" and "system" is always better in a contexual sense. You know that in a specific system you work with specific data (component). And entity you use only for defining relation between bag of data (component) and other bag of data. And also you can make sort of "entity children array" for defining entity tree relation. Inheritance will not always work for defining some sort of universal game object. It's not always a perfect fit for understanding code, especially if it's very deep like in UE :)) Overall, almost everyone has different vision on "ECS" and adds different details to this "paradigm". Your concept is fine, until you face a really big projects.

It took this video 8 minutes to get to the only real reason people are embracing ECS.

Probably a noob question but at 2:30 why do you use this flag enum system instead of individual booleans? Is it just to avoid clutter? My guess is this has to do with using structs instead of objects?

So... If you get ECS for free as a library or a framework and all you have to do is define what's a component + register systems and - boom! - everything magically works... Then your arguments of investing time in something you don't need will be irrelevant.

I can't turn on a compiler programming stream without stopping work on my game project to go make my own toy compiler. It's some kind of obsessive compulsive behavior :)

The size of the functions you show in the video clearly states your programming knowledge. One day you will learn how to program. It took me 10 years to achieve it.

Singlehandedly answered all my questions, and made my decision. I'll be going with OOP instead of ECS. Now just to research frameworks.

ECS are definitely NOT good for designers. They are very expressive and good for worlds with lots of actors. The main benefit you get is, if you have a good scheduler, the chance to massively parallelize execution. And its all it cracked up to be.

As a C# programmer, I can't imagine not being able to associate functions with entities. I even go the other way and have outside functions control entities that meet a criteria (with Interfaces), but most of the time just having it all in the class works for me. I haven't heard a strong reason this is bad other than "oop bad." To be clear, I'm not using inheritance, and only using interfaces lightly.

your suggestion to store all the indices to various arrays in Entities is really just not good For one, you lose the advantage of flexibility because you can't iterate over 2 units of data at once (assuming the arrays are contiguous and not sparse). As an example, let's say you want to iterate over the renderable draw texts, if you just iterate from 1 to the length of the draw text and index both the draw text and the renderable, the data you're accessing isn't necessarily related. Two is you now need to manually manage and keep in sync the array with the rest of your entity pool. Effectively, you're manually performing an ECS algorithm The thing about the mega approach is that it is literally an unoptimized ECS. You have all the data stored in one struct and flags that determine and interpret the meaning of that data, this means that you're 1. wasting memory, 2. having to iterate over the entire ECS to just get a few entities. I agree with you, this just isn't a big a deal as it seems. But also, it is sometimes a big deal, and when it is, you should invest time into making an ECS. I think another issue with this approach is the lack of type safety from your data. Your entity stores absolutely everything, and from a glance, it can be difficult to gauge what a specific part of the entity is and whether a specific entity actually has the relevant data. A possible solution without going towards a full ECS is just splitting out the big Entity struct into separate arrays which are of length max entities, or of the maximum amount that specific component can have. An index of 1 corresponds to the same group of data in every array, this is a balance between the big megastruct approach and an ecs. This lets you get some of the type safety back, but still has the issue of needing to iterate over everything since the array is sparse. But honestly, an ecs isnt that complex of a thing. It's actually pretty simple if you're doing a sparse set based one, and it just overall makes your life a lot easier. Especially in languages without inheritance.

For me even if ECS wasn't best for performance, I would still use it. I spent a lot of time in OOP and the main hero of the ECS paradigm are Systems. (Entities and Components are just details that can have any shape) Systems help not to hide dependencies and I know any code that is running is inside of Systems and there are no hard to see links between components When I come back to by code bases, I do not need to know hierarchies of objects referencing each other, since ECS provide flat architecture I look at the individual systems and know what they do and what they interact with.

The points made in this video are great, I agree with most of what's been said. but I really hate this trend were people feel the need to downplay or attack things that aren't useful to them.

Programmers are a thickle bunch. Endlessly miandering around in circles chasing fads as the accepted / commonly used standards as they ebb and flow like fluid over time. ECS is the flavour of the month today, before that it was OOP, tomorrow it'll probably be a reversion back to structural or functional programming. Pick a sturdy rock you are happy with - then bludgeon everyone else to death with it.

ECS is a tool and with data oriented a great tool. It isn’t compression it is decouple data from code. And the problem is not complexity it is idiots who think ecs is like a particle system or using it to make a authentic phong game. Then it is over enginering. The strengt of ECS DOD is wen you make a large scope game like homeworld or Xseries a rts game or ARMA milsim The strengt is that you manage complexity. Due to decoupling the code that matters is without side effects whitin that system and the component it mutates. For a game like arena shooter clasical cod ip , it is borderline overenginering. It is the best solution if you encounter c++ inheritance diamond like in ARMA you can easy implement a tank and a truck without, but you can have a halftrack armord car. For large studio who use lot of middle ware that can complicate ecs. It is huge difference entity component vs ecs . Avoiding inheritance in oop is good think because inheritance isn’t the default solution for good oop. The key problem with ecs is the huge experience with OOP most dev has SOLID understanding of oop. But are noobs in data oriented. And its difficult if dod feels weird but you know how to do it in goog oop. They start early on mixin oop with dod. Oop kills several benifits of dod and then it become a mess. No problem in small games but large scope game wich can use ecs get mess. Ecs is also not premature optisation. Optimisation in ecs is re-arange data to match optimale memory acces pattern by profiling. It is than only within one ore few systems. Also because of the decoupling multithreading within system is easier to do because non shared mutable data. Also if you need performance modern cpu are multi core. So you need build engine that uses a good multithreaded architecture and multithreade render api like dx12/vulkan.

The other advantage of ECS systems is for *fast querying* of entities based on which components they have. Your example had to do a linear search for onfire objects. An archetype based ECS would have it handled by partitioning and be proportional to O(number of archetypes + number of onfire entities). If not using archetypes it can be implemented by hierarchical bitmaps. You will want something like it if you have a lot of very specific properties that your entities can have Also, the video does apply to handmade game engines, but not as much to when choosing an already made game engine with a mature ECS like Bevy, and comparing it to a mainstream one like say Godot which can be very object oriented. Chosing something like Bevy vs something like Godot is something that is strongly dependent on how you feel about composition vs inheritance

Thanks for this, I was hoping you could help though, how would you add custom behaviour to these entities, let's say I have an NPC that should teleport me when interacted with, where would that logic sit. It seems sort of impossible without using some kind of inheritance doesn't it? As I don't quite see how I could add a Teleporter object into my []Entity array

A lot of false dichotomies in this rant. You say that Systems are primarily for performance optimization and if you don’t need the performance then it’s unnecessary increasing complexity. This is all incorrect. Systems force developers to make explicit dependencies on the Components they care about and then to write focused code pertaining to just those components. Rather than having long complicated update logic that touches many different aspects of the game, a good ECS implementation will use several Systems, each doing a fairly small straightforward task. Like in your on fire example, you might have a flammable component and an on fire component. The PropagateFireSystem might find all flammable entities next to on fire entities and decides whether or not to also set those to on fire. Then the FireDamageSystem would take all thinks that are on fire and have a hitpoint component and start deducting hit points. Then a AssignDeadSystem marks any hitpoint entity with 0 points with a dead component, and so on. Coding this way is incredibly simple, not an addition of complexity that you claimed. This is just one of the few false dichotomies that you’re providing throughout the video.

Periphery spotted. I already agree with you. EDIT: And after watching, I still do. It's very easy for people (myself included) to end up getting the hammer/nail problem, and it gets worse when people "marry" a given data structure or technique, after that it becomes pure ideology.

I mean if I understand correctly (hopefully), you are describing a structure that is very similar to what the Godot engine does. A type system organized hierarchically (that can be extended with scripts) and a bunch of systems that iterate through this hierarchy and execute it.... very similar to an HTML render engine I'd say. Which is perfectly fine of course... although maybe I think you could call your system aggregation based, instead of composition based? (both which achieve the same objective by the way). But yeah in case anyone is interested on the Godot approach, look for the "Why isn't Godot an ECS-based game engine?" article that you can find on the web.

I always thought the whole point of ECS was just for its parallelisation ability. Lke using CPU-only OpenCL in a much easier way.

This video confuses me a little, I get your point: there is no need to implement ECS every time, and I agree, you don't need it. But you also continuously implied that ECS is just an annoying meme of no value, while highlighting why your provided alternatives are still inferior to ECS (e.g. "hey look, you can compose this way instead, it still uses more memory than ECS, and it is also uglier than ECS, but... but hey! You don't need any of that! Probably!"). Again, I agree that you don't *need* ECS, as in, implementing a fully-featured ECS engine for your small indie game, including the features that you do not need, is most certainly not worth it. And while this video contains a lot of great advice for beginners, I feel your criticism of ECS seems mostly emotional, I'm just not seeing these "half-truths", I don't think anyone said that ECS was the only way to do composition, or that it's the only pattern that is good for designers, or that it's the only pattern with good performance. From my understanding, the main point of ECS is that it's a pattern that can be used as an alternative to OOP, it's not the end-all be-all of game development, it's just a good alternative to OOP, as it is more cache-friendly than OOP, while still having a nice design pattern, it covers all bases, even if you don't need it, it is a very general solution, just like OOP. What you propose is to not stick with neither of these patterns, and act on a case-by-case basis, which is good advice, but that doesn't say there is anything wrong with ECS, the benefits are definitely there, even in your examples, it's just a question of scale.

It's not because one acquires a hammer that every problem will become a nail.

People see Unity's DOTS and think ECS is the ultimate solution for their own engine, when in reality ECS is a general solution to problems which may or may not exist in your game. In many cases it'll run slower and be harder to maintain than a solution hand-tailored to your game. Having said that, ECS is far more than a compression algorithm. One of the big benefits is existential processing, which avoids the classic mess at 2:21.

I'm very new to game programming, and even though I haven't attempted to program an ECS, I got a lot out of this video. I've already sensed that the programming can quickly get very complex beyond a very simple game, with many cross-cutting concerns. The question of how to deal with this as I progress to more complex games is always in the back of my mind. Avoiding the urge to generalize everything in a single Entity struct has greatly helped, but I've wondered if there was another way. Your examples have shown me how to use a single Entity struct but get the differentiation without too much bloat: bit flags and unions for tracking entity type. Thanks!