Bob Nystrom - Is There More to Game Architecture than ECS?
Roguelike Celebration3 HN recommenders · 2020–2026
301K views · talk · evergreen · Uploaded 2018-10-09
Bob Nystrom, author of Game Programming Patterns, gives a Roguelike Celebration 2018 talk questioning whether entity component systems are the only way to structure a game. He walks through alternative architectures drawn from roguelike development.
HN commenters cite it as a level-headed counterpoint to ECS zealotry and a good intro to game architecture beyond ECS.
38:47RailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
25:06"Making Impossible States Impossible" by Richard Feldman
elm-conf
1:00:19How To Design A Good API and Why it Matters
Google TechTalks
31:44The Value of Values with Rich Hickey
InfoQ
1:04:04Overwatch Gameplay Architecture and Netcode
GDC Festival of Gaming
1:02:26Solving Problems the Clojure Way - Rafal Dittwald
Clojure/north
1:12:56Lecture 1A: Overview and Introduction to Lisp
MIT OpenCourseWare
7 comments from Hacker News
This is known and heavily used by the game industry for a long time now. Ultimately it comes down to data locality and there's no silver bullet. Performance varies with your data access pattern and code must be adapted to keep caches as warm as possible. There are also maintainability trade-offs. In general I'd advise this kind of optimization only for performance-critical code like games. For more information on how game development approaches this, read about Entity Component Systems. Here's a good start: [VIDEO]
Isn’t there a ton of prior art? I’ve seen tech talks about ecs implementations for years. From the top of my head, here’s a great tech talk about overwatch. [LINK] Here’s a tech talk by Bob Nystrom (the game programming patterns guy) that mentions ecs from years ago [VIDEO] Edit: letsInvalid in another thread above linked to an article from 2013: [LINK]
I can't help but be heavily skeptical of approaches to a (traditional) roguelike that use ECS. The idea is very entrenched in the rust gamedev community, but for a turn based tile based game there's extremely little benefit and a lot of added complexity. Bob Nystrom has an excellent talk on roguelike architecture [0] and rust as a language itself doesn't prevent any of these approaches. If anything, the existence of sum types as enums make many of them all the more powerful. [0]: [VIDEO]
I've also seen a few game devs saying ECS are useless in quite a few situations (or, at least, a very zealous adherence to ECS). I guess it's one of those things that you don't know until you try (and hit the limits of using or not-using one). I'm also reminded of Robert Nystrom's "Is There More to Game Architecture Than ECS": [VIDEO] (Yes, Robert Nystrom of Game Programming Patterns and Crafting Interpreters )
Since engine is targetting pixel art, isn't ECS a bit of an overkill...? And yes, technically artstyle has nothing to do with game architecture. But in practice, most games of this style are pretty small, and thus don't really have any real performance requirements, so ecs'ing everything is overengineering compared to oop-style, coupled architecture, no? Also related: [VIDEO]
The crossover of language design/implementation and game development made me assume this was either a Jonathon Blow (Jai, Braid, The Witness) or Bob Nystrom project (Game Programming Patterns, Crafting Interpreters, 'Is There More to Game Architecture than ECS?' [1]). Either way, given the time constraints and requirements I'm expecting a lot of text adventures and rogue-likes. [1] [VIDEO]
I'd say don't immediately go into making an ECS and don't sweat about perf too much. You can totally do this in any programming language. This is a good talk about roguelike software design in general: [VIDEO] Tbh the whole channel is a gold mine of inspiration. Also check: [LINK]