Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

491–500 of 996 posts

Re: Leaving Rust gamedev after 3 years

#491

Earlier quoted context omitted.

I'd say the inertia is far more social than codebase size related. Right now whilst there are pockets of interest there is no broader reason to switch. Bevy as the leading contender isn't going to magic it's way to being capable of shipping AAA titles unless a studio actually adopts it. I don't think it's actually shipped a commercially successful indie game yet. Also game engines emphatically don't have to be huge.…

> Also game engines emphatically don't have to be huge. Look at Balatro shipping on Love2d. Balatro convinced me that Love2D might be a good contender for my next small 2D game release. I had no idea you could integrate Steamworks or 2D shaders that looked that good into Love2D. And it seems to be very cross-platform, since Balatro released on pretty much every platform on day 1 (with some porting help from a third p…

There’s a pretty big difference between the Playdate and anything else in performance but also in requirements for assets. So much so I hope your idea is scoped accordingly. But yeah Love2d is great.

Re: Leaving Rust gamedev after 3 years

#492
post #76

Earlier quoted context omitted.

> Unity is so good and quite affordable, basically there’s zero upfront risk of using it. Other than the absurd license changing shenanigans they tried to shove through recently. Hopefully they learned their lesson.

Unity learned that they have to turn the temperature up slower. They kept the new license that everyone was mad about but just made it so you can keep your current license if it's cheaper for you. No doubt they'll be tweaking these values over time.

It was changed to being able to keep the old license if you don't upgrade to Unity 6 or beyond. They added 2.5% revenue share as an option to the flat runtime fee to make sure you can't end up in a situation where you are losing money per user just from the runtime fee alone. Unity by default charges for whichever ends up cheaper.

https://unity.com/pricing-updates

Re: Leaving Rust gamedev after 3 years

#493

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

Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.

They have an interpreter mode now that is quite good and should be well-suited for these situations

Re: Leaving Rust gamedev after 3 years

#494

Earlier quoted context omitted.

Disagree the adoption of C++ was more about Moore's law than ecosystem, although having compilers that were beginning to not be completely rubbish also helped.

I worked on many of Activision's games 1995-2000 and C++ was the overwhelming choice of programming language for PC games. C was more common for console. In 1996 the quality of MSFT IDE/ Compiler, plus the CPUs available at the time was such that it could take an hour to compile a big game. By 1998 it was a few minutes. As I recall I think MSFT purchased another companies compiler and that really changed Visual Studi…

I was a teenager at that point. I learnt C in the early 90s and C++ after 96 IIRC. Didn’t start professionally in games until 2004 though!

Re: Leaving Rust gamedev after 3 years

#495

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

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

Re: Leaving Rust gamedev after 3 years

#496

Earlier quoted context omitted.

Yeah, OOP makes sense for games. The language will matter a bit for which one takes off, but anything will work given enough support. Like, Python doesn't inherently make a lot of sense for data processing or AI, but it's good enough.

OOP kind of goes out the window when people start using entity component systems. Of course, like the author, I'm not sure I'll need ECS since I'm not building a AAA game.

Had to look up ECS to be honest, and it's pretty much what I already do in general dev. I don't care to classify things, I care what I can do with something. Which is Rust's model.

Re: Leaving Rust gamedev after 3 years

#497
post #247

Earlier quoted context omitted.

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

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.

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.

Re: Leaving Rust gamedev after 3 years

#498
post #46

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

Garbage collection causes performance issues.

Re: Leaving Rust gamedev after 3 years

#499
post #358

Earlier quoted context omitted.

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

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

Again, if you disallow unwrapping and panicking at the CI level, you actually force your developers to properly handle these situations.

Re: Leaving Rust gamedev after 3 years

#500
Jesus, now that's what I call comprehensive.

On the "hot reloading" remark: I believe that, to some extent, compiled languages that lean into metaprogramming are innately at odds with the concept of hot reloading. You're spitting out a (mostly) monolithic binary - rewriting that on the fly just isn't going to be reliable beyond an extremely basic level, and shoving it all into some kind of VM for the purposes of hot reloading introduces variance and general performance overhead that both mean that the "hot reload" environment is no longer an accurate depiction of the real application's behavior.

Post reply on HN