I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective: We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code. Speaking of game audio, I actually think rust…
Leaving Rust gamedev after 3 years
591–600 of 996 posts
Re: Leaving Rust gamedev after 3 years
#592That's a good article. He's right about many things. I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust. Notes: * There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be writ…
I'm happy to see someone still doing some work in second life.
None of this is yet increasing Second Life usership much, but it remains the best metaverse around.
I thought the metaverse thing was going to be bigger. Meta spent so much money to produce so little.
Re: Leaving Rust gamedev after 3 years
#593Earlier quoted context omitted.
> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are…
Here's a trace of a Bevy demo: https://i.imgur.com/oXUxC2h.png You can see that all the CPUs are being maxed out. This actually does result in significant FPS increases. Does it matter for every game? No. But it does result in better performance!
Re: Leaving Rust gamedev after 3 years
#594Interesting read! If I had not picked Elixir + Godot for the multiplayer game I'm making, then I would've gone with Rust for the whole thing. The old naive version of me would've tried doing it in C++ + Unreal but I knew better this time around. I think multiplayer game devs are sleeping on Elixir! It has made the network side of things so much easier and intuitive with fast prototyping and built in monitoring - so m…
I would love to read more about these Godot/Elixir adventures. Do you have a blog or a repo I could look through?
But I'm planning to release the game for testing next month! Its a browser "MMO" game too so its going to be easy to try out. And then I'll have time to write some more detailed technical notes online.
Re: Leaving Rust gamedev after 3 years
#595As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…
> My priorities are reasonable performances and the fastest iteration time possible. I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on... // 2024-02-01 $ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l 29 // 2023-12-21 $ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l 6 // 2023-12-14 $ curl https://www.taleworlds.com/en/…
It didn't stop Adobe from being worth 200B.
Re: Leaving Rust gamedev after 3 years
#596As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…
> a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases. That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence. (Whether Rust tooling is actually at a level to take advan…
To be fair, they need to be able to make large changes with confidence because what would be small changes in other languages tend to end up being very large changes in rust like languages.
Re: Leaving Rust gamedev after 3 years
#597Earlier quoted context omitted.
I think most people here understand that a language that is great for kernel development isn't necessarily great for everything else.
I work fulltime in Rust (embedded stuff) but actually think the "everything else" influence into Rust is stronger than the systems stuff, and it's harming the ecosystem. Just try finding e.g. an MQTT or WebSocket or etc library that doesn't drag the whole mammoth tokio ecosystem (which is really geared for Web Scale! projects) in with it. Rust is becoming the language that tokio ate, and Cargo/Crates.io the new NPM.…
(How is tokio fundamentally different than boost.asio and beast in this regard?)
> That is, Rust is the systems language that a wave of non-systems developers insist on using, leaving behind a trail of non-systems-appropriate crates and projects.
I have hard time understanding how this "trail" of stuff (evoking imagery of pollution) that no one is forced to depend on nor is promoted in any special way in the core library or language is any meaningful impediment to developing and distributing libraries more appropriate to the embedded domain, but perhaps one can explain how.
Re: Leaving Rust gamedev after 3 years
#598> Rust gamedev ecosystem lives on hype I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot. My experience was instantly terrible. Slow compile times and iterations, huge pack…
> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own too…
Re: Leaving Rust gamedev after 3 years
#599As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…
> My priorities are reasonable performances and the fastest iteration time possible. I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on... // 2024-02-01 $ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l 29 // 2023-12-21 $ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l 6 // 2023-12-14 $ curl https://www.taleworlds.com/en/…
Re: Leaving Rust gamedev after 3 years
#600Earlier quoted context omitted.
As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.
Go is infamous for its gc latency spikes, which is the thing that games cannot tolerate. Though 1.18 helped a lot, you'd have to do some major persuasion to game devs that Go's gc is the kind of thing they'd want in their game. --- EDIT: Not sure the downvote, Go is know for its (historically at least) unsuitability for RTC or game dev.
If performance were such a huge concern, I don't see any valid resistance to Rust that completely lacks a GC and makes it easy to call C code other than "it's something different", "there's too much hype", or "I don't like it". Recent development tools like RustRover make is really damn easy to see whats a move value or a borrow, debug test cases, run clippy automatically, and check crates versions in Cargo.toml. Throw Copilot in there and let it generate mostly correct, repetitious code for you.