Why Rust Is the Future of Game Development • Hacker News Board

Re: Why Rust Is the Future of Game Development

#121

Post by Animats » Mon, Nov 09, 2020, 7:41 PM UTC

gtaylor wrote: post #67

dimes wrote: 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…

What makes games more likely to lean on global state than other kinds of applications?

Classic webcrap is near-stateless, with state in the database only. That way, any server in the farm can handle the next client request. Games have a consistent world to maintain in memory. Sometimes a really big consistent world.

Re: Why Rust Is the Future of Game Development

#122

Post by modo_mario » Mon, Nov 09, 2020, 7:43 PM UTC

lstodd wrote: post #9

Let me tell you that the future of game development is in developing games, and any particular language has nothing to do with it. Does anyone care what language were any particular games that keep being replayed or remembered fondly? No. Never.

Is it me or are you bringing up something completely unrelated there? because it baffles me why

I don't think the writer was talking about the the language somehow directly being related to a gamers experience. He's talking about building complex game engines and the like and the benefits he thinks Rust provides there...

Re: Why Rust Is the Future of Game Development

#123

Post by penagwin » Mon, Nov 09, 2020, 7:43 PM UTC

jrsj wrote: post #93

dimes wrote: 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…

I'm not familiar with rust or if their `unsafe` block mitigates the issue somewhat - I know that for example with memory management, you'd rather ship a game that leaks a bit of memory (since games are generally only open for a few hours at a time, not a lot of memory should be leaked) in exchange for less stutter/performance issues from the GC.

Re: Why Rust Is the Future of Game Development

#124

Post by axegon_ » Mon, Nov 09, 2020, 7:43 PM UTC

adamnemecek wrote: post #74

axegon_ wrote: post #64

Full disclosure: game development beyond the cli-based games and some simple asteroids-like games are the most I've ever done with games. I find them incredibly boring, both to make and play(kind of ironic considering up untilrecently I was working as a developer for a company that made games and I worked there for 8 and a half years). But 3 weeks ago I switched jobs and I am using rust in my current workplace, again…

Rust is progressing at a faster pace than C++.

Indeed, but that's also it's Achilles' heel at this point: it is progressing incredibly fast and most people will have a second thought about using something that might change drastically six months down the line. As I said I love rust and I'm incredibly happy to be using it on daily basis and the company has voted enough confidence in the project but if I were to start something on my own, I will most likely have this fact lurking at the back of my mind.

Re: Why Rust Is the Future of Game Development

#125

Post by steveklabnik » Mon, Nov 09, 2020, 7:44 PM UTC

penagwin wrote: post #123

jrsj wrote: post #93

Earlier quoted context omitted.

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…

I'm not familiar with rust or if their `unsafe` block mitigates the issue somewhat - I know that for example with memory management, you'd rather ship a game that leaks a bit of memory (since games are generally only open for a few hours at a time, not a lot of memory should be leaked) in exchange for less stutter/performance issues from the GC.

Leaking memory is safe in Rust. There is also no GC.

Re: Why Rust Is the Future of Game Development

#126

Post by stunt » Mon, Nov 09, 2020, 7:46 PM UTC

It really depends on which part of "Game Development" you are talking about. What most of the people agree is that Rust can deliver value to the core and to the performance focused components in the game engine. I assume that's what this article is talking about too. But beyond that it's hard to see it eating the market in other areas.

You really want to have some easy to find average coders that can pretty much script your game on top of an engine and framework, and you don't want to spend way too much on them. It could be a different story for some multiplayer AAA games since they have enough lifetime to become mature and start to take every optimization opportunity.

Re: Why Rust Is the Future of Game Development

#127

Post by rhodysurf » Mon, Nov 09, 2020, 7:48 PM UTC

steveklabnik wrote: post #101

rhodysurf wrote: post #88

Earlier quoted context omitted.

OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below

Isn't it a use-after free? (I haven't had time to compile and run it) You have a temporary std::string, pointed to by a string_view, which means that it's freed, and the view is dangling, and then used when printing things out.

So thats what I initially thought but then I ran it and it works so IDK anything anymore.

Re: Why Rust Is the Future of Game Development

#128

Post by rhodysurf » Mon, Nov 09, 2020, 7:49 PM UTC

clappski wrote: post #106

rhodysurf wrote: post #88

Earlier quoted context omitted.

OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below

The issue isn’t anything to do with copying - the issue is that a string_view is a non-owning reference, and that std::string on the right side is an rvalue. Meaning that when you deref the char* in the string_view you’ll segfault or summon demons or something.

Yeah I expected a segfault too... but it didnt happen for me and printed fine so I was confused.

Re: Why Rust Is the Future of Game Development

#129

Post by k__ » Mon, Nov 09, 2020, 7:50 PM UTC

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.

Re: Why Rust Is the Future of Game Development

#130

Post by steveklabnik » Mon, Nov 09, 2020, 7:52 PM UTC

rhodysurf wrote: post #127

steveklabnik wrote: post #101

Earlier quoted context omitted.

Isn't it a use-after free? (I haven't had time to compile and run it) You have a temporary std::string, pointed to by a string_view, which means that it's freed, and the view is dangling, and then used when printing things out.

So thats what I initially thought but then I ran it and it works so IDK anything anymore.

UB can do anything, including something that seems like it works.

Just because the memory has been deallocated doesn't mean that the bytes there were changed. The pointer may still point to them, and it may still "work."