[jackb4040]

Best comment from last time this got posted:

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.

https://news.ycombinator.com/item?id=43593913

[cloutiertyler]

Just to copy in my response from there too:

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.

[kriper]

How would you simulate physics, pathfinding, animation state on the server using this tech? Do you have to ditch your engine (do I have to reimplement what unity/unreal gives me for free?) ?

[ncr100]

Cool, jumping in as a noob to multiplayer dev, so currently for BitCraft MMORPG simulation, e.g. to prevent "god-mode flying", would be done outside the server.

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!

[whizzter]

Prediction can definitively be argued that it belongs in a layer above it, multi-version/rollback/reconciliation should be integrated however and I don't really see any mention of it from a quick skimming. (really need to take a closer look later today).

[gafferongames]

[flagged]

[tomhow]

Hey, can you please make your substantive points without shallow dismissals or snark? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html. Unfortunately you posted a few comments in this thread that have crossed that line.

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.

[insraq]

Just want to chime in that although this comment is a bit harsh, it does hold a lot of truth. As a game netcode engineer, most of my time is spent on latency hiding techniques and its consequences (for example, we use rollback netcode and lots of efforts are spent on minimizing visual/sound glitches when mispredict, rollback and reconcile). There are lots of middleware that help with this (eg. Photon, SnapNet, etc) but in general there's no silver bullet - it's highly gameplay specific. Even for the same game, the solution can vary depending on different trade-offs (i.e. budget, correctness/anticheat).

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

[1] https://gafferongames.com/

[TeMPOraL]

Well, I'm not a professional gamedev, nor did I ever do much multiplayer code, but:

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".

[cloutiertyler]

We can and plan to handle the complex lag masking netcode as well. We've just focused so far on games that don't need very sophisticated lag compensation

[XCSme]

As a gamedev, I don't understand the use-case for SpacetimeDB.

Is it simply to be able to persist the game state?

[neuroelectron]

Wasm? What a great idea.