Less lines of code than vanilla C while abusing query planning as a state machine is peak engineering malpractice. I love it.

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.

I want to point out that they set up an EU and US multiplayer server! Nice touch.

Meanwhile I'm too inept to get WordPress to load dynamic content faster than molasses.

This should be illegal :)))) Wow!

Nice piece of advertisement. Kind of hard to stand out in the world of SQL dbs. That definitely raised eyebrows.

> 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!

Nice

Thats ridiculous I love it. The visual in the bottom right it a great illustration.

(This has been posted numerous times but none of them made the front page. I've made a new copy of the earliest one that got comments.)