Supporting existing game engines

[dxenonb]

Is it within the scope of the working group to look at how Rust can help game developers using existing commercial engines?

There is a large game development community in my area, and nobody is writing their own engine. Most game developers uses an existing engine, like Unreal or Unity, especially if they are serious about making a game within any certain time constraints.

I believe it could really support the pure-Rust ecosystem if we developed resources for using Rust with existing game engines, since it makes it more palatable for existing teams to invest in Rust.

Unreal Engine 4 uses C++ and Unity uses C#. Godot apparently supports both officially. Unity is heavily exploring ECS as the future, and from what I've seen, it looks like Rust ECS is far more ergonomic and requires jumping through far less hurdles. Working with UE4 may admittedly be difficult due to the heavy usage of very-magical seeming macros. Translating between engine structures and Rust structures also incurs a cost that makes Rust less beneficial.

That said: maybe Rust could be a great way to use ECS in Unreal or pull in useful utilities/critical routines in Unity.

I think a guide on how Rust can be used with Unreal and Unity could provide significant value. Does anyone have thoughts on

• if this is a thing worth spending energy to explore; and
• where and how you would love to use Rust in an existing engine?

[kvark]

I don't mind this to be in scope for the WG, but personally I'm not interested to invest in this direction, as indicated in https://github.com/rust-gamedev/wg/issues/23#issuecomment-512453163

[Lokathor]

I think that, in the same way that wgpu-rs operates as a pure rust crate, and then also has a separate crate that wraps it into a C lib, it's entirely reasonable to design some elements of a project with the idea in mind that someone would make a second crate to expose the pure rust library as a C lib.

Doing the work to expose a crate as a C lib isn't always possible, and if it is then it's still not always practical. It's also a lot of work that I don't expect people to suddenly do for no reason. However, it's reasonable to ask people making a foundational library to just keep in mind that perhaps someone might want to call your crate from another language when designing the API. Then people using the other language can write bindings over top of your crate and benefit from your work.

one problem with calling Rust from Unity is that, at this time, there's not really anything in the rust ecosystem that's worth doing all of that data marshaling over FFI. There are success stories where people using Python, Ruby, or Erlang have converted their code into Rust and had huge speed gains, but I think they wrote their own Rust based on their existing code. Picking a Rust crate off the shelf doesn't give you much compared to the libraries that already exist in C++ and C#, because those languages have been around for far longer. My example above with wgpu-rs is the closest thing to a general purpose Rust crate that you can't easily already find in C++/C#, and I don't even know if you could plug that into Unity because Unity is already doing its own rendering thing. And of course there's doubtlessly also already wgpu implementations being worked on in C++/C# since it's just a specification after all.

@dxenonb my question to you is: Do you have specific Rust libraries in mind that you'd want to call from C++/C#? Or were you thinking kinda "in general try to be FFI friendly"?

[erlend-sh]

The most natural place to start doing some bridge building would be https://github.com/GodotNativeTools/godot-rust by @karroffel. Out of the 3 engines mentioned, Godot is the only one that has made an official investment in Rust support. How might the Godot project and the Rust GDWG help one another?

There is some prior art for Unity too https://github.com/jimfleming/unity-to-rust by @jimfleming but that seems to have been more of a one-off experiment done back in 2015.