9 ms·

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 t

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, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases. We almost never have specifications, almost nothing is set until the game is done. It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries. Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.

mrkeen 2y ago
> 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/News/547 | grep "Fixed a crash that" | wc -l 101 Maybe feeling like you're iterating fast isn't the same as getting to the destination faster. Edit: Lol guys calm down with the down-vote party. I was counting crashes, not bugs: $ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a bug that" | wc -l 308 Does your C++ not crash, just theirs?
- tedajax 2y ago
  This comment is nonsense
- stephc_int13 2y ago
  Yeah this is a common problem in the industry, we rarely have enough time to refactor what should be considered prototype-level code into robust code.
  - hi-v-rocknroll 2y ago
    The game dev industry could form a consortium to launch its own dedicated general purpose language built from scratch to compile very fast like V or Go, run predictability, be much safer, be more reusable, and be extremely productive with the lessons learned from C, C++, C#, and more. Also, I think LLMs will be able to run against code bases to suggest mass codemods to clean things up rather than having humans make a zillion changes or refactoring fragile areas of tech debt. LLMs are already being applied to generate test cases.
    - stephc_int13 2y ago
      I believe that better tooling can help, yes. With refactoring, debugging, creating performance and style reports, updating documentation and a ton of other stuff.
    - jibe 2y ago
      Jonathan Blow’s Jai is an attempt at something like this. It’s looking promising so far!
      - hi-v-rocknroll 2y ago
        Interesting. I went through the primer spec. Appears to be a different kind of D or Go with some key points. Any new language should begin with a specific thesis of specific competitive advantages and problems it solves over existing customary and alternative tools. Kai appears to fulfill this property, so that's a good sign.
      - johnisgood 2y ago
        > It is still in development and as of yet is unavailable to the general public. Is it still the case?
- lionkor 2y ago
  With Rust and the exact time iteration times, management and deadlines, you end up with the same amount, just theyre panic!() instead. Thats an improvement, sure, but its fighting a symptom.
  - mrkeen 2y ago
    With modern languages that take safety more seriously, it's a lot easier to spot places where the code 'goes wrong'. In an older language, you have nothing to tell you whether you're about to dereference null: foo.bar.baz = ...; Even if you've coded it 100% correctly, that line of code still looks the same as code which will segfault. You need to look elsewhere in codebase to make sure the right instructions populated those fields at the right time. If I'm scrolling past, I'll slow down everytime to think "Hey, will that crash?" Compare that with more safety focused languages where you can see the null-dereferences on the page. Unwrap() or whatever it is in Rust. Since they're visually present, you can code fast by using the unsafe variants, come back later, and know that they won't be missed in a code review. You can literally grep for unsafe code to refactor.
  - sam0x17 2y ago
    There are a bunch of useful clippy lints to completely disable most forms of panicking in CI. We use this at my work since a single panic could cost millions of $ in our case.
- thom 2y ago
  Hard to know what TaleWorlds are actually optimising for because half the features of Bannerlord feel like they’ve never been played by a dev let alone iterated on.
- bogwog 2y ago
  That game (currently) has 88% positive reviews on steam and a 77 metacritic score with over 15.5k people playing the game right now (according to steamcharts.com) Thats a lot of happy customers.
- meinersbur 2y ago
  My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.
  - mrkeen 2y ago
    > My impression is that this is due to their non-robust programming style. It's been 50+ years. I don't think that it's worthwhile just telling the programmer to do a better job. > They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash. This is a pretty big feedback loop: * The programmer puts the null into the code * The code is released * The right conditions occur and the player triggers it * IF DONE SKILLFULLY AND CORRECTLY the game is able to recover from the null-dereference, write it out to a log, and get that log back to the developers. * The programmer takes the null out of the code. If you don't do the first step, you don't get stuck doing the others either.
    - nurettin 2y ago
      50+ years and people still fail to grasp this. You have to put something (an optional, or a default constructed object in a useless state) and all you did was to skip the null check. In case of optional, you introduced a stack rewind or a panic. Everything else stayed the same. Maybe that default even deleted the hard drive instead of crashing. Coding is hard. "just don't code" is not the answer. You can avoid something, that doesn't mean it won't show up in some other fashion.
      - sam0x17 2y ago
        Again, if you disallow unwrapping and panicking at the CI level, you actually force your developers to properly handle these situations.
      - mrkeen 2y ago
        > You have to put something (an optional, or a default constructed object in a useless state) No, you really don't. There is no default number, no default string, no default piece of legislation, no default function.
