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

91–100 of 205 posts

Re: SpacetimeDB

#91

Post by manas96 »

Cieric wrote: post #75
manas96 wrote: 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…

Then again looking at the FAQ for Bitcraft, we have this:

"What engine does BitCraft use? The BitCraft client is developed using the Unity game engine. For the server, we have developed a sophisticated distributed system called SpacetimeDB, which hosts the entirety of BitCraft’s server architecture. "

Correct me if wrong, but this suggests the physics engine is Unity's, and not something implemented in SpacetimeDB.

Re: SpacetimeDB

#92

Post by MPSimmons »

This feels like very old-school java client/server architectures.

>This means that you can write your entire application in a single language and deploy it as a single binary. No more microservices, no more containers, no more Kubernetes, no more Docker, no more VMs, no more DevOps, no more infrastructure, no more ops, no more servers.

This is an abstraction layer that will end up being applied on top of most or all of those technologies. You can't hide from the fact that the database instances need to run on something.

Re: SpacetimeDB

#93

Post by cloutiertyler »

gafferongames wrote: post #90
cloutiertyler wrote: post #80

Earlier quoted context omitted.

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]

Ah you mean like implementing UDP and supporting complex lag masking netcode before we have to?

Re: SpacetimeDB

#94

Post by cmrdporcupine »

cloutiertyler wrote: post #83
cmrdporcupine wrote: post #56

Earlier quoted context omitted.

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.

Hey Tyler; looking back I think maybe a better language than "reducers" etc would have been to just something analogous to the ECS term "systems", which I understand to be "processes that operate on entities / components" and always seemed overly general and non-specific to me but at least is familiar to game programmers operating in data driven design.

You may recall I was partial to the term "verb" :-)

Re: SpacetimeDB

#95

Post by Cieric »

manas96 wrote: post #85
Cieric wrote: post #75

Earlier quoted context omitted.

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

On of the people who implemented it is from unity, from my understanding he can't actually release the code. For the other guy, this was his last comment on the matter > Sure, my plan was to write a readme and share the code with my colleagues anyway. It should be ready by the weekend because I'm in the middle of a refactoring right now. > The gist of it: each time a System adds a "movable" component to a StDb table, it also adds the rigid body and collider in Rapier. Then, a scheduled reducers updates the simulation then fetches resulting positions and velocities from Rapier and updates the "movable" components. I have no client prediction at this time.

So my understanding is rapier is just compiled into the wasm and run like normal while the results are stored into the table for clients to receive via subscription. I won't say it's a perfect solution, but efforts are being made by the small community to see how we can really push the db.

Note: while it's all very procedure like you can just store data normally in the rust side, you just have to push the information to the table for it to be query-able.

Re: SpacetimeDB

#97

Post by cloutiertyler »

hesdeadjim wrote: post #41

$0.28/gb for net traffic on the Maincloud is pretty brutal.

We want to dial these numbers in, but we have to err on the side of too high, because it's easier to lower prices than to raise them. We want to bring it down as low as we possibly can.

Re: SpacetimeDB

#98

Post by insraq »

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]

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/

Re: SpacetimeDB

#99

Post by pphysch »

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]

Happy to help.

Re: SpacetimeDB

#100

Post by Psyferio »

manas96 wrote: post #91
Cieric wrote: post #75

Earlier quoted context omitted.

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…

Then again looking at the FAQ for Bitcraft, we have this: "What engine does BitCraft use? The BitCraft client is developed using the Unity game engine. For the server, we have developed a sophisticated distributed system called SpacetimeDB, which hosts the entirety of BitCraft’s server architecture. " Correct me if wrong, but this suggests the physics engine is Unity's, and not something implemented in SpacetimeDB.

I am contributing to a project by a SpacetimeDB community member to get Rapier running within Unity. Instead of trying to get Unity PhyX running on the server, we just use a deterministic Rust physics engine on both client and server. It is a mostly complete drop in replacement as it stands and is deterministic (Unity's PhyX is not). We'll keep improving it!

https://github.com/Daxode/rapier4unity

Post reply on HN