6 ms·

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 perfe

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.

Repulsion9513 2y ago
> 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.
- StressedDev 2y ago
  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 quality is already fine. 99% of the games I play have very few noticeable bugs (I play on an Xbox Series X). Even the games with bugs are still fun. Basically, gamers are looking for fun games which work well. They are not looking for perfect software which has no bugs.
  - lelanthran 2y ago
    > 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.
    - pcwalton 2y ago
      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.
      - lelanthran 2y ago
        > 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". I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever). I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise.
        pcwalton 2y ago
        > I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever). That's not what you said: you said you're going to be less productive in Rust than nearly any other language, not "mainstream GC'd languages". > I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise. Depending on the domain, I am disputing that, because of things like the Cargo ecosystem, easy parallelism, ease of interop with native code, etc. There is no equivalent to wgpu in other languages, for example.
        lelanthran 2y ago
        > That's not what you said: you said you're going to be less productive in Rust than nearly any other language, not "mainstream GC'd languages". I feel that you're selectively reading only what you have talking points to respond to. Here is exactly what I said: > 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. I mean, I literally carved out an exception use-case for Rust; viz for software that can't handle GC. I wrote a single sentence with a single point, not a a single point diluted over multiple paragraphs. You have to literally read only half-sentences to interpret my point the way you did. If you aren't going to even bother reading full sentences, why bother engaging at all?
    - drogus 2y ago
      Have you written much Rust?
  - Repulsion9513 2y ago
    Uhh, no, the games we got 15 years ago and before were definitely just as fun.
- Const-me 2y ago
  > I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long I have recently completed Cyberpunk Phantom Liberty. The game crashed 4-5 times during 100-150 hours of gameplay. The crashes were pretty much painless because I quick save often. The game was amazing. The development of the game started in 2012, 12 years ago. I’m not sure you or most gamers would rather want a fully-finished "perfect" Cyberpunk 2077 game released in 2036.
  - Repulsion9513 2y ago
    > 4-5 times during 100-150 hours of gameplay Great, thanks for proving my point! If you had played CP at release, how many times would it have crashed? Do you really think it would have taken them another 12 years to get to the point they're at now if they hadn't released it 4 years ago? SMH
- lelanthran 2y ago
  > 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_5_always_been_extremely_buggy_or_am_i/ 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.
  - KronisLV 2y ago
    > 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). Sounds about on par even for enterprise software, in cases where shipping quickly is prioritized over overall quality, doubly so for gamedev which is notorious for long hours and scope creep.
  - Repulsion9513 2y ago
    > Evidence suggests otherwise. Of all demographics, gamers appear to be the most tolerant of buggy software. Evidence suggests otherwise. Of all demographics, game studios appear to be the most tolerant of buggy software. bladeblablabla Just go look at CP2077 or BF2042 or Fallout 76 or ... So many games out there that no one wanted to play until they finally actually made a game that was ready for release, a year or more after they released it.
- CJefferson 2y ago
  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.
  - Repulsion9513 2y ago
    Ah right that's why no games existed two decades ago.
- bcrosby95 2y ago
  Hell no. Lots of these games take 5-7 years to make. You want to turn that into 10-14? I can live with the rare crash bugs.
  - eviks 2y ago
    What if it's 5-7, but only after there is a deep enough dev pool and language tooling to address some of the productivity issues mentioned in the blog? Why make up arbitrary x2 factors?
  - Repulsion9513 2y ago
    IDK, seems to me like studios did just fine putting release-quality games out at release 15-20 years ago shrug "rare" LOL
- KaiserPro 2y ago
  perfect is the enemy of good. You never release anything thats perfect. Perfect is impossible.
  - Repulsion9513 2y ago
    > "perfect" > perfect See the difference?
- flohofwoe 2y ago
  It's a chicken-egg problem. You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all). YMMV depending on the complexity of the game of course. But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in the wild that your game will crash for some users. And for the affected users it doesn't matter whether that crash is caused by crappy game code, or some crappy 3rd party software interfering with your game. For the user it's always the game's fault ;)
  - Repulsion9513 2y ago
    > You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all). Just because they like to say that doesn't mean it's true. I've had access to see the list of known issues considered "critical" around release time for a few games. They know the bug exists, they just want to release it more than they want to fix it. > But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in the wild that your game will crash for some users. Which in no way invalidates the point that most modern games are absolutely unplayable for most users at release. Oh yeah, and also that's why beta testing exists

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.

