[chrisdirkis]

Undoubtedly? Modern video games are pretty good, and there's a lot of them. They're mostly written in mainstream programming environments. I don't see without explanation how the take is undoubtedly correct in that context.

[kragen]

Fortunately, well-respected game programmers like Muratori and Blow, who have written games that are more highly regarded by critics than BAC Skywalk and who also have more experience than you do, have spent thousands of hours providing that explanation. If you aren't going to listen when they explain it, you aren't going to listen to me either.

[chrisdirkis]

Thanks for checking out my portfolio! I have to admit, it's a bit out of date, but I also don't think that my background in games matters all that much in any specifics. I can talk to principles.

To try and understand where you're coming from, I'll make a few notes and you can tell me where you agree or disagree.

I think we'll both agree that Rust is probably not suitable for most parts of game development. Rust, while enabling "bug-free" refactoring with it's expressive type system, also imposes that type system when you don't want it. Oftentimes, when tweaking a game, you'd rather try things out in a state where things could break than be forced to finish the refactor every time, and Rust doesn't have particularly ergonomic escape hatches for that. If there are specific components with well defined inputs and outputs for your use case (say, maybe, an input system, or a rollback netcode engine), then I think Rust could be a good choice, but you'd also be paying when interfacing with whatever other tools you're using.

I think we'll possibly disagree with the idea that games need to be fast. They need to be fast enough to work! A stable 60fps is pretty much table stakes nowadays too, even in genres that don't benefit hugely from such low latency, in terms of player perception. But "fast enough" is a different bar in different contexts. Mario is fun, and in 2025 I would not need to put much effort in at all to make Mario fast enough in ~any context someone will play it in. On the other hand, I'd probably have to put a lot of work into a photorealistic open world RPG, or an RTS with tens of thousands of units. Many games live in between those two, and oftentimes there's reason to optimise some parts and not others. If a game runs at 60fps on a 5-year-old Android phone, which can often be achieved with Unity (modulo garbage collection hitches), I'm not going to spend extra effort optimising further.

Where I probably disagree most is that we currently err too far on the side of correctness. One thing you didn't note (and I'm not sure if Muratori or Blow talk to) is the difficulty in finding bugs. Games are a massive ball of mutable state and operations on it, and games are usually massively wide artifacts, played on a huge variety of target devices, that are hard-to-impossible to cover the full state space of. Bugs are often non-trivial to see when writing, see when testing, or notice if a reversion exposes them. If I were to guess, I've seen more time spent on resolving bugs than from writing features, from me and the devs I've worked with in my career.

I think in the iron-triangle-esque trade between "easy to write more game", "hard to write bugs", and "game runs fast", I personally bias towards the first two. Few games _need_ the latter, fewer still need it everywhere in the game. Scripting languages and higher-level langs like a C# are pretty ergonomic for games (and the latter specifically, outside the Unity context, is pretty good in terms of optimisation capabilites too).

I'm unsure what made you think that I'd be unlikely to want to listen or discuss things with you, so if you do have notes there I'd be happy to hear them too.

[kragen]

Interesting and thought-provoking.

I don't think Rust is mainstream enough to be what they were attacking, especially 6 years ago or whenever Blow gave that talk. Unity certainly is, and they seem to reserve special scorn for it, maybe because it's so popular.

I don't agree that it's easy to make Mario hit a stable 60fps in any popular gaming environment. In the browser, it's easy to hit 60fps but impossible to keep it stable. And, as you concede, it can be challenging with Unity (or Godot).

Latency is a separate issue from fps, even when the fps isn't janky. With your PC plugged into a Smart TV, you can hit a stable 60fps, but typically with two or even three frames of lag from the TV, which is a very noticeable downgrade from a 6510-based Nintendo connected to an RF modulator and a CRT TV from 01979. And often the OS adds more! Three 60fps frames of lag is 50ms. The one-way network latency from New York to London is 35ms. Most players won't be able to identify that there's a problem, but they will reliably perform more poorly and enjoy the game less.

I'm skeptical of the Muratori crowd's implicit assertion that this kind of responsivity is inherently something that requires the game developer to understand the whole technology stack from SPIR-V up. I think that's a design problem in current operating systems, where it definitely does exist. And, while I'm skeptical of their dismissal of the importance of bugs, I'm confident that they're representing their own needs as accurately as they can.

But probably it's better for you to engage with their explanation of their own ideas than with mine. I might be misunderstanding them, and I don't have their experience.