Hacker News Reader

Comment by rtpg | Hacker News Reader

Not to tone police that much but I really don't get people like Casey. Like his whole thing is spending a billion years writing his game engine, and then whining about all these "bloated" tools. Just completely dismissive of everything that doesn't align directly with his values (which don't include actually shipping game!)

I like people who write their own engines and make bespoke things for fun. Just really dislike people who lack the imagination to wonder why some people just want to make games rather than spend their life writing engine code, and actively shitting on stuff that exists. Just so much negative energy to put out in the world.

Of course in practice Unity _is_ a major pain in the butt but UE has the nice aspect of actually working for very large projects and shipping stuff. Yeah there's obtuse stuff, but in practice what happens is you join a team and then you actually learn to use it. In exchange you have releases.

The one thing that really is rough for me with _both_ UE and Unity is that they're both very oriented towards teams with dedicated art people who can put out assets to use. BSP-based workflows where you can quickly greybox out levels to playtest (basically giving level designers without art sense a fighting chance) are much nicer with older engines.

There's a nice missing middle that Valve kinda fills with Source, except everyone that has worked with Source seems to dislike it for other reasons. But I'm sure we could make 3D engines with nicer usability for people who, for lack of a better word, can't 3D model too great.

View on HN

Roughly 600 episodes translates to roughly 600 work hours. That's 15 weeks. And now it's a full 3D game engine. Because he's not doing it contiguously and instead doing it once a week or so (there are breaks sometimes), it's continued over many years. So by episode 40, he's done about 1 normal work-weeks worth of work (and in truth, constantly starting and stopping affects the productivity, as does doing it live and explaining yourself. Imagine your productivity hit while doing pair programming, basically).

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.

I think making the content he makes is very very cool! I think it empowers people and is super interesting! I think that kind of content is few and far between as well.

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.

He’s not doing that to engines in this case, though. The quote in the article is complimentary of UE5. And whenever he complained about bloated tools he put his money where his mouth was, depite people claiming it was impossible, or that it would take several man-years.

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.

These days, if you're making a game, even a fairly small indie game, you usually want it to run on as many platforms as possible.

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.

You're repeating advice for people with zero experience in making games, which is fine. But it doesn't have much to do with this discussion.

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.

On the other hand, porting to other platforms is probably never a no-op even when building on big 3rd party tech stacks. Many of the platform specifics will shine through to the high-level code.

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.

That right there is the crux: "And personally I find it rewarding to learn how to properly layer the code in order to factor out platform concerns."

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.

It is not a riddle. I see it as a general lesson in software architecture, that might help you just as well to factor the use of libraries, for example.

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

It actually is the one about platforms because Unity has established itself as the standard in game dev (and I am saying that as a Godot VR game developer who is trying to break through that)

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

I think the point here is that he has some really spicy takes that one can not call balanced or objective by any measure, while not doing anything that's impressive enough to actually deserve to be taken seriously when it comes to such sweeping claims.

Casey has been in the industry since before DirectX existed, worked for RAD Game Tools, and likely has code in more games than you've ever even played.

...and I've been programming games since 0x13h ModeX and contributed to core industry software. Which means absolutely nothing. It's quality times quantity. Not time and acquired credentials.

Well then, perhaps you have inside knowledge to share that justifies your claim that Casey hasn't done anything "impressive" enough to justify his take?

Can you provide an example of that?

you mean this topic in general? The tweet this response came from is Casey's:

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'm looking for a single example of a "really spicy take that one can not call balanced or objective by any measure".

He was a programmer at RAD game tools, which is industry standard for game tools. He also was the principal game engine engineer on The Witness, and has probably worked on other 3d games in the industry.

> principal game engine engineer on The Witness

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.

I remember he mentioned something about his role to that effect in one of his handmade hero streams. Can't remember which exactly, but he did mention he did a bunch of code contributions to the engine. Possible I am misremembering.

In any case, he has experience in working on and shipping actual 3D game engine code.

One of the things he did as the tooling https://www.youtube.com/watch?v=JhvnJWKfELc

So he powers off after every video? And doesn't think about it until the next video?

600 work hours give or take the 20,000 that got him the expertise required to sit down and write it in the first place. Do you end up with your own game engine, or a clone of Casey's game engine? That depends on what you already knew going into the series.

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.

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

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

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.

You have been overly dismissive of Casey's work. HH is a treasure, and if you consider that he explained the how and the why of every single line of code, on stream, without cutting any corner, your consideration about the time spent become meaningless. There are people interested in copy-pasting and glueing together pre-baked parts to ship something, and there are people interested in developing a deep understanding of how things work, to be able to break and reassemble new toys with complete freedom. There are people that value the product and people that value the process. Casey's work is targeted at the second group, and I thank him immensely for what he does, even if some of his rants are pretty ignorant (usually when talking about things he knows nothing about). Take the good parts. There are many.

yeah I think what he does is cool! Just like… ok if you’re that person you’re not using Unreal or Unity anyways.

> You have been overly dismissive of Casey's work.

I am reading it not as what Casey is doing isn't cool, just that it is not at the level to enable Casey to be himself dismissive of other people's work to the extent he is.

Has nobody looked at what Casey did for a living before Handmade Hero?

You mean like that time he cobbled together terminal emulator in a week running at >1K fps after some MS drone called it a doctoral thesis project level of difficult?

If you look at the background Casey was in, then his thought process becomes a bit understandable. He worked for a long time doing R&D at RAD Game Tools, which is a company that provided various game development middleware and tools. So his interests naturally gear more towards low-level game tools/systems development rather than high-level design and scripting, which is why he couldn't understand the value proposition of more widely-used monolithic game engines like Unity, Gamemaker, etc. (For example, his attitude towards actual gameplay code in Handmade Hero is "It's not my concern, I'll finish the engine and then someone else will fill the gaps").

Note that he almost did have experience in creating an actual full game by himself before, though he didn't publish it eventually since he was unsatisfied with the final product, which is quite absurd to me! (https://www.destructoid.com/he-worked-on-it-for-three-years-...) He also worked on The Witness team with Jonathan Blow and others, but mainly on engine programming. He is currently working on a new game called 1935 (along with his other myriad projects like Handmade Hero and Star Code Galaxy), but details about it are very, very sparse.

> He also worked on The Witness team with Jonathan Blow and others, but mainly on engine programming.

Just to be clear, he came into the project much later and didn't contribute nearly as much to the game as i.e Jonathan and Ignacio.

His contributions seem limited in scope but very significant: https://youtu.be/YE8MVNMzpbo

It's worth noting that Jonathan's tone is very similar indeed.

> Just completely dismissive of everything that doesn't align directly with his values (which don't include actually shipping game!)

