Basically is programming against composable interfaces like COM, Objective-C protocols, and anything else like that, but sold in a way that anti-OOP folks kind of find acceptable, while feeling they aren't using that all mumbo jumbo bad OOP stuff some bad Java teachers gave them on high school.

Most of them tend to even ignore books on the matter, like "Component Software: Beyond Object-Oriented Programming." [0], rather using some game studios approach to ECS as the genesis of it all.

[0] - https://openlibrary.org/books/OL3564280M/Component_software

▲

sirwhinesalot 5 days ago | parent [-]

None of that is what people mean by ECS. ECS is a poor man's relational database. Do you think SQL is OOP too?

▲

pjmlp 5 days ago | parent [-]

People without CS background say a lot, like confusing ECS with data oriented design.

▲

sirwhinesalot 4 days ago | parent [-]

I have a PhD in computer science and I'm also able to stop for two seconds and understand what ECS as used by game devs means. It is pointed out in the talk that the design pattern was used in sketchpad of all things and reinvented in 1998. They call that pattern ECS. It is unfortunate the name is overloaded but that doesn't mean that when they say ECS they're referring to the ECS you are and it is somehow a gotcha since that other ECS is still very much OOP.

They are not talking about that ECS.

▲

pjmlp 4 days ago | parent [-]

Then lets sort this out, point an github repo of your choice for a game engine using ECS and lets discuss the implementation from CS point of view regardling programming language features used for the implementation.

Given that both of us have the required CS background should be kind of entertaining.

▲

sirwhinesalot 4 days ago | parent [-]

Sure, the Bevy engine is the one I'm most familiar with:

- An entity is a 64 bit integer wrapped in a struct for typesafety (newtype pattern). This is a primary key.

- A component is a struct that implements the "component" trait. This trait is an implementation detail to support the infrastructure and is not meant to be implemented by the programmer (there is a derive macro). It turns the struct into a SoA variant, registers it into the world object (the "database") plus a bunch of other things. It is a table.

- A query is exactly what it sounds like. You do joins on the components and can filter them and such.

- A system is just code that does a query and does something with the result. It's basically a stored procedure.

It is a relational database.

EDIT: forgot to link the relevant docs: https://docs.rs/bevy/latest/bevy/ecs/component/trait.Compone.... It is really critical to note a programmer is not expected to implement the methods in this trait. Programmers are only supposed to mark their structs with the derive macro that fills in the implementation. The trait is used purely at compile time (like a c++ template).

There's also flecs which doesn't rely on OOP-ish traits in its implementation: https://www.flecs.dev/flecs/

Either way, it doesn't matter if OOP is used in the implementation of an ECS, just as it doesn't matter if MySQL uses classes and objects to implement SQL.

	▲	4 days ago \| parent [-]
		[deleted]