3 ms·

The example shows using it to update player positions. Doesn’t Postgres add significant latency considering a 16-33ms budget for state updates? How well does t

The example shows using it to update player positions. Doesn’t Postgres add significant latency considering a 16-33ms budget for state updates? How well does this scale?

andyferris 1y ago
Generally client games optimistically carry on a few frames (and sometimes much more!) ahead of the what the server has responded with as accepted. This is because gamers require low latency to effectively play, but things can be slightly out of sync and logic can be complex, and anti cheat can be hard to implement server side only (which is why eg fortnite and valarant install fancy client side anti cheat software too). For a friendly game of stardew valley or turn based strategy you can afford to wait for transactions to complete and causality to be enforced.
- kaliqt 1y ago
  We CAN submit the change to the DB and not listen to the message on if it succeeded or not! The message will arrive eventually, it's just not necessary to await it, so you have options.
jasonjmcghee 1y ago
I had a similar reaction / question. Why not use KV store and get sub millisecond latency?
- kaliqt 1y ago
  So it's a bit of tradeoffs, we may add a second DB to the compose by the time we reach v1.0, but, if we had to pick the convergence of simplicity and flexibility to start, PostgreSQL is it. We prototyped SQLite as well. It just wasn't working in the stack like we had needed. The idea is simple: use as few components as possible to achieve the outcome. Better to have less than more initially, because we can simply add the more and extend the API, but ripping everything out and trying to trim it down is damn near impossible, especially when the platform garners widespread usage. The decision to do the less then more instead of more then less approach was spurred by us (the wider project) always having way too much bulk and then finding it impossible to turn the ship when we needed to (https://github.com/vircadia/vircadia-native-core https://github.com/vircadia/vircadia-native-core). We need to be agile to reach the milestones we have set out, hence the differed approach using off the shelf parts and only adding what we need, when we need it.
kaliqt 1y ago
Postgres finishes its updates sub-ms in a reasonably sized DB if optimized correctly. In terms of upper-scale (>1000 players in a somewhat real-world scenario), we're working out benchmarks to test that. Postgres is not slow by any stretch of the imagination, but it depends on how the schema is setup and what layers you have between the user and the DB, naturally any game developer will want to tweak the client+schema before going live. The layers between we manage to make it as minimal as possible, so that shouldn't be touched, if it's too slow for a reasonable use case, it means we have more optimization to do!

The example shows using it to update player positions. Doesn’t Postgres add significant latency considering a 16-33ms budget for state updates? How well does this scale?

andyferris 1y ago

Generally client games optimistically carry on a few frames (and sometimes much more!) ahead of the what the server has responded with as accepted. This is because gamers require low latency to effectively play, but things can be slightly out of sync and logic can be complex, and anti cheat can be hard to implement server side only (which is why eg fortnite and valarant install fancy client side anti cheat software too). For a friendly game of stardew valley or turn based strategy you can afford to wait for transactions to complete and causality to be enforced.

kaliqt 1y ago
We CAN submit the change to the DB and not listen to the message on if it succeeded or not! The message will arrive eventually, it's just not necessary to await it, so you have options.

jasonjmcghee 1y ago

I had a similar reaction / question. Why not use KV store and get sub millisecond latency?

kaliqt 1y ago
So it's a bit of tradeoffs, we may add a second DB to the compose by the time we reach v1.0, but, if we had to pick the convergence of simplicity and flexibility to start, PostgreSQL is it. We prototyped SQLite as well. It just wasn't working in the stack like we had needed. The idea is simple: use as few components as possible to achieve the outcome. Better to have less than more initially, because we can simply add the more and extend the API, but ripping everything out and trying to trim it down is damn near impossible, especially when the platform garners widespread usage. The decision to do the less then more instead of more then less approach was spurred by us (the wider project) always having way too much bulk and then finding it impossible to turn the ship when we needed to (https://github.com/vircadia/vircadia-native-core https://github.com/vircadia/vircadia-native-core). We need to be agile to reach the milestones we have set out, hence the differed approach using off the shelf parts and only adding what we need, when we need it.

kaliqt 1y ago

Postgres finishes its updates sub-ms in a reasonably sized DB if optimized correctly. In terms of upper-scale (>1000 players in a somewhat real-world scenario), we're working out benchmarks to test that. Postgres is not slow by any stretch of the imagination, but it depends on how the schema is setup and what layers you have between the user and the DB, naturally any game developer will want to tweak the client+schema before going live. The layers between we manage to make it as minimal as possible, so that shouldn't be touched, if it's too slow for a reasonable use case, it means we have more optimization to do!