Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rust Is the Future of Game Development

thefuntastic.com

Post reply on HN
Print view View original

161–170 of 247 posts

Re: Why Rust Is the Future of Game Development

#161

Post by sgift »

RcouF1uZ4gsC wrote: post #2

> Way back around 2010, Mozilla was frustrated by the state of development in Firefox, a massive software project written mostly in C++. Despite best practices > Even so, manual memory manipulation is easy to get wrong, Even predating C++11, you should not have been doing manual memory management. I don’t think Mozilla was following best practices. IIRC, there were pointers everywhere. Even before C++11 best practice…

This is not a theoretical problem, it has been researched and the results are not encouraging even for "modern" C++.

Either some of the biggest software companies (Mozilla, Microsoft, Google) are all incompetent or there is a problem with C++ in the real world which still hasn't changed despite "you only need to follow best practices in C++".

Re: Why Rust Is the Future of Game Development

#162

Post by randartie »

andrewmcwatters wrote: post #115
AsyncAwait wrote: post #107

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.

I believe Bevy (rust game engine) does leverage multi-threading for running game code (most 'data oriented' frameworks do). The most popular older engines like Unity do not (unless using the experimental DOTS framework).

So, the phrase "a tremendous amount of game code doesn't benefit from multithreading" is actually true since most game code is in unreal/unity, but it's not a hard constraint for all game engines.

Re: Why Rust Is the Future of Game Development

#163

Post by dxuh »

mlindner wrote: post #145
andrewmcwatters wrote: post #115

Earlier quoted context omitted.

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…

Games code is very often about objects interacting. Especially the expensive stuff (collision/physics and then probably AI). Games don't use global state, because they use C++ and everyone is so bad at programming, but because that's what fits the problem domain.

Not to be condecending, but you should try making a game and see how well that parallelization idea of yours turns out.

Re: Why Rust Is the Future of Game Development

#164

Post by dxuh »

k__ wrote: post #129

Rust is in an interesting place right now. It's something that can compete with C/C++, but has a community as good as Ruby. No other programming language has both. With the diaspora of Rust engineers from Mozilla, I'd guess things only to improve even further.

I think Rust is actually pretty cool and I have tried it myself for a few small things, but it's definitely the most obnoxious programming language community out there (which does not mean, at all, that everyone that is a part of that community is obnoxious). Remember that "Rewrite it in rust" is a meme.

Re: Why Rust Is the Future of Game Development

#166

Post by andrewmcwatters »

randartie wrote: post #162
andrewmcwatters wrote: post #115

Earlier quoted context omitted.

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.

I believe Bevy (rust game engine) does leverage multi-threading for running game code (most 'data oriented' frameworks do). The most popular older engines like Unity do not (unless using the experimental DOTS framework). So, the phrase "a tremendous amount of game code doesn't benefit from multithreading" is actually true since most game code is in unreal/unity, but it's not a hard constraint for all game engines.

I think there is without a doubt a space for it. Multithreading in today's game engines should be commonplace, I think. And that's outside of the obvious threads like main and audio.

The problem is that most naive "game engines" which provide nothing more than bindings to OpenGL/bgfx, OpenAL, Box2D, etc. and are really just "game libraries," don't even provide things like out-of-the-box multiplayer or level loading, so the idea that they're going to make the leap from providing basically nothing to providing mechanisms for multithreaded game logic, which requires some sort of gamerules/gamemode abstraction first is not something I think you'll see in practice.

Most game libraries or game frameworks like these only provide things like load, update, draw callbacks with some nice bindings.

Re: Why Rust Is the Future of Game Development

#167

Post by iphorde »

shrimp_emoji wrote: post #133
jokoon wrote: post #118

Sorry, but the learning curve of a programming language matters a lot. It's already hard enough for people to read and write code, so to learn another hard language like rust is not something you do lightly. Rust is a cool language, but it's a cool tool, nothing more. I'd rather see the ownership process implemented in some C/C++ dialect. I'm not entirely sure, but I think that C++ concepts, in a way, have the same g…

I think Rust is actually much easier to use than C/C++. Sure, the borrow checker can be a pain, but the tooling and design is light years ahead. Moreover, C++ is actually one of the most difficult languages to use.

"C++ is actually one of the most difficult languages to use"

That is your opinion, and one shown time and time again is not true.

Re: Why Rust Is the Future of Game Development

#168

Post by ImprobableTruth »

andrewmcwatters wrote: post #34

This article doesn't actually talk about "Why Rust Is the Future of Game Development." You could have taken out the game development piece, and it still doesn't talk about "Why Rust Is the Future of Development," more than talking about Rust features themselves. I should be able to complete the sentence, "Rust is the future of game development because...," but I can't in any meaningful way. Here are the highlights of…

>It may come as a surprise, but you basically have to bake networking into the engine

I'm not sure what you mean? Are you saying bevy's architecture isn't fitting?

Not to mention that you evidently don't _have to_ do this, seeing as how in Unity you're basically forced to work with raw sockets.

Re: Why Rust Is the Future of Game Development

#169

Post by blub »

bsoft16385 wrote: post #152
naikrovek wrote: post #141

Earlier quoted context omitted.

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…

The one thing I will note is that most of what you have said about performance is relevant primarily in the AAA game space (and in higher end mobile titles, which increasingly look like AAA games). In the indie space, you see a lot more titles where performance is a secondary consideration. The concept (and the style of the visuals) is often more important than having cutting edge graphics. There are also segments of…

"In the indie space, you see a lot more titles where performance is a secondary consideration"

With the added mention that the game still has to run smoothly, otherwise it's extremely annoying, no matter how great the concept.

Re: Why Rust Is the Future of Game Development

#170

Post by iphorde »

thom wrote: post #109

Realistically, do current practices even work for game development? Obviously many games are wildly profitable, but the amount of human suffering and crunch time that goes into the release of an AAA title, and indeed into its day zero multi-gigabyte patch to make it actually playable, seems to imply that we should at least be open minded. But also I suspect many of the issues aren't just your choice of language.

Crunch time has nothing to do with the language. We're not fighting the language. We're fighting last minute requirements, design changes, etc. My favorite that always happens, a complete change to the UI. I've never been on a project were it didn't happen.
Post reply on HN