3 ms·

It's interesting to see the convergence between ECS (primarily game engine) and RDBMS. "AoS" ~ tables "systems" ~ queries "handles" ~ primary keys Makes me

It's interesting to see the convergence between ECS (primarily game engine) and RDBMS. "AoS" ~ tables "systems" ~ queries "handles" ~ primary keys Makes me wonder if you could architect a "RDBMS" that is fast enough to be used as the core of a game engine but also robust enough for enterprise applications. Or are there too many tradeoffs to be made there.

bitwize 3y ago
IBM was, for a while, in the business of selling "gameframes" -- mainframe systems that performed updates fast enough to run a MMO game. They used Cell processors to provide the extra needed compute, but it was the mainframe I/O throughput that allowed them to serve a large number of players. It was backed by IBM DB2 for a database, but it's entirely likely the game updates were performed in memory and only periodically committed to the database. Since, as you say, ECS entity components closely resemble RDBMS tables, this could be accomplished quickly and easily with low "impedance mismatch" compared to an OO game system. https://en.wikipedia.org/wiki/Gameframe https://en.wikipedia.org/wiki/Gameframe Back on Slashdot there was a guy called Tablizer who advocated "table-oriented programming" instead of OOP. The rise of ECS means that when it comes to gamedev, TOP is winning. Tablizer might be surprised and delighted by that.
syntheweave 3y ago
Essentially all a game engine is are these things: * A tuned database for mostly-static, repurposable data * I/O functions * Compilation methods for assets at various key points(initial load, levels of detail, rendering algorithm) * Constraint solvers tuned for various subsystems(physics, pathfinding, planning). A lot of what drives up the database complexity for a game is the desire to have large quantities of homogenous things in some contexts(particles, lights, etc.) and fewer but carefully indexed things in others(mapping players to their connections in an online game). If you approach it relationally you kill your latency right away through all the indirection, and your scaling constraint is the worst case - if the scene is running maxed-out with data it should do so with minimal latency. So game engines tend to end up with relatively flat, easily iterated indexes, a bit of duplication, and homogenization through componentized architecture. And that can be pushed really far with static optimization to describe every entity in terms of carefully packed data structures, but you have to have a story for making the editing environment usable as well, which has led to runtime shenanigans involving "patching" existing structures with new fields, and misguided attempts to globally optimize compilation processes with every edit[0]. Godot's architecture is a good example of how you can relax the performance a little bit and get a lot of usability back: it has a scene hierarchy, and an address system which lets you describe relationships in hierarchical terms. The hierarchy flattens out to its components for iteration purposes when subsystems are running, but to actually describe what you're doing with the scene, having a tree is a godsend, and accommodates just about everything short of the outer-join type cases. [0] https://www.youtube.com/watch?v=7KXVox0-7lU https://www.youtube.com/watch?v=7KXVox0-7lU

bitwize 3y ago

IBM was, for a while, in the business of selling "gameframes" -- mainframe systems that performed updates fast enough to run a MMO game. They used Cell processors to provide the extra needed compute, but it was the mainframe I/O throughput that allowed them to serve a large number of players. It was backed by IBM DB2 for a database, but it's entirely likely the game updates were performed in memory and only periodically committed to the database. Since, as you say, ECS entity components closely resemble RDBMS tables, this could be accomplished quickly and easily with low "impedance mismatch" compared to an OO game system. https://en.wikipedia.org/wiki/Gameframe https://en.wikipedia.org/wiki/Gameframe Back on Slashdot there was a guy called Tablizer who advocated "table-oriented programming" instead of OOP. The rise of ECS means that when it comes to gamedev, TOP is winning. Tablizer might be surprised and delighted by that.

syntheweave 3y ago

Essentially all a game engine is are these things: * A tuned database for mostly-static, repurposable data * I/O functions * Compilation methods for assets at various key points(initial load, levels of detail, rendering algorithm) * Constraint solvers tuned for various subsystems(physics, pathfinding, planning). A lot of what drives up the database complexity for a game is the desire to have large quantities of homogenous things in some contexts(particles, lights, etc.) and fewer but carefully indexed things in others(mapping players to their connections in an online game). If you approach it relationally you kill your latency right away through all the indirection, and your scaling constraint is the worst case - if the scene is running maxed-out with data it should do so with minimal latency. So game engines tend to end up with relatively flat, easily iterated indexes, a bit of duplication, and homogenization through componentized architecture. And that can be pushed really far with static optimization to describe every entity in terms of carefully packed data structures, but you have to have a story for making the editing environment usable as well, which has led to runtime shenanigans involving "patching" existing structures with new fields, and misguided attempts to globally optimize compilation processes with every edit[0]. Godot's architecture is a good example of how you can relax the performance a little bit and get a lot of usability back: it has a scene hierarchy, and an address system which lets you describe relationships in hierarchical terms. The hierarchy flattens out to its components for iteration purposes when subsystems are running, but to actually describe what you're doing with the scene, having a tree is a godsend, and accommodates just about everything short of the outer-join type cases. [0] https://www.youtube.com/watch?v=7KXVox0-7lU https://www.youtube.com/watch?v=7KXVox0-7lU