Bob Nystrom - Is There More to Game Architecture than ECS?

[DrunkGeko]

That weird moment when you click on a random game dev talk and you discover you already have the book

[skaruts]

_"I worked for EA for eight years, so I have experience being trapped in dungeons for a long time."_
lol brilliant. :)

[PinikRahman]

I dont remember seeing a better presentation slide in my life.

[KarlSchmidtDev]

Other side benefits of separating out "actions" is you can serialize them for replay systems, multiplayer, offline simulation - lots of stuff!

[NikolaiKojevnikov]

this is the single most useful game presentation talk I have ever watched.

[sh]

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.

[darkivn]

Robert is amazing on many levels, wish he's do more public appearances and talks.

[DavidPD]

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.

[storerestore]

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.

[ArthurCousseau]

Roguelikes are so amazing to program. They teach you so many things.

[daelenkelly]

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! :)

[mr-boo]

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.

[SolidAir]

@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.

[carsonskjerdal]

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 :)

[iamatwork]

Loved the talk. Incredible. So weird I only found this after 5 years! Learned a lot. Thank you!

[Neightr]

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.

[lionelt.]

The man, the myth, and the e-book. It's mentioned and suggested a surprising amount online.

[dukkhan]

Hey, I know this guy, I read his book. Highly recommended. Humorous and smooth read while dense with enlightening info

[cem.ugur.karacam]

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.

[csudab]

A fantastic talk. If you are like me back here to review the patterns, that starts at 10:30