Is that true? He is listed in the credits under "Additional contributions in programming by", and in his blog posts about the "Walk Monster" problem, his role sounds like that of an independent contractor brought on late in the project.
In any case, he has experience in working on and shipping actual 3D game engine code.
https://twitter.com/cmuratori/status/1514420516286709760
>Having looked at UE5's promotional content, I'm honestly just wondering: what is the point of Unity, now? Either you don't want to deal with a big unwieldy engine, in which case you roll/mod your own, or you do, and you would just use UE5, right? What am I missing?
>It seems like it is so far ahead of Unity at this point on all fronts, including asset provision (megascans + metahuman), I'm honestly just not sure what Unity's value proposition would be. Maybe devs who are sticking with Unity could fill me in?
Maybe he was truly just curious on an engine he never worked in and was genuinely impressed with the car sticker UE5 was showing (another engine he almost never worked in, so getting the information purely from PR. Point for Epic's PR team). But anyone who's seen the "debates" on those engines know he just sparked another war.
I just don’t believe that he has good judgement about what makes sense for people making games professionally in this specific context. And I think he could be much happier in his life if he just didn’t feel the need to shit on other peoples work.
You can do cool stuff in your corner of the world without being obsessed with what other people are doing.
If anything, you are the one “shitting on other peoples work” here by claiming he’s “spending a billion years”, or saying he’s not capable of judging something in his area of expertise. He’s one of the most knowledgeable experts in this field, make no mistake.
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.
- 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 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.
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.
> 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...".
Not dismissing the value of the series here, just saying the average would-be game developer likely does not have the same skillset as Casey and, unless creating game engines is the goal, would be better served by Unreal or Unity.
Even for a 2D game, there's big advantages to using a ready-made engine that natively supports many platforms, from mobile to high-end consoles (across OpenGL, D3D, Metal, and proprietary console rendering APIs).
If you're building a game engine as a fun/learning project, that's cool. But if your goal is to make a game, pick a ready-made engine as a starting point. Whichever you choose, you'll probably end up both loving it and hating it, but you'll get a heck of a lot more game-making done than if you go down the 'build your own engine' route.
Casey Muratori is not teaching people how to make an indie game or an AAA. He's teaching how to make almost everything in a video game from scratch. He speaks constantly of how he's not a game-code programmer, let alone a game designer. Pretty much everyone watching it knows what they're in for, because he talks about it all the time.
Those ready-made engines you're talking about have to be made by someone. Not to mention that anything beyond "basic indie game" requires someone who knows deeply how a game works. And those people are who Casey is currently educating.
Someone doing Unity/Unreal for several years won't learn those things Casey is teaching unless they really dive into deeper material, and Casey is providing exactly this kind of material.
This industry doesn't need more people with Junior-level experience even though they've been working at it for 20 years.
Maybe this kind of education not you, and that's fine, but just because something is being taught on the internet, doesn't automatically mean you and everyone have to learn it. You gotta learn to live with it.
And personally I find it rewarding to learn how to properly layer the code in order to factor out platform concerns. Many of the differences between platforms will seem kind of dull and the different platform implementations will seem kind of repetitive, but it's not terrible either if you develop on one main platform and routinely port to a handful of other platforms.
I suppose that graphics APIs are the biggest annoyance here because there is comparatively a lot of setup boilerplate required, and depending on your game, considerable math code will have to be in implementation-specific shader code. There are standalone 3D graphics libraries with backends for OpenGL/Direct3D/Vulkan/Metal, not sure how well they work.
I like tech riddles and figuring out how to make stuff work, investors unfortunately do not.
If you constantly have to defend why you can't just do X if everybody else can just because the stuff is only available on Unity and you have to write the underlying plugins yourself it get's old pretty quickly.
> If you constantly have to defend why you can't just do X if everybody else can just because the stuff is only available on Unity and you have to write the underlying plugins yourself it get's old pretty quickly.
Well this is a different point, not the one about platforms.
So "every" company that builds something in that space targets Unity first, Unreal second and after that maybe something like Godot. Most of the things can be implemented by developers not using Unity as well but while others are actually building the game, you are building the framework below it. That is a noble thing to do and will help the community in the long run but has zero advantage for shipping your game on time.
The best example is Meta's OpenXR support. They released it on Unity first (as they do all their other features) and Unreal game developers were complaining that they can't use passthrough because Meta hasn't rolled out support for Unreal for several months. So while the Unity developers were already happily working on their projects, Unreal devs were waiting and not even having a timeline when it will be possible.
In our case with Godot it's actually a question of, do we put in the time to port to Unity or do we put in the time to build support for all the things we need that are already available for Unity. And how often do we expect that situation to come up in the future
In that time, he's already got a hot reloading 2D engine https://www.youtube.com/watch?v=YBCOijN2fNA . And he's not exactly implementing it for speed of getting something done, but for educational purposes, by doing things like explicitly not using libraries, implementing PNG decompression, math functions, and doing software rendering first, and then switching to hardware acceleration even though he knew he would eventually do hardware acceleration anyway.
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.
Furthermore, 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." Do you know how many people his educational videos have helped? The amount of patience and dedication it takes to answer all of these beginner questions and explain things way below his level of experience in terms of difficulty qualifies him for sainthood in my opinion.