I think you're reading something that's not there. Some big name (and "big" is relative) says something, like Carmack, Stallman, or even someone like Jeff Vogel, and people get up in arms about it. To be honest, I think most people are reacting to how celebrities make them feel rather than what celebrities say. If Muratori is "dismissive", it could be because you feel dismissed, or some other feeling you have, rather than something Muratori is actually saying.

The biggest problem with tone policing is that it's so damn inaccurate.

Anyway, we need people like Casey Muratori in the ecosystem. You get a mix of architecture astronauts and philosophizers with "just get it done and ship it" folks. Both groups of people learn things that the other group needs to know. Both groups of people build things that the other group wants to use.

> Just really dislike people who lack the imagination to wonder why some people just want to make games rather than spend their life writing engine code, and actively shitting on stuff that exists. Just so much negative energy to put out in the world.

Doesn't seem like Muratori to me. He does have his weird fan group that seems to amplify stuff he says 100x (like Blow and Carmack), but calling Unreal "unwieldy" is not exactly "shitting" on it. It is unwieldy, like most mature pieces of software. I often say that C++ is a trainwreck of a language, but that doesn't mean that I don't think that C++ has a value proposition. If I said that with a fan group like Muratori's weird fans, maybe it would make people more upset--as it is, I'm just some unknown commenter on HN.

> Like his whole thing is spending a billion years writing his game engine, [..]Just completely dismissive of everything that doesn't align directly with his values (which don't include actually shipping game!)

I think Casey has been vocal enough (at least in his HMH streams) that he is not a game designer, but a game engine programmer. He is trying his hand at making full games, but I wouldn't expect him to skip over the part he is proficient at to the one at which he isn't.

As long as the "why" of making his games is not "getting rich", I think it's uncharitable to sneer at his choices.

I don’t mean to sneer at his choices ( I think it’s cool and fine), I just wish he would spend less time sneering at other peoples choices (especially when that antagonism just makes it harder for someone to not get defensive).

I think a balance needs to be found. Maybe what you're looking for in Casey is not what he provides. He tries to provide people with sound engineering foundations on which huge engines can be built.

I think this isn't what a lot of people (including me) are looking for. They are looking for a tutorial on how to build a relatively competent engine from scratch in a decent amount of time.

Which is entirely possible, I don't claim to have Casey's engineering chops, but in college (about a decade ago), I built an engine with dynamic lighting, physics, loading 3d models and integrated Lua scripting from scratch in about a month while doing my classes.

It was as I remember, between 10k and 20k lines, of not very pretty code.

While I wouldn't show the code as an example to anyone, even if I had it, I think people need to realize, that for their own game, writing the necessary engine plumbing might be entirely possible, and a lot more possible nowadays, and if people actually built a community around this attitude, a lot of tooling, whose lack can be painful now, might just emerge from folks.

