Live data from Hacker News

Why Rust Is the Future of Game Development

thefuntastic.com

141–150 of 247 posts

Re: Why Rust Is the Future of Game Development

#141
post #93
post #47

Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefi…

Isn't this basically saying that you can't have the compiler guaranteeing you aren't including bugs in those optimizations / global variable usage because it's more efficient to just write and then ultimately ship some bugs? To me it seems like this would require a significant adjustment in how certain problems are approached, but the outcome would likely be more effective development as you could eliminate a lot of…

Game development problems are very often global state manipulation problems. In a given game, many things may have genuine need to be able to read and write to multiple global variables once per frame (that's usually somewhere between 30 and 240 times per second), and that is after all unnecessary global state has been removed.

Enterprise developers often look very poorly upon the solutions that game developers come up with, but game development is an entirely different realm, very far away from any enterprise software development stuff I've worked on, or even heard of. I've looked. I didn't believe this myself for a long time.

Games have very strict performance requirements that enterprise software simply does not have. Virtually no one in enterprise software cares about performance, really, and certainly not as a primary concern. Enterprise developers will often just throw more RAM or CPU at the problem until it goes away. I mean why not, that's an option that is on the table. Of course they're going to take that route sometimes. Game developers can't do this, because they're not in control of the hardware that their game is run on.

Games are often scored on how good they look, and how well they perform. Game sales are a function (at least partially) of the score/rating that the title attains, and game developers are paid out of the money that game sales provide. Concerns that do not result in an improved critical game rating are secondary. So, there is a very strong hunger there for performance which simply does not exist in other software development fields. Until enterprise software developers are paid based on the performance of the applications they write, no one who has NOT developed a game and fought performance problems along the way can ever understand.

There are games which consume nearly the entire bandwidth between CPU and RAM on a modern PC -- continuously -- and this is after many optimization passes to prune the data that is needed from RAM at any particular moment in time and make it as small as possible.

Game development is just an entirely different thing than any other kind of software development. Languages created with general purpose use in mind may achieve (and have achieved) some success in game development, but those languages will get in the way of the developer at least as often as they aid the developer. Same rule applies for general software engineering rules.

Re: Why Rust Is the Future of Game Development

#142

I haven't worked in the games industry so please correct me if I'm wrong, but isn't game development culture one of rushing crude hacks out the door at the last minute? Rust seems like a poor 'culture fit' in this regard.

From what I can gather (from the outside) this has changed over the years. Games are not monoliths anymore and some parts have to work for successors or other games based on the same tools, so "things work for more than the bare minimum" has become more important over time. I'm sure there's still more than enough throwaway code, but that is probably not done in C++ currently either, but in some kind of scripting language.

Re: Why Rust Is the Future of Game Development

#143
post #93
post #47

Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefi…

Isn't this basically saying that you can't have the compiler guaranteeing you aren't including bugs in those optimizations / global variable usage because it's more efficient to just write and then ultimately ship some bugs? To me it seems like this would require a significant adjustment in how certain problems are approached, but the outcome would likely be more effective development as you could eliminate a lot of…

That's counter productive when it comes to gamedev. Most of the code you write for a game is going to be thrown out at some point. Being able to get the idea onto the screen and iterate rapidly is worth a lot more than not having a dev build crash after a while. Make it work, make it right, make it fast except the last two are usually transposed in gamedev.

Re: Why Rust Is the Future of Game Development

#144

Earlier quoted context omitted.

No, it’s saying that you can do clever memory optimizations that the Rust compiler won’t let you do.

you can do all of that in `unsafe` blocks

What then would be the advantage in using Rust?

Re: Why Rust Is the Future of Game Development

#145

Earlier quoted context omitted.

> It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact, multiplayer and all its challenges have nothing to do with Rust. I think multiplayer is an area where you'd want "fearless concurrency". Rust could do well here.

Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. A better argument might be Rust and Vulcan, though. Even still, you can get very far with just using OpenGL.

> Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust.

Is that it doesn't benefit, or is it that the benefits are too hard to achieve given the nature of memory issues with games that like to have global state and are written in C++? A lot of games do a bunch of things every frame and then increment state. Those can all be parallelized as they only depend on the previous frame's state.

Re: Why Rust Is the Future of Game Development

#146
post #135

Earlier quoted context omitted.

(They did but have since stopped.)

Do you have any articles or any info on why they decided to stop using Rust? I remember seeing things about them using Rust but never saw anything about them not using it and I'm curious.

They made a few offhand comments on Reddit, but that's it.

They decided that having a unified tech stack for the games themselves was worth more than Rust's advantages. Basically, they decided to re-build Witchbrook on top of Wargroove's engine.

That being said, I guess I should have put an asterisk on there; they aren't using Rust in game anymore, but they are still (apparently, last we heard) using Rust for server-side components. Wargroove's servers are implemented in Rust.

Re: Why Rust Is the Future of Game Development

#147
post #90
post #86

Earlier quoted context omitted.

GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.

>GC is a no-go, as it causes unacceptable frame-rate dips. Does it, though? I've played titles written in Java and achieved smooth 60 fps back in 2008.

Those games will have been written in such a way as to avoid allocations like the plague, giving the GC very little to do. Sometimes your game can be written that way -- sometimes it can't.

Re: Why Rust Is the Future of Game Development

#148

I haven't worked in the games industry so please correct me if I'm wrong, but isn't game development culture one of rushing crude hacks out the door at the last minute? Rust seems like a poor 'culture fit' in this regard.

Common game industry joke:

Q: What does a game company call a teetering tower of ugly hacks on top of ugly hacks?

A: Shipped!

Source: 5 years in the games business. The game development process can get messy. My studio doesn't crunch, but elsewhere crunch is the norm, and does anyone think the code is gonna stay beautiful during endless crunch? The old-timers here all have their war stories they tell of last minute ugly hacks tossed in just to get a game out the door on time.

Re: Why Rust Is the Future of Game Development

#149
post #86
post #80

When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Menu) being long, then I question why Java isn't the future. By all accounts Java has the most sophisticated runtime out there, it has all the safety features of Rust without fucking around with the borrow checker which seems like a huge piece of complexity just…

GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.

Advanced garbage collectors have short pause times. In [1], the author cites Twitter statistics showing approximately two 0.5ms "pause" times per GC cycle for the go language garbage collector, and during the GC cycle only 25% of the CPU was used by the GC. It doesn't seem like this is going to cause frame-rates to dip.

To be fair, every application is going to differ, and perhaps games need tighter control of memory than a high performance GC is capable of, but automatic GC does make programming a lot easier.

[1] https://blog.golang.org/ismmkeynote

Post reply on HN