Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SpacetimeDB

spacetimedb.com

Post reply on HN
Print view View original

161–170 of 205 posts

Re: SpacetimeDB

#161

Post by sitkack »

hansvm wrote: post #160
Geee wrote: post #159

Does this make any sense in single-player games, where the db would run locally on the user's machine? Does it have any benefit to run all game state through a local db? 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.

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 lif…

If you know all of your queries ahead of time, then compiling them efficiently has already been shown to be effective.

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

Re: SpacetimeDB

#162

Post by aeturnum »

efilife wrote: post #87
aeturnum wrote: post #49

Earlier quoted context omitted.

Like, if you decide to do your backend in rust or python you can choose async or synchronous approaches - but Node locks you into async. I'm not a node developer so I can't sing the praises of what you get, but being locked into JavaScript's process model, VM, and type system is certainly a downside (for which you get the whole JS world). It's another example of...if you are architecting your service and you pick thi…

maybe I don't understand something but most if not all node methods have their sync counterparts

You're thinking about JavaScript but I am talking about Node, which fundamentally uses a single-threaded approach[1] to great effect.

[1] https://stackoverflow.com/questions/17959663/why-is-node-js-...

Re: SpacetimeDB

#163

Post by XCSme »

gafferongames wrote: post #17
jackb4040 wrote: post #10

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 persisten…

[flagged]

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

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

Re: SpacetimeDB

#164

Post by 999900000999 »

Seems like a neat idea, but for the love of Jesus Christ offer me a flat rate billing solution. Or at least an option of doing that. This seems like the type of thing that will accidentally burn through all of your credits if you code something wrong, and then you're going to have to beg their tech support to refund you.

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.

Re: SpacetimeDB

#165

Post by sroussey »

cess11 wrote: post #146
barrell wrote: post #48

Earlier quoted context omitted.

When node first came out, it was pretty revolutionary. Being able to almost instantly start a JavaScript thread from a single file that could support realtime experiences (a la socket.io et al) without a build step felt pretty paradigm shifting

How would that differ from PHP?

Websockets et al

Re: SpacetimeDB

#166

Post by zinlencer »

Rohansi wrote: post #133
ncr100 wrote: post #38

Earlier quoted context omitted.

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!

Since SpacetimeDB would be your backend (game client SpacetimeDB) you would need to verify the inputs to your reducers to prevent cheating. Not really different from anything else.

But that's completely different from how Unreal typically does it. Movement is client-side predicted and server authoritative out of the box. How does SpacetimeDB even know the collisions of my level?

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)?

Re: SpacetimeDB

#167

Post by dtj1123 »

gafferongames wrote: post #86
pphysch wrote: post #82

Earlier quoted context omitted.

You will implement terrible lag masking and clientside prediction if you aren't looking at it from the UX perspective, because that is literally the only reason these features exist, to trick players into thinking the game signals are moving faster and with greater frequency through the network than is physically possible. Perhaps you would make better games if you considered the user perspective.

[flagged]

[flagged]

Re: SpacetimeDB

#168

Post by MasterYoda »

aeturnum wrote: post #42
cloutiertyler wrote: post #36

Earlier quoted context omitted.

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.

Absolutely! I work in Elixir and I feel very good about its tradeoffs - and a lot of being good with the tool is knowing when to not use it. This tech is very much out of my wheelhouse but it seems very cool and I hope y'all find a nice fit!

Which tradeoffs does elixir have?

Re: SpacetimeDB

#169

Post by Cieric »

999900000999 wrote: post #164

Seems like a neat idea, but for the love of Jesus Christ offer me a flat rate billing solution. Or at least an option of doing that. This seems like the type of thing that will accidentally burn through all of your credits if you code something wrong, and then you're going to have to beg their tech support to refund you. I had an idea last night for an RTS like game where the units can only be controlled via radio co…

SpacetimeDB is open source[1], the open source version doesn't currently have all the features of maincloud, but most of those features are solely for scalability. I've done all of my work on my own local servers. I would even suggest paying for your own server up front until you're ready to scale out. I believe the 4 years is when the license changes to a more open license. And the scalability features on local are coming, they're just not here yet.

[1] https://github.com/ClockworkLabs/SpacetimeDB

Re: SpacetimeDB

#170

Post by XCSme »

cloutiertyler wrote: post #31
Rohansi wrote: post #26

Earlier quoted context omitted.

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…

It 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)

> 1. Server client sync is handled for you

In what sense? Is it as fast as using UDP with protobuf packets?

Post reply on HN