This is great, because Unreal is a C++ project that's not so easy to just Rewrite In Rust.
It's also nice it uses bevy's ECS. It's made to fit Rust's type system and borrow checking model, and is highly parallel. It's really awesome how easy it is to distribute work across cores with it, without risk of heisenbugs thanks to Rust's data-race-safety guarantees.
I know game development sees traditional software best practices as not applicable to them, but then games struggle with showstopping bugs and single-core performance bottlenecks. I hope someone will bet that Rust, despite being stricter and seemingly slower to iterate with, can be a net benefit from lower defect rates. Rust users outside of game dev praise the "if it compiles, it's usually correct", and that junior devs can be told not to write unsafe code, so they can't cause UB and memory corruption.
Why do specifically Rust programmers think that people in every domain are just misguided and waiting for someone to teach them the right development practices? The sheer hubris…
The kind of bugs that games mostly struggle with these days have nothing to do with the stuff Rust is targeting, like memory safety. They are “business logic” problems with many interacting systems resulting in unpredictable behavior, buggy level geometry, or poorly scripted missions not accounting for all player behavior. How exactly does Rust help with any of that?
Why would you think that? All of the game developers I've met don't really view themselves as separate from traditional software best practices, just that there's a lot more involved in making a game than people are ever really aware of. They're also among some of the most talented programmers, the stuff they have to come up with is insanity sometimes, so it's certainly not about them not caring about best practices.
Games aren't struggling because they're written in Unreal's flavor of C++ (or whatever other currently existing engines and their respective languages), there are insane deadlines always being pushed. There is never enough time and never enough money. Neither of these problems are solved with Rust, at least not to a substantial degree.
> Rust users outside of game dev praise the "if it compiles, it's usually correct",
Why do people keep echoing this sentiment? I don't find this to be particularly true, in my sense of "correct". Yes, it does what the code says it'll do, but rarely the problem I actually get stuck at are language/syntax/semantic errors, it's usually domain/logic errors.
Same can be said for PHP, JavaScript and a bunch of languages, as every program that is possible to run without error, is correct, at least in the eyes of the interpreter. But again, the difficult errors are not syntax/language errors.
I am always skeptical about these type of projects. Out of the box Unreal Engine supports C++ and Blueprint.
The problem with C++ is the slow compile times, and if you make mistakes the engine crashes. In general you produce stuff slower by using C++.
Blueprint is a visual scripting tool, it compiles fast. But it stores code as a binary blob in source control. And I'm personally not a fan of visual scripting, I would prefer scripting by just writing code.
So generally I prototype in Blueprint and then rewrite in C++ later on. I would love an intermediate language that has fast compile times and saves as a source file instead of a binary blob.
The problem is most of the projects that integrate with another language get abandoned after a while. MonoUE was abandoned, USharp was abandoned, now the newest attempt to integrate UE with C# UnrealCLR looks abandoned. SkookumScript doesn't support UE5. Haxe support for UE was abandoned.
Do I really want to risk writing a ton of code in a language that might not support future engine versions? To be honest, I don't want to take that risk.
This is great, because Unreal is a C++ project that's not so easy to just Rewrite In Rust.
True. Although rewriting Nanite in Rust would be useful. Nanite is a very clever data structure for meshes. It's brittle, and full of internal relative addresses within the data item, so it's very vulnerable to buffer overflows. If it becomes widely used outside of UE, it might become something that gets supported in GPU hardware.
> It's brittle, and full of internal relative addresses within the data item,
I am not sure how much you would gain by doing this.
Internal references are one of the things where it is very hard to express in safe Rust what you want to do (see doubly linked lists and graphs). You can get around that by using vectors and indexes, but that is bypassing the borrow checker, and with it, much of your safety and mutability checks.
>Nanite is a very clever data structure for meshes. It's brittle, and full of internal relative addresses within the data item, so it's very vulnerable to buffer overflows.
Using bounds checking is likely to kill performance on such data structures, while using `get_unchecked` or raw pointers will keep the issues.
But even then, I would love to see Nanite implemented in Rust.
I write a lot of C++ plugins that are used in both Unreal and Unity. I like to think of them as "side loading". They can do whatever they want, however they want. The API surface that interacts with either engine is pretty minimal.
I think "use Unreal as a renderer" is underrated. You could imagine writing your full simulation logic independent of the AActor framework and then using Unreal just for rendering. For a client/server game the server might not use Unreal at all!
I'm not sure how valuable it is to use Rust but also use Unreal's framework and blueprints. Bevy + Unreal is a pretty fascinating combo and how much lifting is done by each side can be done in lots of ways.
I'm waiting on Verse a new scripting language for UE by Epic called Verse. A Twitter thread posited it may be called Unreal Verse ;) It is supposedly inspired by Smalltalk and has some Lispy goodness. Can't wait. I played with Rust, and I think it is fine, but too much overhead for me to get productive with it. But that's just me. I click more with Lisp and terse languages (J, APL, Scheme, etc.). So many options to be grateful for!
Some "lispy goodness" like what? Is it s-expressions? Or do you mean like it has things lisp invented: things like conditionals ("if/else" statements), garbage collection, recursion and first-class functions?
If the first, that'd be super interesting! If it's the latter, tons of programming language have implemented features like that before :)
This reminds me of Unreal.js, which allows you to write games with Unreal Engine in JavaScript (V8, to be specific): https://github.com/ncsoft/Unreal.js.
Unreal really is a fun tool to use, and I highly recommend it over Unity for stuff like blueprints. Things like this are awesome as well.
What I really really want (and maybe I can have this easily!) is to be able to inline some C++/Rust inside a blueprint. Sometimes there are expressions that would be way easier to type out, or some tricky state logic that I can express with prose more nicely than with arrows.
I imagine the "serious" thing to do is to build out the C++ in some other file and then do the thing with my blueprint, but imagine if we had a completely smooth gradient for upping the tooling from blueprint to C++ when needed!
I haven't heard great things about it, but there is a Marketplace product that should let you do what you are after. Alternatively, you could just write the code you want in some BPFL file, and expose them as static functions.
Unreal already supports full Python for some stuff. They do also have a language called Verse in the works but I don’t believe that it has any relationship to Python
These discussions always remind me of some talks by Jonathan blow where he argues rust doesn’t solve the hard problems he needed it to. There are podcast episodes with better discussions, but the main one people link to seems to be this
I haven’t used rust, but I sympathize with his problems with pointers and learned a lot from the various ways people try to solve them
He also admits he hasn't written more than a hundred lines of code with it before, and that was 4 years ago, more than half rusts lifetime ago.
My understanding is his priorities are C level control over memory, fast compiles, and ergonomics for the kinds of operations he commonly does.
Rust solves for memory/ergonomics, though the strictness it holds you to is in opposition to what (I understand) he considers ergonomic access & control of memory.
Therefore rust solves ~1 of his priorities, so it's not really a good fit.
To extrapolate that to "doesn't solve the hard problems" is another logic step that I probably don't agree with.
Because C++ already is way too slow to compile wich hurts iteration time, wich is why most people fall back to plain simple blueprints, and even that can become quite heavy
Epic is working on a new scripting language that will improve this
What Rust brings to game development and how it's better than C/C++ in that regard?
Because you don't develop a game the same way, with the same constraints as a driver for example
Is it? With live coding how long do your compiles take?
TBH Unreal C++ is faster to compile than Unity C#. It is slower than an interpreted language. But I’ve also worked pipelines that chain Python executions which compound into ~5 second boot time.
Faster is always better of course. But I often think people overstate compile times. The upside is it means people work hard to improve things from good to great!
What use cases would be this suitable for? It seems this approach is a bit of a hack that would fall apart in use. It would be nice to program games using Unreal, using the Rust language, but this doesn't sound like that.
I respect that making FFI bindings to Rust would be very difficult or impractical, but that's what I think would be interesting.
This is really cool. It's projects like these that makes me want to experiment with random things. It might not make sense or feasible but that is what's fun about it :)
same here - firs reaction in my head was this, and then I knew (milliseconds) later it'll be about the Unreal Engine... but "Unreal Mode" is stuck there first deep into the L0 cache line.
[+] [-] pornel|3 years ago|reply
It's also nice it uses bevy's ECS. It's made to fit Rust's type system and borrow checking model, and is highly parallel. It's really awesome how easy it is to distribute work across cores with it, without risk of heisenbugs thanks to Rust's data-race-safety guarantees.
I know game development sees traditional software best practices as not applicable to them, but then games struggle with showstopping bugs and single-core performance bottlenecks. I hope someone will bet that Rust, despite being stricter and seemingly slower to iterate with, can be a net benefit from lower defect rates. Rust users outside of game dev praise the "if it compiles, it's usually correct", and that junior devs can be told not to write unsafe code, so they can't cause UB and memory corruption.
[+] [-] t8sr|3 years ago|reply
The kind of bugs that games mostly struggle with these days have nothing to do with the stuff Rust is targeting, like memory safety. They are “business logic” problems with many interacting systems resulting in unpredictable behavior, buggy level geometry, or poorly scripted missions not accounting for all player behavior. How exactly does Rust help with any of that?
[+] [-] waboremo|3 years ago|reply
Games aren't struggling because they're written in Unreal's flavor of C++ (or whatever other currently existing engines and their respective languages), there are insane deadlines always being pushed. There is never enough time and never enough money. Neither of these problems are solved with Rust, at least not to a substantial degree.
[+] [-] capableweb|3 years ago|reply
Why do people keep echoing this sentiment? I don't find this to be particularly true, in my sense of "correct". Yes, it does what the code says it'll do, but rarely the problem I actually get stuck at are language/syntax/semantic errors, it's usually domain/logic errors.
Same can be said for PHP, JavaScript and a bunch of languages, as every program that is possible to run without error, is correct, at least in the eyes of the interpreter. But again, the difficult errors are not syntax/language errors.
[+] [-] zinlencer|3 years ago|reply
The problem with C++ is the slow compile times, and if you make mistakes the engine crashes. In general you produce stuff slower by using C++.
Blueprint is a visual scripting tool, it compiles fast. But it stores code as a binary blob in source control. And I'm personally not a fan of visual scripting, I would prefer scripting by just writing code.
So generally I prototype in Blueprint and then rewrite in C++ later on. I would love an intermediate language that has fast compile times and saves as a source file instead of a binary blob.
The problem is most of the projects that integrate with another language get abandoned after a while. MonoUE was abandoned, USharp was abandoned, now the newest attempt to integrate UE with C# UnrealCLR looks abandoned. SkookumScript doesn't support UE5. Haxe support for UE was abandoned.
Do I really want to risk writing a ton of code in a language that might not support future engine versions? To be honest, I don't want to take that risk.
[+] [-] Animats|3 years ago|reply
True. Although rewriting Nanite in Rust would be useful. Nanite is a very clever data structure for meshes. It's brittle, and full of internal relative addresses within the data item, so it's very vulnerable to buffer overflows. If it becomes widely used outside of UE, it might become something that gets supported in GPU hardware.
[+] [-] RcouF1uZ4gsC|3 years ago|reply
I am not sure how much you would gain by doing this.
Internal references are one of the things where it is very hard to express in safe Rust what you want to do (see doubly linked lists and graphs). You can get around that by using vectors and indexes, but that is bypassing the borrow checker, and with it, much of your safety and mutability checks.
[+] [-] newpavlov|3 years ago|reply
Using bounds checking is likely to kill performance on such data structures, while using `get_unchecked` or raw pointers will keep the issues.
But even then, I would love to see Nanite implemented in Rust.
[+] [-] forrestthewoods|3 years ago|reply
I write a lot of C++ plugins that are used in both Unreal and Unity. I like to think of them as "side loading". They can do whatever they want, however they want. The API surface that interacts with either engine is pretty minimal.
I think "use Unreal as a renderer" is underrated. You could imagine writing your full simulation logic independent of the AActor framework and then using Unreal just for rendering. For a client/server game the server might not use Unreal at all!
I'm not sure how valuable it is to use Rust but also use Unreal's framework and blueprints. Bevy + Unreal is a pretty fascinating combo and how much lifting is done by each side can be done in lots of ways.
[+] [-] eggy|3 years ago|reply
[+] [-] capableweb|3 years ago|reply
Some "lispy goodness" like what? Is it s-expressions? Or do you mean like it has things lisp invented: things like conditionals ("if/else" statements), garbage collection, recursion and first-class functions?
If the first, that'd be super interesting! If it's the latter, tons of programming language have implemented features like that before :)
[+] [-] sanxiyn|3 years ago|reply
[+] [-] rtpg|3 years ago|reply
What I really really want (and maybe I can have this easily!) is to be able to inline some C++/Rust inside a blueprint. Sometimes there are expressions that would be way easier to type out, or some tricky state logic that I can express with prose more nicely than with arrows.
I imagine the "serious" thing to do is to build out the C++ in some other file and then do the thing with my blueprint, but imagine if we had a completely smooth gradient for upping the tooling from blueprint to C++ when needed!
[+] [-] sk0g|3 years ago|reply
https://www.unrealengine.com/marketplace/en-US/product/magic...
[+] [-] coolspot|3 years ago|reply
[+] [-] techdragon|3 years ago|reply
I looked into using this approach when I was playing around with the idea. Writing lots and lots of C wrappers seemed … wasteful.
[+] [-] geenat|3 years ago|reply
[+] [-] ferrumfist|3 years ago|reply
https://github.com/20tab/UnrealEnginePython
[+] [-] sanxiyn|3 years ago|reply
[+] [-] dagmx|3 years ago|reply
Unreal already supports full Python for some stuff. They do also have a language called Verse in the works but I don’t believe that it has any relationship to Python
[+] [-] hertzrat|3 years ago|reply
I haven’t used rust, but I sympathize with his problems with pointers and learned a lot from the various ways people try to solve them
https://m.youtube.com/watch?v=4t1K66dMhWk
[+] [-] tbillington|3 years ago|reply
My understanding is his priorities are C level control over memory, fast compiles, and ergonomics for the kinds of operations he commonly does.
Rust solves for memory/ergonomics, though the strictness it holds you to is in opposition to what (I understand) he considers ergonomic access & control of memory.
Therefore rust solves ~1 of his priorities, so it's not really a good fit. To extrapolate that to "doesn't solve the hard problems" is another logic step that I probably don't agree with.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Kukumber|3 years ago|reply
Because C++ already is way too slow to compile wich hurts iteration time, wich is why most people fall back to plain simple blueprints, and even that can become quite heavy
Epic is working on a new scripting language that will improve this
What Rust brings to game development and how it's better than C/C++ in that regard?
Because you don't develop a game the same way, with the same constraints as a driver for example
[+] [-] pornel|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] forrestthewoods|3 years ago|reply
TBH Unreal C++ is faster to compile than Unity C#. It is slower than an interpreted language. But I’ve also worked pipelines that chain Python executions which compound into ~5 second boot time.
Faster is always better of course. But I often think people overstate compile times. The upside is it means people work hard to improve things from good to great!
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] the__alchemist|3 years ago|reply
I respect that making FFI bindings to Rust would be very difficult or impractical, but that's what I think would be interesting.
[+] [-] michaelsalim|3 years ago|reply
[+] [-] mrlonglong|3 years ago|reply
[+] [-] malkia|3 years ago|reply
[+] [-] PixelOfDeath|3 years ago|reply
[+] [-] Ygg2|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] vardump|3 years ago|reply
https://en.wikipedia.org/wiki/Unreal_mode
[+] [-] unknown|3 years ago|reply
[deleted]