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...".
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.