Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Some algorithms are much more easily represented as SQL or that plus a little wrapper code. E.g., somebody re-wrote E-Graphs Good using SQL as their primitives, and that viewpoint made a bunch of other features and optimizations obvious.

Stated somewhat differently, do you want to write the algorithm to do a 3-connected recursive join in linear time, or do you want to slap the join into a DB and move on with your life?

For a concrete example, a DB could make the Entity-Component architecture even simpler to use than it already is (give me all the npcs in this radius who haven't attacked in the last second, have a distance attack, and are facing the right direction).

Would it have performance pitfalls if you weren't careful? Almost certainly. It could be a fun way to structure a game though.



If you know all of your queries ahead of time, then compiling them efficiently has already been shown to be effective.

Noria

https://github.com/mit-pdos/noria

https://www.youtube.com/watch?v=kVv9Pik6QGY

https://thesquareplanet.com/research/

Materialize/TimelyDataflow

https://scholar.google.com/citations?hl=en&user=YYJ3aycAAAAJ...


Oh, sure, the complaint wasn't about SQL per se, but that making complicated things easy to write isn't necessarily a win. Even if a big query perfectly represents the problem, and even if you can use compiled SQL to match hand-written efficiency, it still might not be the optimal way to approach the problem in the first place. If you have experience and plan for that it needn't be bad at all, but I think it's easier to write performance footguns in SQL (the "right" data model is more prescriptive, even with some number of years of experience, and is less likely to be tuned to your actual problems) than with traditional code, so I'd be quite surprised if the majority of game developers (even those with some degree of success currently average <3 YOE) wouldn't run into major performance issues with a SQL-based engine, even a good one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: