Hacker News Reader

This is the essence of MVC/MVP architecture!

When I first tried to learn ECS (recently!), I couldn't wrap my mind around how arcane it seemed to be. What "components" should there be? What properties should each Component track? How do I organize it? What if I move things around? I have to write handlers that load and unload the damn things, and a System that somehow knows where to find certain properties on the various Components enough to operate on them? Examples were always pretty esoteric or contrived. Didn't help that they were all written in C++.

One day it clicked that this revolutionary idea sure looks a lot like a series of queries/views ("Systems") on a bunch of database tables ("Components") foreign-keyed to a single object ID ("Entities").

Some people can overcomplicate anything...

I once wrote an ECS for a game and it was literally a database without WHERE clauses (write your own if statements, indexes are too expensive). Each component was a table and your systems used left joins or inner joins to query the tables. The join algorithm was quite simple as well. Just a binary search to find the next element by its ID.

When you reinvent the wheel you can't call it the wheel or people will know it isn't new. 'Entity component' makes no sense for being a kind of spreadsheet, but at the very least it is a good approach to the problem. It should have been called 'state tables' or something like that.

On the other hand gears, wheels, and fans are all wheels.

Reply on news.ycombinator.com