SpacetimeDB
spacetimedb.com
spacetimedb.com
Other techs in this category have seen a lot of success. I'd classify Elixir and Node as being similar in that you adopt a stack to get access to some rare guarantees and also accept new or exotic limits.
I think these things tend to rely on having clear-eyed visionaries out in front, able to show off their strengths in open source. Without a successful project it's hard to believe the claims. I hope clockwork labs is able to deliver their example game (it seems high risk because, even if the game is a technical wonder - what if it isn't fun?!).
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?
Node supports realtime applications? Really? Isn't it garbage collected? Or does the term mean something different in nodejs? I've only come to know the term in the context of time guarantees (i.e. if it's scheduled to run in x, it is guaranteed to run at that time) and that shouldn't apply to nodejs I think? When you schedule something there, I believe it'll run on the first free thread after the timer relapsed - which entirely depends on the load of the system
Real-time in this context is more like real-time communication rather than process scheduling.
That said, real-time communication _is_ a soft real-time system.
Basically like 24 FPS or higher is real-time. Even that'd be laggy for a game but not unplayable. I choose this specifically because that's what movies typically use and they're very watchable.
Hard real time (or just "real time" in firmware/hardware contexts) is effectively a term of art. One that's been increasingly watered down by the rest of the industry.
Strict definitions matter when system failure == pacemaker missing a beat or train signalling system drives a freight train into the back of 400 passengers.
Context matters.
they are vibe coding since the beginning.
I worked on telco grade systems running on Rhino, in interpreted mode, in 2006. Leveraging Java to JS bindings. Responding to HTTP/JMS/etc.
[1] https://stackoverflow.com/questions/17959663/why-is-node-js-...
That's not a judgment on SpacetimeDB, but it is kinda how it plays out with these kinds of things.
I've been making multiplayer games professionally for twenty years from fast-paced shooters to spaceship MMOs and to me this isn't really crazy. If you wanted to make a comparison it's like having SQLite in memory but with the added infrastructure to support networking to clients and persisting state to disk. Obviously there is more work involved than that but conceptually thats where things are at. How nice it is to actually develop a game with is a pretty open question, and almost certainly the most important one when evaluating this sort of product, but you'd be surprised at the range of stacks in existence.
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).
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.
If you are trying to build a new MMO that scales to the moon, you might want to take a look at how the existing market goes about things.
Take World of Warcraft for example. You could probably put a $20 MySQL VPS behind a realm and have it reliably persist state with how authoritative and infrequently updated the clients are.
Being clever with what you can trust the client with and how the server reconciles events is where I think you will find most of the scaling hacks.
I did hit a personal bias: when I saw "maincloud" as a phrase to do with pricing my heart sank because my brain went "they've wedged in some crypto shit!". Turns out no, it's just a naming thing for hosting credits.
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.
Kind of sad that people can't see past that, but I also understand. It is what it is.
You may recall I was partial to the term "verb" :-)
"mutation" may also have been a good choice?
[0] https://github.com/ClockworkLabs/SpacetimeDB?tab=License-1-o...
Are there any game devs here who can comment on how useful this actually is? The pitch seems pretty cool but I can't tell how much of it is just good marketing.
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)
For BitCraft we scale it with IMC (inter-module communication). It works very similarly to Elixir.
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.
Seems to have paid off for them: https://play.google.com/store/apps/details?id=com.lightfoxga...
Does not feel like it paid off for them. But SpacetimeDB might of course not be the reason for that.
1. Server <> client sync is handled for you 2. Server <> database sync is eliminated 3. Deployment is super easy because you just upload your wasm module to the database, and SpacetimeDB schedules it (similar to Kubernetes honestly, but at a different level of the stack)
Getting rid of a game engine on the server side adds a lot more work. I don't think it would even balance out.
If they in fact can solve that (haven't checked myself), it would be a massive time saving for development.
In what sense? Is it as fast as using UDP with protobuf packets?
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.
The unity tutorial is just to get up and running as fast as possible in the simplest way possible, not to make the perfect decisions for a networked physics based game.
I however do think they should provide an actual reference to prove the claim,
If that is the case I would really like to see some internals of how the physics engine has been implemented in their pattern. I'm not asking for the rapier port source code, but it is hard to think in terms of a new advertised programming paradgim when there's no working examples.
For example I am very curious to see how a constraint solve is implemented in a SQL-like fashion. You would need various math operations and an efficient matrix representation off the top of my head, and I can't think of how that maps to a SQL-like interface.
So my understanding is rapier is just compiled into the wasm and run like normal while the results are stored into the table for clients to receive via subscription. I won't say it's a perfect solution, but efforts are being made by the small community to see how we can really push the db.
Note: while it's all very procedure like you can just store data normally in the rust side, you just have to push the information to the table for it to be query-able.
"What engine does BitCraft use? The BitCraft client is developed using the Unity game engine. For the server, we have developed a sophisticated distributed system called SpacetimeDB, which hosts the entirety of BitCraft’s server architecture. "
Correct me if wrong, but this suggests the physics engine is Unity's, and not something implemented in SpacetimeDB.
I guess making the claim that is was more complicated might have not been right for me to do, but it would be hard to believe that they did the degenerate case of O(n^2).
Speculation: I have only written a physics engine once during college (so please excuse my ignorance), but I think for a basic mmo a simple chunk and AABB approach would work. It would be easy to query for the surrounding chunks and just run the collision on that subset. I know one of the team members was working on porting a minecraft 1.7.3 server at one point, but I don't know if they got up to the point of moving collision off of the server and into the database.
Speculation as well: Looking at the trailer for Bitcraft, it looks like they have articulated characters and cloth physics. This raises more questions for me.
This is nice and all but the hard part is replication and consistency in a distributed database. In memory has its uses, also disk backed tables can have their uses. Pretty much normal databases already do this, just writing domain logic in stored procs is kind of annoying.
I'd imagine embedding sqlite in your binary using memory tables is equivalent at the moment. Well you'd have to write code to publish table updates to clients. I suppose it has that going for it.
I've seen some hand wavy docs about clustering but nothing concrete.
#[table(name = person, public)]
pub struct Person {
name: String,
}
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.
I'm not a game dev, but I'm imagining that if I'd write a custom game engine, I'd have to write just the "frontend" aka. graphics engine if I'd have a robust state manager (+tooling) as a separate piece of software.
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.
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...
>This means that you can write your entire application in a single language and deploy it as a single binary. No more microservices, no more containers, no more Kubernetes, no more Docker, no more VMs, no more DevOps, no more infrastructure, no more ops, no more servers.
This is an abstraction layer that will end up being applied on top of most or all of those technologies. You can't hide from the fact that the database instances need to run on something.
Lowering down the TRSACTION LEVEL, Async transctions on disk backed tables and UNLOGGED Tables can help you go a long way.
Also, in next major version (v18) of PG, they are trying to implment io_uring support which will further drastically improve the random read/write performance.
I checked out BitCraft and it's not released yet. Don't know if I'm being unfair here, but isn't this a bit misleading?
I'm sorry but there might not be a good market for this.
They had an MMO-targeted database called Spacebase, and a bunch of awesome JVM technology. Their founder actually works for Oracle now, if I'm not mistaken.
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.
I had an idea last night for an RTS like game where the units can only be controlled via radio commands which are only sent every minute or so, but this feels like a very strange way to do it. Not to mention hey it's not open source, but after 4 years will open source everything ?
Why, why wouldn't I just want to pay render or something $7 a month for a normal server versus this ? And use an actual open source stack.
Why not use something with a vastly friendlier license. Most companies don't want to play the GPL dance when alternatives exist.
I kept on reading expecting to see motion prediction, multiversion, or similar given the name and focus on games, but no. This is a totally normal database, designed for low latency and with support for WASM stored procedures. You can host your own server or they will rent you one. Don't get me wrong, this looks very nice. It looks like a solid building block for persistent worlds in multiplayer games. You'll just have to do your lag masking netcode yourself.
1) AFAIR, the ECS patterns family[0] originally came from MMORPG world, and boiled down to designing your game state to work well with relational databases;
2) Around 6 years ago, while toying with yet another (see [0]) take on ECS for a simple game, and wondering how to query stuff efficiently, it dawned on me that the code I'm writing is basically implementing spacial indices and other such concepts from relational DB world. At that point, I thought to myself, "why continue wasting time Greenspunning[1] a database for the internal state, when I could use a real one?", and followed by "you know what I really need next? An in-memory SQLite database to store all my runtime game state!".
I didn't get very far with my experiment due to constraints of adult life, but I did prove that I can build a basic Roguelike skeleton (2D tile map, entities, walls, collisions) while storing all state in SQLite, and have it run at 60 FPS with half of the frame time to spare for other things, on moderately powerful machine (as of 6 years ago), all without too much optimization (Common Lisp with FFI bindings to libsqlite3 + a simple RLU cache in front of queries).
So it's not at all a stupid idea, IMO :). I would test it further if I had the time.
--
[0] - The term means different things to different people. I've seen at least three distinct gamedev design patterns claiming the name ECS for themselves, all conceptually incompatible with each other. More, if you also consider "whatever Unity/Unreal/Godot/... calls ECS".
As to how to store the game state in memory, it's usually not something that needs much thinking: it's simply done the same way (or similar) as the game's client code. After all, netcode is mostly about efficient state replication and this saves CPU time when replicating it across clients - and gives more CPU time for minimizing bandwidth (like delta encoding, quantization, etc). If you want, you can utilize some techniques like ECS to optimize for CPU cache locality, but it affect gameplay code a lot and would need to get the whole team onboard.
Also, I just noticed the username "gafferongames" - Glenn's blog[1] has been a must-read for netcode engineers. It helped me a lot when I started working on netcode in the 2010s
Is it simply to be able to persist the game state?
If you know more than others as a professional multiplayer game developer, that's great, but in that case the thing to do is to share some of what you know, so others can learn. If you don't want to do that, that's fine, but in that case please don't post. Putdowns and swipes only degrade the discussion.
I could post anything objectively true in this thread like "the sky is blue", and some idiot will post a one sentence response that in fact it's not. This idiot likes to be the last person getting snark in responding to a completely reasonable statement of fact or opinion by an expert in the space.
What I do differently is that yes, I do reply to the snark with a rebuttal. Is this rebuttal snarky? Potentially, but is it earned? Definitely.
You're moderator so let me speak to you that way. If you don't let people rebut bullshit in this comment section, you'll just end up with a bunch of uninformed discourse, where the final word is made by some idiot, who doesn't even make multiplayer games and everyone ends up thinking the sky is fucking green. This has real world consequence when future game developers try to build games on poorly made technology, which ruins game studios and people's lives.
Then again, it's hacker news, and what do a bunch of wannabe startup guys know about making games in the first place. Unskilled and unaware of it. Moderate away sir!
https://news.ycombinator.com/newsguidelines.html
Btw, it's quite common for commenters to underestimate the provocation in their own posts and overestimate the provocation in other people's posts. Those two factors can multiply into quite a skew in perception (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...). I wonder whether this might be a bit of a factor here, if you really don't see how aggressively your comments were coming across.
In the future, I don't feel that writing anything more here on this topic is a worthwhile use of my time.
You're just being asked not to be a jerk to people on a messageboard. It's the same thing being asked of everyone else so that we can have a decent messageboard and it's not difficult.
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.
Q How is that coordinated with the SpacetimeDB? Is there a penalty, or perhaps a correction applied to the malicious client (and replicated to listening clients) in the case a hacker modifies their movement illegally?
Tx for sharing your time btw!
If I were to cheat and disable all wall collisions on the client. An Unreal server would roll me back, to all other people it would look like I'm walking into the wall. How do you even get SpacetimeDB to run Unreal's runtime (because movement kind of depends on deterministic results for frames). How does SpacetimeDB get hold of the assets (collisions)?
As a service backend+database the concept is cool and probably useful. But I don't see it being good at being a game server.
A common scenarios:
- "Game-server" using "regular" server+DB frameworks, often works but seldom in real-time scenarios.
- Realtime Game-servers (with in-memory state, sometimes supporting rollback,etc) that then has persistence more or less as an afterthought (duplicating state management between client<->server<->persistence)
What spacetime tries to do (and my current experiment) is to merge the server and DB to move persistence _performance_ concerns into the backend process.
We _rightfully_ moved databases out of server processes for easier management and safety in the 90s, but since f.ex. SQLite has been a bit of a resurgence because the usercode was in a managed language and wasn't as likely to cause a corruption issue.
WASM is a great enabler here because it allows the server/DB to sandbox the logic-code even in "unsafe"/realtime languages from the more precarious DB parts of the process so we don't have to risk data-safety even as we move back to co-locating server-state and persistence data within the same process.
One thing about SpacetimeDB that I'm not sure about is if reducers can run concurrently or not. I would hope so but it's very possible they don't and that can be a big regression vs. current game servers.
It seems that they're built to run serially to achieve reproducible simulations so my guess would be no, this is one thing my experiment does differently although formally it might just be a naming difference.
It's not a major issue though I think, the stuff I work on could shard work by area so single areas are single-threaded but world-wise it's parallel (Eve online has done this for ages).
Rather the main thing is mainly about coupling storage and sharding decisions with the simulation, since both a sharded simulator and sharded storage system will need logic for sharding and time-versioning, it's silly to duplicate work (or worse have out of sync semantics). In addition cohabiting simulation and storage will lessen latency and other issues w.r.t. to separating them.
Now, it's entirely possible that I'm barking up the wrong tree but considering that many are exploring this design-space means that there is interest and merits even if only the Spacetime and a few others have taken the leap yet.