> I was surprised how easy it is to express pretty complicated game logic in SQL. The game logic is just ~5900 lines of SQL.
I still think HN is taking major naps on the capabilities of contemporary SQL.
There are businesses so complicated that maintaining procedural code over the domain is largely infeasible. Implementing business rules in SQL can decompose the problem in ways that allow for a lot more people to interact with it at the same time.
When I was working in semiconductor manufacturing, we relied very heavily on stored procedures and SQL to operate the factory. Very little operational decision logic existed in code. We had hundreds of users who were inspecting and proposing changes to the same set of procedures. Testing this stuff was trivial because we replicated the prod DB every morning and experimented against live data directly. There was no gap between the information of the business and its logic. Most shops are not ran this way. They treat the database like some CRUD retrieval engine instead of the nexus of both the data and logic.
When people advocate for spending big piles of money with Microsoft, Oracle and IBM, they are generally going for something like the above. They want literally one system the business operates inside of. Spreading a solution across 10+ vendors and tools when you could do with one is borderline negligence depending on your role in the organization.
Yes, this is fantastic! I'm trying it right now. I look forward to the day when LLM inferencing can be done in a sql query and take less than the age of the earth to do something. This works way better than I would have expected, since, well, it's sql all the way down.
I noticed the cedardb.com blogpost on the project is slashdotted at the moment, but the game itself plays just fine.
Off topic, but say you have a program that needs to calculate something but takes a long long time, how to counter hardware failure without needing to calculate everything from the start?
The game state being a SQL table just kinda triggered a memory of a year of optimization for me. One thing I'm still unsure of being a good decision or a bad one, when I wrote my casino in 2010, was having every remote call update game states on SQL tables that were used as the source of truth. With multiple players you can imagine that there would sometimes be issues. Some of the deadlock problems early on were horrific; scaling was a nightmare. But everything was atomic. No risk of lost data beyond one turn not reaching the server or deadlocking, nothing like a huge nodejs process choking on everyone's calls at the same time, or losing its memory. You always had state.
Looking back it seems like not a terrible design pattern for multiplayer turn-based games, if you can work out the kinks. Atomicity guarantees at least that there is a consistent state that won't get lost. Doing that read/write loop for an action game? Pure folly, but it's pretty funny to me.
There is a whole chapter in Designing Data Intensive Applications dedicated specifically to handling atomic transaction concurrency issues while avoiding the performance trade-off you're describing here, you will definitely find it interesting.
I was actually just recently looking if there is a self-hostable alternative to a HTAP system like TiDB + TiFlash with a Postgres-compatible syntax, but LLMs didn't really pick up on CedarDB yet. These guys know game.
> The game logic is just ~5900 lines of SQL. While this sounds a lot, it’s definitely less than the original C source code which does the same in about 9000 lines!
I still think HN is taking major naps on the capabilities of contemporary SQL.
There are businesses so complicated that maintaining procedural code over the domain is largely infeasible. Implementing business rules in SQL can decompose the problem in ways that allow for a lot more people to interact with it at the same time.
When I was working in semiconductor manufacturing, we relied very heavily on stored procedures and SQL to operate the factory. Very little operational decision logic existed in code. We had hundreds of users who were inspecting and proposing changes to the same set of procedures. Testing this stuff was trivial because we replicated the prod DB every morning and experimented against live data directly. There was no gap between the information of the business and its logic. Most shops are not ran this way. They treat the database like some CRUD retrieval engine instead of the nexus of both the data and logic.
When people advocate for spending big piles of money with Microsoft, Oracle and IBM, they are generally going for something like the above. They want literally one system the business operates inside of. Spreading a solution across 10+ vendors and tools when you could do with one is borderline negligence depending on your role in the organization.
> very little operational decision logic existed in code
I'm curious, what do you think SQL is if not...code?
I noticed the cedardb.com blogpost on the project is slashdotted at the moment, but the game itself plays just fine.
Looking back it seems like not a terrible design pattern for multiplayer turn-based games, if you can work out the kinks. Atomicity guarantees at least that there is a consistent state that won't get lost. Doing that read/write loop for an action game? Pure folly, but it's pretty funny to me.
https://www.oreilly.com/library/view/designing-data-intensiv...
Nice