5 ms·
Wonderful! Thanks for sharing. This sounds like the exact sort of work that Rust is perfect for. I'm making a game in Rust and Godot (engine) and since it's a
by gridspy 6y ago
Wonderful! Thanks for sharing. This sounds like the exact sort of work that Rust is perfect for.
I'm making a game in Rust and Godot (engine) and since it's a factory game the simulation performance is important. Rust means I worry far less about stability and performance.
I bet if you wrote a good blog entry with screenshots and explanation of how your code loads and renders I imagine it would do well on HN.
- Animats 6y agoToo soon. Someday perhaps a Game Developers Conference paper/talk. I was considering one, but live GDC has been cancelled for 2021. My real interest in this is how do we build a big, seamless metaverse that goes fast. I'm far enough along to see that it's possible, but not far enough along that people can use the client. Rust is good for this sort of thing. It's overkill for most web back end stuff. That's where Go is more useful. Go has all those well-used libraries for web back end tasks. Parallelism in web back ends tends to be about waiting for network events, not juggling heavy compute loads of coordinated disparate tasks. Hence all the interest in "async" for web servers. As I've said before, use the right tool for the job.
- gridspy 6y agoOne idea I liked was ... You have an authoritive world simulation server, as usual. You then have several servers whose chief job is to keep clients in sync with the authoritive server. Most network games combine these two roles, but there is a lot of processing and network traffic required to keep clients in sync. For massive multiplayer there is a benefit to scale the "client-interaction" servers.