- kbenson 2y ago
  I can't really comment on the quality of the game or experience or how buggy it feels because I've never played it, but I will say that counting fixed crash situations is a somewhat arbitrary and useless metric. If each of those crashes affected and was reported by a single person or even nobody because no regular person could really encounter it is a vastly different situation than if each of those crashes was experienced by even 1% of the users. The criteria by which something is decided to mention in the patch notes is not always purely because the users care. Sometimes it's because the developers want to signal effort to user and/or upper management. Maybe Mount and Blade was super boggy in the past and is still super buggy now so all the crashes fixed are just an indicator of how large the problem is for them and how bad the code still is. I dunno, you didn't really give any information to help on that front.
  - Repulsion9513 2y ago
    > If each of those crashes affected and was reported by a single person or even nobody Then do you really think they'd be spending time fixing it? (Actually, you know what, they probably would.)
    - kbenson 2y ago
      That's why I had a paragraph mentioning different reasons things might be mentioned. I don't think it's uncommon to find a bug that could cause a crash while working something else, confirm it does crash, and then fix it. If the culture is to mention those things in patch notes even if you're not sure it actually ever caused a user problem, then it will be listed. That doesn't mean all, or even any, of the listed crashes were like that, but it does illustrate that it's hard to know what they actually mean without additional info. (for what it's worth, I'm a long time Tarkov player, so I'm definitely familiar wroth buggy games and apparent development problems with rushing, so this is more a devils advocate position on my part)
  - cultureswitch 2y ago
    Mount & Blade 2 was released very early and despite constant improvement (they keep patching it at a strong pace), it's only slowly evolving. It was even downright unfinished on release, with many game systems claiming to be doing something actually being simply unimplemented. But despite all that it was and is still fairly playable and enjoyable, even at release. A game only needs a great core gameplay loop to succeed, even if large parts of it are completely broken. Interestingly, Taleworlds make their own engine with fairly unique capabilities. 200 players can fight in fast paced, precise melee combat on a single server. Even more than in fast-paced shooters, it can be extremely frustrating for players when the game doesn't behave in exactly the way that you would expect (for example, standing undefended just a few centimeters away from the reach of an opponent's swing, or relying on interrupting their attack with your own landing 100 milliseconds before). They've made their own scripting language for everything related to policy. So this scripting language is what modders interact with. And it is absolutely atrocious as a language, but it serves the purpose well enough.
- raincole 2y ago
  Photoshop does crash. Trust me if you do enough image editing you'll know it's not even a super rare event. They're generally doing a poor job handling the situations where you have no enough storage or RAM. It didn't stop Adobe from being worth 200B.
- CJefferson 2y ago
  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.
- int_19h 2y ago
  And yet the fact that Bannerlord game logic is entirely in C# makes this possible: https://github.com/int19h/Bannerlord.CSharp.Scripting https://github.com/int19h/Bannerlord.CSharp.Scripting which in turn makes it a lot easier and more convenient to mod. Try that with Rust...
- flohofwoe 2y ago
  How many of those crashes were caused by memory safety issues though? A lot of those crashes might simply be called a "panic" in Rust.
hi-v-rocknroll 2y ago
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.
- celdon25 2y ago
  Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.
  - hi-v-rocknroll 2y ago
    Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better choice for such a use-case. * So fast, they really don't need HCR.
    - celdon25 2y ago
      I haven't tried it yet but I've wondered if Elixir might be a good choice for a game server with many concurrent players.
      - hi-v-rocknroll 2y ago
        Definitely and for chat. BEAM/HiPE VM allows native linking using NIFs so it's possible to integrate Erlang or Elixir with C-compatible projects for critical code sections, library interfacing, and perhaps even the majority of a performance-critical game engine as native code. Rustler also exists to write NIFs in Rust. Recall how VMware ESXi core tech was implemented mostly as Linux kernel modules and heavily-modified Linux to turn it inside-out as a type-1 hypervisor.
    - misswaterfairy 2y ago
      Nim does, when tied in with Unreal Engine 5. https://github.com/jmgomez/NimForUE https://github.com/jmgomez/NimForUE https://www.youtube.com/watch?v=Cdr4-cOsAWA https://www.youtube.com/watch?v=Cdr4-cOsAWA
lmm 2y ago
> 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 advantage of that is another question)
- wredue 2y ago
  >Rich type systems make it easy to change your mind about things and make large changes to your code with confidence. 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.
- Kamq 2y ago
  > 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. I don't think this is true. Rust makes it easy to get the refactor right (generally speaking 100% right). But that's not what they're describing. They're describing where the ability to make the refactor fast, even if it doesn't work correctly (in the formal sense of correctly). That is to say, memory leaks and race conditions and all sorts of horrible nastiness may be tolerable during the dev process in exchange for trying out an idea more quickly. This is, of course, significantly more work at the end to patch up all of the things you did, but if you don't have to do the full work on 99/100 iterations, or got to try out more iterations because of the quick turnaround time, that would be considered a win here.
- flohofwoe 2y ago
  Pretty much every compiled language with a static typesystem has that "large-scale refactoring support" though. That's not Rust's USP, on the contrary: a too strongly typed language can make refactoring actually harder than it needs be. The sweet spot is somewhere in the middle (where exactly is up for discussion of course).
harpiaharpyja 2y ago
I had similar thoughts, about Rust being a good match for game engines but not games. Maybe it suggests Rust game engines might want to include an interpreter for some higher level language to actually do the gamedev in. Rust is pretty good for writing PL interpreters (and similar tooling) too, actually.
Zambyte 2y ago
I know you're not asking for recommendations, but Lisp, particularly SBCL, really seems to check all your boxes. I say this as someone who generally reaches for Scheme when it comes to Lisps too. There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games. [0] https://github.com/CodyReichert/awesome-cl?tab=readme-ov-file#game-development https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...
fmbb 2y ago
> It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries. But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios that are researching and prototyping are working on. C++ is not a popular language to implement the actual game in for all the reasons you list. It is too slow to compile and too rigid. The people who actually build the games, make them tick, are all working in visual scripting languages.
- stephc_int13 2y ago
  Visual scripting languages are easy to use and practical for low-complexity code, but they scale very poorly once the complexity increases. Gameplay code is still better written with code, C# or C++ or sometimes Lua.
- antifa 2y ago
  > visual scripting languages I'm surprised no one has made such a language that is designed from the ground up to be used as such for rust. Nim/coffeescript come to mind, but they target non-rust languages. Lua would be close enough if it weren't so alien to everything people like about rust.
  - Silphendio 2y ago
    Someone did actually create a scripting language specifically designed to work with rust: https://rhai.rs/ https://rhai.rs/
Tade0 2y ago
> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code. Not a game developer, but each time I tried to make one not using ECS(or something at least similar in spirit) I quickly found myself not being able to proceed due to the sheer mess in the codebase. How does one normally avoid that?
scotty79 2y ago
> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code. I'd love to see a language built around ECS. I wonder how nice it can be in a language syntax where ECS is the easiest thing you can do.

mrkeen 2y ago

> 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/News/547 | grep "Fixed a crash that" | wc -l 101 Maybe feeling like you're iterating fast isn't the same as getting to the destination faster. Edit: Lol guys calm down with the down-vote party. I was counting crashes, not bugs: $ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a bug that" | wc -l 308 Does your C++ not crash, just theirs?

tedajax 2y ago
This comment is nonsense
stephc_int13 2y ago
Yeah this is a common problem in the industry, we rarely have enough time to refactor what should be considered prototype-level code into robust code.
- hi-v-rocknroll 2y ago
  The game dev industry could form a consortium to launch its own dedicated general purpose language built from scratch to compile very fast like V or Go, run predictability, be much safer, be more reusable, and be extremely productive with the lessons learned from C, C++, C#, and more. Also, I think LLMs will be able to run against code bases to suggest mass codemods to clean things up rather than having humans make a zillion changes or refactoring fragile areas of tech debt. LLMs are already being applied to generate test cases.
  - stephc_int13 2y ago
    I believe that better tooling can help, yes. With refactoring, debugging, creating performance and style reports, updating documentation and a ton of other stuff.
  - jibe 2y ago
    Jonathan Blow’s Jai is an attempt at something like this. It’s looking promising so far!
    - hi-v-rocknroll 2y ago
      Interesting. I went through the primer spec. Appears to be a different kind of D or Go with some key points. Any new language should begin with a specific thesis of specific competitive advantages and problems it solves over existing customary and alternative tools. Kai appears to fulfill this property, so that's a good sign.
    - johnisgood 2y ago
      > It is still in development and as of yet is unavailable to the general public. Is it still the case?
lionkor 2y ago
With Rust and the exact time iteration times, management and deadlines, you end up with the same amount, just theyre panic!() instead. Thats an improvement, sure, but its fighting a symptom.
- mrkeen 2y ago
  With modern languages that take safety more seriously, it's a lot easier to spot places where the code 'goes wrong'. In an older language, you have nothing to tell you whether you're about to dereference null: foo.bar.baz = ...; Even if you've coded it 100% correctly, that line of code still looks the same as code which will segfault. You need to look elsewhere in codebase to make sure the right instructions populated those fields at the right time. If I'm scrolling past, I'll slow down everytime to think "Hey, will that crash?" Compare that with more safety focused languages where you can see the null-dereferences on the page. Unwrap() or whatever it is in Rust. Since they're visually present, you can code fast by using the unsafe variants, come back later, and know that they won't be missed in a code review. You can literally grep for unsafe code to refactor.
- sam0x17 2y ago
  There are a bunch of useful clippy lints to completely disable most forms of panicking in CI. We use this at my work since a single panic could cost millions of $ in our case.
thom 2y ago
Hard to know what TaleWorlds are actually optimising for because half the features of Bannerlord feel like they’ve never been played by a dev let alone iterated on.
bogwog 2y ago
That game (currently) has 88% positive reviews on steam and a 77 metacritic score with over 15.5k people playing the game right now (according to steamcharts.com) Thats a lot of happy customers.
meinersbur 2y ago
My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.
- mrkeen 2y ago
  > My impression is that this is due to their non-robust programming style. It's been 50+ years. I don't think that it's worthwhile just telling the programmer to do a better job. > They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash. This is a pretty big feedback loop: * The programmer puts the null into the code * The code is released * The right conditions occur and the player triggers it * IF DONE SKILLFULLY AND CORRECTLY the game is able to recover from the null-dereference, write it out to a log, and get that log back to the developers. * The programmer takes the null out of the code. If you don't do the first step, you don't get stuck doing the others either.
  - nurettin 2y ago
    50+ years and people still fail to grasp this. You have to put something (an optional, or a default constructed object in a useless state) and all you did was to skip the null check. In case of optional, you introduced a stack rewind or a panic. Everything else stayed the same. Maybe that default even deleted the hard drive instead of crashing. Coding is hard. "just don't code" is not the answer. You can avoid something, that doesn't mean it won't show up in some other fashion.
    - sam0x17 2y ago
      Again, if you disallow unwrapping and panicking at the CI level, you actually force your developers to properly handle these situations.
    - mrkeen 2y ago
      > You have to put something (an optional, or a default constructed object in a useless state) No, you really don't. There is no default number, no default string, no default piece of legislation, no default function.
kbenson 2y ago
I can't really comment on the quality of the game or experience or how buggy it feels because I've never played it, but I will say that counting fixed crash situations is a somewhat arbitrary and useless metric. If each of those crashes affected and was reported by a single person or even nobody because no regular person could really encounter it is a vastly different situation than if each of those crashes was experienced by even 1% of the users. The criteria by which something is decided to mention in the patch notes is not always purely because the users care. Sometimes it's because the developers want to signal effort to user and/or upper management. Maybe Mount and Blade was super boggy in the past and is still super buggy now so all the crashes fixed are just an indicator of how large the problem is for them and how bad the code still is. I dunno, you didn't really give any information to help on that front.
- Repulsion9513 2y ago
  > If each of those crashes affected and was reported by a single person or even nobody Then do you really think they'd be spending time fixing it? (Actually, you know what, they probably would.)
  - kbenson 2y ago
    That's why I had a paragraph mentioning different reasons things might be mentioned. I don't think it's uncommon to find a bug that could cause a crash while working something else, confirm it does crash, and then fix it. If the culture is to mention those things in patch notes even if you're not sure it actually ever caused a user problem, then it will be listed. That doesn't mean all, or even any, of the listed crashes were like that, but it does illustrate that it's hard to know what they actually mean without additional info. (for what it's worth, I'm a long time Tarkov player, so I'm definitely familiar wroth buggy games and apparent development problems with rushing, so this is more a devils advocate position on my part)
- cultureswitch 2y ago
  Mount & Blade 2 was released very early and despite constant improvement (they keep patching it at a strong pace), it's only slowly evolving. It was even downright unfinished on release, with many game systems claiming to be doing something actually being simply unimplemented. But despite all that it was and is still fairly playable and enjoyable, even at release. A game only needs a great core gameplay loop to succeed, even if large parts of it are completely broken. Interestingly, Taleworlds make their own engine with fairly unique capabilities. 200 players can fight in fast paced, precise melee combat on a single server. Even more than in fast-paced shooters, it can be extremely frustrating for players when the game doesn't behave in exactly the way that you would expect (for example, standing undefended just a few centimeters away from the reach of an opponent's swing, or relying on interrupting their attack with your own landing 100 milliseconds before). They've made their own scripting language for everything related to policy. So this scripting language is what modders interact with. And it is absolutely atrocious as a language, but it serves the purpose well enough.
raincole 2y ago
Photoshop does crash. Trust me if you do enough image editing you'll know it's not even a super rare event. They're generally doing a poor job handling the situations where you have no enough storage or RAM. It didn't stop Adobe from being worth 200B.
CJefferson 2y ago
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.
int_19h 2y ago
And yet the fact that Bannerlord game logic is entirely in C# makes this possible: https://github.com/int19h/Bannerlord.CSharp.Scripting https://github.com/int19h/Bannerlord.CSharp.Scripting which in turn makes it a lot easier and more convenient to mod. Try that with Rust...
flohofwoe 2y ago
How many of those crashes were caused by memory safety issues though? A lot of those crashes might simply be called a "panic" in Rust.

hi-v-rocknroll 2y ago

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.

celdon25 2y ago
Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.
- hi-v-rocknroll 2y ago
  Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better choice for such a use-case. * So fast, they really don't need HCR.
  - celdon25 2y ago
    I haven't tried it yet but I've wondered if Elixir might be a good choice for a game server with many concurrent players.
    - hi-v-rocknroll 2y ago
      Definitely and for chat. BEAM/HiPE VM allows native linking using NIFs so it's possible to integrate Erlang or Elixir with C-compatible projects for critical code sections, library interfacing, and perhaps even the majority of a performance-critical game engine as native code. Rustler also exists to write NIFs in Rust. Recall how VMware ESXi core tech was implemented mostly as Linux kernel modules and heavily-modified Linux to turn it inside-out as a type-1 hypervisor.
  - misswaterfairy 2y ago
    Nim does, when tied in with Unreal Engine 5. https://github.com/jmgomez/NimForUE https://github.com/jmgomez/NimForUE https://www.youtube.com/watch?v=Cdr4-cOsAWA https://www.youtube.com/watch?v=Cdr4-cOsAWA

lmm 2y ago

> 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 advantage of that is another question)

wredue 2y ago
>Rich type systems make it easy to change your mind about things and make large changes to your code with confidence. 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.
Kamq 2y ago
> 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. I don't think this is true. Rust makes it easy to get the refactor right (generally speaking 100% right). But that's not what they're describing. They're describing where the ability to make the refactor fast, even if it doesn't work correctly (in the formal sense of correctly). That is to say, memory leaks and race conditions and all sorts of horrible nastiness may be tolerable during the dev process in exchange for trying out an idea more quickly. This is, of course, significantly more work at the end to patch up all of the things you did, but if you don't have to do the full work on 99/100 iterations, or got to try out more iterations because of the quick turnaround time, that would be considered a win here.
flohofwoe 2y ago
Pretty much every compiled language with a static typesystem has that "large-scale refactoring support" though. That's not Rust's USP, on the contrary: a too strongly typed language can make refactoring actually harder than it needs be. The sweet spot is somewhere in the middle (where exactly is up for discussion of course).

harpiaharpyja 2y ago

I had similar thoughts, about Rust being a good match for game engines but not games. Maybe it suggests Rust game engines might want to include an interpreter for some higher level language to actually do the gamedev in. Rust is pretty good for writing PL interpreters (and similar tooling) too, actually.

Zambyte 2y ago

I know you're not asking for recommendations, but Lisp, particularly SBCL, really seems to check all your boxes. I say this as someone who generally reaches for Scheme when it comes to Lisps too. There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games. [0] https://github.com/CodyReichert/awesome-cl?tab=readme-ov-file#game-development https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...

fmbb 2y ago

> It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries. But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios that are researching and prototyping are working on. C++ is not a popular language to implement the actual game in for all the reasons you list. It is too slow to compile and too rigid. The people who actually build the games, make them tick, are all working in visual scripting languages.

stephc_int13 2y ago
Visual scripting languages are easy to use and practical for low-complexity code, but they scale very poorly once the complexity increases. Gameplay code is still better written with code, C# or C++ or sometimes Lua.
antifa 2y ago
> visual scripting languages I'm surprised no one has made such a language that is designed from the ground up to be used as such for rust. Nim/coffeescript come to mind, but they target non-rust languages. Lua would be close enough if it weren't so alien to everything people like about rust.
- Silphendio 2y ago
  Someone did actually create a scripting language specifically designed to work with rust: https://rhai.rs/ https://rhai.rs/

Tade0 2y ago

> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code. Not a game developer, but each time I tried to make one not using ECS(or something at least similar in spirit) I quickly found myself not being able to proceed due to the sheer mess in the codebase. How does one normally avoid that?

scotty79 2y ago

> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code. I'd love to see a language built around ECS. I wonder how nice it can be in a language syntax where ECS is the easiest thing you can do.