>His point stands up completely. You can follow handmade hero and have your own 2D game engine up and running in roughly 1 week's time.
No, Casey can follow Handmade hero and have his own 2d game engine up and running in roughly a week, at least in "get it done" mode instead of educational mode. I'm an engine programmer myself and I sure wouldn't have my own engine spun up that fast because I'm 20 years behind Casey in that regards (as well as any other non=professional years he's spent tinkering with low level code... where I learned what programming was at 16 years).
And even then, like most education these lessons don't take into account the time needed to go back and either expand on features or maintain bugs that pop up during game development.
>it's pretty disgusting to call an educational project that's had hundreds of hours poured into it "spending a billion years writing his game engine, and then whining about all these 'bloated' tools."
To be fair, this is a result of Casey himself dissing on the most popular engine and suggesting an ultimatim that it's either UE5 or make your own engine. I'm sure Casey's been around long enough to know that his words would spark yet another unnecessary "debate" on what tools are the best for the job. When the answer should be "whatever you and your team is comfortable with".
>Do you know how many people his educational videos have helped?
To be honest, no. That's the tricky thing about edTech. It feels like they help a lot in the beginning, but many people outside of a govt. sanctioned school environment will drop off quickly. That's not Casey's fault, but it does make me doubt that his videos will bring about an era of homespun engines.
The point was that for cases where Unreal 5 isn't suitable for your needs, what's the best alternative:
- Using Unity and potentially all the baggage that comes with it
- Making your own engine
Therefore the crux of the argument was to prove that making your engine wasn't as complicated as people are making it out to be.
From my perspective, the question he posed in the tweet is a valid consideration. What actually is the value added by using Unity beyond the initial section of having your engine bootstrapped?
> I sure wouldn't have my own engine spun up that fast
I'm thinking I should do as Casey has done before and put my money where my mouth is and show how long it takes me to make a 2D game engine in that same amount of time just by following HMH, but also with the ability to use existing libraries. I bet it'll be less than a week. And fwiw, I'm a software engineer at a high frequency trading firm with 12 years of self taught experience. I'm not a game developer, just an amateur who learned some things on the side. If I end up doing this, I'll reply to this comment with a link to the VODs.
And let's not forget, his target in the tweet was game developers. If they can't make a 2D game engine in 2 weeks (to be extra generous) full time work with their experience and literally just following HMH as a guide, then that's kind of surprising.
>the crux of the argument was to prove that making your engine wasn't as complicated as people are making it out to be.
the question posed is fine, the framing seems (potentially uninentionally) inflammatory, for a topic that is basically the gamedev equivalent of emacs vs vim. I feel like Casey should know better at this point, but maybe this was an honest blind spot. Or maybe he was intentionally invoking Cunningham (which seems unnecessary given his presence. But hey, it's effective)
>and show how long it takes me to make a 2D game engine in that same amount of time just by following HMH, but also with the ability to use existing libraries. I bet it'll be less than a week
depends on what we define as "game". I've done a fair number of game jam games in 2-3 days with a variety of technologies, from tiny 2d game frameworks to Unity. I could make something "playable" in a few days. I'm sure in a week with my experience that I could roll together something neat to show off to friends.
But I wouldn't consider any of those projects close to "shippable". And being a game dev I can talk your ear off for hours about the difference between "playable", "shippable"[0] , and "competent"[1], and the steps/polish needed for each.
To spare you that huge lecture, I'll just mention that gamedev, once you go past the "solo indie project" scale, is a multi-disciplinary collaboration between (but not limited to) programming, art, sound design, and writing. on any project past this solo indie project scale, you'll need tools to accommodate the non-technical folk, and those tools take time to develop and maintain. You can either play double duty as gameplay and tools programmer, have a dedicated tools maintaininer/go-between for the artists (because it always becomes a full-time gig), or make use of already made tools that already have these considerations in mind. In that latter case, an engine is invaluable.
[0] i.e. 99.9999% of games you'll find on steam are basically the benchmark of "shippable"... but how many of those in a random sample would you actually play for more than 5 minutes?
[1] you know, an actually good game that you'd pay money for, in an age where at least a bunch of mobile crap is free to screw around with for 5 minutes. If you're trying to make any revenue whatsoever, that's the bar being set.
What Casey is making is more like a reference guide to "if you encountered a similar problem, here is how I worked through it". Hundreds of hours of live video content is good source material for resolving a certain kind of coding bottleneck where there are no standard solutions. But it does also mean that most people, looking to solve standard problems in standard ways, had their questions answered at the very beginning, and the stuff that he's implemented since then pushes at the boundaries of his own knowledge. He doesn't have an ideal lighting or physics solution that he can clearly articulate step by step, but he also doesn't want to cut it down and leave those things unaddressed for the sake of making a consumable tutorial. So a lot of these later videos are plodding forward, revising, doing something a little hacky, coming back to it to change the approach.
And I think that's valuable in a different sense - for people who want to pursue engine dev in depth, this is ideal content. They want to see that grind taking place and how someone with a lot of experience approaches things. What they should and shouldn't prioritize. It goes well outside of the usual bounds of "education", which tries to package up testable knowledge, and is more akin to seeing a top athlete's workout.
Casey asking "why wouldn't you use UE5" is not being combative or ranty: it's an honest ask of what problems need solving that aren't accommodated by what is clearly the technological leader in most of the traditional metrics(render perf, hardware usage, asset pipelines for high end 3D, source access), but are accommodated by Unity. It does show his blind spot, which is that he isn't able to envision the larger span of production metrics himself - team familiarity and inertia, particular pieces of tooling and UX, etc. - but he's also trying to fill in that blind spot here.
I'm mixed on it. Because while I do agree that the content is worth its weight in gold (there really is no other source where you'll find a seasoned developer struggling in real time to solve a problem that has arisen. You don't see that in tightly edited turorials until you are that developer) it also does make filtering through to what you may specifically need a challenge. It can be difficult enough in a curated course to find the nuggets you need and Casey's videos are basically the equivalent of searching years of security footage for that one moment where you swear you saw a yeti pass by.
> It does show his blind spot, which is that he isn't able to envision the larger span of production metrics himself - team familiarity and inertia, particular pieces of tooling and UX, etc. - but he's also trying to fill in that blind spot here.
that's fair. I did consider that factor in a later comment, and I'm willing to give the benefit of the doubt (never shame someone for genuinely trying to learn). But I guess I do also find it surprising that someone as long standing in the industry and with as much of an internet presence as Casey wouldn't realize what kind of can of worms are being opened why stepping into the "engine wars".
Again, not his fault (he didn't start the fire). Just one of those moments where someone like me shakes his head and goes "here we go again...".
No, Casey can follow Handmade hero and have his own 2d game engine up and running in roughly a week, at least in "get it done" mode instead of educational mode. I'm an engine programmer myself and I sure wouldn't have my own engine spun up that fast because I'm 20 years behind Casey in that regards (as well as any other non=professional years he's spent tinkering with low level code... where I learned what programming was at 16 years).
And even then, like most education these lessons don't take into account the time needed to go back and either expand on features or maintain bugs that pop up during game development.
>it's pretty disgusting to call an educational project that's had hundreds of hours poured into it "spending a billion years writing his game engine, and then whining about all these 'bloated' tools."
To be fair, this is a result of Casey himself dissing on the most popular engine and suggesting an ultimatim that it's either UE5 or make your own engine. I'm sure Casey's been around long enough to know that his words would spark yet another unnecessary "debate" on what tools are the best for the job. When the answer should be "whatever you and your team is comfortable with".
>Do you know how many people his educational videos have helped?
To be honest, no. That's the tricky thing about edTech. It feels like they help a lot in the beginning, but many people outside of a govt. sanctioned school environment will drop off quickly. That's not Casey's fault, but it does make me doubt that his videos will bring about an era of homespun engines.