I think if you can build solid engine foundations in a month, that's a lot less time than what you'd have to spend with wresting Unity's broken, undocumented, ship-of-Theseus, features (Scriptable Render Pipelines), doing frustrating trial and error, and mining obscure forum posts for nuggets of info.

You clearly have no idea what's he is all about.

His message is very clear: Modern software is crap. It's orders of magnitude slower than it should be, it's buggy, and,yes, bloated.

And if you ever used any piece of software today I don't see how you can you not agree with it...

He is never advocating NOT using engines, but rather that one can be much better and more efficient developer with just a little bit knowledge of inner workings of an engine.

Him "spending a billion years" is nonsense. Handmade Hero is his side-side project which he does once a week for couple hours. You can think of HH as a teaching tool (and not even a good one which he would admit himself im sure) and not 'here is definite guide on how you make an engine yourself'. HH inspired and showed ropes to so many developers, its value is immeasurable.

> Modern software is crap. It's orders of magnitude slower than it should be, it's buggy, and,yes, bloated.

And, that's where he lost me. Software was always crap. Emacs = Eight Megabytes and constantly swapping.

Because even if you squeeze every last cent of performance, someone will have a great idea that will spend each dime you saved and then even add some debt on it.

Performance is never a positive as much as a disqualifying negative. Features are what sell the software. Why would people use/pay for IDEs over a free text editor.

And if you listen to Casey's advice, well, be ready to rewrite your entire stack because almost no software today is willing to do what you need. It's a good advice if you know you'll keep programming for next 120-30000 years. And don't have any competition willing to cut corners.

A game that illustrates that success is tied to performance is factorio. Because it can scale to absurd amounts, while still running on an old labtop.

It’s in a genre with notorious performance issues and limitations as well as bugs, but they managed to put in the time and effort. Some of the lessons and solutions are quite educational even.

There’s games that are ridiculously simple in comparison let your fans spinning for no reason, grind to a halt or crash.

Performance is key here, as it is one of the most limiting factors for _both_ quality and features. Namely the things you can do and how well you can do them is tied to performance. If you are pushing those in any dimension, then you want control.

> A game that illustrates that success is tied to performance is factorio.

Sure, performance is important if you are making a game with that level of simulation. Most games (or software in general) don't go for that level of simulation/performance.

For every Factorio, there are thousands of games that work just as well without that level of simulation. From FPS to trashy mobile games that are just a well disguised slot machine.

> There’s games that are ridiculously simple in comparison let your fans spinning for no reason, grind to a halt or crash.

Sure and Morrowind used to corrupt your save-files in a horrible manner. It still sold as hot cakes. Even though I remember it being a hog on my resources.

Warcraft 3 had an unpatched memory issue people used to extend its programming capabilities, until it turns out said issue could be used for RCE, so Blizzard had to break every existing custom map (like DOTA, not like custom melee map) to fix it. It started several independent genres.

------------

Point is you don't need to think about every ms of execution if you are writing 99.9% of software. Sure you can take some precautions and use some tried and true methods (using immutable trees for editing).

But even those come with caveats. You have only so and so complexity budget, will you spend it on features or performance? Almost always the answer is features.

That’s right but the point I was trying to make that there are whole categories of features you cannot implement if performance doesn’t allow it.

I‘m not looking at this from a pure business perspective because it’s not fruitful. We all know that you can produce crap and make a huge buck, because of marketing, dark patterns, manipulation, exploitation, luck and so on.

I‘m saying there are good examples where building things from a lower layer up does not only make sense, but is necessary for creative freedom and quality they achieved.

Sure, software of the past wasn't that much better, but relative to hardware it ran on it was much more performant.

I think the main point of his view is that with current hardware advances we should be able to have a cake and eat it too. We can have both the features and the speed, but we don't care about that. The only thing that matters is to be first.

> The only thing that matters is to be first.

To quote a famous asshole: "Real artists ship."

Or another "Perfect is the enemy of Good Enough™"

Network effects are real and being first to (idea) market has its own benefits. Who would have thought, speed of development has its own merits.

It is possible to have the cake and eat, meaning: have performance and be first, as has been shown recently by Casey Muratori himself in a very public debacle.

People who care about performance also care about speed of development. The only people saying it's impossible to reconcile both is the people who religiously dismiss the need for performance in modern software.

> Performance is never a positive as much as a disqualifying negative. Features are what sell the software

Except we're talking about video games, where time and time again performance was crucial in achieving new breakthroughs, from Mario's side scrolling, to Carmack's advances in FPSs, to... FFS, we're talking about Unreal 5, this version's selling point is mainly being able to do in realtime what was previously only possible before with offline rendering.

Just because there are trash mobile games that make money doesn't mean there isn't money in high-performance software.

