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.
I'm Tyler (guy in the video). We do not currently do lag compensation/client-side prediction for you, but you can do it. In BitCraft we implement it 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!
Coming from gamedev I was expecting it too for real multi-player RPGs, shooters, etc, or something fancy like simualtenous turn based gaming (which was done in the past).
Definitely something we're looking to tackle in the near future. Lag-compensation, client-side prediction, and alternative transport layers are all in the works!
How would you deal with this common issue in many multiplayer shooters?:
- I see someone sniping
- I go behind a wall to safety
- I still die
From the enemy snipers perspective I was still in view when he shot.
From my perspective I was not.
Many game servers only roll back time to validate from the shooter's perspective.
In this case you'd want some logic to perhaps negotiate a compromise - like only dealing half damage.
This is an awesome project and an interesting use case for WASI.
Get rid of this though:
> This means that you can write your entire application in a single language, Rust, 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.
Based on the description, it’s because you don’t get raw SQL access; they say the game logic is embedded directly into the database and you interact with it through stored procedures. All the rules are enforced there instead of whatever API endpoint you would normally use.
We are currently working on IMC (inter-module communication) which allows the database modules to act like persistent actors. They can pass messages between databases and create new databases as well. It's similar to Erlang/BEAM.
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.