Read the change in which Embark's CTO backs off from Rust.[1] They were building their own rendering ecosystem, but seem to have backed off from that.
The mainstream Rust 3D ecosystem just isn't good enough yet. I've brought this up before.
The core crate for 3D is WGPU. This is a layer which tries to cover Vulkan, Metal, OpenGL, DX12, Android, and WebGPU targets. It works, but there are performance compromises to support all those different targets. Supporting web and Android means giving up some parallelism on desktop.
The main alternative to WGPU is Vulkano, and MoltenVK, which is an adapter for Apple's Metal. (Apple just had to Think Different, which is why many games are not ported to MacOS.) It's OK, but it's really just a subset of Vulkan on top. Same parallelism problem, although not for any essential reason.
All those offer a Vulkan-type API, which is rather low level. The caller has to manage GPU memory and scheduling. For that, there's Bevy, which is a whole game engine framework. Good work has been done in Bevy, but it's a framework, so you do it their way or not at all. There's Rend3, which is just a crate to manage memory and scheduling. I use that. It's been abandoned. I may have to take up maintaining that.
Nobody is pushing these towards maximum performance and quality. Nobody has a good modern big-world 3D shooter on these stacks.
All this stuff works fine if you're doing simple scenes. If you're pushing towards, say, the level of a 10 year old AAA title, it's not there. Modern Unreal Engine, not even close.
From my friends who work on rust-GPU it’s been my impression that Embark is moving away from Rust. But it’s not because of the ecosystem. Although I agree that it is immature. Instead it seemed to be more an economic situation.
It’s hard to pay the frontier tax and ship AAA games.
I would say the main alternative is ash not vulkano, from my experience in experimenting with graphics on rust, I haven't seen much support or like for vulkano as it has many of the same performance issues as wgpu and doesn't simplify too much after the trade off of the lack of resources, it also appears embark was using ash atleast for kajiya.
I have encounter a lot of your posts and that's what pushed me towards just tackling vulkan instead of using wgpu. I also encountered many of the same issues around the ecosystem. I think the main issue is there is just not enough dev time going into it or money. Even valoren, which I already knew of before learning rust from posts in linux/oss communities only has received 8k of funding, while offering the closest to an AA experience.
But I don't think its that reasonable to expect the ecosystem to just have a batteries included performant general rendering solution, idk if any language has that? I know there is bgfx, which might be the closest thing but I assume also has its own issues. So I don't really think its the graphics part holding things back, as ash is a great wrapper around vulkan and maps 1-1 with a little bit of improvements (builders for structs, not needing to set stype for each struct, easy p chaining).
The main issue I encounter is all around the lack of dev-time and the tendency for single developers and for small single purpose crates. Most of my friction is around lack of documentation, constant refactoring making that lack even worse, and this causing disjoint dependency trees. So many times have I encountered one create using version x.x of one crate that depends on x.y version of another then the next being on z.x of another dependency and then another still needing z.y. This normally wouldn't be that big of an issue, except the tendency to constantly introduce refactoring and breaking changes meaning I end up having to fork and fix these inter-dependencies myself and cant just patch them.
But this all just circle back to there just isn't much dev time going into them. It also seems the "safety" concerns and rust just not allowing some things causes devs of many crates chasing their tails with refactors trying to work around these constraints. But it does get quite tiresome having to deal with all of these issues. If I was using c++ I could just use sdl/glfw, imgui, vma and vulkan and they would all be up to date with each other. In rust I need winit, imgui bindings, imgui-winit, imgui-vulkan, raw-window-handle, ash and vma bindings. And most of these are all using different versions of each other and half of them have breaking changes version to version.
Does anyone know if Embark are still using a lot of rust in their production games? They seem to be a very well funded studio (lots of employees, big fancy office, competes with other AAA FPS-games). I wonder if these experimental-sounding projects have given way to more classic tech in the churn of building games that are profitable.
According to the article, Rust is (or was) used in the kajiya renderer and in the "creative platform", not in their production games:
> Our Rust project has different requirements than a video game. It’s a platform that will enable everyone — not just professional game makers — to build new small interactive experiences.
The "creative platform" is now apparently available under wim.live (and has a twitter account called @createplaywim): https://wim.live/en/ - but the website only seems to play a video, I couldn't find any other functionality.
One obstacle is that at least one of the major console vendors prohibits using anything other than C++ plus their official compiler. So shipping on that platform using i.e. Rust, Swift, C# is currently against the rules. (Unity gets an out here since they compile C# down to C++ using IL2CPP.)
I expect some studios are just quietly breaking the rule and not telling anyone, but I'd be worried, personally.
People outside of the industry woudn't believe how it is to work with first party such as Sony, just to get SDK / api / documentation / forums access you need to have a very complicated process that involves public IP whitelisting etc..
Even NVidia's GeForce Now cloud gaming service is like that. I tried to get a developer account and they wanted US$10,000 just to talk. It's not like getting an AWS account.
CrossCode was written in JS/HTML5 and was ported over to consoles just fine, though.
They mention stuff like "an interpreter which translates the [JavaScript] code but locks it up in a cage"¹, their presentation² mention JS interpreters and a JS AoT compiler, so I'm not really sure how they did it
My gut says Nintendo, because Microsoft doesn't give a shit what you use as long as you write for them, and Sony doesn't feel like they'd be that petty.
The finals is such an impressive game. I’d love to learn how they managed it. The destruction of the entire map doesn’t slow down the game at all.
That said, the only thing stopping the finals from becoming a leading franchise is some balance and game design issues. They’ve built a wonderful casino, but the rules for the card games are rough around the edges. I hope they can drive a dump truck of cash up to riot HQ, and hire a designer passionate about esports. There is so many obviously wrong things in the game… like the recent lh-1 buff that lasted a day before being reverted. What were they thinking? That said, it’s the first game I’ve played in twenty years that makes gaming feel new, and we love so many things about it.
I'm a gameplay engineer who worked on THE FINALS. There's a GDC talk that one of the engineers who worked on the destruction system gave and I imagine that talk will be uploaded on youtube at some point in the future: https://schedule.gdconf.com/session/engineering-mayhem-techn...
Most of the answer to your question is really good iterative tooling on the authoring side, and very pinpoint optimizations on the runtime side. You basically amortize everything, how much is "strain" is simulated per frame, how much physics simulation is simulated per frame, how much is replicated per frame, etc. Almost any game could do what THE FINALS did but it really just requires you to solve many of the hard obvious problems for a good couple years.
I'm glad you enjoy the game! I also agree with you that there's a lot that can be improved.
Notice the (2021).
Read the change in which Embark's CTO backs off from Rust.[1] They were building their own rendering ecosystem, but seem to have backed off from that.
The mainstream Rust 3D ecosystem just isn't good enough yet. I've brought this up before.
The core crate for 3D is WGPU. This is a layer which tries to cover Vulkan, Metal, OpenGL, DX12, Android, and WebGPU targets. It works, but there are performance compromises to support all those different targets. Supporting web and Android means giving up some parallelism on desktop.
The main alternative to WGPU is Vulkano, and MoltenVK, which is an adapter for Apple's Metal. (Apple just had to Think Different, which is why many games are not ported to MacOS.) It's OK, but it's really just a subset of Vulkan on top. Same parallelism problem, although not for any essential reason.
All those offer a Vulkan-type API, which is rather low level. The caller has to manage GPU memory and scheduling. For that, there's Bevy, which is a whole game engine framework. Good work has been done in Bevy, but it's a framework, so you do it their way or not at all. There's Rend3, which is just a crate to manage memory and scheduling. I use that. It's been abandoned. I may have to take up maintaining that.
Nobody is pushing these towards maximum performance and quality. Nobody has a good modern big-world 3D shooter on these stacks.
All this stuff works fine if you're doing simple scenes. If you're pushing towards, say, the level of a 10 year old AAA title, it's not there. Modern Unreal Engine, not even close.
Not enough money behind it.
[1] https://github.com/EmbarkStudios/rust-ecosystem/commit/61f0e...
From my friends who work on rust-GPU it’s been my impression that Embark is moving away from Rust. But it’s not because of the ecosystem. Although I agree that it is immature. Instead it seemed to be more an economic situation.
It’s hard to pay the frontier tax and ship AAA games.
I would say the main alternative is ash not vulkano, from my experience in experimenting with graphics on rust, I haven't seen much support or like for vulkano as it has many of the same performance issues as wgpu and doesn't simplify too much after the trade off of the lack of resources, it also appears embark was using ash atleast for kajiya.
I have encounter a lot of your posts and that's what pushed me towards just tackling vulkan instead of using wgpu. I also encountered many of the same issues around the ecosystem. I think the main issue is there is just not enough dev time going into it or money. Even valoren, which I already knew of before learning rust from posts in linux/oss communities only has received 8k of funding, while offering the closest to an AA experience.
But I don't think its that reasonable to expect the ecosystem to just have a batteries included performant general rendering solution, idk if any language has that? I know there is bgfx, which might be the closest thing but I assume also has its own issues. So I don't really think its the graphics part holding things back, as ash is a great wrapper around vulkan and maps 1-1 with a little bit of improvements (builders for structs, not needing to set stype for each struct, easy p chaining).
The main issue I encounter is all around the lack of dev-time and the tendency for single developers and for small single purpose crates. Most of my friction is around lack of documentation, constant refactoring making that lack even worse, and this causing disjoint dependency trees. So many times have I encountered one create using version x.x of one crate that depends on x.y version of another then the next being on z.x of another dependency and then another still needing z.y. This normally wouldn't be that big of an issue, except the tendency to constantly introduce refactoring and breaking changes meaning I end up having to fork and fix these inter-dependencies myself and cant just patch them.
But this all just circle back to there just isn't much dev time going into them. It also seems the "safety" concerns and rust just not allowing some things causes devs of many crates chasing their tails with refactors trying to work around these constraints. But it does get quite tiresome having to deal with all of these issues. If I was using c++ I could just use sdl/glfw, imgui, vma and vulkan and they would all be up to date with each other. In rust I need winit, imgui bindings, imgui-winit, imgui-vulkan, raw-window-handle, ash and vma bindings. And most of these are all using different versions of each other and half of them have breaking changes version to version.
Does anyone know if Embark are still using a lot of rust in their production games? They seem to be a very well funded studio (lots of employees, big fancy office, competes with other AAA FPS-games). I wonder if these experimental-sounding projects have given way to more classic tech in the churn of building games that are profitable.
According to the article, Rust is (or was) used in the kajiya renderer and in the "creative platform", not in their production games:
> Our Rust project has different requirements than a video game. It’s a platform that will enable everyone — not just professional game makers — to build new small interactive experiences.
The kajiya renderer is available on GitHub, but contributions have slowed down since mid 2022: https://github.com/EmbarkStudios/kajiya/graphs/contributors
The "creative platform" is now apparently available under wim.live (and has a twitter account called @createplaywim): https://wim.live/en/ - but the website only seems to play a video, I couldn't find any other functionality.
They seem to be using Rust in a lot of tools though: https://github.com/EmbarkStudios
The author of the linked article (and Kajiya) quit Embark to work on an indie title with his wife around mid 2022 if memory serves me right.
Nope, their two flagship games (The Finals, and the soon-to-be-released Ark Raiders) are all using Unreal Engine.
Seems that they're trying to earn money by shipping games in Unreal first, while developing their Rust-based engine behind the scenes.
Their Rust game is currently in closed alpha: https://wim.live/en/.
Last time I tried it, they were working on integrating wasm support for user-accessible custom scriptable scenarios (a la Roblox).
The games embark has released are made in Unreal Engine, maybe the game using rust hasn't been released yet.
One obstacle is that at least one of the major console vendors prohibits using anything other than C++ plus their official compiler. So shipping on that platform using i.e. Rust, Swift, C# is currently against the rules. (Unity gets an out here since they compile C# down to C++ using IL2CPP.)
I expect some studios are just quietly breaking the rule and not telling anyone, but I'd be worried, personally.
People outside of the industry woudn't believe how it is to work with first party such as Sony, just to get SDK / api / documentation / forums access you need to have a very complicated process that involves public IP whitelisting etc..
https://www.scedev.net/index.html
Even NVidia's GeForce Now cloud gaming service is like that. I tried to get a developer account and they wanted US$10,000 just to talk. It's not like getting an AWS account.
CrossCode was written in JS/HTML5 and was ported over to consoles just fine, though.
They mention stuff like "an interpreter which translates the [JavaScript] code but locks it up in a cage"¹, their presentation² mention JS interpreters and a JS AoT compiler, so I'm not really sure how they did it
¹: https://www.radicalfishgames.com/?p=6892 ²: https://www.youtube.com/watch?v=KfBzlzvt8RU
Which console vendor is that?
Sony
They get really upset if you disclose things like that :)
My gut says Nintendo, because Microsoft doesn't give a shit what you use as long as you write for them, and Sony doesn't feel like they'd be that petty.
You can ship games for Nintendo with private modification of NativeAOT + FNA: https://viridiansoftware.com/blog/csharp-on-game-consoles
But Microsoft _does_ have a widely known C++ compiler. I doubt Sony does. Does Nintendo?
What would the reasoning for such a decision be?
The article's author now works with his girlfriend on this[1] game also written in Rust.
[1] https://store.steampowered.com/app/2198150/Tiny_Glade/
The finals is such an impressive game. I’d love to learn how they managed it. The destruction of the entire map doesn’t slow down the game at all.
That said, the only thing stopping the finals from becoming a leading franchise is some balance and game design issues. They’ve built a wonderful casino, but the rules for the card games are rough around the edges. I hope they can drive a dump truck of cash up to riot HQ, and hire a designer passionate about esports. There is so many obviously wrong things in the game… like the recent lh-1 buff that lasted a day before being reverted. What were they thinking? That said, it’s the first game I’ve played in twenty years that makes gaming feel new, and we love so many things about it.
I'm a gameplay engineer who worked on THE FINALS. There's a GDC talk that one of the engineers who worked on the destruction system gave and I imagine that talk will be uploaded on youtube at some point in the future: https://schedule.gdconf.com/session/engineering-mayhem-techn...
Most of the answer to your question is really good iterative tooling on the authoring side, and very pinpoint optimizations on the runtime side. You basically amortize everything, how much is "strain" is simulated per frame, how much physics simulation is simulated per frame, how much is replicated per frame, etc. Almost any game could do what THE FINALS did but it really just requires you to solve many of the hard obvious problems for a good couple years.
I'm glad you enjoy the game! I also agree with you that there's a lot that can be improved.
The finals does not use Rust what so ever. It's an Unreal game.
Yeah, one of the first to use the latest version of unreal with new physics engine.
I just wanted to talk about the finals because I love it.
(2021)
Note: this was published in 2021
https://loglog.games/blog/leaving-rust-gamedev/