> Except we're talking about video games, where time and time again performance was crucial

In that domain speed is pretty important, but even there it's not as crucial as you might assume. I'm not saying discount it altogether, just good gameplay will trump good performance. They aren't completely unrelated, but there are diminishing returns.

What are the titles that need to be that much performant? AAA titles are just rehash/sequels with latest monetization tactics tacked on. On low end you got shitty mobile games that only optimization is user conditioning.

That leaves you with Indies, that can use GameMaker/Unity and still get their game out.

Sure some AAA use Unreal to their absolute limits. In same way some people develop drivers for embedded hardware. You still don't want to develop games and software in general, the same way those few studios do.

> What are the titles that need to be that much performant?

Nearly every single game no matter what it looks like makes performance trade offs.

Number of enemies on screen, ai search depth, world size, world granularity, whether to allow partial transparency, number of lights, number/complexity of systems etc…

Even for something that may look like just another indie side scroller.

Sometimes these constraints breed creativity. But if you use game maker/unity, you will find yourself regularly running into performance issues that will require problem solving.

The same is true when making an engine, but the problem space is far, far more nuanced than just: some types of games don’t need to worry about performance and so are fine using game maker/unity.

That's a gross simplification of how the market of games works and why people buy them. Plus, you're claiming that both AAA and mobile are money-grabbing schemes where performance and features affected by performance don't matter, which couldn't be further from the truth.

Not to mention that very often good gameplay also requires appropriate performance. This is still critical in titles not targeting high-end hardware, but also in AAA. Frame render time matters, and lack of performance can affects the work of not only developers, but also artists.

Even in mobile games performance could make a huge difference: something with low performance might not run in some mobile phones and you'd lose a huge chunk of audience (and no, before you say it, it's not just people with iPhone 16s that are a target to make money).

> That's a gross simplification

Sure it's a simplification. But it is the truth. AAA are generally that way now, because people don't want to bet a lot of money without it being a sure fire bet. And it's same for game mills in mobile land.

> Not to mention that very often good gameplay also requires appropriate performance.

Yes, but point is good performance. Casey insists performance is thing to optimize for. When in reality it's like n-th thing to focus-on.

> Sure it's a simplification

Yep, a gross and incorrect one, invented only to advance an argument that doesn't match reality. Performance and ms-per-frame is still highly critical in AAA-land, despite your opinions on current gaming trends. There are people working hard on it, including the Unreal and Unity teams.

> Yes, but point is good performance. Casey insists performance is thing to optimize for. When in reality it's like n-th thing to focus-on.

Again, this is a bit of a misrepresentation, and probably a bit of projection. His rants are often about specific issues he finds, and mostly about low-hanging-fruit issues that cause real usability problems for end users.

He might write and teach how to write high-performance code and high-performance architecture, but it was not to the detriment of code quality, speed of development or architecture quality. The architecture of Handmade Hero, for example, is significantly better than most "make your own engine" shows on Youtube.

> Yep, a gross and incorrect one, invented only to advance an argument that doesn't match reality. Performance and ms-per-frame is still highly critical in AAA-land,

I beg to differ it's not an incorrect one.

AAA Titles (+ if I did play them):

Destiny - Review say perf OK.

Elden Ring(+) - Performance Ok on consoles on release it was a slideshow. It ran like garbage. Personally I think it's a clusterfuck

GTA V(+) - Had a huge performance blunder. Released for n-thienth time. Good performance today for game that was released in 2013.

FIFA/NFL/Sports game - Runs ok. It's the same game as year X-1 except with some tweaks (like microtransactions and ads).

Call of Duty - Review while perf is Ok, it's not something

Battlefield - They were Ok, they went too loose with optimization resulting in the shitfest that was 2042. They got punished for it.

Fortnite - Sure stellar work from the guys making Unreal engine no complaints.

According to revenue PUBG belongs on this list. PlayerUnknown’s Battlegrounds - Barely holding itself at the seams this game made mad money while being a buggy and lice infested mess. It

Pokemon - It's Ok, but nothing to write home about.

Resident Evil: Village(+) - Played it. It ran like shite. Had to crack it to get decent performance.

Far Cry 6 - Ok performance, but essentially Farcry X-1. With more content.

---------

From examples given, while performance is usually critical for online multiplayer shooters, it's not so much being faster as being less slow than the guy next to you. E.g. PUBG was fine and dandy, even though it was really, really badly optimized.

> Again, this is a bit of a misrepresentation, and probably a bit of projection. His rants are often about specific issues he finds, and mostly about low-hanging-fruit issues that cause real usability problems for end users.

It's not. He compares Visual Studio 2019 to Visual Studio 6 and concludes that MSFT is staffed by idiots https://www.youtube.com/watch?v=GC-0tCy4P1U

