4 ms·
> like treating your game state like a normalized database This makes me curious, how bad would it be to actually store game state in say, an in-memory sqlite
by infogulch 8y ago
> like treating your game state like a normalized database
This makes me curious, how bad would it be to actually store game state in say, an in-memory sqlite database? I feel like this could get you some nice things, like auto-destroying all components of an entity via foreign key deletion, being able to merge/join entities with the intersection of multiple components etc. Assuming the clunkiness of interacting with sqlite is abstracted away, I wonder what the real performance differences would be.
- reificator 8y agoI've wondered that as well. My gut feeling is that when crossing the SQL boundary you would lose a lot of the performance you would otherwise be gaining from using an ECS to begin with. Especially when talking to the GPU. I'd love to be proven wrong if someone has the time though.
- imtringued 8y agoCompared to iterating over an array of structs (or a struct of arrays if you want to be fancy) it's probably multiple orders of magnitude slower. And lets be honest, half of my performance problems in webapps are caused by the overhead of sending a query, the database is rarely bottlenecked by inserting or updating the data on the physical storage device if I do not use bulk insert or bulk update methods.
- setr 8y agoI assume you mean sending a query over the network, as most webapps do; sending it to a local sqlite file should be far less impactful.
- reificator 8y agoBut still not free. Please try it out though, I would love to see a proof of concept that took the ECS-as-database approach. Like I said earlier in the thread I expect it would not do well, but I'd be interested to see the results either way.