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

151–160 of 247 posts

Re: Why Rust Is the Future of Game Development

#151

Post by suprfnk »

jayd16 wrote: post #15

I think Rust would eat into C++ more than C#. Microsoft is pushing C# and the tooling fairly hard right now. Performance is pretty good and even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. I don't think the population of studios that chose C#'s performance and convenience over C++ but would now choose Rust is all that large. But hey, lets start talking about bindings…

> even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time.

Just curious; what's the tooling gap between Rust and C#, according to you?

I work in C# profesionally, and dabble in Rust, and haven't really found Rust tooling lacking yet -- but maybe that's because I'm only working on small hobby projects.

Re: Why Rust Is the Future of Game Development

#152

Post by bsoft16385 »

naikrovek wrote: post #141
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…

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 the business that are more like enterprise software. If you look at something like League or WoW, you have titles that are continuously evolved over many many years, and getting the infrastructure right matters a lot.

Re: Why Rust Is the Future of Game Development

#153

Post by some-guy »

naikrovek wrote: post #141
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…

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…

In enterprise, if you introduce a bug that causes a business to not function, you must fix it right away because you may receive lost business and possibly a lawsuit.

In game development, if you introduce a bug that causes a game to not function, you must fix it right away because you may receive lost business and possibly a death threat.

Re: Why Rust Is the Future of Game Development

#155

Post by polytely »

skadamat wrote: post #140

I'm more skeptical to be honest. Jonathan Blow discusses the unique programming & design challenges that most (not all) video games face in this great podcast episode: https://oxide.computer/podcast/on-the-metal-9-jonathan-blow/

This is such a good episode, would highly recommend this to any hackernews reader.

Re: Why Rust Is the Future of Game Development

#156

Post by andrewmcwatters »

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…

No, it's that most people won't benefit from it.

You can't just take any type of game logic and parallelize it either, since there are types of game logic that aren't just dependent on the previous frame. You may be wholly dependent on something that has just occurred earlier in the frame, but has not been networked to clients yet.

Re: Why Rust Is the Future of Game Development

#158

Post by rrobukef »

nine_k wrote: post #114
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…

Unfortunately, Rust has limitation on what it can prove to be safe using the ownership and lifetimes approach. One of the simplest things which can't safely be done in Rust is a doubly-linked list. I'm certain that Rust will help some parts of game development a lot, but I'm also certain that game developers sometimes use tricks safety of which cannot be proven by Rust's type system.

I haven't found any problem where a linked list could not be replaced with a vector of index-element pairs (or triples) with a reductions in allocationd.

I'm open for discussion as I haven't been able to convince myself of the use of any linked list.

Re: Why Rust Is the Future of Game Development

#159

Post by orf »

Animats wrote: post #100

I'm ambivalent on this. Right now, I'm writing something 3D game related. It needs considerable parallelism. The existing tool in this area is mostly single threaded, it's a mess internally, and everyone who looks at it is scared to try to parallelize it. So I'm writing in Rust. Safe concurrency is a plus. There are some other wins. You can be bolder about not copying things. When decoding an incoming packet with a l…

> The type of error objects is still a mess. Rust needs something like Python's exception type hierarchy and a consistent way to convert special error types into more general ones. I notice there's a Rust working group on error handling, again.

Anyhow[1] and thiserror[2] really help here, no?

1. https://github.com/dtolnay/anyhow 2. https://github.com/dtolnay/thiserror

Re: Why Rust Is the Future of Game Development

#160

Post by iphorde »

sgift wrote: post #157
iphorde wrote: post #150

Yea, don't count on it. I spent 3 months getting a game up on Ogre3D, and no thank you. I'll stick with C++.

Ogre3d is written in C++? What do you want to tell us?

Crating is horrible. How about that to start with. String -> Str() -> String. Macros? Really Macros? Bindgen doesn't work, exceptions are not handled properly, creating a thin layer between Rust and Ogre3D was seriously inconvienant.

I heard all of the hype, and I completely fell for it. This is not a language for game developers (35 years experience in game development here).

Oh, how about some simple data structures you need. Like developing dynamic graphs with pointers needed to and fro. What a serious PIA.

Post reply on HN