31–40 of 139 posts
Tangentially related - if anyone is new to Rust and wants to see some simple mini text game examples, I've been working on a bunch [0]. It also includes some more complicated text games: Asylum - Choose your own adventure style interactive narrative Knights and Barbarians - Simple turned based strategy game Legend of the Rusty Dragon - Simple adventure game inspired by Legend of the Red Dragon [0] https://github.com/…
It'd be very interesting to read real-world experiences of experienced game programmers with the language itself; all the discussions around the net are purely academic. Long ago I've read on Reddit a programmer posted his detailed experience of the problems they've found on a non-trivial game, but I can't find it. I also wonder if anything changed.
Earlier quoted context omitted.
> Counter-rant from Jonathan Blow I've just watched the first 20 minutes of that video. So far, it's all "yeah, she's basically right". When does he get to the point? I.e., what does he actually object to?
An issue that Jonathan Blow had was that one of the touted benefits of Rust is it's ownership semantics, yet the ECS (Entity Component System) that the talk demonstrated was effectively bypassing that.
I don't see how that's the case [1]. The entities are owned by the ECS (or the game state, or whatever), not by each other. Entities can conceptually reference each other, but not own each other. The only time this is problematic, is when one entity is destroyed while another one is still holding a reference to it. At the beginning of the video, he discussed basically all approaches to solve that problem:
1) Raw pointers. Bad for obvious reasons.
2) Smart pointers which keep the referenced object alive. No good, he says, because one entity should not keep another one alive, if the game logic says it should be removed.
3) Weak pointers which are safely invalidated when the referenced entity is removed. No good, he says, because keeping track of back-references is inefficient.
4) Weak pointers which check whether the referenced entity is still alive before accessing it. Which is exactly what the ECS does. Rust's ownership semantics still help here, because entities are unambiguously owned by the ECS, which returns a type-safe None value when you try to access a deleted entity.
[1] I'm not arguing against you, indy; I understand that you paraphrased Blow's argument.
Earlier quoted context omitted.
I just recently came across these two videos. Using Rust For Game Development by Catherine West: https://www.youtube.com/watch?v=aKLntZcp27M Counter-rant from Jonathan Blow: https://www.youtube.com/watch?v=4t1K66dMhWk
> Counter-rant from Jonathan Blow I've just watched the first 20 minutes of that video. So far, it's all "yeah, she's basically right". When does he get to the point? I.e., what does he actually object to?
He seems to disagree with that secondary thesis. He thinks she did a good job implementing a toy ECS, but that Rust itself wasn't particularly helpful to her.
Not deeply familiar with Rust but with its memory management concept does it allow for something like arena allocator?
I assume most game development (or, at least, game engine development) is still in C++? How easy would it be to start moving parts of it to Rust? For example, if I were to write a library (e.g. a physics engine) in Rust, how easy is it for game developers to incorporate it into their C++ games? Would they need to set up a separate Rust toolchain alongside their existing C++ one? It seems it would be much harder to fo…
Mozilla has also published information on how they are rewriting components in Rust and integrating them into the Firefox codebase, though they were using C apis - exposing Rust to C and vice versa is relatively straight-forward.
Earlier quoted context omitted.
Rust has good C interoperability. So from C++ it’d look like a C library. You can either write your own glue code or use something like cbindgen to autogen the header file.
Many interesting SDKs come with C++ APIs that aren't necessarily translatable to C. Choosing Rust for engine development has the potential of severely hamstringing the team. It is the same tough uphill battle for all languages that aren't C++. Even more so now that the smoke is slowly rising from the battlefield of licensed engines and only a few contenders remain standing. And all of them have a massive C++ codebase…
At this time we only target the VFX C++ ecosystem but I'd be surprised if people wouldn't use (and extend) this to cover a broader set of C++ libs.
Maybe you can give an example of a C++ API that you deem not "translatable to C"?