Man the dumb brigade is out in full force in this comment section.
@GetIntoGameDev22 күн бұрын
No shade, but I must respectfully disagree. In the composition example, the idea of using bitmasks is very cool, but the entities are still essentially being checked for all possible behaviours, this is not good for cache locality as each successive entity can send the execution down different paths. The idea that an entity is a primary key in a database is incredibly powerful for cache friendly composition because it ensures no branching is done. Everything is batched up and ready to go. This can even be taken further, if an enemy is performing too much logic in its update then branch divergence becomes a problem, so "request objects" can be created, then processed by another system all in one go, and their results can then be processed by a sort of "post update" system. Anyway, massive tangent, sorry about that. Regarding parallelism, there's currently a lack of practical knowledge on implementing it in games, and saying "writing multithreaded code is hard" every time the topic comes out doesn't help that. Thanks for the video! I appreciate the perspective that we can't just follow trends because they philosophically "feel optimal". Keep up the good work!
@techpriest478728 күн бұрын
I chose a middle ground. But first regarding composition. I use Rust because of that as a language in the first place. And instead of entities and components I use what I call Prefabs Nodes Systems. I still use systems for multi threading and plugins. I did not like the components limits of Bevy that only one component of one type can be added to the same entity. And that in the end not all can be done in parallel in the first place and even Bevy had to use entity handles too. So I just use node handles dalways instead of having to use entity handles and then having to extract the damn component anyways. So a group of data is essentially a prefab now instead of a entity. Though. Bevy seems messy. Flecs if I am not mistaken can use more than onen component of the same typenon the same entity?! Even events are systems in my Prefabs Nodes Systems (PNS) application kernel.
@hectormejia499Ай бұрын
In other words, start with the simplest possible solution that will get you to the goal the fastest, change it only when necessary. I've been coding for around 10 years, I feel my skills and ability to get stuff done increased drastically when i actually internalized this. Great video!!
@minutesock9649Ай бұрын
0:19 Periphery spotted.
@xbmarxАй бұрын
Over a year later, I'm coming back to this to say I finally came around and I'm pretty much removing ECS from my game too. 🤣 I think ECS is fine if you are making a completely generic engine, where you don't even know what type of game people will make with it. But I want something laser-focused to make something narrow, so I don't need or even want to support arbitrary behaviors or systems.
@ScaredHelmetАй бұрын
Why are you so salty about this lmao
@matejzajacik84962 ай бұрын
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.
@christian-loock2 ай бұрын
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.
@joshuamanton2 ай бұрын
>since a general use "Game Engine" doesn't know about the entities you need My engine doesn't "know" about my entity types so I'm not sure what the problem is there. It uses metaprogramming to find them all and generates the code required at build time to do what it needs to do. I don't need to modify engine code to add new entities to my game. >Also you are not force to implement your own ECS you know. There are actually quite a few out there that are very good. Why would I use a library for something that is the backbone of my game? That's just foolish.
@christian-loock2 ай бұрын
@@joshuamanton Why would you assume that you are more capable of solving problems that have been solve endless times before. That is just arrogant.
@joshuamanton2 ай бұрын
@@christian-loock Because I know the actual problems I need to solve and some several-10's-of-thousands-of-lines-of-code library solves basically none of them. The whole point of making an engine is reducing your dependence on other people in order to ship games. The more libraries you have, the less you know what your codebase is doing, the less you can debug, the less control you have. If you want to minimize the ratio of problems solved per line of code and maximize the ratio of problems invented per line of code, then use libraries because they help tremendously on both fronts.
@Pandanubex2 ай бұрын
Very good video
@27klickslegend2 ай бұрын
I disagree with your reasons for why ECS is good, its just good because its simple.
@Lycam2 ай бұрын
bro, i cant hear anything, its a lecture for ants
@azgan1233 ай бұрын
Why would I watch a video that opens up with some dumbo having 4k lines of code in a single file
@gsestream3 ай бұрын
forced implementations shuggg. forced motivation is not there.
@leonsonstwie48163 ай бұрын
This might have been the best video about software developement in general I have seen
@joshuamanton2 ай бұрын
Thank you. :)
@nangld3 ай бұрын
Good argument!
@lukagarner4 ай бұрын
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.
@AChannelINeed4 ай бұрын
Dude be like: "I don't need ECS for my 2D 8 sprites game". Good for you lol.
@joshuamanton4 ай бұрын
Yes you have correctly identified the thesis of the video. Don't solve problems you don't have. Most indie games don't need anything resembling an ECS.
@trixer2304 ай бұрын
This was pretty well spoken brother! Lots of great advice here!
@nobu-sh5 ай бұрын
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.
@asmonull5 ай бұрын
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).
@avwie1327 күн бұрын
Game developers almost never write automated tests. Why? I don’t know. 🤷
@kishirisu12685 ай бұрын
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.
@BonktYT5 ай бұрын
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
@kdngrus5 ай бұрын
PERIPHERY MENTIONED RAAAAA
@jamesmillerjo5 ай бұрын
I totally agree. There are so many andies out there.
@bryanedds89225 ай бұрын
Any particular reason you need to play your voice in fast forward? This makes this hard to understand and painful to listen to.
@patto2k3585 ай бұрын
It's a little quiet
@BigJMC6 ай бұрын
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.
@jerth6 ай бұрын
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.
@arcaneminded6 ай бұрын
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.
@radioleta7 ай бұрын
How did you get access to Jai?
@avwie1327 күн бұрын
You need to pay to get access
@colincurrie79307 ай бұрын
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)?
@joshuamanton7 ай бұрын
No idea! The song doesn't seem to be explicitly about Hades or Greek mythology in general so it's probably more of a symbolic name I think.
@SergeyLergDev7 ай бұрын
Great video, you've put it nicely what I had on my mind about ECS. Subscribed. And hello from the Jai world.
@cheerwizard218 ай бұрын
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.
@joshuamanton8 ай бұрын
The whole point of the video is an exercise in engineering a specific solution for one's specific problem. Breaking down a paradigm into its parts, evaluating the parts we actually need, and then composing a purpose-built solution from that. There is no "components and systems are objectively bad." This is engineering; its all about making informed tradeoffs based on the actual requirements you have. You were looking for a low-brow take on ECS and that's simply not what this is.
@ihydf8 ай бұрын
It took this video 8 minutes to get to the only real reason people are embracing ECS.
@anima948 ай бұрын
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?
@joshuamanton8 ай бұрын
It is just to avoid clutter and keep things small. A boolean is a full byte, so if you have 8 toggles then that will take up 8 bytes of memory. If instead you use flags, you can reduce the required storage to 8 _bits_. So 1/8th the size. This savings is important because the smaller your data footprint is, the faster your code can run because it's not having to fetch stuff from memory all the time! > My guess is this has to do with using structs instead of objects? "Object" is a metaphysical category that doesn't have any physical form. A struct can be an object and a class can be an object. The "objectness" exists only in the programmer's mind.
@anima948 ай бұрын
@@joshuamanton oh that makes total sense, thanks! For some reason I had in my head that a boolean is just a bit eventhough when I think about it that shouldnt be the case because we adress via bytes
@cprn.9 ай бұрын
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.
@joshuamanton9 ай бұрын
This is only true if you live in a fantasy land and don't care about the overall complexity level and performance of your program as a whole. Everything "working" is step 1. Libraries are not "free," they are debt you take on and often have to pay back with very high interest later on. Especially if you are making something non-trivial.
@cprn.9 ай бұрын
@@joshuamanton Fair point, libraries aren't free and I'm not familiar with your work so I don't know the complexity of your GE. I've seen your video because I was researching Bevy which is an ECS game engine in Rust. So far it seems "free" but it's in early stages. I wish someone did something big with it and share their experience so I'd know how much debt there really is.
@0ia9 ай бұрын
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 :)
@fernandolener11069 ай бұрын
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.
@joshuamanton9 ай бұрын
I've been programming for 12. It's okay, you'll get there one day 🙂
@rmt358910 ай бұрын
Singlehandedly answered all my questions, and made my decision. I'll be going with OOP instead of ECS. Now just to research frameworks.
@thygrrr10 ай бұрын
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.
@schelney Жыл бұрын
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.
@QIZI94 Жыл бұрын
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.
@aurelianspodarec26296 ай бұрын
That's like true and false IMO context matters a lot
@NEO97online4 ай бұрын
ECS looks good to you because you're coming from OOP. You know what else provides you the same thing as what you're valuing Systems for? Its called a "function"
@QIZI944 ай бұрын
@@NEO97onlineI coming from C++ and C I spent years at jobs using them so OOP is just one of the paradigms I am coming from. For me the concept of the system or as you called just a function isn't about if its a function or function "attached" to instance of an class, its about design of ECS that only interactions between entities and components happens in those chosen functions and nowhere else. In OOP where you often make hard links between other objects that in big enough code base become forgotten/invisible dependencies, which leads interactions happening everywhere. Can you use "advanced" software architecture in designing your OOP structure and mitigate the interactions and dependencies happening everywhere ? Yes. But will most programmers do it ? No. This forced "order" structure, kinda makes it harder to make these hard links and dependencies. Should you use ECS everywhere ? No not even close. Should you at least consider ECS when starting project instead of going OOP by default ? Yes.
@notactuallyarealperson22674 ай бұрын
@@NEO97onlineI think that’s what OP was saying. Systems are just functions as components and entities can be arbitrary
@QIZI943 ай бұрын
@@NEO97online I have mostly spent most of my work in C and C++ some rust and then python and other popular languages. So OOP isn't only thing I spent my time with. System doesn't have to be a function it can be anything that can manage interactions between components and entities. It looks good to me because I went into OOP for significant amount of time and identified main drawbacks of which few of them are addressed by ECS.
@giftcardgiveaway697 Жыл бұрын
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.
@JohnSmith-ze7sv Жыл бұрын
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.
@SuperG316 Жыл бұрын
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.
@BosonCollider Жыл бұрын
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
@iafog11 ай бұрын
But composition and inheritance are complimentary...
@DaGhost1415 ай бұрын
@@iafog depends, functional inheritance is great but combinding data and functions and inheriting both leads to all kinds of problems (see c++ diamond problem). Rust does this imo quite well, make functionality inheritable and to data via composition.
@bertrodgers2420 Жыл бұрын
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
@joshuamanton Жыл бұрын
I don't have a problem with subtyping if you don't go psycho with it. I do one level of inheritance for my game; so I have a base Entity struct and then Teleporter would inherit from that. The all_entities array is an array of a union of all the entity types so the teleporter can live in there alongside other entities of different types. If you wanted your player to teleport on touching a teleporter the basic thing would be to do Player *player = ...; for (int64_t i = 0; i < all_entities.count; i++) { Entity *other = &all_entities[i]; if (other->type == ENTITY_TELEPORTER) { Teleporter *tp = (Teleporter *)other; if (is_overlapping(player, tp) { player->position = tp->exit_portal; } } }
@bertrodgers2420 Жыл бұрын
@@joshuamanton That makes sense, I think that is the problem I'm having as Go can't treat embeded structs as their parent class, so I'd need an interface inbetween. I get that flow better now though thanks, so you'd switch the logic round, as where I'm putting the interact logic in the Teleporter class, you'd put it in the player
@saritsotangkur2438 Жыл бұрын
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.
@jamesmillerjo5 ай бұрын
Your logic is typical trait of ideology. Coders need to know more humanities....
@filmamundo91945 ай бұрын
@@jamesmillerjo Sure...but nothing proves he is wrong
@rodrigoserafim88344 ай бұрын
@@jamesmillerjo No. Appeal to feelings is a typical trait of ideology. Logic is the complete opposite of that. The dude made a thoughtful explanation of each claim and how it works. Then made his conclusions based on those explanations. Not on his opinions. You are the one making blind assertions without any detail or train of logic. If anything, coders need to stay the hell away from your kind of "humanities".
@joshuamanton2 ай бұрын
You just described the most rube-goldberg way to implement the fire spreading example. Instead of writing the code in a single spot with perfectly linear and easy to understand/debug code, it's just spread everywhere probably in 4 or 5 different files. This is insane. The complexity point was mainly about complexity of implementation of the underlying system powering all this nonsense. I don't even remember if I touched on complexity of usage, but that is also through the roof as you have outlined.
@iMagUdspEllr2 ай бұрын
@joshuamanton I'm still generally on team entity. But, the point is that you don't need to give every entity every feature it could possibly have (which may involve adding new methods and fields to its class for every possible feature). You can design each feature separately and tack it on or remove it in a modular manner. That seems to be better. Anything that can be added and removed easily like that seems way better because you don't have to plan ahead as much. You could simply add and remove behaviors and states as specified in each system you write instead of needing to update the class for every entity to accommodate the new feature. But, I'll have to practice more to see where the downfalls are.
@SpookySkeleton738 Жыл бұрын
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.
Пікірлер
Man the dumb brigade is out in full force in this comment section.
No shade, but I must respectfully disagree. In the composition example, the idea of using bitmasks is very cool, but the entities are still essentially being checked for all possible behaviours, this is not good for cache locality as each successive entity can send the execution down different paths. The idea that an entity is a primary key in a database is incredibly powerful for cache friendly composition because it ensures no branching is done. Everything is batched up and ready to go. This can even be taken further, if an enemy is performing too much logic in its update then branch divergence becomes a problem, so "request objects" can be created, then processed by another system all in one go, and their results can then be processed by a sort of "post update" system. Anyway, massive tangent, sorry about that. Regarding parallelism, there's currently a lack of practical knowledge on implementing it in games, and saying "writing multithreaded code is hard" every time the topic comes out doesn't help that. Thanks for the video! I appreciate the perspective that we can't just follow trends because they philosophically "feel optimal". Keep up the good work!
I chose a middle ground. But first regarding composition. I use Rust because of that as a language in the first place. And instead of entities and components I use what I call Prefabs Nodes Systems. I still use systems for multi threading and plugins. I did not like the components limits of Bevy that only one component of one type can be added to the same entity. And that in the end not all can be done in parallel in the first place and even Bevy had to use entity handles too. So I just use node handles dalways instead of having to use entity handles and then having to extract the damn component anyways. So a group of data is essentially a prefab now instead of a entity. Though. Bevy seems messy. Flecs if I am not mistaken can use more than onen component of the same typenon the same entity?! Even events are systems in my Prefabs Nodes Systems (PNS) application kernel.
In other words, start with the simplest possible solution that will get you to the goal the fastest, change it only when necessary. I've been coding for around 10 years, I feel my skills and ability to get stuff done increased drastically when i actually internalized this. Great video!!
0:19 Periphery spotted.
Over a year later, I'm coming back to this to say I finally came around and I'm pretty much removing ECS from my game too. 🤣 I think ECS is fine if you are making a completely generic engine, where you don't even know what type of game people will make with it. But I want something laser-focused to make something narrow, so I don't need or even want to support arbitrary behaviors or systems.
Why are you so salty about this lmao
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.
>since a general use "Game Engine" doesn't know about the entities you need My engine doesn't "know" about my entity types so I'm not sure what the problem is there. It uses metaprogramming to find them all and generates the code required at build time to do what it needs to do. I don't need to modify engine code to add new entities to my game. >Also you are not force to implement your own ECS you know. There are actually quite a few out there that are very good. Why would I use a library for something that is the backbone of my game? That's just foolish.
@@joshuamanton Why would you assume that you are more capable of solving problems that have been solve endless times before. That is just arrogant.
@@christian-loock Because I know the actual problems I need to solve and some several-10's-of-thousands-of-lines-of-code library solves basically none of them. The whole point of making an engine is reducing your dependence on other people in order to ship games. The more libraries you have, the less you know what your codebase is doing, the less you can debug, the less control you have. If you want to minimize the ratio of problems solved per line of code and maximize the ratio of problems invented per line of code, then use libraries because they help tremendously on both fronts.
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
Thank you. :)
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.
Yes you have correctly identified the thesis of the video. Don't solve problems you don't have. Most indie games don't need anything resembling an ECS.
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).
Game developers almost never write automated tests. Why? I don’t know. 🤷
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?
You need to pay to get access
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)?
No idea! The song doesn't seem to be explicitly about Hades or Greek mythology in general so it's probably more of a symbolic name I think.
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.
The whole point of the video is an exercise in engineering a specific solution for one's specific problem. Breaking down a paradigm into its parts, evaluating the parts we actually need, and then composing a purpose-built solution from that. There is no "components and systems are objectively bad." This is engineering; its all about making informed tradeoffs based on the actual requirements you have. You were looking for a low-brow take on ECS and that's simply not what this is.
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?
It is just to avoid clutter and keep things small. A boolean is a full byte, so if you have 8 toggles then that will take up 8 bytes of memory. If instead you use flags, you can reduce the required storage to 8 _bits_. So 1/8th the size. This savings is important because the smaller your data footprint is, the faster your code can run because it's not having to fetch stuff from memory all the time! > My guess is this has to do with using structs instead of objects? "Object" is a metaphysical category that doesn't have any physical form. A struct can be an object and a class can be an object. The "objectness" exists only in the programmer's mind.
@@joshuamanton oh that makes total sense, thanks! For some reason I had in my head that a boolean is just a bit eventhough when I think about it that shouldnt be the case because we adress via bytes
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.
This is only true if you live in a fantasy land and don't care about the overall complexity level and performance of your program as a whole. Everything "working" is step 1. Libraries are not "free," they are debt you take on and often have to pay back with very high interest later on. Especially if you are making something non-trivial.
@@joshuamanton Fair point, libraries aren't free and I'm not familiar with your work so I don't know the complexity of your GE. I've seen your video because I was researching Bevy which is an ECS game engine in Rust. So far it seems "free" but it's in early stages. I wish someone did something big with it and share their experience so I'd know how much debt there really is.
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.
I've been programming for 12. It's okay, you'll get there one day 🙂
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.
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.
That's like true and false IMO context matters a lot
ECS looks good to you because you're coming from OOP. You know what else provides you the same thing as what you're valuing Systems for? Its called a "function"
@@NEO97onlineI coming from C++ and C I spent years at jobs using them so OOP is just one of the paradigms I am coming from. For me the concept of the system or as you called just a function isn't about if its a function or function "attached" to instance of an class, its about design of ECS that only interactions between entities and components happens in those chosen functions and nowhere else. In OOP where you often make hard links between other objects that in big enough code base become forgotten/invisible dependencies, which leads interactions happening everywhere. Can you use "advanced" software architecture in designing your OOP structure and mitigate the interactions and dependencies happening everywhere ? Yes. But will most programmers do it ? No. This forced "order" structure, kinda makes it harder to make these hard links and dependencies. Should you use ECS everywhere ? No not even close. Should you at least consider ECS when starting project instead of going OOP by default ? Yes.
@@NEO97onlineI think that’s what OP was saying. Systems are just functions as components and entities can be arbitrary
@@NEO97online I have mostly spent most of my work in C and C++ some rust and then python and other popular languages. So OOP isn't only thing I spent my time with. System doesn't have to be a function it can be anything that can manage interactions between components and entities. It looks good to me because I went into OOP for significant amount of time and identified main drawbacks of which few of them are addressed by ECS.
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
But composition and inheritance are complimentary...
@@iafog depends, functional inheritance is great but combinding data and functions and inheriting both leads to all kinds of problems (see c++ diamond problem). Rust does this imo quite well, make functionality inheritable and to data via composition.
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
I don't have a problem with subtyping if you don't go psycho with it. I do one level of inheritance for my game; so I have a base Entity struct and then Teleporter would inherit from that. The all_entities array is an array of a union of all the entity types so the teleporter can live in there alongside other entities of different types. If you wanted your player to teleport on touching a teleporter the basic thing would be to do Player *player = ...; for (int64_t i = 0; i < all_entities.count; i++) { Entity *other = &all_entities[i]; if (other->type == ENTITY_TELEPORTER) { Teleporter *tp = (Teleporter *)other; if (is_overlapping(player, tp) { player->position = tp->exit_portal; } } }
@@joshuamanton That makes sense, I think that is the problem I'm having as Go can't treat embeded structs as their parent class, so I'd need an interface inbetween. I get that flow better now though thanks, so you'd switch the logic round, as where I'm putting the interact logic in the Teleporter class, you'd put it in the player
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.
Your logic is typical trait of ideology. Coders need to know more humanities....
@@jamesmillerjo Sure...but nothing proves he is wrong
@@jamesmillerjo No. Appeal to feelings is a typical trait of ideology. Logic is the complete opposite of that. The dude made a thoughtful explanation of each claim and how it works. Then made his conclusions based on those explanations. Not on his opinions. You are the one making blind assertions without any detail or train of logic. If anything, coders need to stay the hell away from your kind of "humanities".
You just described the most rube-goldberg way to implement the fire spreading example. Instead of writing the code in a single spot with perfectly linear and easy to understand/debug code, it's just spread everywhere probably in 4 or 5 different files. This is insane. The complexity point was mainly about complexity of implementation of the underlying system powering all this nonsense. I don't even remember if I touched on complexity of usage, but that is also through the roof as you have outlined.
@joshuamanton I'm still generally on team entity. But, the point is that you don't need to give every entity every feature it could possibly have (which may involve adding new methods and fields to its class for every possible feature). You can design each feature separately and tack it on or remove it in a modular manner. That seems to be better. Anything that can be added and removed easily like that seems way better because you don't have to plan ahead as much. You could simply add and remove behaviors and states as specified in each system you write instead of needing to update the class for every entity to accommodate the new feature. But, I'll have to practice more to see where the downfalls are.
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.