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

131–140 of 205 posts

Re: SpacetimeDB

#131

Post by flockonus »

Rohansi wrote: post #46
cloutiertyler wrote: post #31

Earlier quoted context omitted.

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)

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

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

Re: SpacetimeDB

#132

Post by nilamo »

hdjrudni wrote: post #118
Jarwain wrote: post #73

Earlier quoted context omitted.

Theres discussion distinguishing hard real-time (what you describe), firm real-time (infrequent deadline misses are problematic but managable), and soft real-time (missing deadlines aren't a big deal). Node does a pretty hood job with soft real-time.

Ya'all are very strict in your definitions then. My definition is "does it feel laggy" or "do I have to walk away and come back when this thing is done". 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.

That definition of real time is not good enough for things like pacemakers, where real time really does actually matter.

Re: SpacetimeDB

#133

Post by Rohansi »

ncr100 wrote: post #38
cloutiertyler wrote: post #30

Earlier quoted context omitted.

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…

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.

Re: SpacetimeDB

#134

Post by drwiggly »

This looks to be an in memory db, with a wasm runtime to host domain logic. The hand wavy part was how do they handle scale and clustering? Are we sharding the data our selves (atm it seems so.).

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.

Re: SpacetimeDB

#135

Post by Swannie »

barrell wrote: post #48
theLiminator wrote: post #45

Earlier quoted context omitted.

> Node What's your reasoning behind this? Just being able to run the same code on frontend and backend?

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

Yeah, nah.

I worked on telco grade systems running on Rhino, in interpreted mode, in 2006. Leveraging Java to JS bindings. Responding to HTTP/JMS/etc.

Re: SpacetimeDB

#136

Post by Rohansi »

cloutiertyler wrote: post #32
matthewfcarlson wrote: post #11

Earlier quoted context omitted.

Not a developer affiliated with the project. But here's my take: 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) Running…

I mean you can download it and give it a try! For BitCraft we scale it with IMC (inter-module communication). It works very similarly to Elixir.

It's in closed alpha so there's a limited number of players but I am curious to hear more about how BitCraft is scaling out. Is it a single, seamless world for all players? How much scaling is currently required? How is data replicated when horizontal scaling comes into the picture?

Re: SpacetimeDB

#137

Post by beaudidly »

nilamo wrote: post #132
hdjrudni wrote: post #118

Earlier quoted context omitted.

Ya'all are very strict in your definitions then. My definition is "does it feel laggy" or "do I have to walk away and come back when this thing is done". 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.

That definition of real time is not good enough for things like pacemakers, where real time really does actually matter.

[dead]

Re: SpacetimeDB

#138

Post by LarsDu88 »

gafferongames wrote: post #114
Aeolun wrote: post #111

Earlier quoted context omitted.

Man, cynical much? I feel like OP has been honestly trying to engage with you here, and the only thing you’ve been is snippy and abrasive.

[flagged]

This guy is blunt... but he's correct.

This company focused all it's effort in reinventing the part of multi-player games that did not need reinventing.

40 engineers for 5 years. I'm guessing at least 20 million dollars spent. 1 million trailer views... Let's say 100k wishlists, 10,000 sales at 30 LTV. 300k in revenue

This company will need to pivot if the game is not successful.

I would say the db could be pivoted for multi-player Figma style apps rather than games, but the coupling of server and db means you can't scale the db layer the same way you could do with literally every other db solution available s your company scales

Re: SpacetimeDB

#139

Post by smus »

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

#140

Post by lomase »

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]

This is the Internet now, is not worth it, those times are over.
Post reply on HN