@@kyonas6047 I work for EA as a gameplay programmer and that's generally the case, but it's still a massive game company so all the standard issues of a large international game company apply. The pay is absolute dog doodoo and the administation is garbage.
Not to mention testing. You can write unit tests for precise sequences of actions instead of trying to coax some unified object to act in a certain way, and you can automatically iterate over permutations of action sequences
Same, I want to see more talks with him. He finished his new books about creating a own programming language (which is awesome btw), I hope he makes something new in the future, because I need more of his programming content haha
For the undo feature in an editor, I had some luck with a different approach to actions. There is an effective state that is calculated on the fly based on a stack of sparse representations of the state. The stack items take precedence from top to bottom, so each frame works like an overlay for the frames under it, optionally overloading changes made in the frames below it. You can think of it as layers in Photoshop. I have two operations for this stack: create a new frame, and merge the bottom two frames. All user actions that make sense as discrete steps in the undo history just mutate the top stack frame. Once the action is complete, they create a new stack frame. If there are too many stack frames, the bottom two frames are merged. This is effectively the limit on the undo level. Undo and redo is done by simply changing the stack top index. It's probably slow for something complex, but in my case the state is a 40x25 text screen so there's no problem having iterating over the stack frames while you render it. It could easily work for something like a simple tile map editor. Originally I wanted to implement this as an action history, but then I'd have to repeat the entire history of actions - 1 to undo, or implement reversible actions. The benefit of the state stack approach is that I could easily graft it onto a system that already mutated the state wildly without much change to the editing actions I had already implemented.
So generally - some objects that can tell how to go from state A to state B. In general - actions define the behaviour themselves, while your differential state objects contain just data processed by one general piece of code, am I correct?
Great talk! Performance characteristics are cool but the real reason I'm drawn to learning ECS architecture is that sometimes I _really_ want to be able to treat my game like it's a database. I was doing a tutorial (Hands on Rust by Herbert Wolverson) where putting an item in your inventory was as simple as adding a CarriedBy (player) component to the item. I can really see a lot of possibility to think of the _relationships_ between components when designing new systems.
Absolutely fantastic breakdown of the components and structure of commands and how you'd implement them, best part is even though you've used roguelike as the example, any game system (specially RPG in nature) can benefit from all these architectures! Thank you for sharing! :)
@@pythonxz Without the need to dive deep into physics, rendering, or in many cases audio, you can really dig into system architecture and other low-level topics like data structures. On the game side, it also helps in prototyping quickly with AI, game mechanics, and procedural generation.
Great talk. I was almost debating switching my new roguelike to implement more nested inheritance, but this helped me reconsider that notion. Very informative, will watch again :)
Great talk! Main take-away/reminder for me: Don't overuse architectural patterns. Employ those that actually make sense in your domain: those that help provide clear structure to the solution of your particular problem. Obvious of course, but it's worth to frequently reflect on healthy architectural methodology.
I like how Casey Muratori describes programming. In his mind "architecture" is the wrong term. He sees it more like city planning. You have to shape your structure as you build it.
I was surprised to find out that this was the same person who made Game Programming Patterns! I've read from the site of that book and enjoyed it quite a bit.
Yeah man, I was expecting something shallow and relaxing, but he actually gives some serious insight about software architecture and modeling like, I had to come back. As he said, we all "reinvent" it many times and then forget about it. But doing it knowingly saves time and the result is better. Sometimes we constrain ourselves with language constructs or programming patterns, when in reality you can't always map your problem to these, then you should "eject" and "roll your own" solution.
His Crafting Interpreters book is awesome too! I read that recently, didn't know he was a game dev too, just stumbled on this video while searching for videos on dungeon generation.
I wish I could find this great talk before. This is the best and easy to follow talk I ever listen about game architecture. Blessings to Bob Nystrom. One thing that I'd like to mention is strategy pattern would fit perfect into "command object" instead of command pattern. Nevertheless, both pattern would yield the same result in this case.
Actually command pattern is the best solution in the example he used. Strategy would make sense if, for example, you have 2 or more playable characters, where say the AttackAction, implements a different algorithm depending on the character. Command is about the what (move, jump, attack), strategy is about the how. In any case, command pattern or strategy it all depends on your GDD, you could even combine both of them, but I wouldn´t say use strategy instead.
This talk helped me understand how to reason about the design patterns I've been seeing around for years, but never understood the rationale behind. Great talk!
I want to notice that the described pattern IS NOT ECS. It's just Entity-Component pattern, where Entity is component container and Component is game logic part which contains both data and logic. That's like classic OOP with more emphasis on composition. Bob used systems only for calling Component.Update() method as you can see at 6:50. Entity-Component-System is ANOTHER architecture pattern. Yeah, both are called very similar, but there are a lot of differences. Main point of ECS is strictly data/logic separation. Entity is still just a container of Components, BUT Components MUST contain ONLY DATA. It's very important and this restriction is ALL power of ECS. What should contain game logic then? You think right: Systems will contain all logic of your game and just read and write components, just like conveyor that process all game data. Systems should not contain data, but it's not restricted. Secondary point of ECS is Composition OVER inheritance. You MUST NOT inherit components, but you can inherit systems. ECS is more like procedural programming, not OOP.
@@MuhammadHosny0, I think it's possible to name Bob's pattern as Entity-Component System and what I'm talking about as Entity-Component-System. But it's better to separate them and use the following naming: Entity-Component architecture pattern and Entity-Component-System architecture pattern to avoid confusion
@@nothingtoospecial777en.wikipedia.org/wiki/Entity_component_system The implementations of ECS in Unity and Flecs are good examples in my opinion, but I am sure there are others.
Thank you. I was looking for this comment. (I felt, wading through all the "awesome", "amazing" talk comments that something must be wrong with me then. Not just about the ECS misunderstanding, BTW.)
I think the speaker may have been confused between Entities, Components and Systems (ECS) and Entity/Component Systems. The later is the one where you create an entity class that has a list of components where each component is a class that is some behaviour. This is the pattern used by older versions of the Unity game engine. The former is where an entity is just an id, a component is a POD type and a system is a function which filters the entities by which components are required for a given piece of game logic. This is the pattern used by newer versions of the Unity game engine with their Burst compiler. These patterns are very different, they just have an unfortunately similar name.
I admit that I'm somewhat confused by "Idea #1". That's exactly how components are used in ECS (or at least most interpretations of ECS that I am familiar with). Components do not represent domains but capabilities. Having an "AI" component is similar to having a giant "update()" call on your entity class so that doesn't make any sense. Also, the command pattern later doesn't quite seem right. A proper command would more likely be a data structure / class that describes the action. That action can then be run in an interpreter, which performs the side effects of that action.
Same thing. You can serialize commands (or actions), and they're usually separated from implementation details, right? I can't bring myself to dislike the talk, though
This is really cool! Im making a game that works like a roguelike and I wound up doing pretty much all of this. Actions as the command pattern, and actors that implement interfaces, etc. I guess if two people wind up independently designing the same solution, it's probably at least good for something!
How about splitting up video game code according to function? For example separating your logic layer from your visual layer and from your audio layer, etc. So that if you want to do something like for example make different art styles for your game, such as one that is your default art style and another that uses ascii art style, you can easily add the code for those different art styles, without having to rewrite the logic portion of the game.
You've just described the primary motivation for ECS. Orienting a game around functions rather than objects you get functional programming rather than OOP. Rather than having orienting architecture around big player classes and inheritance, you divide the game into data components and systems of functions (the C and the S). Entities are just are just the keys to the component hash tables. Every pattern the video describes as good for rogue likes is just a naive reimplementation of true ECS.
Patterns Bob Nystrom ♥s: Components: Literally just data components. If your entity can move, add the Movement component. If it can break add the Breakable component. Type Objects: ECS uses composition rather than inheritance. You just have two components rather than parent child classes. Command Objects: When in doubt, try turning a verb into a system(s) and a component. E.g. a FireSpreadSystem, FuelSystem and FlammableComponent. The only difference is his memory layout and that he sticks to OOP things like inheritance, which just ends up coupling actions to specific objects like actors. I would prefer to have those capabilities more composable and reusable myself.
@@keldencowan the separation of concerns is also a thing in OOP. It's a thing in any paradigm. The advantage of ECS depends on the specifics of a given goal. Also, *_"Every pattern the video describes as good for rogue likes is just a naive reimplementation of true ECS."_* No it's not. It's actually a smart implementation of OOP through composition, instead of inheritance.
@18:10 While I generally like the command pattern---I've used it in a editor with multiple undo and it works great there---I think you have to watch out. As in his WalkAction command you can end up with a bunch of IF statements such as "if (actor is Hero)" and the need to query actors. You're trading off virtual functions for if statements; just slicing things a different way. It may end up being just as unorganized.
What I think woudl click for most people when trying to explain ECS.. it is a database like relationship table model and the flow of information is not much different. It is simply data oriented architecture.
Whao, when he started talking about "capabilities"; it's like he was talking about Rust's trait system lol. Composition in general is far superior. And that "fireball-shooting sword" is a great example where the class doesn't adhere to its supposed hierarchical ancestry and thus inheritance breaks down, causing a lot of overhead and possibly a lot of bugs by inherited features that were never needed. Traits are much more superior.
This is not the correct representation of ECS that is used in the industry today, which is understandable because the name is confusing. ECS today is Entities are treated as identifiers, Systems exists to contain a list of entities which have the component that System manages, and Components have just data, no functions. Entities should not have anything in them other than maybe an ID and a transform if 3D location is a first class data member, and your entity manager can hold all the components and give them to each SYstem, or maybe encapsulate that in your scene graph. This particular representation is also a very old form of Actor-Model system from the 90s, just using the terms Entity and Component, but it achieves nothing more than the old Actor-Model system and has the same problems. A correct ECS truly seperates the burden of work on the Systems, but at the same time gives the SceneGraph/Entity manager the control of which system gets what component, and Entitys have 0 data tied to them so you can pass them around like nothing.
I think maybe they forgot to mention something important? Cuz at 6:50 the code they present looks more like ECS system looping thru the components separately from the entities
@Darkwing Dumpling That's because this talk is about an ALTERNATIVE to ECS for roguelikes. At 1:51 he explains that the talk is about why he DOESN'T use classical ECS. At 4:51 he begins to summarize how classical ECS works, as you explained it, though he does gloss over it since it is not the subject of this talk. At 8:14 he points out that for a game as simple as a roguelike, ECS is often overkill, and spends the rest of the talk discussing organization. But thanks for clarifying how classical ECS works
@@slBrelaz It is most certainly the de facto standard in terms of ECS, you can consult with Ubisoft or Overwatch developers and I believe there are GDC talks in which Assassins Creed, Overwatch, and even Halo are shown and described the ECS which they use and you can see the description matches with what I wrote about true ECS. As for Unity and Unreal, these are also common misconceptions but again you can verify these by taking a look into the UE4 source code, and Unity itself does much to distance itself from the term ECS as they know the implementation is not an actual ECS. 1) Unity until very recently did not use ECS, it even referred to it specifically as the Unity Component System in all documentation. Only recently does it use *some* actual ECS concepts, yet you can watch their video shows and they still try and steer clear from comparing their ECS to an industry ECS. 2) Unreal does not use ECS. It uses Entity-Components, which is the system I described is the same as Actor Model in the comment. You can take a look for yourself through UE4 and see that they do not have any concept of Systems or managers for their components. They even still use the term Actor instead of Entity, most likely as a relic of the original Actor-Model system they had in UE2 & UE3, and it has gone (architecturally) unchanged. As stated in the comment the only similarity is in the name. As for your industry contacts, I can't really speak on whether or not they are using ECS as I don't know them, but as long as the description matches up it is ECS, and you're free to view GDC talks or dev shows or even online references I'm sure from industry names will also describe the same system I describe.
so, how do you query the Actor in an Action.Perform method? 18:05 I tried something like that: - set static fields in Action class, such as currentActor/gameScene/mapSet - when an actor finish it's turn, the GameLogicClass switch the 'currentActor' and other static fields It looks strange, but it works well. I hope this is the right way : )
Well, I assume you know what the actor is when you create the action object. Why not just use a member variable? If it's a property of the action, it should go with it. Using a static or class side variable will break in a lot of circumstances, it's basically just using a global. Anything that takes an action outside of the context in which it was created, basically is prone to fail.
@@frechjo oh，there are so many params in the action instance, game manager, main scene, word map, current actor, attack target...I am just trying to keep the code simple while create an certain action with those params
Well, in my opinion, carry all those params to a single instance for example 'gameInstance' , and then pass it to the action constructor. They are doing the same thing. I mean using the global variable...
@@whitebai6367 Maybe you could break your actions into subclasses? I doubt all actions need all those fields. And are you sure an action should have to know things like "game manager", or "main scene", or "world map"? By it being as using globals, I mean you can only hold a single value for all the actions if you use a class variable. If you have actions to process, all with different actors, targets, or whatever, your global/class variable will point only to the last one, and the rest will have the wrong information. So you can never produce actions to evaluate them at a different stage, or store them (for undo, replay, whatever), and maybe a bunch of other things you might want to do. If you are just going to call the action at the moment you create it, you could have simply called a function.
He was describing the evolution towards ECS the first few examples aren't meant as examples of ECS they were to illustrate the problem ECS was meant to solve. He probably wouldn't want to have an update sure on the component class itself sure albeit depends how it's implemented.
Here is the problem, Processors have stopped getting more powerful since 2007ish. Stacking a bunch of them together is their way of fixing this but as software developers, it really fucks up our code. Even using 20 processors at the same time means the game can be 2x as complex as what a 10 core processor computer could have. That is way to limiting, especially compared to the traditional generation jumps such as snes->n64->gamecube. In other words, until better computers arrive, such as quantum computers , we will have the same technology in 2030, 2040, and so on, as now.
2007 is pulled out of your ass. Single-Core performance increases started to seriously diminish in the mid- to late-2010s The rest is incorrect too. Processors are not the limiting factor anymore. Only for graphics and rendering or research purposes. Normal applications wouldn't massively benefit from more powerful processors.
@@automatic241 eh, he said "-ish", when talking decades, that includes mid to late 2010s. yes, moore's law is dead. if we want to write increasingly complex AI, we can no longer fall back on the exponential growth in processing power like we used to. we have to write clean code, which is what code architecture is all about.
They actually keep getting more and more powerful, not exactly "exponentially", but significantly in fact. At the moment we are limited by lithography, stability and inevitably by silicon, but as new technologies are developed (like the one you were studying, of using photons to build processors) we will have a gain in processing power. The speed limit we have in our universe is literally how many operations we can do simultaneously close enough to the speed of light threshold.
@@fergal9808 Well sure you could. You could wrap all behaviours into a static class or a normal function. But then you would have to feed in all the details you need as parameters--which adds complexity because you can now mess up calling the action correctly. You might solve that by passing in the Actor & Target as parameters and have the function sort it all out from there, but now the action functions just became a lot more bloated: do you have nested functions to extract the relevant info from the objects? Do you always have a target? How do you deal with multiple optional targets? How easy is it to add a second type of attack that for whatever reason needs to be handled differently--ranged or touch attacks for example. I'm sure you can think of solutions to these 'problems' I mention, but that is the whole point of this talk: solve problems we run into while developing games. You'll notice Bob uses very soft language when talking about patterns. There really isn't "wrong" and "right" so much as "this is useful" and "this leads to migraines".
stop talking about Monster and Breed classes in the same sentence. Some people here have watched japanese animated movie art and know where this is going.
My takeaway is that his point wasn't to throw ECS out the window but to organize your components around their gameplay mechanisms rather than technical domains.
Nah, it's very much OOP, and very little ECS. There's a whole spectrum of ECSs, but ECS is actually a data driven paradigm, where components contain exclusively data -- no functions, that's what the systems are for -- and the entity is either just an ethereal ID that components are bound to, or an object with just an id and a component list, or something of that sort. What he's doing there is very much OOP, but, like he mentioned, it favors composition rather than inheritance, which is usually said to be a good practice. _Entity Component System_ doesn't mean _"a system of components and entities",_ it means _"a paradigm involving entities, components and systems"._ I would argue systems would've been better named as _"processes",_ but...
It's really not an ECS, even his example in the beginning misses the point of an ECS since it's still based on entities carrying their own behaviour and updating themselves. The fundamental point of an ECS is to be data driven with systems consuming components and, crucially, specific combinations of components for crosscutting concerns - not just slightly change way you loop through composition objects. With that approach using an ECS would suddenly feel a lot more natural for a roguelike.
Moore's Law never indicated that CPUs got twice as fast every 18 months, but rather that the number of transistors per area in a chip doubled. Also, Moore's Law is basically dead.
6:45 This is also slow. Having the update in each component isn't good (components should only be data). The code that does the updating should be in the system itself. I've tested it in javascript, not c, c++, or c#. That's up to you. I can't recall the cause exactly, but I think it has to do with caching the code that's running; so it's similar to the caching issue you talked about, but for the actual code itself. (IIRC)
Update() function in the Component typically means going through a vtable for being virtual, plus function invocation overhead(push/pop stack stuff). An inlined Update() would get rid of the overhead you're talking about, I believe
You might want to actually look at game code from the 90s. They were doing composition long before you kids thought it was cool. This stuff isnt even remotely as new as you seem to think it is. 90s game devs were way better than most people today.
"I split out each capability that an item has into a separate class" "Whether or not you call it 'component' is kind of an interesting question ... this is just the old principle of preferring composition over inheritance" Wikipedia page for ECS: *_ECS follows the composition over inheritance principle_* that allows greater flexibility in defining entities where every object in a game's scene is an entity... Every entity consists of one or more components which contains data or state.
He didn't, he is talking about composition in the world of object-oritentation and OO patterns. ECS is data-oriented design, without OO patterns, without behaviour attached to data, and when things done in a completely different way than he is showing in his example.
@@lekretka His architecture is a bit different from ECS, but his explanation of ECS was completely wrong. He got the Systems part right, but his god class representation of Entities wasn't even close. In fact, his own Entity-Component relationship is exactly the same as in ECS (though the implementation is usually--but not necessarily--data-oriented).
@@lekretka Alright, so instead of lumping all the procedures for accessing an object's fields, he separates the functions into data objects that are referenced by the first object. That's the Tao of data oriented (functional) programming. He does this again with the Actor class, it just becomes a data class with all the code in Action objects. OOP is about hiding an object's data as private and giving it a bunch member functions. This is doing the opposite, so it's not _really_ OOP paradigm is it? It's at least Procedural, maybe even DOP. People think ECS is just about data layout and performance, it's just as much about reducing complexity. I'm not saying what he's made is precisely an ECS, more like it's an ECS-lite. All the bits are there in his code, there's just a resistance to dropping the OOP frame of mind in an instance where it is clumsy.
The problem with shitty abstractions (high level programming languages being just one example) is that they cover up and distract you from thinking about stuff that really matters (such as algorithms, data structures, and hardware) in favor of some linguistic fantasy. It doesn't just concern game programming, but programming (manipulating data) in general. Pretending too much that things are something else than they are and sweeping critical issues under the rug leads into performance disasters. If you want to use high level abstractions and rely on optimizations through tools such as compilers, you still have to understand how these tools (don't) work. Generally speaking, optimizations are only possible when crucial information is not arbitrarily withheld from the optimizer (which also applies to other processes outside of CS). Performance engineering is similar to accounting, you have to keep in mind where the costs/overheads are and what is causing them.
That weird moment when you click on a random game dev talk and you discover you already have the book
Had the same moment when he mentioned Crafting Interpreters.
Watching this again, now I have that feeling too (now that I own both books)!
Same. I have about 100 bookmarks related to gamedev and this book is at the top of the list. Never read it, I will now though 😅
I dont remember seeing a better presentation slide in my life.
Fitting that a programmer would program his presentation.
_"I worked for EA for eight years, so I have experience being trapped in dungeons for a long time."_
lol brilliant. :)
Not enough people laughed at that.
@@BenGearig *Insert 'Nam flashbacks.
tho i heard EA treats employees better than customer lol
@@kyonas6047 I work for EA as a gameplay programmer and that's generally the case, but it's still a massive game company so all the standard issues of a large international game company apply.
The pay is absolute dog doodoo and the administation is garbage.
@@bearwynn really? I thought the money was good at least
Other side benefits of separating out "actions" is you can serialize them for replay systems, multiplayer, offline simulation - lots of stuff!
Not to mention testing. You can write unit tests for precise sequences of actions instead of trying to coax some unified object to act in a certain way, and you can automatically iterate over permutations of action sequences
this is the single most useful game presentation talk I have ever watched.
Robert is amazing on many levels, wish he's do more public appearances and talks.
Same, I want to see more talks with him.
He finished his new books about creating a own programming language (which is awesome btw), I hope he makes something new in the future, because I need more of his programming content haha
@@r1pfake521 I thought I was a creepy because I absolutely love everything he writes!
For the undo feature in an editor, I had some luck with a different approach to actions. There is an effective state that is calculated on the fly based on a stack of sparse representations of the state. The stack items take precedence from top to bottom, so each frame works like an overlay for the frames under it, optionally overloading changes made in the frames below it. You can think of it as layers in Photoshop. I have two operations for this stack: create a new frame, and merge the bottom two frames.
All user actions that make sense as discrete steps in the undo history just mutate the top stack frame. Once the action is complete, they create a new stack frame. If there are too many stack frames, the bottom two frames are merged. This is effectively the limit on the undo level. Undo and redo is done by simply changing the stack top index.
It's probably slow for something complex, but in my case the state is a 40x25 text screen so there's no problem having iterating over the stack frames while you render it. It could easily work for something like a simple tile map editor.
Originally I wanted to implement this as an action history, but then I'd have to repeat the entire history of actions - 1 to undo, or implement reversible actions. The benefit of the state stack approach is that I could easily graft it onto a system that already mutated the state wildly without much change to the editing actions I had already implemented.
This is essentially how differential backups work, or transaction logs in database engines. Nice.
So generally - some objects that can tell how to go from state A to state B. In general - actions define the behaviour themselves, while your differential state objects contain just data processed by one general piece of code, am I correct?
Great talk! Performance characteristics are cool but the real reason I'm drawn to learning ECS architecture is that sometimes I _really_ want to be able to treat my game like it's a database. I was doing a tutorial (Hands on Rust by Herbert Wolverson) where putting an item in your inventory was as simple as adding a CarriedBy (player) component to the item. I can really see a lot of possibility to think of the _relationships_ between components when designing new systems.
Absolutely fantastic breakdown of the components and structure of commands and how you'd implement them, best part is even though you've used roguelike as the example, any game system (specially RPG in nature) can benefit from all these architectures! Thank you for sharing! :)
Roguelikes are so amazing to program. They teach you so many things.
What topics do you think they do a great job teaching you?
@@pythonxz Without the need to dive deep into physics, rendering, or in many cases audio, you can really dig into system architecture and other low-level topics like data structures. On the game side, it also helps in prototyping quickly with AI, game mechanics, and procedural generation.
Great talk. I was almost debating switching my new roguelike to implement more nested inheritance, but this helped me reconsider that notion. Very informative, will watch again :)
you'll miss on fun stuff, like "why do dogs inherit fom car?"
Can we please take a moment for that epic EA burn at the beginning.
Great talk! Main take-away/reminder for me: Don't overuse architectural patterns. Employ those that actually make sense in your domain: those that help provide clear structure to the solution of your particular problem. Obvious of course, but it's worth to frequently reflect on healthy architectural methodology.
I like how Casey Muratori describes programming. In his mind "architecture" is the wrong term. He sees it more like city planning. You have to shape your structure as you build it.
Loved the talk. Incredible. So weird I only found this after 5 years! Learned a lot. Thank you!
The man, the myth, and the e-book. It's mentioned and suggested a surprising amount online.
I was surprised to find out that this was the same person who made Game Programming Patterns! I've read from the site of that book and enjoyed it quite a bit.
A fantastic talk. If you are like me back here to review the patterns, that starts at 10:30
Yeah man, I was expecting something shallow and relaxing, but he actually gives some serious insight about software architecture and modeling like, I had to come back.
As he said, we all "reinvent" it many times and then forget about it. But doing it knowingly saves time and the result is better. Sometimes we constrain ourselves with language constructs or programming patterns, when in reality you can't always map your problem to these, then you should "eject" and "roll your own" solution.
Read his book, absolutely worth it!!
His Crafting Interpreters book is awesome too! I read that recently, didn't know he was a game dev too, just stumbled on this video while searching for videos on dungeon generation.
I wish I could find this great talk before. This is the best and easy to follow talk I ever listen about game architecture. Blessings to Bob Nystrom. One thing that I'd like to mention is strategy pattern would fit perfect into "command object" instead of command pattern. Nevertheless, both pattern would yield the same result in this case.
Actually command pattern is the best solution in the example he used. Strategy would make sense if, for example, you have 2 or more playable characters, where say the AttackAction, implements a different algorithm depending on the character. Command is about the what (move, jump, attack), strategy is about the how. In any case, command pattern or strategy it all depends on your GDD, you could even combine both of them, but I wouldn´t say use strategy instead.
This talk helped me understand how to reason about the design patterns I've been seeing around for years, but never understood the rationale behind. Great talk!
Hey, I know this guy, I read his book. Highly recommended. Humorous and smooth read while dense with enlightening info
Crafting Interpreters is AMAZING thank you Bob!!!!!
Awesome presentation. Helped me a lot understanding the directions I need to take on my project! Thanks! Gonna try to read your book!
The third one just gave me an idea to solve the current problem in my personal project
I want to notice that the described pattern IS NOT ECS.
It's just Entity-Component pattern, where Entity is component container and Component is game logic part which contains both data and logic. That's like classic OOP with more emphasis on composition. Bob used systems only for calling Component.Update() method as you can see at 6:50.
Entity-Component-System is ANOTHER architecture pattern. Yeah, both are called very similar, but there are a lot of differences. Main point of ECS is strictly data/logic separation. Entity is still just a container of Components, BUT Components MUST contain ONLY DATA. It's very important and this restriction is ALL power of ECS. What should contain game logic then? You think right: Systems will contain all logic of your game and just read and write components, just like conveyor that process all game data. Systems should not contain data, but it's not restricted. Secondary point of ECS is Composition OVER inheritance. You MUST NOT inherit components, but you can inherit systems. ECS is more like procedural programming, not OOP.
@@MuhammadHosny0, I think it's possible to name Bob's pattern as Entity-Component System and what I'm talking about as Entity-Component-System. But it's better to separate them and use the following naming: Entity-Component architecture pattern and Entity-Component-System architecture pattern to avoid confusion
Where can I read more about this
@@nothingtoospecial777en.wikipedia.org/wiki/Entity_component_system The implementations of ECS in Unity and Flecs are good examples in my opinion, but I am sure there are others.
Thank you. I was looking for this comment. (I felt, wading through all the "awesome", "amazing" talk comments that something must be wrong with me then. Not just about the ECS misunderstanding, BTW.)
@@lunakid12 but didn't he said he doesn't use "classical ecs"?
I appreciate this talk. It gives me more insight in how to maintain the structure of my own code more
I think the speaker may have been confused between Entities, Components and Systems (ECS) and Entity/Component Systems.
The later is the one where you create an entity class that has a list of components where each component is a class that is some behaviour. This is the pattern used by older versions of the Unity game engine.
The former is where an entity is just an id, a component is a POD type and a system is a function which filters the entities by which components are required for a given piece of game logic. This is the pattern used by newer versions of the Unity game engine with their Burst compiler.
These patterns are very different, they just have an unfortunately similar name.
I didn't understand most of what he was talking about but I enjoyed the presentation.
Though this is an old talk, i quite like it and was 1. very informative 2. very entertaining 3. Funny.
Thanks for the great video!
Useful set of things to do to resolve unobvious issues.
the presentation slides were dope
I'm introverted. You're introverted. We can introvert together while avoiding eye contact. ❤️️
you need to move your raycast higher
@@CariagaXIII Thankfully I wasn't drinking anything when I read that
thats not introverted, that's socially awkward.
14:13 "Reinventing object orientation at the application level"
i think this is the best programming presentation i've ever saw lol
I was having the same issue and I found this talk, such a great talk! AMAZING!
thank you!
Yes, we should always think - very carefully - about how best to organise our data, for that's one house you really don't want to be untidy...!!
This talk has the best graphics of all the talks. Fight me.
Toady was better, obviously!
great talk, the action objects are a neat idea
I admit that I'm somewhat confused by "Idea #1". That's exactly how components are used in ECS (or at least most interpretations of ECS that I am familiar with). Components do not represent domains but capabilities. Having an "AI" component is similar to having a giant "update()" call on your entity class so that doesn't make any sense.
Also, the command pattern later doesn't quite seem right. A proper command would more likely be a data structure / class that describes the action. That action can then be run in an interpreter, which performs the side effects of that action.
Same thing. You can serialize commands (or actions), and they're usually separated from implementation details, right?
I can't bring myself to dislike the talk, though
You could treat the AI component as an ability to perform actions on a set of components automatically. This fits well with the ECS standard.
I love Bob so much!
This is really cool! Im making a game that works like a roguelike and I wound up doing pretty much all of this. Actions as the command pattern, and actors that implement interfaces, etc. I guess if two people wind up independently designing the same solution, it's probably at least good for something!
17:50 one can imagine just how long this kind of chain of events can get in a properly programmed roguelike
Wow, one of the most useful presentation I've seen so far ! :) Thank you !
Clear and insightful. Just like his book. Legend.
Good talk, thanks Bob!
And thanks for writing and sharing your great book on Game Design Patterns, too. :D
I really enjoyed it!
Very interesting talk, thanks
It's a great pack of ideas for any game with simple graphics. Thank you, Bob!
20:40 "... take some verb ... and turn it into a noun ..."
How about splitting up video game code according to function? For example separating your logic layer from your visual layer and from your audio layer, etc. So that if you want to do something like for example make different art styles for your game, such as one that is your default art style and another that uses ascii art style, you can easily add the code for those different art styles, without having to rewrite the logic portion of the game.
You've just described the primary motivation for ECS. Orienting a game around functions rather than objects you get functional programming rather than OOP. Rather than having orienting architecture around big player classes and inheritance, you divide the game into data components and systems of functions (the C and the S). Entities are just are just the keys to the component hash tables. Every pattern the video describes as good for rogue likes is just a naive reimplementation of true ECS.
Patterns Bob Nystrom ♥s:
Components:
Literally just data components. If your entity can move, add the Movement component. If it can break add the Breakable component.
Type Objects:
ECS uses composition rather than inheritance. You just have two components rather than parent child classes.
Command Objects:
When in doubt, try turning a verb into a system(s) and a component. E.g. a FireSpreadSystem, FuelSystem and FlammableComponent.
The only difference is his memory layout and that he sticks to OOP things like inheritance, which just ends up coupling actions to specific objects like actors. I would prefer to have those capabilities more composable and reusable myself.
@@keldencowan the separation of concerns is also a thing in OOP. It's a thing in any paradigm. The advantage of ECS depends on the specifics of a given goal.
Also,
*_"Every pattern the video describes as good for rogue likes is just a naive reimplementation of true ECS."_*
No it's not. It's actually a smart implementation of OOP through composition, instead of inheritance.
12:08 .... omg makes sense now.
@18:10 While I generally like the command pattern---I've used it in a editor with multiple undo and it works great there---I think you have to watch out. As in his WalkAction command you can end up with a bunch of IF statements such as "if (actor is Hero)" and the need to query actors. You're trading off virtual functions for if statements; just slicing things a different way. It may end up being just as unorganized.
the voice cracks really make this
Action classes are classy, I like it.
Idea #3 is awesome. turn verbs into nouns.
Well not necessarily but thinking about verbs like abstractable things is cool!
Love anything regarding architecture, especially in rpgs.
What I think woudl click for most people when trying to explain ECS.. it is a database like relationship table model and the flow of information is not much different. It is simply data oriented architecture.
OMG I love your web page name!
Wow, that level gen looks awesome! Anyone know which mysterious game is referenced in this talk?
Whao, when he started talking about "capabilities"; it's like he was talking about Rust's trait system lol. Composition in general is far superior. And that "fireball-shooting sword" is a great example where the class doesn't adhere to its supposed hierarchical ancestry and thus inheritance breaks down, causing a lot of overhead and possibly a lot of bugs by inherited features that were never needed. Traits are much more superior.
Thank you for making that connection, I don't use rust but ECS but that makes me feel like rust makes a bit more sense to me now lol
Great! Interesting talk!
This is not the correct representation of ECS that is used in the industry today, which is understandable because the name is confusing. ECS today is Entities are treated as identifiers, Systems exists to contain a list of entities which have the component that System manages, and Components have just data, no functions. Entities should not have anything in them other than maybe an ID and a transform if 3D location is a first class data member, and your entity manager can hold all the components and give them to each SYstem, or maybe encapsulate that in your scene graph.
This particular representation is also a very old form of Actor-Model system from the 90s, just using the terms Entity and Component, but it achieves nothing more than the old Actor-Model system and has the same problems. A correct ECS truly seperates the burden of work on the Systems, but at the same time gives the SceneGraph/Entity manager the control of which system gets what component, and Entitys have 0 data tied to them so you can pass them around like nothing.
Yeah I was very confused. Thought this was outdated. Entities (Hold ID's), Components (Hold Data), Systems (Do Functionality)
I agree, this is how I implemented my ECS for my project.
I think maybe they forgot to mention something important? Cuz at 6:50 the code they present looks more like ECS system looping thru the components separately from the entities
@Darkwing Dumpling
That's because this talk is about an ALTERNATIVE to ECS for roguelikes.
At 1:51 he explains that the talk is about why he DOESN'T use classical ECS.
At 4:51 he begins to summarize how classical ECS works, as you explained it, though he does gloss over it since it is not the subject of this talk.
At 8:14 he points out that for a game as simple as a roguelike, ECS is often overkill, and spends the rest of the talk discussing organization.
But thanks for clarifying how classical ECS works
@@slBrelaz It is most certainly the de facto standard in terms of ECS, you can consult with Ubisoft or Overwatch developers and I believe there are GDC talks in which Assassins Creed, Overwatch, and even Halo are shown and described the ECS which they use and you can see the description matches with what I wrote about true ECS.
As for Unity and Unreal, these are also common misconceptions but again you can verify these by taking a look into the UE4 source code, and Unity itself does much to distance itself from the term ECS as they know the implementation is not an actual ECS. 1) Unity until very recently did not use ECS, it even referred to it specifically as the Unity Component System in all documentation. Only recently does it use *some* actual ECS concepts, yet you can watch their video shows and they still try and steer clear from comparing their ECS to an industry ECS. 2) Unreal does not use ECS. It uses Entity-Components, which is the system I described is the same as Actor Model in the comment. You can take a look for yourself through UE4 and see that they do not have any concept of Systems or managers for their components. They even still use the term Actor instead of Entity, most likely as a relic of the original Actor-Model system they had in UE2 & UE3, and it has gone (architecturally) unchanged.
As stated in the comment the only similarity is in the name.
As for your industry contacts, I can't really speak on whether or not they are using ECS as I don't know them, but as long as the description matches up it is ECS, and you're free to view GDC talks or dev shows or even online references I'm sure from industry names will also describe the same system I describe.
Great video
what font is that in the presentation? i want to use it in my ide
Nice that you use Dart!
12:08 "This is the case where I think actually inheritance works very well, where you have the hierarchy that is not very deep, but it's really wide."
7:16 bro was having vietnam flashbacks ON CAMERA thinking about physics... What things did he see while trapped at EA?!
Idea #3 is basically a defunctionalization, right?
what font is that?
Anyone know what font he uses on his slides?
was just looking this up lol its different than the NES/Gameboy font and Commodor64 font, wondering if he drew it himself?
it is the most similar to the Commodor64 font (see lower case a, b, d) but its slightly different on many letters (lower case p, u, m) etc.
actually this one is pretty close : fontsme.com/pixel-sans-serif-condensed.font
Press start 2P font
Thanks for this video.
so, how do you query the Actor in an Action.Perform method? 18:05
I tried something like that:
- set static fields in Action class, such as currentActor/gameScene/mapSet
- when an actor finish it's turn, the GameLogicClass switch the 'currentActor' and other static fields
It looks strange, but it works well.
I hope this is the right way : )
Well, I assume you know what the actor is when you create the action object. Why not just use a member variable? If it's a property of the action, it should go with it.
Using a static or class side variable will break in a lot of circumstances, it's basically just using a global. Anything that takes an action outside of the context in which it was created, basically is prone to fail.
@@frechjo oh，there are so many params in the action instance, game manager, main scene, word map, current actor, attack target...I am
just trying to keep the code simple while create an certain action with those params
Well, in my opinion, carry all those params to a single instance for example 'gameInstance' , and then pass it to the action constructor. They are doing the same thing. I mean using the global variable...
@@whitebai6367
Maybe you could break your actions into subclasses? I doubt all actions need all those fields. And are you sure an action should have to know things like "game manager", or "main scene", or "world map"?
By it being as using globals, I mean you can only hold a single value for all the actions if you use a class variable.
If you have actions to process, all with different actors, targets, or whatever, your global/class variable will point only to the last one, and the rest will have the wrong information. So you can never produce actions to evaluate them at a different stage, or store them
(for undo, replay, whatever), and maybe a bunch of other things you might want to do.
If you are just going to call the action at the moment you create it, you could have simply called a function.
@@frechjo thanks for your examples, I get you point now. It's kind of you.
"cpu's have been getting twice as faster, we get to be twice as lazy as developers" *jonathan blow wants to know your location*
this is one of those talks that you might dismiss at first glance, but you'll come back a month/year/project later and realize how smart it is.
I didnt understand anything but still interesting.
Bob your book is the dogs bollocks!
When you turn actino into an object, what do you generally pass to it as properties?
Hmm I think your implementation of ECS at the beginning is not correct... in ECS entities have no behaviour, they are just a bag of components
He was describing the evolution towards ECS the first few examples aren't meant as examples of ECS they were to illustrate the problem ECS was meant to solve. He probably wouldn't want to have an update sure on the component class itself sure albeit depends how it's implemented.
Even the "bag of components" is a specific design decision that isn't in all ECS implementations.
My player objects ARE monsters... With a different controller implementation
1:26 did he say: "I beat egg band"?
I want to know what he said here too.
@@Xonatron "I beat Angband". It's some roguelike that I don't know anything about except that it's quite respected
@@defaultservices3483 Thank you!
dude literally described ecs without performance bonus =)
"Saddest hype statement ever" Man, don't do that. Respect your craft
Here is the problem, Processors have stopped getting more powerful since 2007ish. Stacking a bunch of them together is their way of fixing this but as software developers, it really fucks up our code. Even using 20 processors at the same time means the game can be 2x as complex as what a 10 core processor computer could have. That is way to limiting, especially compared to the traditional generation jumps such as snes->n64->gamecube.
In other words, until better computers arrive, such as quantum computers , we will have the same technology in 2030, 2040, and so on, as now.
We have really good processors already though, we just write really slow programs
2007 is pulled out of your ass. Single-Core performance increases started to seriously diminish in the mid- to late-2010s
The rest is incorrect too. Processors are not the limiting factor anymore. Only for graphics and rendering or research purposes. Normal applications wouldn't massively benefit from more powerful processors.
@@automatic241 eh, he said "-ish", when talking decades, that includes mid to late 2010s. yes, moore's law is dead. if we want to write increasingly complex AI, we can no longer fall back on the exponential growth in processing power like we used to. we have to write clean code, which is what code architecture is all about.
They actually keep getting more and more powerful, not exactly "exponentially", but significantly in fact. At the moment we are limited by lithography, stability and inevitably by silicon, but as new technologies are developed (like the one you were studying, of using photons to build processors) we will have a gain in processing power. The speed limit we have in our universe is literally how many operations we can do simultaneously close enough to the speed of light threshold.
can someone explain what should be in Attack class?
is it correct?
class Attack {
int minDamage;
int maxDamage;
Hero hero;
hit(Actor target) {
...
}
}
@Jeremy Russell Couldn't you just make a function out of it though? Wouldn't that be easier rather than having to think of instances etc. ?
@@fergal9808 Well sure you could. You could wrap all behaviours into a static class or a normal function. But then you would have to feed in all the details you need as parameters--which adds complexity because you can now mess up calling the action correctly. You might solve that by passing in the Actor & Target as parameters and have the function sort it all out from there, but now the action functions just became a lot more bloated: do you have nested functions to extract the relevant info from the objects? Do you always have a target? How do you deal with multiple optional targets? How easy is it to add a second type of attack that for whatever reason needs to be handled differently--ranged or touch attacks for example.
I'm sure you can think of solutions to these 'problems' I mention, but that is the whole point of this talk: solve problems we run into while developing games. You'll notice Bob uses very soft language when talking about patterns. There really isn't "wrong" and "right" so much as "this is useful" and "this leads to migraines".
which programming language is this ? i didnt understand it it looks like c# but it is not c#
I think it's Dart.
gpu.doitall(defer), cpu only manages household
gigabyte caches
why did you go into latency main ram? sdram in gigabytes, sdr
you can always raid the sdram sdr blocks to get quad data rates over bandwidth
external l3 cache, same speed
This is not ECS. Components should not have any behavior.
That's the problem with paradigms - ECS means 20 different things at this point.
He mentioned this is OOP through composition (12:47). Components aren't exclusive to ECS (and there's many variations of ECS as well).
stop talking about Monster and Breed classes in the same sentence. Some people here have watched japanese animated movie art and know where this is going.
my monster comes with a BreedAction object built in which enables uhh
you know ;)
@@Kavukamari ( ͡° ͜ʖ ͡°)
But this is literally an ECS.
which is literally just oop
My takeaway is that his point wasn't to throw ECS out the window but to organize your components around their gameplay mechanisms rather than technical domains.
Nah, it's very much OOP, and very little ECS. There's a whole spectrum of ECSs, but ECS is actually a data driven paradigm, where components contain exclusively data -- no functions, that's what the systems are for -- and the entity is either just an ethereal ID that components are bound to, or an object with just an id and a component list, or something of that sort. What he's doing there is very much OOP, but, like he mentioned, it favors composition rather than inheritance, which is usually said to be a good practice.
_Entity Component System_ doesn't mean _"a system of components and entities",_ it means _"a paradigm involving entities, components and systems"._ I would argue systems would've been better named as _"processes",_ but...
It's really not an ECS, even his example in the beginning misses the point of an ECS since it's still based on entities carrying their own behaviour and updating themselves.
The fundamental point of an ECS is to be data driven with systems consuming components and, crucially, specific combinations of components for crosscutting concerns - not just slightly change way you loop through composition objects. With that approach using an ECS would suddenly feel a lot more natural for a roguelike.
as in "if the only tool you have is a hammer( ..err ECS), then you see all problems as a nail"?
using classes for a rogue game...
You can make undo by just remembering the whole state=) Much more memory, but don't need to make each command undoable.
Moore's Law never indicated that CPUs got twice as fast every 18 months, but rather that the number of transistors per area in a chip doubled. Also, Moore's Law is basically dead.
6:45 This is also slow. Having the update in each component isn't good (components should only be data). The code that does the updating should be in the system itself. I've tested it in javascript, not c, c++, or c#. That's up to you.
I can't recall the cause exactly, but I think it has to do with caching the code that's running; so it's similar to the caching issue you talked about, but for the actual code itself. (IIRC)
Update() function in the Component typically means going through a vtable for being virtual, plus function invocation overhead(push/pop stack stuff). An inlined Update() would get rid of the overhead you're talking about, I believe
ecs is like minecraft in real life
You might want to actually look at game code from the 90s. They were doing composition long before you kids thought it was cool. This stuff isnt even remotely as new as you seem to think it is.
90s game devs were way better than most people today.
required viewing
I hope the books arent written with this font
Well... duh...
this doesnt make any sense to me
LMAO he throws shade at a straw man of ECS and then literally reinvents ECS.
"I split out each capability that an item has into a separate class"
"Whether or not you call it 'component' is kind of an interesting question ... this is just the old principle of preferring composition over inheritance"
Wikipedia page for ECS:
*_ECS follows the composition over inheritance principle_* that allows greater flexibility in defining entities where every object in a game's scene is an entity... Every entity consists of one or more components which contains data or state.
He didn't, he is talking about composition in the world of object-oritentation and OO patterns.
ECS is data-oriented design, without OO patterns, without behaviour attached to data, and when things done in a completely different way than he is showing in his example.
@@lekretka His architecture is a bit different from ECS, but his explanation of ECS was completely wrong. He got the Systems part right, but his god class representation of Entities wasn't even close. In fact, his own Entity-Component relationship is exactly the same as in ECS (though the implementation is usually--but not necessarily--data-oriented).
@@lekretka Alright, so instead of lumping all the procedures for accessing an object's fields, he separates the functions into data objects that are referenced by the first object. That's the Tao of data oriented (functional) programming. He does this again with the Actor class, it just becomes a data class with all the code in Action objects. OOP is about hiding an object's data as private and giving it a bunch member functions. This is doing the opposite, so it's not _really_ OOP paradigm is it? It's at least Procedural, maybe even DOP.
People think ECS is just about data layout and performance, it's just as much about reducing complexity. I'm not saying what he's made is precisely an ECS, more like it's an ECS-lite. All the bits are there in his code, there's just a resistance to dropping the OOP frame of mind in an instance where it is clumsy.
The problem with shitty abstractions (high level programming languages being just one example) is that they cover up and distract you from thinking about stuff that really matters (such as algorithms, data structures, and hardware) in favor of some linguistic fantasy. It doesn't just concern game programming, but programming (manipulating data) in general. Pretending too much that things are something else than they are and sweeping critical issues under the rug leads into performance disasters.
If you want to use high level abstractions and rely on optimizations through tools such as compilers, you still have to understand how these tools (don't) work. Generally speaking, optimizations are only possible when crucial information is not arbitrarily withheld from the optimizer (which also applies to other processes outside of CS). Performance engineering is similar to accounting, you have to keep in mind where the costs/overheads are and what is causing them.