3 ms·
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
by Rohansi 2y ago
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.
- cloutiertyler 2y agoIt solves 3 problems: 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)
- Rohansi 2y agoThe first two problems are nothing, IMO. Server <> client sync is handled by your engine or, if you need to roll your own, it's not that hard. Syncing to a database is more tedious than difficult. Getting rid of a game engine on the server side adds a lot more work. I don't think it would even balance out.
- flockonus 2y agoHaving implemented the first two for a web game i absolutely guarantee you those are far from "nothing". It takes considerable diagraming & handling to coordinate FE + API on state changes. If they in fact can solve that (haven't checked myself), it would be a massive time saving for development.
- Rohansi 2y agoMaybe I'm just used to it having implemented it several times. But my point is that they require a relatively fixed amount of effort. Once it's implemented you shouldn't need to touch it again.
- XCSme 2y ago> 1. Server <> client sync is handled for you In what sense? Is it as fast as using UDP with protobuf packets?