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!
kaliqt•1y 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•1y ago
nand_gate•1y ago
kaliqt•1y 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•1y 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•1y ago
andyferris•1y 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•1y ago
jasonjmcghee•1y ago
kaliqt•1y 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.
koakuma-chan•1y ago
kaliqt•1y ago
Drakim•1y ago