[BobbyJo]

> Focusing on a _code_ design pattern is the antithesis of _data_-oriented design

Doesn't the former enable the latter? Ideally, language (both human and machine) would have the semantics needed to represent all transforms, but that's not the case. Code you rely on, since none of it is written in isolation, needs to enable you to implement data-oriented design should you so choose.

Also, I don't think pointing out that 'all games are essentially...' is particularly useful. It's true, no question, but that doesn't mean it's the most useful mental model for people to use when developing software. Our job as engineers is to make software that functions according to some set of desires, and those desires may directly conflict with approaching an optimal transform.

[jeremycw]

> Doesn't the former enable the latter?

Not necessarily. ECS is a local maxima when developing a general purpose game engine. Since it's general purpose it can do nothing more than provide a lowest common denominator interface that can be used to make any game. If you are building a game from scratch why would you limit yourself to a lowest common denominator interface when there's no need? Just write the exact concrete code that needs to be there to solve the problem.

> Our job as engineers is to make software that functions according to some set of desires, and those desires may directly conflict with approaching an optimal transform.

All runtime desires of the software must be encoded in the transform. So no software functionality should get in the way of approaching the optimal transform. What does get in the way of approaching the optimal transform is code organization, architecture and abstraction that is non-essential to performing the transform.

[BrS96bVxXBLzf5B]

> Just write the exact concrete code that needs to be there to solve the problem.

Good luck with that when the exact code to solve the problem is not the exact code the next week, because the problem has changed or evolved.

Not to suggest an ECS is the answer, but this line of thinking is reductive to the realities of creating a piece of art. It's not a spec you can draw a diagram for and trust will be basically the same. It's a creature you discover, revealing more of itself over time. The popularity of the ECS is because it provides accessible composition. It's not the only way of composing data but being able to say "AddX", "RemoveX" without the implementation details of what struct holds what data and what groupings might matter is what makes it appealing.

[meheleventyone]

I think there’s two orthogonal things being conflated by you. Flexibility of a solution and how general the solution is.

What you’re basically saying is a solution should be flexible to change because making a game requires trial and error. I totally agree with that.

Using a general solution is one path to flexibility but it does come with a cost associated. It’s flexibility built on a tower of complexity and if you look at a modern ECS implementation that is performant it’s actually quite a lot of complexity. You’re also reducing flexibility in the sense that these sort of solutions generally have preferred patterns you need to fit your game design into. So you end up introducing a learning, maintainance and conceptual burden into the project you might not need.

OTOH if you have a specific problem you can write a specific solution for you will end up with less code, hopefully in a conceptually coherent form. That in itself offers flexibility. Simple code you can easily replace is often more flexible than complex code you need to coax into a new form.

The key is to recognise whether your problem is specific or general you need flexibility.

These architectural patterns are fun to argue over and obsessed over by armchair game developers but are a trap if you’re trying to make a game rather than a general purpose game engine.

Which isn’t to say you don’t want some framework underlying things for all sorts of mundane reasons. But most games could get away with that being an entity type that gets specialised rather than anything more complex.

[BrS96bVxXBLzf5B]

> I think there’s two orthogonal things being conflated by you. > It’s flexibility built on a tower of complexity

Agreed with the 'flexibility on a tower of complexity', 100%! :) was trying to not appear too dogmatic by describing is as 'accessible composition'; generally any solution that is 'accessible' is also broad enough that it has as many flaws as benefits, and an ECS definitely isn't an exception.

> These architectural patterns are fun to argue over and obsessed over by armchair game developers but are a trap if you’re trying to make a game rather than a general purpose game engine.

Again, agreed. Speaking from experience as an iterator and rapid prototyper who has used an ECS for years, and has been bitten by the complexity but hasn't been able to beat the flexibility of being able to just write something like `entity->Add<ScaleAnimation>(...)`, `entity->Add<DestroyAfter>(...)`, `entity->Add<Autotranslate>(...)`, `entity->Add<Sprite>(...)` to be quickly and easily create a thing that looks nice, pops in smoothly, moves effortlessly, destroys itself thoughlessly. It lets you move between ideas quickly and then you can pivot to addressing concerns if any show up.

[meheleventyone]

Yeah for sure, I love a good composable approach to entity creation as well particularly when it’s specified in data rather than code. The basic framework for getting that going is extremely lightweight which is fantastic.

[BobbyJo]

> If you are building a game from scratch why would you limit yourself to a lowest common denominator interface when there's no need?

There is a need: the limits of the human mind. Nobody can model an entire (worthwhile) game in their head, so unless you plan on recursively rewriting the entire program as each new new oversight pops up, you aren't going to get anywhere near optimal anyway.

[debaserab2]

> If you are building a game from scratch why would you limit yourself to a lowest common denominator interface when there's no need? Just write the exact concrete code that needs to be there to solve the problem.

Coming from the realm of someone who has mostly swam in the OO pool their career, I struggle understanding how a concrete implementation of something like a video game wouldn't spiral out of control quickly without significant organization and some amount of abstraction overhead. That said, I have found ECS type systems be so general purpose that you end up doing a lot of things to please the ECS design itself than you do focusing on the implementation.

Do you have any examples of games and/or code that are written in more of a data oriented way? I'd really love to learn more about this approach.

[jeremycw]

While stylistically I don't necessarily agree with him all the time, Casey Muratori's Handmade Hero (https://handmadehero.org/) is probably the most complete resource in terms of videos and access to source code as far as an 'example' goes.

[debaserab2]

Thank you!

[throwaway17_17]

The archetypal ’talk’ on Data Oriented Design (in the way GP is talking about it) is Mike Acton’s 2014 CPPCon keynote.

[1] https://www.youtube.com/watch?v=rX0ItVEVjHc

[debaserab2]

Thanks!