Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

671–680 of 996 posts

Re: Leaving Rust gamedev after 3 years

#671

Earlier quoted context omitted.

I love Rust, but a crashing released game is better than a half-finished "perfect" game, or a game where you couldn't iterate quickly, and ended up with a perfectly tuned, unfun game.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

> For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

Evidence suggests otherwise. Of all demographics, gamers appear to be the most tolerant of buggy software.

I'm playing a 2020 game right now that has (in about 30 hours of gameplay):

1. Crashed twice 2. Froze once 3. Has at least ONE reproducible bug that a player would run into at least once every mission (including the first one).

Since this game is now so old it's not getting any more patches, these bugs are there for all eternity, because they just do not move the needle on enjoyment by the gamer.

Searching forums for Far Cry 5 Bugs gives results like this: https://www.reddit.com/r/farcry/comments/1ai4jzx/has_far_cry...

Gamers just don't care about bugs unless it stops them playing the game at all!

In order for bugs to have an effect on gamer enjoyment, it literally needs to make the game unplayable, and not just make the player reload from the last savepoint.

Re: Leaving Rust gamedev after 3 years

#672

As 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,…

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.

>As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#.

I read on a recent HN thread that Crystal compilation is slow due to its type inference, IIRC.

Re: Leaving Rust gamedev after 3 years

#673

Earlier quoted context omitted.

I'm happy to see someone still doing some work in second life.

There's a lot going on. Someone is doing a new third party viewer, Crystal Frost, in Unity. Linden Lab has a mobile viewer in alpha test. Rendering is PBR now for new objects. There are mirrors! Content upload is moving to glTF, to be compatible with everybody else. Voice is switching from Vivox to WebRTC. Game controller support is in test. New users get better avatars. The dev staff is larger. None of this is yet i…

> There's a lot going on.

I'd like to use the opportunity to ask: What happened during the covid pandemic? I haven't heard/read anything about second life during the pandemic even though this was probably a once-in-a-lifetime opportunity?

Are there any news sources that you can recommend to keep an eye on second life, because it doesn't seem that it gets that much press coverage?

Re: Leaving Rust gamedev after 3 years

#674

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

The problem is we would have a lot less games and the games we would get would not be as fun. Rust appears to have the following problems: 1) As the article pointed out, game developers are less productive in Rust. This is a huge problem. 2) Game budgets are not going to get bigger. This means that if Rust reduces productivity, games are going to be less polished, less fun, etc. if they are written in Rust. 3) Game q…

> As the article pointed out, game developers are less productive in Rust. This is a huge problem.

I don't think it's limited to just game developers though. Unless you are writing something in which any GC time other than 0ns is a dealbreaker, and any bug is also a dealbreaker, you're going to be less productive in Rust than almost any other language.

Re: Leaving Rust gamedev after 3 years

#675
post #432

Earlier quoted context omitted.

Speaking as a Godot supporter, I don't think sales numbers of shipped games are relevant to anyone except the game's developer. When evaluating a newer technology, the key question is: are there any major non-obvious roadblocks? A finished game (with presumably decent performance) tells you that if there are problems, they're solvable. That's the data.

> A finished game (with presumably decent performance) tells you that if there are problems, they're solvable. It doesn't tell you anything about velocity, which is by far the most important metric for indie devs. After all, the studio could have expended (maybe) twice as much effort to get a result.

Or maybe Rust allowed them to develop twice as fast. Who knows? We're going by data here, and this data point shows that games can be made in Bevy. No more and no less.

Re: Leaving Rust gamedev after 3 years

#676

Earlier 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!

>> 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

> You can see that all the CPUs are being maxed out.

You're missing the forest for the trees - the poster above basically said "seeing all the CPUs being maxed out is a pointless feature" and you reply with "but see, all the CPUs are being maxed out".

You're literally ignoring the complaint and replying with marketing.

Re: Leaving Rust gamedev after 3 years

#677

Earlier quoted context omitted.

The problem is we would have a lot less games and the games we would get would not be as fun. Rust appears to have the following problems: 1) As the article pointed out, game developers are less productive in Rust. This is a huge problem. 2) Game budgets are not going to get bigger. This means that if Rust reduces productivity, games are going to be less polished, less fun, etc. if they are written in Rust. 3) Game q…

> As the article pointed out, game developers are less productive in Rust. This is a huge problem. I don't think it's limited to just game developers though. Unless you are writing something in which any GC time other than 0ns is a dealbreaker, and any bug is also a dealbreaker, you're going to be less productive in Rust than almost any other language.

Oh, come on, we're yet again extrapolating from "Rust is bad at rapid iteration on an indie game" to "Rust is bad at everything". If Rust were really that astoundingly unproductive of a language, then so many developers at organizations big and small wouldn't be using it. Our industry may be irrational at times, but it's not that irrational.

Re: Leaving Rust gamedev after 3 years

#679

Earlier quoted context omitted.

I love Rust, but a crashing released game is better than a half-finished "perfect" game, or a game where you couldn't iterate quickly, and ended up with a perfectly tuned, unfun game.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

No, the game doesn’t take twice as long. It just gets abandoned half-finished.

The world is full of half-finished games, it takes time and money to push to a finish.

Post reply on HN