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•11mo ago
Interested to know why Deutsche telekom sponsored this
nand_gate•11mo 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•11mo 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:
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•11mo 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•11mo 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•11mo 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•11mo ago
I had a similar reaction / question. Why not use KV store and get sub millisecond latency?
kaliqt•11mo 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).
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•11mo 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!
koakuma-chan•11mo ago
I love that you use Bun.
kaliqt•11mo 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•11mo 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?
reedf1•11mo ago
I would love to get into some game design - and something like this seems intuitive enough from my perspective as a software engineer. Forgive me if this is a naive question, but is the use case for this single-player games or multiplayer games?
kaliqt•11mo ago
Definitely multiplayer games, you wouldn't really need a syncing networking layer if you're doing single player as you can store state in any method you desire, something as simple as serializing JSON to the disk for example, or up to your server. But even then, a traditional setup like Supabase might be simpler to wrap your head around if you're just handing "user" data and not "player" data in a shared world.
kaliqt•11mo ago
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•11mo ago
nand_gate•11mo ago
kaliqt•11mo ago
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-sdk https://github.com/vircadia/vircadia-native-core
kaliqt•11mo ago
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•11mo ago
andyferris•11mo ago
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•11mo ago
jasonjmcghee•11mo ago
kaliqt•11mo ago
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).
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•11mo ago
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!
koakuma-chan•11mo ago
kaliqt•11mo ago
Drakim•11mo ago