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.
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.
Do you not feel as though that's incredibly anti-social? It's a very zero-sum "I'd prefer if things were better for me in direct proportion to how much worse they'll be for '_others_'"
A few quick q's, since I'm working on a game with a hand-rolled rollback impl (we have state copying, so we can do some nice tricks):
- Is there anywhere we can follow you about the clock-sync trick? I'd definitely love to be notified
- On the adaptive delay, are there gameplay or rollback engine implications to variable delays? Seems somewhat "unfair" for a player to be penalised for poor network conditions, but maybe it's better than them teleporting around everywhere.
Good luck with the project! I'll hopefully have a fiddle around with it soon :)
I need to emphasise that this is dramatically different. Comparing the first clip of OoT to [1], I see:
- Higher framerate
- Real-time lighting
- Real-time shadows
- Higher render resolution
- Water ripples/splashes (unsure about these being new)
- Widescreen, motion blur, etc.
If your contention is "they're not an improvement on the graphics, just changes", then we can agree to disagree, but they're otherwise incredibly noticeable!
Specifically, he's not just investing in startups, but investing in ones that have a factor that is either unknown or unknowable. That's a different strategy from YC's "Invest in promising founders" or the typical VC "Invest in early stage startups with good metrics".
I believe the new legislation says, if GP were to be punished for not being available for such a call, that'd be illegal and they could launch some sort of action. This seems totally compatible with GP's policy; boss can call them outside hours, GP can respond, if GP doesn't respond there's no consequences.
I believe this is a feature that exists with Copilot in VSC too.
I'm also not convinced it's useful. Either the commit message contains surprising information that cannot be derived from the changes, or it doesn't and the message derivation can either be done in-real-time or by reading the changes manually. In general, I'd prefer the former state of things; the commit messages I find useful contain the "why", which often isn't clear from the code changes.
They're in the process of swapping out their Mono fork for a modern Core fork, which I believe they're planning on upstreaming changes to too. A few years ago, someone demonstrated a 1-week hackathon version of a game build running on Core, and recently (2023-12), someone on the forum noted that they have an internal Editor running on Core.
Most modern large games use IL2CPP, the C++ transpiler; it's a requirement on iOS, nearly a requirement on Android, and almost certainly a requirement on consoles. Perf is often nicer and it's harder to mod/hack, which some devs like.
Sibling poster notes different .Net compatibility settings. Modern Unity versions allow you to be in either .Net 4.6(ish) mode or .Net Standard 2.0/2.1 mode. The latter comports more with Core's APIs, though is pretty old at this point.
And, since we're on similar topics, Unity currently supports C# 9.0, minus a few minor features[1]. This is a massive improvement compared to a few years ago, where we were stuck with C# 4 or 6, and means you can write pretty modern and performant C#. Especially notable is Span support, a way of representing (basically) non-owning array slices.
Troupo is citing facts, you're citing incentives/habits. While incentives are powerful and those habits have been borne out repeatedly by Apple, one of you has the clearly more documented argument. To be convincing, you need to demonstrate that Apple chose to deprecate Flash to help establish a walled garden. You've shown that they'd probably _want_ to, but that's still one step away.
I disagree with Harriet Johnson in at least a few cases, but the entire thrust of that piece and her argument within is "it's insane that people make judgements on my quality of life, without asking me, and say that I should not be born". You can make that argument and also believe that abortion is an appropriate tool for some cases.
I hear this claimed a lot. They removed it from their motto, but have retained it in their code of conduct, according to Wikipedia[1], and Alphabet has also adopted a similar motto. Whether you want to argue their actions match this, that's up to you, but factually, they did not drop it "from everything forever".
I'll note, for the purpose of discussion, that this is put forth as part of an example engineering strategy document. The author does not recommend _the reader_ do this, at least not here.
With that said, yeah, I think "a static ratio" vs "a flat count based on desired features" vs something else is an interesting discussion! My experience is that more product means more usage of the breadth of infrastructure, and requires both more infra development and more support, but I haven't worked in large orgs, so I don't know how this nets out as size grows.
I guess that's the parent's annoyance. It'd be nice to be able to use something like tags or labels for other things than releases, but since they're commit referents, they're pretty much only useful for releases and nothing else.
This is something that both interests me and seems difficult to build. I went to a random university in Australia, where there was a decent softdev club-ish thing with some graduates, and then moved to another city. I'd be happy to interface with that club and give back to that community in general, but that's about a thousand kilometers away now. It would seem weird to me to just go up to the local uni club here and be like "yep, I just want to lend a hand" -- that is, if I could even find said club!
I've heard of software shops in Australia that work on this model, too. I'm slightly unsure that it's actually beneficial for companies? Seems like having a bunch of juniors around and giving them more or harder work than they're ready for will usually result in souring client relationships when the work isn't up to scratch.
Not sure what can really be done about it, either. Seems like the issues are both hard to detect _and_ hard to regulate against.
With "something meaningful", I'm using the parent's terminology. If Guzey has written arguments against non-meaningful stuff, I don't think that's evidence for the meaningful stuff being wrong. That's about the end of my stance; I definitely don't have the info or background knowledge (or effort!) to evaluate either the book or the response on technical merits.
Not exactly a knockdown argument, but: if he was wrong about "something meaningful", Guzey probably would have added it to his list.
More generally, if you make a claim and someone claims you're entirely wrong, it should be surprising if they don't attack the parts you consider meaningful. If they wanted to publicly demonstrate your incorrectness, why wouldn't they attack the important parts? Either they can't, or they chose not to, but the latter doesn't match the apparent motivations.
If you think there's no value to present money flows, I'd love to take $1MM from you. I'll pay it back later, so there's literally no cost to you, right?
Opportunity costs, or any other "virtual" cost, are still meaningful figures.
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.