Comment by pcwalton
9 months ago
> I'd expected some AAA title to be written in Rust by now.
Why? Those kinds of game engines are enormous amounts of code, and there's little incentive to rewrite.
I do strongly disagree that we aren't ever going to see large-scale game development in Rust; it just takes time. Whether games adopt an engine is largely about that engine's maturity rather than anything about the language. Bevy is quite young; 0.13 doesn't even have support for animation blending yet (I landed that for 0.14).
It was a few years back that the question came up to the developers of a Call of Duty title. "Is there still code from Quake 3 in COD?". They dodge around it by saying something like "we cannot deny this but e use the most appropriate tech where needed".
While not confirmation, I wouldn't be surprised if there is a few nuggets of Q3 in that code base still doing some of the basics. That would be really cool if it is true.
It seems like unless you are someone like John Carmack or most of Nintendo, game dev tools are about what can get the best results quickest rather than any sort of technical specifics. It is a business after all.
A neat real-world example of ancient Quake code surviving to this day is visible in Valves games - the hardcoded patterns for flickering lights in Quake 1 survived into GoldSrc and then into Source and then into Source 2, most recently showing up in Half Life Alyx, 24 years on from their original appearance in Quake 1.
https://www.alanzucconi.com/2021/06/15/valve-flickering-ligh...
Basically all of the bigger systems will have been Ship-of-Theseus'd several times over by now, but little things like that can slip through the cracks.
That light flickering is quite cool, thanks for sharing. It reminds me of the Wilhelm scream, but on a much smaller scale of course.
> game dev tools are about what can get the best results quickest rather than any sort of technical specifics. It is a business after all.
Bingo. Rust's biggest strength is correctness. But games aren't mission critical, and gamers are very tolerant towards bugs (maybe not on social media, but very few buggy games have had their sales impacted). Your biggest sale to AAA game devs are to engine programmers to minimize tech debt. But as we are seeing with the current industry, that's not exactly something companies care about until it's too late.
Then on the indie level we get articles like this. Half the article ultimately came down to "it's faster to break things and iterate than to do it right once". Again, similar lack of need for bug-free games. In addition, few indie games are scoped to a point where they need a highly disciplined ECS solution to scale with.
The author even criticizes the "tech specs" community part of rust gamedev. Different tools, diferent goals, different needs. IMO, I think Rust will help make for some very robust renderers one day, but ultimaely the scripting will be done on another language. Similar to how Unity uses C# scripting to a C++ engine, that they IL2CPP to bring back to a full C++ game.
This, exactly. As an embedded turned Unreal developer the first impression I had while using Unreal is how little concern for correctness there is overall. UB is used liberally, and there's clearly a larger focus on development speed and ease off use compared to safety and correctness. If a game has integer overflow or buffer overflows nobody cares. Viceversa, you need to keep the whole thing usable enough for the various 3D artists and such who have a hard time understanding advanced programming.
If that's the question... Let me assure you that there are decades-old pieces of code inside of, and used to assemble, many modern AAA games coming out of mature studios. The systems and tooling is typically carried forward. I don't think this is some big secret and you've intuited exactly the reason why:
> game dev tools are about what can get the best results quickest rather than any sort of technical specifics. It is a business after all.
Not surprised at all that this stuff sticks around. I find it very endearing actually. Ain't broke, don't fix it!
A lot of big projects have amazing longevity to their older architectural decisions. Unreal still has a lot of stuff in it people that used UE1 would recognize, I did most of my professional development on UE3 and a bunch of that is still pretty recognizable. Similarly Chrome is a product of the time it was first created. And looking into the Windows source is probably like staring into the stygian abyss.
There is a lot of legacy and tech debt out there!
I remember years back someone form Microsoft calling the windows code base "The Abyss" because of how much technical legacy there was in it.
I think it was Steve Gibson who said that the Windows code base had some very questionable things in it. For instance they had work experience high school students working on code that made it into the final build that was less than spectacular. Like how Windows used to stall when you put a CD in and wouldn't proceed until the disc spun up and started reading data.
Windows 11 probably would still do that but I don't know because I don't have a disc drive any more.
2 replies →