Does he compare OS support? Features present? Libs used? No. It's bad and it sucks an MSFT doesn't know to do fast software.

I think you're missing the point about performance in games.

More than in other kinds of software, adding new "features" to games tends to slow the game down more (you're trying to do more in the time you have to render a frame). So often performance improvements are needed simply to make room for more "features".

>So often performance improvements are needed simply to make room for more "features"

absolutely. I'm an engine programmer and this has to be my train of thought, otherwise I'd be out of a job (you know, until the 11th hour where I break a lot of work just to get something out).

I'm not saving a few milliseconds on some feature that "only" takes 2 milliseconds because the game needs maximum performance. It's so when the director or designer comes up with some other crazy idea that they have more frame budget to try and fit it in. They may still not be able to, but I don't want my default answer to be "no, we can't spare the time" (not unless it's something absurd).

And I'm saying. Sure some games/software goes for careful time budgeting.

Others don't. Because the floor for performance tolerance is low enough you don't need to bother most of the time.

After all premature optimization is the root of all evil.

I suspect that even for the slow games you listed, performance was very important to get the number of features they needed into the game.

> After all premature optimization is the root of all evil.

This quote means not to optimize too early, not that you shouldn't optimize at all.

>AAA titles are just rehash/sequels with latest monetization tactics tacked on. On low end you got shitty mobile games that only optimization is user conditioning

ehhh. I agree with most of your sentiment, but this is starting to be the gamer version of this topic. Replace "modern software is crap" with "modern AAA games are crap". The industry is too varied to lump it all into one box, especially when several of the largest games this year came out with your normal "buy one get everything" monetization.

Back on topic: I'd say optimization is still an important and under aprreciated factor of development. One where you don't notice it when it's done right but is all that's talked about when done wrong. I want to hope UE5 solves some of those problems, but the proof will be in the pudding as always.

> starting to be the gamer version of this topic

They are crap and getting worse on a completely different axis (social engineering). It's not all gloom and doom, people can get insensitive to strategies and good games haven't, stopped getting made.

> I'd say optimization is still an important and under aprreciated factor of development

I never said it didn't. I said It's not be all end all, and not optimizing is causing collapse of civilization.

> Except we're talking about video games

Not really. Most of the times Casey & Co. (Blow et others) have entire rants bitching about photoshop, visual studio,windows, websites etc. They tend to present videogames as example of "how it should be done".

They (again, as Casey&Blow and the rest of the group they seem to belong to) have this weird attitude of automatically dismiss anything that doesn't belong to whatever microsubset they are already very experienced in.. so Rust is shit, C++ is shit, GC is shit, smart pointers are shit, get/setters are shit, public/private is shit, memory safety doesn't matter and so on.. all this while not offering any alternative other than "git gut". I tend to agree with a lot of the rants to be honest but I also perceive their suggested solutions as total non starters for large scale development.

That’s an unfair mischaracterization and generalization, considering that very often those “rants” are often filled with genuine analysis, criticism, comparisons.

Or, in specific cases, such as OOP criticism, with very vocal disclaimers that his view deviates from the mainstream. Are those people not entitled to an opinion?

The last time one of those happened publicly, Casey was able to provide a proof of concept in a very short timeframe, despite claims that it was impractical and borderline impossible to fix.

Casey is much better and more measured on this front than Jon Blow, who has a history of wandering into random comment threads on HN and pronouncing some topic a "solved problem" or "trivial", only to actually work on the problem himself a few months later and remark that it is more complex than he thought.

But because Casey and Jon are friends and frequent collaborators, and generally prioritize the same things, they get interpreted as sharing each other's views about everything. They don't, but the mischaracterization is not easily dispelled.

If he’s all about saying modern software is crap, then his opinion isn’t very good imo.

I’ll say it again: I think he makes cool stuff! I just don’t think hes right about his judgement here

If you see his points and still disagree that's fair enough

> If he’s all about saying modern software is crap, then his opinion isn’t very good imo.

That's extremely reductionist. He's saying that modern software is crap regarding performance. And whenever he does complain, he manages to demonstrate it.

What's the conclusion though? Modern software is crap so you shouldnt use any libraries and roll your own implementations of everything?

Sounds like a recipe for lots of bugs.

Did you had fun knocking this strawman?

Nobody said or implied that you need to eschew libraries and write everything from scratch to achieve performance, and it is frankly a very dishonest way of conducting this conversation.

Especially considering that we’re talking about someone (Casey) whose previous job was pretty much selling high-performance libraries (RAD Tools).

The claim from the (to be cheeky) “anti-performance” crowd is that it is impossible or unnecessary to extract more performance from modern computers. All that we’re saying is that things are not so black and white.

“The conclusion”, if you need one, is that people saying that more performance is impossible or impractical as a knee-jerk response are often wrong.

If there is no conclusion then you are just un-productively saying "modern software sucks".

My point is, if the claim is that modern software is bad, what do they offer as the solution to that?

> The conclusion”, if you need one, is that people saying that more performance is impossible or impractical as a knee-jerk response are often wrong.

This is barely a statement. I've never heard "performance is impossible" from anyone, and it's amusing you would accuse me of a strawman and then introduce one like this.

The phrase “software is crap” was said by someone criticizing Casey Muratori, not by himself or by me. It was a mischaracterization.

If you want to paraphrase him correctly, he has claimed several times that there are several low-hanging-fruits performance-wise in modern software.

> I've never heard "performance is impossible" from anyone

First, I said “impossible or impractical”. This comment section is littered with the second. Second, this is not an exaggeration, nor refers to you. It actually happened: a FAANG product manager told Casey it would take several years and a PHd degree to fix some performance issues in a MS product that Casey had diagnosed. Casey then proceeded to create a performant proof of concept with feature parity over a weekend or so.

> what do they offer as the solution to that?

Are you asking for a silver bullet? Because there are none. The first step towards a solution for low performance in modern software is stopping the automatic reactions of saying performance is unnecessary, impractical or even impossible, whenever someome with enough knowledge of the problem domain claims otherwise.

The path to faster software involves actual hard work, rather than attempting to publicly shame people who offer solutions.

I really don’t think this is unreasonable at all.

> The path to faster software involves actual hard work, rather than attempting to publicly shame people who offer solutions.

Again, what solutions? Until you can define what these are I'm not sure what his position is or what he's advocating for.

No offense but I've exhausted my interest in the topic, take care

> Again, what solutions?

I am talking about actual concrete solutions. “Do this code change and the bottleneck will go away”.

This person offered ACTUAL CONCRETE SOLUTIONS to performance issues. He literally opened bug-tickets and discussed with the team, and provided proof-of-concepts, but a FAANG manager attempted to shut him down.

This is not some snake oil salesman offering magic performance beans, this is someone who actually knew what they were talking about, and was able to diagnose performance problems in the operating system and solve it, for free. This isn’t some hypothetical, he REALLY did fix it despite being told it was impossible.

EDIT: Like the sibling poster said, the systemic solution is to "git gut". Which is clearly impossible as long as developers and managers foster a culture of dismissing performance, or in some cases inventing excuses not to work on it, as was seen in the Casey/Microsoft debacle.

>Again, what solutions?

The solution is to git gud.

There certainly was actionable advice in the couple of his videos I've seen (I haven't watched many, he's a wandering talker). But the underlying theme is about development process and frame of mind. Just adopting a list of techniques would miss the "greater than the sum of it's parts" value.

>The solution is to git gud.

someone unironically espousing this as a "solution" to a struggling creator will never understand why other frameworks become popular when they cater to helping them out instead of throwing a book at them. That's why Unity is more popular among small creators. They don't necessarily want to be an engineer, they want to create art.

This mentality spreads outside of programming to other software as well. Gimp, Blender (which is fortunately making changes towards accessibility), etc.

> someone unironically espousing this as a "solution" to a struggling creator

Nobody is, though, and if you see other replies with the “git gud” text you’ll see this is used as a way to attack anyone who cares about performance.

If not blatantly obvious, I was being flippant.

You seem committed to the idea anyone is advocating yac-shaving by a highly constrained developer. I'm not seeing that.

Like anything in software projects, the path of least resistance will get you to the quality floor. Trivially actionable advice doesn't exist because it will become part of the quality floor. That's just the evolution of software.

That doesn't mean there isn't actionable advice that's low on the learning curve. But like others skill, there is an unavoidable learning curve, it also takes time to apply the skill, and choosing when to apply it is a skill in and of itself. That's just life in development.

I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done. And the state of affairs is that performance is very frequently sacrificed, leading to a pretty damn sorry looking status quo.

>If not blatantly obvious, I was being flippant.

Poe's law is in effect. I've seen that sentiment elsewhere and even in this post espoused unironically. It happens quite often in these circles unfortunately.

>I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done.

there isn't, but there is something wrong when you question the quality of a developer over it, while not understanding their constraints on knowledge, time, scope, and overall goals. It's just very presumptuous and I've never seen a justified case to shame someone as such.

Promote good practices, educate on bad ones. You can do this without such attitude as "git gud" which targets devs directly (which may not be something you said, but it is said often enough that I feel a need to address it).

Isn't the reason that Unity/UE have crap performance because of the capabilities they offer? For example, you can run the app on multiple platforms.

This is the Electron or Hybrid app argument all over again. For 95% of the applications built, the ability to launch on Win, Mac, Linux, Android and iOS far outweighs the bloat and performance hit you have. But for the few AAA titles out there, then yes supporting native support might be worthwhile.

I mean, thats what modern software development is all about - tradeoffs.

> Isn't the reason that Unity/UE have crap performance because of the capabilities they offer? For example, you can run the app on multiple platforms.

Is anyone, Casey or someone in this thread, complaining that Unity or Unreal have low performance? I don’t think so.

Casey Muratori’s performance rants of the past were almost always about specific pieces of software and in the most public of those he managed to show how to fix those in an acceptable timeframe.

> or someone in this thread, complaining that Unity or Unreal have low performance? I don’t think so.

https://news.ycombinator.com/item?id=31069502

> That's extremely reductionist. He's saying that modern software is crap regarding performance. And whenever he does complain, he manages to demonstrate it.

Did you even read the thread I was responding to?

As far as I know, UE doesn't have crap performance. Some features of Unity might have crap performance, and the solution used by studios shipping games in Unity is to not use those features or use them very carefully.

I'm not GP, but I read the thread, and it seems like you think that this guy has severe performance problems with every piece of modern software, and therefor he has severe performance problems with UE and Unity. He doesn't though. If he did, he would probably publish some rant about the particular problems he has with these particular pieces of software

> and it seems like you think that this guy has severe performance problems with every piece of modern software

You didn't read the thread then. The parent of my parent commented that they thought performance was a problem. I was just responding to that inference. That's all.

> The parent of my parent commented that they thought performance was a problem

You are talking about my post. I did not say anything specific to UE5, I was only trying to fix a misrepresentation of someone else. Please read the full thread for context, and also my replies to you if you need clarification.

That's my post and I didn't complain about UE5, nor said that Casey Muratori did. Let alone saying that UE5 performance is crap.

Also, please read to this part of my comment if you want to understand the situation:

> Casey Muratori’s performance rants of the past were almost always about specific pieces of software and in the most public of those he managed to show how to fix those in an acceptable timeframe.

I find it weird to say that UE would be crap in what it delivers in performance. Or that someone could do better. At least if it comes to real-time graphics rendering and processing. Not saying there isn't likely warts and issues in the gameplay side...

> I find it weird to say that UE would be crap in what it delivers in performance.

I don’t think anyone is saying it. Grandparent poster is inferring it incorrectly.

So you think UE 5 could be 100+ times faster? For reference that means we would be able to run UE 5 games for the PS5 on the PS3 twice in parallel. I doubt you really even believe what you just wrote.

Doesn't it strike you as ironic to shoot out a claim as reductionist as "Modern software is crap." and defend the subtleties. But also call out (what I felt was) an obviously hyperbolic statement in response to another hyperbolic statement without regarding the underlying message?

I don't think that's fair. Sure HH has been going on for eight years, but on average Casey is only putting in 3-4 hours per week. That's not even half a work-day per week. Not to mention that he spends a lot of time explaining every single decision he makes and does black-boarded lectures on pretty much every subject covered in the series.

I think it's reasonable to assume progress would be at least 3-4 times faster if his focus was solely on the code. So what you call "a billion years" is actually more like a total 2-4 months of fulltime coding.

That's assuming each episode doesn't take him any preparation time.

I find him to be elitist sometimes. The community he built around himself likes to gatekeep by defining what is considered "from scratch" and what isn't. I looked up his youtube channel, and it seems he spent few weeks writing an abstraction layer over WinAPI. You could just download SDL and get it over with in a day (and support more platforms). I don't think there's anything wrong with that. There's a difference between using a large framework/engine, where you only give inputs in and get outputs out, and using small libraries to abstract over specific parts of logic. And even after a year of work, the "engine" seems to be very unimpressive, capable of doing some basic 3D graphics.

The whole point of the series is teaching the necessary skills for understanding, writing and maintaining something from scratch, like an engine if need be, but also something like SDL too.

Like it or not, this is interesting to a lot of people. Plus, someone has to maintain and contribute to those libraries like SDL. This is where you learn to.

Plus if you want to see libraries being used there are countless other Youtube channels doing it. This one is just daring to be a bit different.

About the elitism accusations, I frankly don’t see it, and I believe you are strongly projecting your own insecurities here. There is even a semi-official “port” that uses SDL2, done by an audience member.

Accusations of the community being “anti-library” are unfounded, especially considering Casey’s first notable work was in a company that would sell high performance libraries for games (RAD Tools).

> Not to tone police that much but I really don't get people like Casey. Like his whole thing is spending a billion years writing his game engine, and then whining about all these "bloated" tools.

It takes some rather strong motivation (and opinions!) to make your own. If you were fine with whatever was already there, you probably wouldn't bother...

I don't get Casey's point nor your dislike for him either.

I think that between writing your game engine and going full UE5 there is space for a middle ground of smaller, simpler engines. If I were to write a game today, unless I wanted that AAA look with UE5, that middle ground is where I'd look and be most productive. Still waiting for Godot 4 here.

He's not saying don't use UE5. He's saying what's the point of Unity now that UE5 exists.

I know. I'm saying there IS a need for Unity, while Casey argues that either you go full UE5 or you write your game engine. Black or white.

UE5 is too complex for most indie devs, not good at 2d and pixel art, and writing your game engine as a small team is a good way of spending 2 years on engine code, instead of, you know, actually developing a game.

To be clear I agree with you. I use Unity for my hobby stuff because I have 0 interest in using either their subset of C++ nor Blueprints (the only things that visual scripting style things appeal to me are 1. Shaders and 2. content generation in Blender). Just the way you phrased it made it sound like he was against UE as well.

Just curious, have you seen the new tools in UE5 for prototyping levels? I haven't used older game engines, but these are rapid enough for me for blocking out a level.

https://twitter.com/highlyspammable/status/14963145572410982...

ProBuilder and ProGrids (I think ProGrids is still 'experimental' but easy to install) do all of this for me.

Not debating that, was just wondering if this is the sort of workflow they were used to.

When I used ProBuilder and ProGrids, the workflows there weren't quite as intuitive for me. Not bad, I just didn't put the time in to get comfortable with them.

I think you might have missed his point. The gist of it is that almost all modern software is at least 100x slower than it needs to be, for no good reason.

Conventional software practises result in unnecessarily complex code that takes much longer to write and to execute than needed. The problem is so endemic that there isn't really even a good programming language available that makes it easy to use the capabilities of computers.

Fortunately there are a few pioneers trying to improve things, constructively creating solutions such as JAI. Casey is fighting against the fact that not only are industry participants unaware of the problem, buy they actually fight to write bad code to ship bad software to customers because they believe that is the pinnacle.

Why are so many afraid of "negative energy"? Let the man be weird. He doesn't exist to serve your opinion. Open your mind, dude

I freaking suck at modeling and I've been at it for years. Been working with Unity and shipping stuff for a decade. It helps to know how to get the right partners I guess, but I've always been able to get stuff done with Unity. Now the momentum I have with my app store, maybe there aren't many ideas anyone could throw at me where I have to do much more than load up a few things I already own and push stuff around. I barely write code... But its' a lot of experience, unity has gotten massively better. I used to write a lot of C# and trained collaborators on Playmaker. Now it's more focused on just keeping the working directory clean, I don't really like their collab stuff, I prefer to maintain my own git.

What I do and have done is never the same as what most people do for spit and polish, but I'd say Unity has the functionality especially now for people who "can't 3D model too great". I'm pretty sure Unreal can function similar too, maybe with a slightly steeper curve but some neat efficiencies. I think that reality is aaaalmost here though.

>The one thing that really is rough for me with _both_ UE and Unity is that they're both very oriented towards teams with dedicated art people who can put out assets to use. BSP-based workflows where you can quickly greybox out levels to playtest (basically giving level designers without art sense a fighting chance) are much nicer with older engines.

That's because the value proposition with most games is in their art direction and gameplay - nobody cares how you get the polygon on the screen. I wrote my own game engine for a bit but then realized that all the work once the scaffolding was complete was in creating a fun game. Turns out that I don't really enjoy level editing and 3D modeling as much, so I stopped developing the project.

The "not shipping" criticism is too harsh I think - most game projects fail to ship after all, and having worked on some non-shipped games plus having worked on standard setting components shipped in zillions of games is a respectable career.

So which engine is this guy working on? I checked his twitter and his website but there is no mention about the actual engine (only that he is working on one).

He's not currently working on an engine per se (at least not publicly), but he's has a streaming channel where he teaches the fundaments needed for understanding and potentially being able to build one.

So he is all bark no bite. Got it.

Where did the guy even bark? He publicly praised Unreal Engine 5.

Also, why does he have to be working on an engine? He has worked on some others and is one of the few with enough credentials to criticize. In this case he’s not even criticizing, just asking questions which are not really trivial to answer.

I don’t understand the point about the difficulty of grayboxing with Unity. Can you elaborate? All my projects start with programmer art — often just the built-in primitive (cubes, spheres, cylinders, planes).

https://joewintergreendev.tumblr.com/post/152188146576/repos... Here are a set of videos that compare UE4 to Valve's stuff. Just like making it easy to drop a bunch of stuff in and texture things nicely.

Have you seen probuilder for unity? Here's a old video: https://youtu.be/a8JOk8nuK0k

Unity basically bought this third party tool and is now a free package.

Who is "Casey" ?

Casey Muratori, the guy who praised UE5 and criticised Unity in the quote in the article.

Reply on news.ycombinator.com