4 ms·

We gave Vircadia a full Gen 2 overhaul (big thanks to our sponsors such as Linux Professional Institute, Deutsche Telekom, etc. for enabling this), aiming to cu

by kaliqt 1y ago

We gave Vircadia a full Gen 2 overhaul (big thanks to our sponsors such as Linux Professional Institute, Deutsche Telekom, etc. for enabling this), aiming to cut down on code bloat and boost performance. The main shift is swapping out our custom backend infrastructure for a battle-tested, high-performance system like PostgreSQL with Bun wrapping and managing every end of it. It's kind of unheard of to do this for things like game dev (preferring custom solutions), but it works and makes things way easier to manage. The shape of the data in a database affects how well it works for a use case, and that model scales well for virtually every kind of software ever, the same should apply here! Feel free to prototype some game ideas you might have been tossing around, our priority is DX for the project as a whole to enable more developers with less resources to build bigger worlds, so please do share feedback here and/or in GH issues! Our roadmap is for more SDKs, and cutting down on bloat where possible, with the express goal of giving devs more cycles in the day to focus on the actual gameplay instead of tooling.

porridgeraisin 1y ago
Interested to know why Deutsche telekom sponsored this
- nand_gate 1y ago
  My guess is money laundering, given that the product is pretty vapourware-y (as a game dev in a past life: Vircadia looks more like 'how a web dev thinks multiplayer games work' aka basically unusable in a serious title).
  - kaliqt 1y ago
    I think you fundamentally misunderstand the stack. Their main usage of the platform has to do with a E2E solution with avatars, audio, etc. all synced without issue. These features ship with the client and other private repositories wrapping the core. However, for usage to HN users they would be (likely) more interested in the SDK, the core, the underlying system, and how it can fit their use cases. If you want to understand a small part of the scale of this project, you are welcome to check out: https://github.com/vircadia/vircadia-web https://github.com/vircadia/vircadia-web https://github.com/vircadia/vircadia-web-sdk https://github.com/vircadia/vircadia-web-sdk https://github.com/vircadia/vircadia-native-core https://github.com/vircadia/vircadia-native-core
- kaliqt 1y ago
  For an E2E worlds solution, so this https://github.com/vircadia/vircadia-web https://github.com/vircadia/vircadia-web and this https://github.com/vircadia/vircadia-native-core https://github.com/vircadia/vircadia-native-core except heavily condensed so it's easier to modify/upgrade for each new bespoke use case. Our old system, being very monolithic, while extremely performant and capable, was nearly impossible to adapt and change. So what we have now is much more dynamic but also still a work in progress, a more complete example will be published in the coming weeks.
ricardobeat 1y ago
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.
koakuma-chan 1y ago
I love that you use Bun.
- kaliqt 1y ago
  We have to cut bloat where we can if this is to work for higher up revision games, so Bun is the only answer that balances speed and simplicity (TypeScript native).
Drakim 1y ago
How does the system separate between state changes that must be confirmed by backed compared to state changes that can be updated locally (by prediction) to give the user more snappy experience?

by kaliqt 1y ago

porridgeraisin 1y ago

Interested to know why Deutsche telekom sponsored this

nand_gate 1y ago
My guess is money laundering, given that the product is pretty vapourware-y (as a game dev in a past life: Vircadia looks more like 'how a web dev thinks multiplayer games work' aka basically unusable in a serious title).
- kaliqt 1y ago
  I think you fundamentally misunderstand the stack. Their main usage of the platform has to do with a E2E solution with avatars, audio, etc. all synced without issue. These features ship with the client and other private repositories wrapping the core. However, for usage to HN users they would be (likely) more interested in the SDK, the core, the underlying system, and how it can fit their use cases. If you want to understand a small part of the scale of this project, you are welcome to check out: https://github.com/vircadia/vircadia-web https://github.com/vircadia/vircadia-web https://github.com/vircadia/vircadia-web-sdk https://github.com/vircadia/vircadia-web-sdk https://github.com/vircadia/vircadia-native-core https://github.com/vircadia/vircadia-native-core
kaliqt 1y ago
For an E2E worlds solution, so this https://github.com/vircadia/vircadia-web https://github.com/vircadia/vircadia-web and this https://github.com/vircadia/vircadia-native-core https://github.com/vircadia/vircadia-native-core except heavily condensed so it's easier to modify/upgrade for each new bespoke use case. Our old system, being very monolithic, while extremely performant and capable, was nearly impossible to adapt and change. So what we have now is much more dynamic but also still a work in progress, a more complete example will be published in the coming weeks.

ricardobeat 1y ago

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.

koakuma-chan 1y ago

I love that you use Bun.

kaliqt 1y ago
We have to cut bloat where we can if this is to work for higher up revision games, so Bun is the only answer that balances speed and simplicity (TypeScript native).

Drakim 1y ago

How does the system separate between state changes that must be confirmed by backed compared to state changes that can be updated locally (by prediction) to give the user more snappy experience?