What Game Engines Know About Data That Databases Forgot

This seems cool but man it's hard to get over the very, very obvious AI writing.

Serious question:

If you take a BDD/TDD approach - do technologies like this still give you something?

I've dabbled a bit into smth similar (SpacetimeDB) with the aim of creating a headless backend for a game.

But then I realized that I'd still need to define the interface that I was testing in the traditional software layer and that all the nice DB magic seemed worthless since I'd still have to orchestrate traditionally.

(In short: No matter how nice your DB magic is, you will still hide it away in the basement/engine room, right?)

Or in a more general sense: Get your code as close as you can to your data

>Cache locality by default. In a traditional row store, reading all player positions means loading entire rows — names, inventories, health, everything. Most of those bytes are wasted.

Not one mention of column stores? This didn't come from ECS...

https://en.wikipedia.org/wiki/Data_orientation

interesting! foundationdb was created after the team was going to build a massively multiplayer game and couldn't find a database that could support it...

When I learned about ECS, I realized that Tablizer (old Slashdot guy who insisted that OOP was a dead end and "table oriented programming" as was done in FoxPro was the way to go) was probably right. Using an ECS for my Android game was a bit more cumbersome, but paid for itself many times over with the ability to create new kinds of entities, implement familiar behaviors for them, and add new ones without code copypasta or inheritance tree entanglement.

I'm getting fatigued out by "I had a conversation with a chatbot, here's the output" blog posts.