191–200 of 247 posts
Earlier quoted context omitted.
>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.
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.
I really liked the community chat of Rust. For all beginner questions there is someone standing by to answer it in under 10 minutes. Sure, Rust is hard but having people explain everything to you in a chat when you're stuck is worth gold.
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…
A lot of the time, a game's bug surfaces in a way that will never cause a crash: it's just undesired behavior. At some level, the behavior can be defined in terms of "must" and "cannot" constraints, RFC-style.
And in theory you could do some kind of automatic verification of each behavior. But...the majority of the plumbing of the game isn't in the rule logic itself - almost all of the rules are simple. It's in making sure that the mutations produced by one rule will flow neatly into the next, without introducing some form of synchronization bug. This is a real minefield because you're often iterating over lots of similar elements, and it can look like you can bundle their update code to look "clean" or present an opaque interface, but then in practice, you need to split out the iteration differently to resolve a dependency issue.
Developers responded to this by introducing an event-bus abstraction, with bubbling and priorities and all the bells and whistles. But that doesn't really solve having dependencies, it just presents another way to surface a scripting layer.
Repeat this class of problem enough times and you will start inlining the bulk of the update into a single main loop, because that makes manual review of the dependencies more of a spatially engaging process, one where you don't have to provide new boilerplate so that the build process can tell you that you screwed up: instead you just look carefully, see that the ordering is wrong, and shovel around the block of code. Done.
And while you can do this in Rust, it renders a great deal of the language irrelevant, because the features it helps most with are those parts where you want tighter access control across function boundaries. When you start leveraging that access model, behavioral changes can start to take hours instead of seconds, which makes it appropriate for inner-layer backends that need deep optimization, but ergonomically terrible for the greenfield case, which is what games need to bend towards early in production when major features might be changing.
Personally, I'm betting on Haskell - for indie dev in particular where I want to manage huge amounts of complexity as an individual. This is partially because I've been programming Haskell professionally for 5+ years so I'm over the learning curve and well into the realm of efficiency gains. The GHC RTS is akin to the Lua layer and handles all the high-level logic. For storage and compute-intensive things, we can dro…
I could see this with Idris, but Haskell's lazyness is just too unpredictable for anything you wouldn't use a scripting language for. People have been trying to get gamedev done in Haskell for like a decade with virtually nothing to show for. The LambdaCube 3D guys have been working on it for ~8 years and last I've seen they couldn't even get quake 3 graphics to render smoothly.I haven't seen any noticeable developme…
Laziness really isn't an issue. Especially when writing FFI/low-level Haskell. I suspect the heavy-lifting will be written in a more performance-conscious style. And a lot of it will be deferring to industry-standard C libraries. And then you're right, idiomatic Haskell would have its place in the scripting layer.
I honestly don't think there's anything inherent to Haskell that stops it from being used to make high-quality commercial video games. So my plan is to try to build those in Haskell and let the libraries and infrastructure fall out (as it always nicely does using Haskell in my experience.) Honestly, developing high-quality games is more bound by art & creativity than Haskell.
Let me tell you that most C++ game dev never heard of Rust, so imagine how long it's going to take for Rust to be something usable in that domain? Right now in the real world of AAA games it is nowhere, it's not even a consideration so calling it "Rust Is the Future of Game Development" right ... For those who don't work in games, the tech there move very slowly, it's not your typical SV "let's use the latest fun and…
C++ developers who never heard of Rust sounds rather strange to me, like they are stranded on some isolated island.
Show them Rust, and they will say "what can it do that my tooling doesn't?", and then you must be silent.
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…
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.
Earlier quoted context omitted.
I'm assuming it means getting public involvement? Getting people to participate in the process. That said, I do feel most of the examples are not that. The old shareware scene was much closer to the spirit. Now that we are pushing winners only, feels more like corporate control than it does people control. :(
Go visit http://itch.io/ and search around for a bit. There are thousands of games to explore here made by people from all walks of life. Most of these will see zero to minor financial success, but people are still making them because they are inspired to share some experience. Even on the major platforms, you'll find stuff like Umurangi Generation, a game about taking photographs in a surreal autocratic environment.…
As such, I meant the winners to be the few engines that have remained. Feels like a smaller field, but with only bigger players.
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…
> 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…
I am a game developer that mostly works with c++ and my answer is none so far. The projects delay but nor because of the language.
Undefined behavior is c++'s strength. If it was not, we wouldnt have it in the first place
Earlier quoted context omitted.
Most people don't want to build their engines since it's hard in cpp. If building an engine consists of selecting a couple of crates, people might have a different opinion.
No, most people don't want to build their engines because building engines is a different thing than making a game. People want to build just the part that's unique to their game. Very, very game devs care about how things are drawn to the screen or what's happening in their physics engine -- they just expect those things to be easy to use default features.
Earlier quoted context omitted.
C++ developers who never heard of Rust sounds rather strange to me, like they are stranded on some isolated island.
They have work to do, and tooling to do it with. Show them Rust, and they will say "what can it do that my tooling doesn't?", and then you must be silent.