It is high risk, but I think a risk worth taking.

What's your reasoning behind this? Just being able to run the same code on frontend and backend?

That's not a judgment on SpacetimeDB, but it is kinda how it plays out with these kinds of things.

"Phew! I've just finished coding all the complex lag masking netcode myself, you know what I really need next? An in-memory SQL-like database to store my world state!"

I'm Tyler (guy in the video). In BitCraft we currently implement client-side prediction outside of SpacetimeDB.

However, we DO plan to add automatic client-side prediction as a feature for SpacetimeDB in the near-ish future! Because all your server-side logic is in Wasm modules, we plan to run an embedded version of SpacetimeDB to execute the server logic on the client. As long as the server and client agree on the changes to the data we can reconcile the transactions, otherwise we'll rollback. Notably, we can do this with only partial state on the client!

We can also do deterministic simulation if you have total knowledge of the game state with this solution as well.

I have no idea why. I was hired to work on very early versions of it, and left very early on in part because I wanted nothing to do with that angle. IMO it's a liability.

The problem is that the proof is in the pudding. Some of their claims feel outlandish. Imagine writing your game with SQL queries. Rather than crafting update packets that only contain relevant game info you just do `select * from players where abs(player.x - current_player.x) + abs(player.y - current_player.y) + abs(player.z - current_player.z) < 100^2` and it just updates automagically 60 times a second.

Running physics sim in SQL stored functions sounds insane but that's exactly what they're advertising. They say it's due to in-mem DB optimization but I'm not sure how they horizontally scale that (they allow you to run standalone but any scaling requires their cloud product)

There is a pretty big underlap between these problems, and the ones solved by SpacetimeDB. So much so that if you built a system using both SpacetimeDB and another, high-level tool to manage chunking, transitioning, server provisioning etc. it would obviously be the latter system that was more indispensable to scaling your MMO.

Game physics involves a lot of things (solvers, collision detection, numerical stability, etc.). I am skeptical of their claims of being able to run physics in what I understand are stored procedures for their database.

I looked at their docs for physics https://spacetimedb.com/docs/unity/part-4 where they demonstrate the simplest form of collision check (sphere overlap). I fail to see how that is an improvement or speedup over existing methods. Some quotes: "This may not be the most efficient way to do collision checking (building a quad tree or doing spatial hashing might be better), but SpacetimeDB is very fast so for this number of entities it'll be a breeze for SpacetimeDB." >> Nothing is quantified with numbers.

"For every circle, we look at all other entities." >> This is the most inefficient N^2 way you could do collision detection.

And not to mention networked physics is a whole additional layer of complexity, where you have to use some form of prediction techniques and very likely end up changing your core physics code to accommodate this.

All of this suggests to me much thought has not been put into the claim "you can also do physics with it!" and its implications. Perhaps it is enough for extremely simple physics, as demonstrated with their demo game. If the author is reading this, I suggest spending some time understanding what this claim implies and qualifying it better.

However I must mention that I applaud their courage to try something so outlandish. If you truly believe your claims are possible, I encourage you to keep working on it.

But I'll be convinced when extraordinary evidence backs extraordinary claims.

Source: I work on a commercial game physics engine and related netcode.

From my past consulting experience though, the distributed systems side of games is all over the place. Designs tend to need to be customized for each games needs, which usually directly influences which technologies are chosen.

You mention it runs in process? How does this occur? You mention running cached in memory tables. So you're caching on at the application level, not the storage level?

There's a few things with the video I find misleading. You mention 400ms at best to parse, plan and execute a query; That's not true, what about the type of query, etc.

Overall I can see it's still early, which is ok. I will review the code and see what else I can find.