13 ms·
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 developme
by dimes 6y ago
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 benefits of using Rust over C++ for game development are unclear in these regards.
- gameswithgo 6y agoRust over C++ for single player games is definitely of questionable benefit right now. For multiplayer games I think a much more compelling case can be made, certainly on the server if not both server and client.
- gtaylor 6y agoWhat makes games more likely to lean on global state than other kinds of applications?
- Animats 6y agoClassic 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.
- moth-fuzz 6y agoI feel like this is an underrated sentiment. A lot of Rust’s design decisions (lack of inheritance, borrow checking, immutability by default) are complete non-issues when you’re reading a JSON string into some business struct or an enum and then serializing it back out to a DB again. Everything can be flat data types and functions can be pure and stateless. But not if you actually have to keep things around in-memory. Then all the sudden your functions can’t be pure, you have to add additional parameters to each method to account for additional state, and you can’t design flat structs anymore since you have many different object types and they have to go somewhere and you can’t just declare N variables line by line. So you have to grapple with the limited definition of trait objects, or non-extensible enums, or throw everything out and use Any. It gets complicated.
- gameswithgo 6y agoMaybe games are more likely to lean on global in memory state, instead of the global state being in a database.
- samatman 6y agoThe main problem which global state introduces, is making the bad assumption that there will only be one example of a given sort of data. In games, that's a safe assumption for many parts of the system, since you're definitely only going to be running one instance of the game world at a time. So making that state private just means you have to pass around references to it on the stack, and keep track of what you're doing.
- adamnemecek 6y agoGenerational arenas solve a lot of your problems.
- zyxzevn 6y agoAgreed. The extremely slow compile time and extremely limited data flexibility is blocking rapid development. As an alternative to C++, JAI is more promising in my opinion.
- Arainach 6y agoAt this point, does anyone seriously expect JAI to ever be released? It's been 6 years.
- samatman 6y agoI think it's more likely than not, yes. Jonathan Blow has a reputation for taking a rather long time to release something eagerly awaited, and the result being impressive and critically acclaimed. I hope Jai will be the same way. We'll see what happens.
- Arainach 6y agoSure, but that works for a game where you can release it once and then everyone consumes it. Languages are ecosystems. They have tools, and libraries, and shims to integrate with other tools. They need evangelism. They grow with community involvement. As far as I know, no one has ever released a new language that was perfect in its initial release - there has always been feedback and syntax quirks that get addressed in future versions. If a "0.1" compiler with warts was out there for people to play with and improve on, I'd have faith. But if you can't get a demo that you're willing to share within 5+ years, then I have very little faith you'll ever release anything, and absolutely zero faith that you'll be able to compromise your mental idea of perfection enough to build a thriving community around a product.
- pjmlp 6y agoJai is foremost for Jonathan Blow's own usage in his games, whatever happens with it beyond that I doubt he couldn't care less. There are private betas available by the way.
- deleted 6y ago
- Causality1 6y agoRust is just one of the current Silicon Valley memes at the moment. You could hit the front page with an article titled "Why Rust could mean you'll never run into another broken McDonald's ice cream machine again". "Machine learning let me train my dog twice as fast." "How AI will revolutionize marriage counseling" "Study: Using Go results in 10% better senior programmer retention"
- jrsj 6y agoIsn'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 cost that's spent dealing with bugs in the future.
- penagwin 6y agoI'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.
- steveklabnik 6y agoLeaking memory is safe in Rust. There is also no GC.
- coddle-hark 6y agoNo, it’s saying that you can do clever memory optimizations that the Rust compiler won’t let you do.
- steveklabnik 6y agoWhat kinds of things, specifically?
- kbenson 6y agoActually "won't let you do" or "makes you clearly mark where you did those things"? That is, are you referring to things it doesn't actually support doing that you want/need to do, or just that it's unsafe?
- efficax 6y ago
- stcredzero 6y agoLack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. One of my first experiences interacting with a golang programmer, was in the context of my game server project. As an optimization, I had a race condition in the code that disconnected clients. After all, if the connection is about to die, I don't care if it dies in frame n, n+1, n+2...etc. This golang programmer was totally out to tell me I'm stupid, ugly, and bad, because I should always be using -race and always have 0 race conditions. Like, it would have been one thing if he could've had a cogent discussion around how the build should be free of warnings, because that makes such signals super clear, but no, it was just pure dogmatism. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. In ECS, why should object ownership be an issue? The Systems can just own everything.
- gameswithgo 6y agogiven that a behavior in a race condition can be undefined, he or she may have been right. You might get the merely delayed behavior your want now, but something else on a future version of the compiler. Perhaps you are aware of all these subtleties and knew it was ok in this case.
- stcredzero 6y agogiven that a behavior in a race condition can be undefined, he or she may have been right If the other party really had an interest in understanding, and not just condemning, he would've looked for more facts. He wouldn't have been talking over me and cutting me off.
- MaulingMonkey 6y ago> Lack of safety is a feature in game development, Bullshit. How many games have had releases delayed and major wrenches thrown into marketing plans because of progress ruining heisenbugs? How many failed certification passes from banal data races and other undefined behavior? We trap UI in actionscript or javascript, and gameplay programmers in other scripting languages - perhaps python or lua - for faster iteration times, hot reloading, and safety. Because it's difficult enough to keep the build stable when it's merely all the engine programmers who should know better screwing things up with C++. This results in large messes of poorly performing, poorly optimized, garbage-collector laden code that Rust would handle much faster. We're leaving lots of performance on the table, often for little other purpouse than "safety". Console first day patches may have taken off some of the pressure for getting the first release right, but handhelds aren't always online and still have a pretty high bar. > the optimizations required are typically unorthodox Rust's `unsafe` keyword and intrinsics let you do all the unaligned intrinsic-laden data-racey technically-undefined-behavior micro-optimizations you might want to do in C++ in Rust just fine. It'll hopefully trigger a more stringent code review and force you to justify your pile of bugs, but that's a good thing. Or you can skip the code review if your entire company really disagrees. > a super strict language slows development down C++ is also super strict, just in an unenforced-at-compile-time way that result in plenty of late nights chasing heisenbugs. Don't get me wrong - language strictness can slow development down - but that's one of the reasons people eschew C++, too. As for C++ vs Rust? I'm going to spend more time and be far less certain of catching the issues in a C++ code review than I would be in a Rust code review. And while it took a few months for my development speed in Rust to catch up with my development speed in C++, it did happen. Rust merely forces you to acknowledge when you're being sloppy. > Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. I have solved so many sources of endless heisenbugs by eliminating some of these global variables. John Carmack as far back as 2013 was using phrases like "horror show" to describe similar parts of his own codebases[1] and has been agitating for more functional styles. An unclear mudball of global variables is entirely possible - and easy - in Rust if you really want that. You merely need to make it either thread safe, or resort to `unsafe` if you really can't tolerate the overhead of not having threading-related heisenbugs. [1]: https://youtu.be/1PhArSujR_A?t=125 https://youtu.be/1PhArSujR_A?t=125