Live data from Hacker News

SpacetimeDB

spacetimedb.com

81–90 of 205 posts

Re: SpacetimeDB

#81

Earlier quoted context omitted.

just because someone doesn't think and plan just like you do, doesn't mean they will not succeed

[flagged]

For what it's worth, BitCraft currently ships with client-side prediction. It's just not built into SpacetimeDB yet.

It's relatively simple, but "The SpacetimeDB devs have not yet shipped a game using client-side prediction techniques", is not correct.

Re: SpacetimeDB

#82
post #52

Earlier quoted context omitted.

Seems too biased and harsh. The best lag masking and clientside prediction systems I've experienced as a player are those that are closely integrated with the idiosyncratic gameplay mechanics. I would never expect SpacetimeDB to have a one-size-fits-all solution to this, nor for it to be the central focus of their product.

Game development is not something you learn by playing games.

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.

Re: SpacetimeDB

#83
post #4

This looks really interesting, and bitcraft looks cute. I did hit a personal bias: when I saw "maincloud" as a phrase to do with pricing my heart sank because my brain went "they've wedged in some crypto shit!". Turns out no, it's just a naming thing for hosting credits.

There was a lot of crypto-adjacent talk in earlier versions of their marketing and product design. Without it actually being anything actually crypto-adjacent. Analogies drawn to ethereum etc concepts, I guess because they figured somehow there was an audience that would get those references and it would allow them to understand the product better? I have no idea why. I was hired to work on very early versions of it,…

It had nothing to do with marketing, it was because conceptually stored procedures are similar to smart-contracts and share technical aspects. We thought engineers would find the similarities interesting. Instead they immediately assumed we were shilling tokens, so we pulled it down.

Kind of sad that people can't see past that, but I also understand. It is what it is.

Re: SpacetimeDB

#84
post #4

This looks really interesting, and bitcraft looks cute. I did hit a personal bias: when I saw "maincloud" as a phrase to do with pricing my heart sank because my brain went "they've wedged in some crypto shit!". Turns out no, it's just a naming thing for hosting credits.

There was a lot of crypto-adjacent talk in earlier versions of their marketing and product design. Without it actually being anything actually crypto-adjacent. Analogies drawn to ethereum etc concepts, I guess because they figured somehow there was an audience that would get those references and it would allow them to understand the product better? I have no idea why. I was hired to work on very early versions of it,…

Oh it's you! Sorry cmrdporcupine! I didn't see.

Re: SpacetimeDB

#85
post #75
post #74

Earlier quoted context omitted.

Given the name I was also expecting some clever SQL-like data structure/query for fast spatial lookup but I digress. Game physics involves a lot of things (solvers, collision detection, numerical stability, etc.). I am skeptical of their claims of being able to run physics in what I understand are stored procedures for their database. I looked at their docs for physics https://spacetimedb.com/docs/unity/part-4 where…

I believe they've done more complicated physics in their game bitcraft, but that code hasn't been released yet (no idea if it will be.) But there has been work in the discord recently and 2 member have individually implemented rapier[1] at this point. I can't say anything about the related netcode however as I don't know how much they've focused on it. At the very least work has been done. The unity tutorial is just…

Nice, that's very interesting and a commendable achievement!

If that is the case I would really like to see some internals of how the physics engine has been implemented in their pattern. I'm not asking for the rapier port source code, but it is hard to think in terms of a new advertised programming paradgim when there's no working examples.

For example I am very curious to see how a constraint solve is implemented in a SQL-like fashion. You would need various math operations and an efficient matrix representation off the top of my head, and I can't think of how that maps to a SQL-like interface.

Re: SpacetimeDB

#86
post #82

Earlier quoted context omitted.

Game development is not something you learn by playing games.

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]

Re: SpacetimeDB

#87

Earlier quoted context omitted.

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

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

Re: SpacetimeDB

#88
post #73
post #58

Earlier quoted context omitted.

> could support realtime experiences Node supports realtime applications? Really? Isn't it garbage collected? Or does the term mean something different in nodejs? I've only come to know the term in the context of time guarantees (i.e. if it's scheduled to run in x, it is guaranteed to run at that time) and that shouldn't apply to nodejs I think? When you schedule something there, I believe it'll run on the first free…

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.

What games do you know that are hard or firm real-time?

Real-time in this context is more like real-time communication rather than process scheduling.

Re: SpacetimeDB

#89

Earlier quoted context omitted.

[flagged]

For what it's worth, BitCraft currently ships with client-side prediction. It's just not built into SpacetimeDB yet. It's relatively simple, but "The SpacetimeDB devs have not yet shipped a game using client-side prediction techniques", is not correct.

[flagged]

Re: SpacetimeDB

#90

Earlier quoted context omitted.

How can you think deeply and plan for something when you don't know what don't know. You can only really understand these things when you've taken a game using these latency hiding techniques into production, and then after this, you'll probably realize that some of your original ideas were wrong. Where does this leave SpacetimeDB then?

I'd be happy to schedule a chat to talk with you about our plans if you'd like! I'd love to get your thoughts.

[flagged]
Post reply on HN