For those unaware, Casey Muratori started a project called Handmade Hero in 2014 to build a complete game from scratch while livestreaming the entire process, with the goal of showing people not just how, but why, rolling your own engine (hence the "handmade" part) is better than relying on Unity, Unreal, or some other leaky abstraction. He even solicited pre-orders for the finished product, IIRC.
Ten years later, he has no game, only a rudimentary, tile-based dungeon-crawler engine, and reams of code he's written and re-written (as API sands shifted beneath his feet), and the project seems to be permanently on hiatus now. Thus, Casey inadvertently proved himself wrong, and the conventional wisdom (use an existing engine) correct.
As far as OOP goes, 45 years has shown that it makes developers highly productive, and ultimately, as the saying goes, "real heroes (handmade or otherwise) ship." Casey's company was founded 20 years ago, and he's never shipped a software product.
He complains often about software getting slower, which I agree with. Yet how many mainstays of Windows 95/98 desktop software were written in a significantly OO style using C++ with MFC?
I think it's important to note a couple of things about this.
First, Casey offers refunds on the handmade website for anyone who purchased the pre-order. Second, the pre-orders were primarily purchased by people who wanted to get the in-progress source code of the project, not people who just wanted to get the finished game. I'm not aware of anyone who purchased the pre-order solely to get the finished game itself. (Though it's certainly possible that there were some people.) Whether that makes a difference is up to the reader I suppose, since the original versions of the site didn't say anything about how likely the project was to finish and did state that the pre-order was for both the source-code and the finished game.
Second, the ten-year timeline (I believe the live streams only spanned 8 years) should be taken with the the note that this is live streaming for just one hour per day on weekdays, or for two hours two or three times a week later in the project. There's roughly 1000 hours of video content not including the Q&As at the end of every video. The 1000 hours includes instructional content and white board explanations in addition to the actual coding which was done while explaining the code itself as it was written. (Also, he wrote literally everything from scratch, something which he stated multiple times probably doesn't make sense in a real project.)
Taking into account the non-coding content, and the slower rate of coding while explaining what is being written, I'd estimate somewhere between 2-4 months of actual (40hr/week) work was completed, which includes both a software and a hardware renderer. No idea how accurate that estimate is, but it's definitely far less than 10 years and doesn't seem very indicative that the coding style he was trying to teach is untenable for game projects. (To be clear, it might be untenable. I don't know. I just don't see how the results of the Handmade Hero project specifically are indicative either way.)
How much of that is due to the programming practices he espouses, I'm not sure. Ironically, if he went all-in on OOP with Smalltalk, I could see the super productivity that environment provides actually making it harder for him to finish anything, given how much it facilitates prototyping and wheel-reinvention. You see this with Pharo, where they rewrite the class browser (and other tools) every 2-3 years.
But his track record doesn't support the reputation he's built for himself.
> for game projects
That's the problem. Casey holds up a small problem domain, like AAA games, where OOP's overhead (even C++'s OOP) may genuinely pose a real performance problem, and suggests that it's representative of software as a whole; as if vtables are the reason VisualStudio takes minutes to load today vs. seconds 20 years ago.
The article you linked indicates the reason for him not finishing is specifically that he didn't like his game design, which seems orthogonal to coding practices.
He appears to have shipped middleware projects for RAD, and other contract work where he was not in charge of game design.
RAD was what, 15, 20 years ago? What has he released, in terms of proprietary or open source products, since then? Not just games, I mean ANYTHING. Refterm, and... what else? It's not like he was busy with his MSFT or RAD dayjob during this period.
He created Meow Hash somewhat recently and open sourced that. It's not a huge project but it's very useful. A lot of his time goes toward education, his personal projects and contract programming. Not every programmer is dedicated to releasing their own open source or commercial software. I'd bet most programmers don't. Using this as a metric to claim that he has a bad coding approach is ridiculous and laughable. Especially using Handmade Hero as an example... It really reveals your ignorance.
Also, since you care so much, let's see what you've released, smart guy. Preferably code so that we can see how talented you are.
> Also, since you care so much, let's see what you've released, smart guy. Preferably code so that we can see how talented you are.
I'm not the one telling everyone they're doing everything wrong, and did it not occur to you that my perception of what his output ought to have been over that timeframe (especially for someone who rates his own abilities as highly as he does) is informed by my own?
i think it's kinda funny, because Unity is very clearly inspired by some of casey's work
the big one is immediate mode UIs, which casey popularized back in 2005. Unity's editor uses it to this day, and if you do editor scripting, you'll be using it. for in-game UI, they switched to a component-based one, which also somewhat aligns with casey's opinions. and they shipped DOTS, which aligns even more with what he's saying
i think his lack of shipping is mostly because he switched to teaching and has absolutely no pressure to ship, rather than his approach being bad
I can see the argument for using a custom engine if you have specific design goals that can't be met by existing engines, but that seems seems like an edge case. I think 99% of game concepts can probably be done in Unity, Godot, or Unreal.
Meanwhile you could probably surpass Handmade Hero with any off the shelf engine with a tutorial and a few hours' work, or even a project template from an asset store. The biggest problem I have with Handmade Hero is that because Casey is putting so much effort into the coding and architecture up front, the game itself isn't interesting. It's supposed to be a "AAA game" but it's little more than a tech demo.
And that's why you use off the shelf engines - they allow you to put effort into designing the game rather than reinventing the wheel.
> 99% of game concepts can probably be done in Unity, Godot, or Unreal.
The vast majority of developers use these engines, so you would expect the vast majority of games to be stuff that's easy to make within those engines.
With how samey new games are, it's hard to argue that what we see comes close to the full design space of possible interesting games. That's partially developers copying games they've seen work and sell, but it's also developers making what is reasonably easy to make within Unity or Unreal with the resources they have.
I think it's hard to argue that there exists a vast space of untapped design potential for games that can't be realized only because of the limitations of off the shelf game engines. Most people who use custom engines use them for mainstream common game concepts, because they disagree with architectural decisions about the engine itself (most likely the language being used) and they would rather start from scratch than work with the engine.
Handmade Hero can be made in Unity or Godot. So could Braid. I'm actually struggling to think of a game built in a custom engine that's so radically out of pocket design-wise that it needs a custom engine. I'm not arguing that the use case doesn't exist, I'm arguing that most of the time using a custom engine is a matter of convenience and comfort rather than creative expression, and isn't strictly necessary.
A custom engine is never _needed_ technically speaking since COTS engines are often customizable to the point where you can do anything you want with them. That doesn't mean that they don't influence the design of games, though.
There's a talk that Casey gives where he explains how he implemented the movement system for The Witness, in which he shows examples of Unity-based "walking simulator"-type games dealing with limitations of the engine in ways that The Witness was able to totally avoid. This allowed the game's artists to be creative with set design without worrying as much about performance issues or collision bugs, thus potentially opening up more design space.
Here's some praise of The Witness by Fabien Giesen:
> That’s where I am right now. I have never seen another game as cohesive as this. Not even close. Without getting into specifics or spoiler territory, I have never seen a game with such manifest intention behind every single detail, nor one where all the details cohere this well into a whole. This goes for the design and gameplay itself, but also across traditional hard boundaries. Game design and art play off each other, and both of these are tightly coupled with some of the engine tech in the game. It’s amazing. There is no single detail in the game that would be hard to accomplish by itself, but the whole is much more than the sum of its parts, with no signs of the endless compromise that are normally a reality in every project.
> A custom engine is never _needed_ technically speaking since COTS engines are often customizable to the point where you can do anything you want with them
Yeah, no. You can make a lot of things with an engine, and if you don't already have the necessary talent to make a custom engine you probably should just not.
But there are certainly games which would not exist as "Just use COTS" games. The first which comes to mind is Outer Wilds.
Outer Wilds is running a tiny solar system model. Such a model isn't stable for very long even if you had a lot of compute power which a video game console does not, but in Outer Wilds there's an excuse for that [spoiler] the sun is about to explode, it's a time loop game. Still, this is a heavily specialised engine because normal games centre on the camera or player, Outer Wilds can't do that, the model would explode almost immediately if you do that, so the centre is the sun at all times.
I didn't know that. Although it seems as though they're sufficiently far outside what its makers thinks Unity is for that their attempt to go to Unity 5 had big obstacles. Thanks for correcting me!
[Also, another way I was wrong: to make Unity work the centre of the world is the player, and so the universe is implemented in reverse, your orbit around the sun is calculated with you at the middle, this works correctly in our actual Einsteinian universe - no position is privileged, there is no "center", but it would be crazy to do the maths, for the short time Outer WIlds needs it works well enough with their simple Newtonian physics model]
Ten years later, he has no game, only a rudimentary, tile-based dungeon-crawler engine, and reams of code he's written and re-written (as API sands shifted beneath his feet), and the project seems to be permanently on hiatus now. Thus, Casey inadvertently proved himself wrong, and the conventional wisdom (use an existing engine) correct.
As far as OOP goes, 45 years has shown that it makes developers highly productive, and ultimately, as the saying goes, "real heroes (handmade or otherwise) ship." Casey's company was founded 20 years ago, and he's never shipped a software product.
He complains often about software getting slower, which I agree with. Yet how many mainstays of Windows 95/98 desktop software were written in a significantly OO style using C++ with MFC?