Repulsion9513 2y ago

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

StressedDev 2y ago
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 quality is already fine. 99% of the games I play have very few noticeable bugs (I play on an Xbox Series X). Even the games with bugs are still fun. Basically, gamers are looking for fun games which work well. They are not looking for perfect software which has no bugs.
- lelanthran 2y ago
  > 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.
  - pcwalton 2y ago
    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.
    - lelanthran 2y ago
      > 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". I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever). I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise.
      - pcwalton 2y ago
        > I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever). That's not what you said: you said you're going to be less productive in Rust than nearly any other language, not "mainstream GC'd languages". > I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise. Depending on the domain, I am disputing that, because of things like the Cargo ecosystem, easy parallelism, ease of interop with native code, etc. There is no equivalent to wgpu in other languages, for example.
        lelanthran 2y ago
        > That's not what you said: you said you're going to be less productive in Rust than nearly any other language, not "mainstream GC'd languages". I feel that you're selectively reading only what you have talking points to respond to. Here is exactly what I said: > 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. I mean, I literally carved out an exception use-case for Rust; viz for software that can't handle GC. I wrote a single sentence with a single point, not a a single point diluted over multiple paragraphs. You have to literally read only half-sentences to interpret my point the way you did. If you aren't going to even bother reading full sentences, why bother engaging at all?
  - drogus 2y ago
    Have you written much Rust?
- Repulsion9513 2y ago
  Uhh, no, the games we got 15 years ago and before were definitely just as fun.
Const-me 2y ago
> I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long I have recently completed Cyberpunk Phantom Liberty. The game crashed 4-5 times during 100-150 hours of gameplay. The crashes were pretty much painless because I quick save often. The game was amazing. The development of the game started in 2012, 12 years ago. I’m not sure you or most gamers would rather want a fully-finished "perfect" Cyberpunk 2077 game released in 2036.
- Repulsion9513 2y ago
  > 4-5 times during 100-150 hours of gameplay Great, thanks for proving my point! If you had played CP at release, how many times would it have crashed? Do you really think it would have taken them another 12 years to get to the point they're at now if they hadn't released it 4 years ago? SMH
lelanthran 2y ago
> 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_5_always_been_extremely_buggy_or_am_i/ 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.
- KronisLV 2y ago
  > 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). Sounds about on par even for enterprise software, in cases where shipping quickly is prioritized over overall quality, doubly so for gamedev which is notorious for long hours and scope creep.
- Repulsion9513 2y ago
  > Evidence suggests otherwise. Of all demographics, gamers appear to be the most tolerant of buggy software. Evidence suggests otherwise. Of all demographics, game studios appear to be the most tolerant of buggy software. bladeblablabla Just go look at CP2077 or BF2042 or Fallout 76 or ... So many games out there that no one wanted to play until they finally actually made a game that was ready for release, a year or more after they released it.
CJefferson 2y ago
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.
- Repulsion9513 2y ago
  Ah right that's why no games existed two decades ago.
bcrosby95 2y ago
Hell no. Lots of these games take 5-7 years to make. You want to turn that into 10-14? I can live with the rare crash bugs.
- eviks 2y ago
  What if it's 5-7, but only after there is a deep enough dev pool and language tooling to address some of the productivity issues mentioned in the blog? Why make up arbitrary x2 factors?
- Repulsion9513 2y ago
  IDK, seems to me like studios did just fine putting release-quality games out at release 15-20 years ago shrug "rare" LOL
KaiserPro 2y ago
perfect is the enemy of good. You never release anything thats perfect. Perfect is impossible.
- Repulsion9513 2y ago
  > "perfect" > perfect See the difference?
flohofwoe 2y ago
It's a chicken-egg problem. You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all). YMMV depending on the complexity of the game of course. But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in the wild that your game will crash for some users. And for the affected users it doesn't matter whether that crash is caused by crappy game code, or some crappy 3rd party software interfering with your game. For the user it's always the game's fault ;)
- Repulsion9513 2y ago
  > You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all). Just because they like to say that doesn't mean it's true. I've had access to see the list of known issues considered "critical" around release time for a few games. They know the bug exists, they just want to release it more than they want to fix it. > But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in the wild that your game will crash for some users. Which in no way invalidates the point that most modern games are absolutely unplayable for most users at release. Oh yeah, and also that's why beta testing exists