SpacetimeDB

> SpacetimeDB fits into a genre of tech that I want to call "universe brain reorgs" - structural re-arrangements that might unlock wild performance increases. The challenge with these is that they require devs to re-align their thinking and it's hard to disentangle if "the problem" is that the technology isn't being fully embraced or if the promises of the tech don't work for your use case.

And this is exactly why as a professional multiplayer game developer I'm quite concerned about SpacetimeDB.

If you're a game developer and choose to use it, you must accept that you will completely structurally re-arrange your game server, and gameplay and simulation code in such a way that you'll conform to a database structure and programming model developed by some people who are currently making their first game.

I'd be surprised if any professional game developers would consider this a good idea. The last time somebody suggested such a significant refactor for game servers, was when the two cofounders of Improbable walked into our office at Respawn, shortly after we shipped Titanfall 1, and told us they wanted the complete source code for Titanfall 1, and they would show us how awesome Improbable is, by porting the entire Titanfall codebase to Improbable in just a few months!

They ended up getting the source code, despite all programmers and the technical director advising the COO against it... and we never heard from them again.

We are definitely inspired by Elixir/BEAM. IMC (inter-module communication) is directly inspired by it.

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

> Node

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

I feel like a lot of the "needs visionaries?, stuff has a pretty high chance of having not much real value.

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

It's a database that emphasizes stored procedures. And if you need it to distribute computing, it has the same challenges as the eliminated "game servers".

In addition, outside of single table updates and selects, SQL has scaling limits. If you throw the computation at the db server as well, you limit the vertical scaling.

Gaming and gamers are used to sharding (and geographic tower of babel us an implicit shard as well).

[dead]

Just put it all in stored procedures. What could go wrong?

Forgive my ignorance, but why would you implement physics and animations on the server? I feel like you can get away with basic positional data and do the rest of that on the clients.

There was a lot of crypto-adjacent talk in earlier versions of their marketing and product design. Without it actually being anything actually crypto-adjacent. Analogies drawn to ethereum etc concepts, I guess because they figured somehow there was an audience that would get those references and it would allow them to understand the product better?

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.

I feel like they've been inspired by crypto for the way they handle billing. They sell you "Energy" which you use by running on their infra. Seems like a needless abstraction to me.

Not a developer affiliated with the project. But here's my take:

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)

Given the name I was also expecting some clever SQL-like data structure/query for fast spatial lookup but I digress.

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.

It's a cool technology, but the hard thing about building an MMO is architecture, not just making the server faster / wider. If you want a good overview of the types of problems to be solved in scaling an MMO, check out https://youtu.be/-c4t3Y5l5jY.

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.

As a game dev I don't really see what problems this solves. Most of the work you would have in games is related to simulation - something this doesn't help you with at all. It can actually make simulation more difficult because all your state would be decoupled from a game engine (which is built for simulation). So you'd end up having game servers running the simulation syncing to SpacetimeDB... or of course you try to build the simulation inside SpacetimeDB with no help from it.

Professional multiplayer game developer here. I wonder what multiplayer games the SpacetimeDB folks have actually shipped?

Same! The algorithm thinks I needed to watch this.

This sounds like a fundamental disagreement with using ORM. Are you advocating for always writing queries (not excluding the possibility of a query builder) over treating database rows as application-side entities that can have CRUD operations performed on them / persisted?

Haha, yes very suspiciously fast!

Assuming you're referring to the backend side of things for online/multiplayer games, working through the Hathora tutorials in the docs can be a good first introduction to general idioms related to backend systems architecture: https://docs.hathora.dev/#/builder/

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.

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.