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.
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 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.
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.
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.
>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.
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?
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.
>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...".
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.
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
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.
> 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.
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.
> 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.
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.
> 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.
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 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.
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.
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.
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.
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.
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...
> 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.
> That's extremely reductionist. He's saying that modern software is crap regarding performance. And whenever he does complain, he manages to demonstrate it.
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.
> 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.
> 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.
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.
> 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).
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.
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.
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).
>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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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).
As a software developer I've worked with Unity and Unreal in a professional capacity for many years, and shipped quite a few games on both engines. Unreal is powerful, but really shows its game development studio and FPS game roots. Unity has limitations, I won't deny that. And both engines have their own issues and different frustrations in using and deploying them. I have also shipped games on internal, custom built engines too. From a business perspective, hiring Unity developers, i.e. people who can code in C#, is a lot easier. Unreal developers are plentiful, but their knowledge of the guts of Unreal usually stops at the surface level, barely dipping below Blueprints, at least from my experience.
Personally, I prefer Unity over Unreal, but am not averse to using either, in the right context.
The power of unity is that you don't have to delve deeper, just start it up, make a script and start writing code. The weakness then is that all the components you code against are horribly bad/slow, so for a bigger game this approach wont scale, but if you are a programmer and just want to code a simple game unity can get you there in a weekend. First project I made in unity was a top down shooter with simple random map and powerups, took a weekend, I've tried using unreal but it is way harder to interface between code and assets and ui there.
Edit: My point here is that in unity you can easily write your own replacements since it is so easy to write new components in C#. This means you don't have to learn how unity did things, just write your own if you don't like what they did. The only exceptions here are physics and the renderer, you can't easily replace those.
> The only exceptions here are physics and the renderer, you can't easily replace those.
While physics is in the engine itself you can definitely replace or modify the render pipeline. Unity comes with a built-in legacy pipeline but nowadays you mainly use either the High Definition Render Pipeline (HDRP) or Unified Render Pipeline (URP) both of which are open source packages. Meaning they are modifiable. They are also both based on a common base class: Scriptable Render Pipeline, which you can extend to make your own render pipeline from scratch.
Source code access in Unity is available but very expensive, even for large studios.
Coming from a background of working with engines where the source is available it has been frustrating to me being unable to dig into or modify the engine. Especially when I'm at the mercy of some obscure engine bug. But most of the time I've managed to make do.
This advice is a bit generic - but look at either the official examples or tons of github projects that have C++ in them and try to understand how they work - that's the thing that worked for me.
First of all, you have to manage your expectations and be mentally prepared for the fact that you will just not get most of the engine. UE is a massive project (and that is an understatement) and you will be a VERY good student if you just grasp the gameplay framework (core functionality in c++) and a few specific things (if you understand rendering, you may fiddle with the renderer, if you're an audio engineer, mess with meta sounds etc.). If you just look at the amount of code being pushed into the UE repo, you will soon realize that no single person will ever be able to grasp and contextualize even 10% of the engine. It's just not happening. With that out of the way, what I found incredibly helpful was the Ue4/5 cpp game courses on Udemy from Stephen Ulibarri.
One of the most infuriating things about Unity is they tend to deprecate/stop maintaining working things even though the replacement is still in preview and/or not ready. It puts you in this awkward situation of, ok, do I develop against this stable thing only to have to replace it in 6 months, or do I do Unity's beta testing for them and waste a ton of my time dealing with their bugs?
The other thing I really dislike is that quality of life improvements in the editor are necessarily bundled with engine updates. With IDEs, usually I can use a newer IDE with an older version of the compiler in something like C++ or Java. But with Unity, if I want the editor enhancements I have to upgrade /everything/, and it's almost assuredly not backwards compatible, a bunch of things are going to break, and half my plugins are going to struggle. It seems like the only realistic way to use Unity is grab a LTS version, and then never-ever touch it until the project is done.
Also, while I'm generally a fan of C#, I think it was somewhat of a poor choice for games. When I was working in Unity professionally a few years ago I remember we would write code in such a way to avoid creating any garbage for the GC. But that meant that most of the nice features of C# were verboten -- no LINQ, only using certain types of loops, etc etc. Maybe the situation has improved, but it seems like there were better language choices.
> One of the most infuriating things about Unity is they tend to deprecate/stop maintaining working things even though the replacement is still in preview and/or not ready.
A.k.a. life as a software engineer at Google.
I've found that this is just such a common experience, not just with Unity, but everywhere. I think the real problem with Unity is that it's hard to get good guidance about whether to choose the new/experimental path or the old/deprecated path. There are random packages (ProGrids? New input system?) that are marked experimental but ready for production use except the documentation is not as good as it should be. Then there's stuff like DOTS, which is much harder to use in production.
> Also, while I'm generally a fan of C#, I think it was somewhat of a poor choice for games.
This is more of an implementation quality issue than a language design problem. Unity was stuck on an old version of Mono for a long time, for a licensing reason or something like that. I'm aware that newer C# versions have much better GC performance, but it's not something I have personal experience with.
> Also, while I'm generally a fan of C#, I think it was somewhat of a poor choice for games.
What do you think would be better? C++ is too verbose and full of footguns, and python and javascript are dynamically typed (which is imo bad for learning, because the error messages happen at runtime instead of compile time). I'm a big fan of rust, but even using the Bevy game engine has occasionally reminded me that I appreciate just letting the garbage collector worry about memory management.
(The issues with the garbage collector have mostly been resolved at this point, now that they've implemented incremental GC.)
The Unity Editor is moving towards being the container for extensible packages. There is source code provided for rendering pipelines, input handling, UI, and code compiling. This is a lot better than the Unity 4 days where everything would be bundled into the monolith.
Then you can call GC.Collect() to garbage collect e.g. between levels.
LINQ is totally fine as long as you don't do it in e.g. Update() which is called every frame. There are lots of other things you start to learn over time such as .transform internally calls GetComponent<Transform>() which in itself isn't a problem but calling it in an Update() on e.g. VR where you have 72-144 frames per second might not be wise especially if you have 10x Update() methods doing this. That's why Unity has had the Profiler for many years - to pinpoint what is causing garbage to pile up and what methods are killing performance.
In this critique of unity they say that the back half of making a game is the half of suffering. In my experience, it highlights something else that is a massive problem in the game dev space. The game dev community is stuck in software practices of 2005, leading to naive implementation patterns.
As a hobbyist game developer of ~1year, one thing that struck me was how I have not found many good sources of teaching that explains how to make a maintainable game. How does one make a code base for a video game that has desirable the non-functional qualities like maintainability? That question doesn't really have an answer...
I think it doesn't have an answer because those teaching game development haven't really asked. I'm sure it's due to many factors.
For anecdotal, I've asked about testing and CI/CD for unity in online spaces. There isn't much content on these critical subjects in the video game education space. I usually get a mix of responses but one that stuck out to me is that video games aren't appropriate for tests and it just slows down game creation.
I think that thought process more than anything is what leads to back half issues. I think that the video game industry has lagged behind the rest of the software industry and there is a huge opportunity for disruption.
In 5-10 years people should think it's absolutely outlandish to start a complex software project such as a video game project without a CI/CD engine running a suite of sensible tests. I think today that is true for most software projects, although as a community were still wrapping our heads around "what is a good test?"
As a game developer, there are two main reasons we don’t write tests:
A. because the game design is constantly changing, so any tests would slow down iteration time.
B. because the game has so much state it would be very hard to accurately recreate it.
You can do a ton of productive testing just by clearly separating different systems, especially game logic from rendering etc. This is just good code hygiene. Better game-specific tools can also be created, as companies like Larian are doing.
It's not really very different from testing other big complex software. Everybody has evolving requirements. But the general culture of game development is to ignore automated testing entirely, which is awful.
This also runs into an issue of scale. AAA games for live service games certainly do have automated testing for some core features like networking or certain simulations. But that kind of testing for an indie title would be overkill unless you're making a game like Factorio (a near deterministic game heavily relying on simulation). It's really hard to unit test "fun" after all.
There isn't as much benefit for a small platformer to test their jump height or physical interaction with the environment, and then change all tests whenever they decide that they need to adjust that height. On the contrary, some beloved glitches/exploits have come from allowing those weird interactions to exist.
If you haven't seen them yet, Factorio has a few Friday Facts that talk about (and show!) their automated tests. It's quite impressive! One advantage they have in this area is that the game is a fully deterministic simulation, so testing is just a matter of setting up initial state and validating output
I have thought about why it is much harder to follow the general best practice of Unity Tests + Automated Tests we find in web development and I think it is because the amount of "state" a video game has.
In the web we have our cursor and it clicks on an element. In video game design the character can widely vary when it interacts with an element such as a "door".
The classic "why doors are hard" might explain why having a "regression suite for happy paths" might be near-impossible.
Though that the core reason for using the Entity, Component, Systems (ECS) in their coming Data Oriented Technology Stack (DOTS) it does help create far more maintainable code.
I feel the same trying do develop an enterprise application with Unity. When I worked for Unity I found it fascinating that game devs (not coming from game development) were “locked into” a particular version. I hope the package system can alleviate some of that but there is a real need for some automation and upgradability.
Game companies don't care about "correctness" (aka bugfree games). Bethesda releases buggy garbage all the time and it didn't stop them from being successful.
A fair amount of software is about either filling in forms to populate a database or rendering views of a database. In that context, tests and maintainability matters because you're generally implementing business processes.
Traditional games are more like art, or rather more like novels than textbooks, where you write it once and put it out there.
That's of course changing with live service games so I suspect testing and maintainability will become increasingly written about.
Having worked in Unity as a hobbyist for about a decade and considering the switch to Unreal due to obvious issues Unity is currently facing (3 rendering pipelines being the main one), I'd like to hear more input from the programmer experience in both engines.
I think C# in Unity hits a really nice sweet spot: You have a powerful and expressive type system, can use nice high level features like async/await, you get (relatively) quick compile times which help your iteration speed, and decent runtime performance due to IL2CPP.
On the other hand, looking at Unreal, the main options seem to either be C++, in which case you sacrifice a lot of iteration time due to compiles, or Blueprints, which I really have no interest in (I like node editors for shaders, but i'd rather code all game logic). Those are both unappealing to me so I'm a bit stuck.
Here are some of my experiences regarding swapping to unreal:
- the c++ gameplay framework is very friendly. It’s GC, with good high level wrappers that provide stuff like options, maps, classes (ie. Reflection).
- The unreal discord c++ channel is full of people who will actually answer your questions, it’s brilliant.
- Every high level blueprint function is a c++ function. I cannot express how powerful it is to be able to step into the source of like “MoveToPoint” or “Whatever” and see exactly how it was implemented in c++.
- You should use blueprints. It’s like python glue for machine learning; write in c++, but when you need to twiddle an animation curve, or lay out a state machine, it’s pretty good. If you’re working with an art team, they can actually make gameplay changes. It’s very productive.
- Plug-ins are a first party construct; you should use plugins to build reusable content. They’re not quite as good as the unity package manager, but it’s rock solid foundational stuff.
- The compile times are not often an issue; I use the incremental unity builds (it’s a source file aggregation thing, why they called it unity I have no idea) and it takes like what 15 seconds to build a plug-in? Launching the editor is slow 30 seconds?) though.
It’s not all good; it has bugs. Sometimes the editor just goes into crazy mode and needs a restart. When you mess up, it crashes with a segfault.
C++ is just less productive; but I’m using the unreal for rider EAP and it’s pretty good.
So… I miss c#; but overall I would rate my experience as pretty good, and since my experience with DOTS in unity has been, shall we say, 100% negative…
Just want to +1 that Rider for Unreal [1] is GREAT. It's also totally useable for non-Unreal C++ projects. Things like code inspection (e.g. goto definition/find usage/etc) and refactoring are actually fast, unlike Visual Studio. I've got a few quibbles about low-level (think asm) debugging, but I've pretty much moved exclusively to Rider at this point.
The Unreal-specific stuff is nice as well: being able to see what blueprints override a uproperty or implement an event is a huge time saver for AAA-scale codebases.
By unity build I think they mean all cpp files within a module are compiled included into one (so each cpp isn't a separate execution unit, anonymous namespace etc. will bleed over between files unless they are in separate unreal module or plugin).
Similar to SQLite amalgamation.
Turning it off could parralelize the build more, except linkers are often singlethreaded and bottleneck things enough to undo that benefit sometimes.
You really don't want to turn off unity builds in unreal for anything larger than a toy project. The build system is "smart" (albeit itself is slower than say ninja). It breaks the project up into multiple unity "blobs" for you, and they're compiled in parallel. It also integrates with source control to remove files from the "working set" so if you're iterating on a small file it will be removed from the unity blob and compiled on its own for faster iteration.
Running a unity build [1] means the compiler only has to parse and reason about the headers once. So you lose the parallelism of multiple TUs, but you gain on not doing the header crunching over and over again. Whether your codebase will benefit from that is a matter for testing, but many do.
also by using unity build you don't need to link object files. I think that is main reason to use unity build, it eliminates need for any build system and compiling source code in a new machine is as simple as compiling a single transition unit.
C# remains a plus for a lot of game code, but not as much as you might imagine. C++ usage in Unreal is really a small restricted subset of C++. For typical gameplay code, you play within their rules for uclasses/ustructs/etc and it feels pretty much like any other managed GC language. Meanwhile, for places where it matters, "raw" C++ is of course always available.
Re: iteration time, Live++ [1] integration has matured a lot in UE5. That means compiling most code changes without having to restart the editor (or even in-editor game session). Again, not much different than Unity here, though both can break and require editor restarts for certain types of changes.
To double-down on OP, by far the biggest advantage Unreal has for professional development (aka anything you want to ship) is full source code. I've worked in both but can't imagine going back to a black-box engine. Unity/Unreal are both MASSIVE codebases ported across every modern platform imaginable and guess what: there a plenty of bugs in both. I can't imagine going back to an engine where I can't A) see what it is doing and B) fix issues without waiting weeks/months for a patch.
> Re: iteration time, Live++ [1] integration has matured a lot in UE5. That means compiling most code changes without having to restart the editor (or even in-editor game session). Again, not much different than Unity here, though both can break and require editor restarts for certain types of changes.
A week of doing things in unreal engine 5 C++ has resulted in more editor restarts than years of doing things in unity. They are not really comparable. And this is from someone who have written a a few hundred thousand lines of C++ at Google and no professional experience with C#, getting to a productive state in unreal engine C++ as a solo developer is a huge slog compared to unity.
If you do most things in blueprints then unreal might be fine, but for an experienced programmers blueprints feels extremely slow and clunky to work with. I want to write code.
Launching the editor from visual studio makes the code and compile workflow quicker. On our project we take map ids from the command line. Thus I can set my visual studio to open a specific map when I hit run. Compined with a powerful cpu and optimized include what you use header usage the iteration time is compatible to a large unity project.
Unreal has a ton of hidden magic most people only learn from other people. Which is fine if you are working at a studio with other more experienced devs. Not great if like me you started as a hobbiest.
As someone who generally hates visual programming and just wants a text editor, I'd say blueprints is actually one of the most enjoyable of these. They really nailed the editor and you can have a lot of fun just playing around.
Also the c++ unreal shouldn't be compared to pure C++. You're working with the unreal framework which adds a lot of quality of life features. I've been working with it for the last month or so and while it's not as easy an experience as c# it's probably the cleanest c++ experience I've had so far.
blueprints are pretty great and lower the barrier of entry for people (especially for like game jam stuff), but I do wish they would have a "here you can just write some Lua" block sometimes... kinda hard to do structured programming the times you kinda want it.
But the discoverability stuff along with loads of nice error checking are very nice.
This is what i was wondering that wasn't explained in the article... does UE offer some guardrails for working with c++ that make the jump from C# an easier decision?
short answer: yes. If you stay within their uclass/uproperty framework, you have garbage collection, guaranteed initialization of class members, type reflection, etc.
Rare issues come up like:
```
int* Element = &Array[0];
Array.Add(0);
*Element = 3; // could be access violation or memory-stomp if array was resized
```
Which can be addressed somewhat by code style policies.
Their garbage collector is also slightly weird in that it most things are deleted when there are no more references to it (as expected) but Actors can be deleted explicitly, in which case all references to them are set to null. This makes a lot of sense for a game engine actually, just perhaps unexpected from a language like C#.
so interesting, as a mostly C++ dev, UE's C++ style feels absolutely awful aha. Of course it mostly has to be like this because c++ used to not have reflection at all but I think that nowadays one could use similar principles as the ones I've tried to develop for audio / media objects in https://github.com/celtera/avendish to implement game objects / UObject in a much cleaner way and with better compile times.
Add a couple custom attributes implemented as a clang plug-in like e.g.
[[ue::name("Player HP")]]
int hp{};
which can be done in a couple afternoons by an intern and things would look sooo muuuch better.
Having used Unreal for years in the past (UE4 only), I agree with you that C# would definitely win over the C++/Blueprint combo.
Over the years, especially since blueprints compile down to C++, I've learnt to let go and embrace a lot more this visual programming approach. And it does have its benefits. With a strict approach, just as you would in programming paradigm, the readability and 'visual scanning' of opening old code in blueprints really stands out. You instantly feel where everything is, much faster than scrolling up and down code, navigating to/from methods.
I've had experimented with Unity but I found at the time that UE4 was the way for me. At the time I was even working with some guys promoting UnrealJS or something, can't remember the name now, which was bringing JS to Unreal, but it sort of faded as it takes a monumental effort to bring another language to such platform. Ultimately, blueprints are fine, and I'm only using C++ for A* path finding or other heavy algo where math functions are the main focus. You can also make a library of C++ heavy math'ish things and expose them to blueprint. Overall It's pretty ok.
One aspect that is not talked about much is the weight of it all. UE4 was huge. Recompiling the engine was a 3-4 hours business. When I switched to Godot for lighter games, the whole thing was rebuilt in 5-10 mins.
Python is not that bad to compile. For me, less than 1 minute for a full compile of Python. A full compile of Binutils + GCC + Newlib is much worse, but it's still well under 10 minutes. I'm not even using a particularly fast system.
Unreal is more comparable to projects like LLVM or Chrome.
Why does every game engine seem to write their own language? Why not choose an existing one - in this case C# seems like an obvious choice because it's already used in another major game engine and seems to be well liked.
First of all, you need to understand that all current (serious) game engines primarily use C++, in order to provide maximum performance at the low-level. But C++ is incredibly unproductive as a language for actual high-level game development, since C++ takes ages to compile and has more weird and dangerous footguns than any other language. So developers often end up binding a scripting language onto their C++ core, so they can have fast development cycles and move fast. So even C# in Unity is just a scripting language binded onto the core C++ engine. The problem is that C# isn't a language intended for embedding, and you need a lot of effort to bind the two seamlessly.
When Unity started making their engine in the 2000s they had engineering troubles with integrating the Mono C# runtime into their engine, and eventually they needed to obtain a custom license from Morell to fork and modify to their liking (at the time Mono was the only C# runtime that supported other platforms like Mac OS and mobile, and it was dual licensed as LGPL/commercial). There were also myriad problems with this choice, including being stuck with an outdated version of the Mono runtime which they needed to relicense (at a hefty price) to upgrade, myriad issues with the very slow Boehm garbage collector, etc etc. Eventually Microsoft would buy Xamarin (the successor of Morell) and relicense Mono to the MIT license, which was a lifesaver for Unity since they could now update to the latest Mono runtime at no cost. Still they're kinda stuck with their initial decision of using the Mono runtime, and it seems ever unlikely that they're going to migrate to dotnet (which I've never heard any success of embedding with C++). So in conclusion, it took a lot of time for C# in Unity to be useable to the degree we're at now, and it's more of a special edge case of gamedev history than anything else. Most game engines use a much more easily embeddable scripting language such as Lua for good reason (or end up creating their own language!)
About the topic of why does every game engine seem to go the route of creating their own scripting language, I find the explanation of the Godot Engine devs very well written: https://docs.godotengine.org/en/3.0/about/faq.html#gdscript-... (Godot Engine tried integrating many other languages before deciding to write their own scripting language called GodotScript.)
It's honestly just a few lines of C code that you point at some c#/java method and run it. The truth is probably that people want to invent their own languages for their own reasons, e.g to have full control. Personally I've never understood that which is why I know so much about language interop now. Embedding is even easier for various scripting languages. I've also done interop for Dart. I don't like Lua but I've also looked at how easy it is for that. Imo there is no justification for game engines not having a C API so that everyone can code in whatever language they prefer.
Well that's something I've never heard of, seems like a pretty recent API. Though it doesn't explain how to call C++ functions from CLR (not the other way), which is the most tedious and error-prone part. It also doesn't explain how to expose foreign C++ objects to CLR either.
Unity is currently working to make Unity compatible with .NET 6 / CoreCLR, but they don't yet have a release date for that yet. The progress is being tracked in this megathread:
I agree, it seems like a huge effort. But if they reach their ultimate goal of shipping an unmodified version of .NET, it seems like that work would pay off:
Burst is such an interesting project. The fact that, because they know what they are trying to do more than a c++ compiler really can due to the intended use cases, they can be more aggressive with optimizations like SIMD. I remember a talk where they were discussing replacing c++ code with the Burst stuff as you mentioned, and I recall the biggest reason being they could write more succinct code that kept the speed because they weren't having to convince the compiler to do a lot of optimizations they needed to keep it fast.
Agree. I was so happy when I heard they were introducing an intermediate language and so disappointed when I found out it was custom.
I'm back to being quietly hopeful though:
- Epic ships games and has internal game developers. They're probably not going to create something too dynamic or untyped that has issues scaling.
- I was worried about coverage but then realised all of BP is generated from code annotations using the unreal header tool, and they've already done it for Python (I think? maybe just editor functions).
If it's just a textual replacement of blueprint that will be enough to make me so much more productive for gameplay programming.
Might be more likely it'll be used for player-generated-content and their metaverse push ala roblox though.
Verse isn't entirely a new language, it's actually them acquiring the team behind SkookumScript, as well as some external hires such as Haskell/Microsoft Research's SPJ.
Excited to give it a try when it releases, will be interesting. The syntax previewed was... different.
Thing is, it's not just having an approacheable/hireable language, its about the availability of tutorials, learning materials, community, and existing code. That takes a lot of time and its Unity's moat that Epic can't really replicate by creating yet another Unrealscript
You absolutely cannot use UE without ending up with C++, blueprint only shines with animation rigging, material, vfx where you need a lot of quick feedback loop by exploring possibilities.
What's the standard compile time for a short iteration in Unity's C#?
I use C++ in UE4 as much as possible and even the iterative compile time with LiveLink breaks my iteration flow. BP is great for iteration but I keep as much in C++ as possible and this has made things much easier to maintain. At the moment I'm trying to prototype in BP then move completed stuff to C++.
A magical property of Unreal is it's open-source-ish nature. Industry leading people constantly contributing features at high quality that become integrated into the engine. I contrast, for Unity, you have to shop around in the Asset Store for that does the thing.
An example for it is procedural shattering - some guy needed it in their game and now it's standard in Unreal. For Unity, you have to buy it from the store, and I guarantee it, it won't be even nearly as good.
I think the Asset Store is a poisoned apple for Unity - for developers it makes very little financial sense, since you are looking at what, 1000s of sales for $50, of which Unity makes some significant commission? That's why people put a ton of half-baked stuff in there, which they abandon, and due to the constant shift of Unity, becomes unusable in like 3 releases.
They also can't integrate their stuff at the same quality in the engine as if they had source access.
Additionally this creates another headache for Unity as well - now if they wanted to 'properly' support this feature, they'd be competing with people who wrote the asset store version - sending the signal to them, that if you do really well, your feature will be stolen by your masters.
What does also happen is Unity buys a particularly high-quality plugin (TextMesh Pro, ProBuilder) and they just give it away and don't bother to integrate it, which means it will stick out like a sore thumb.
I've worked as professional Unity developer for 8 years after learning it as a hobbyist for 3, and I'm happy to finally be rid of it. It's good for prototypes and beginners, sure. But when you start to build big projects, you learn that al those learning resources guide you towards using awful architectural practices, and that there's a million of edge cases and weird bugs that would absolutely kill your project but will stay unfixed for years.
Also, since ~2015, Unity as a company have been more and more interested in developing shiny prototypes of new features that would look great in presentations, but it would take forever to finally get them to be production ready, and they would be rid with problems even then. It's as if Unity cared more about increasing numbers of newcomers than retain old-timers and studios which already invested heavily into the engine.
But I have to be honest, if you're doing mobile 2d game development, want to ship a product on both operating systems and don't want to invest in building your own game engine, it is still the best option. There are other solutions, but none have such an incredible amount of tools and assets.
“…since ~2015, Unity as a company have been more and more interested in developing shiny prototypes of new features that would look great in presentations, but it would take forever to finally get them to be production ready, and they would be rid with problems even then. It's as if Unity cared more about increasing numbers of newcomers than retain old-timers and studios which already invested heavily into the engine.”
this sounds like the way every other company operates. maximize profits above all else naturally resulting in the degradation of the product
> this sounds like the way every other company operates. maximize profits above all else naturally resulting in the degradation of the product
Absolutely, that's the result of switching from a co-founder CEO that followed a humble philosophy to a mass market game industry CEO with own controversies.
It's not profit above all else. It's short-term profit above long-term profit, because management doesn't plan on staying that long, or just isn't capable of building a long-term thinking culture.
"UE5 is very pretty because Sweeny is a rendering god. But its hell to do any real programming with. A project that took me two weeks or so in C# is taking months to reproduce in C++ and Blueprints.
UE5 is a very pretty FPS engine with a low-level plugin interface and a scripting language. The further you get from an FPS the more unwieldly it becomes.
Unity is a programmable physics simulator that happens to have a render pipeline bolted onto it. It is much more flexible, though sadly not as pretty,"
Am also asking myself. Did the company behind Unity going public last year or so not help with the situation? I mean extra money and public scrutiny usually do.
I'm not really sure where this came from, but it's pretty much nonsense.
Tim Sweeney hasn't written rendering code (or engine code) in years, the Unreal rendering team is enormous these days.
> But its hell to do any real programming with. A project that took me two weeks or so in C# is taking months to reproduce in C++ and Blueprints.
How much of that is familiarity with C# vs unfamiliarity with C++? I find it pretty unbelieveable that someone couldn't reproduce 2 weeks of work in "months".
> UE5 is a very pretty FPS engine with a low-level plugin interface and a scripting language.
Unreal has its roots in an FPS, and that shines through in places, but this hasn't been true for over a decade. The gameplay framework in UE4 is suitable for (and has shipped) many different genres of games. Looking at even wikipedia's list [0] will show you a laundry list of games that are not FPS games that have shipped with Unreal. There are major ARPG, beatemup, open-world shooter, racing, straight up RPG games, and there have been other games announced that don't fit in those categories (e.g. RTS games).
> Unity is a programmable physics simulator that happens to have a render pipeline bolted onto it. It is much more flexible, though sadly not as pretty,"
This is a ludicrous take on Unity. How is it "more flexible" than Unreal? And the claim that it's "not as pretty" is also bizarre (well, up until very recently at least), Unity's pipeline is just as programmable as Unreal's, and sure at the very very very top end of the range of outputs it tops out Unreal, but an "average" PBR pipeline in Unity and an "average" PBR pipeline in Unreal with zbrush sculpts and substance textures/materials is going to be comparable.
My last kismet project looked like an ER diagram for a government database. Kismet had decent grouping objects to where you could organize your Kismet, but even my largest and most complex kismets could have been replaced by about 100 lines of unreal script. It's just not as expressive as code. I miss unreal script.
I used Kismet for years and fought with its limitations on a daily basis. By far the biggest limitation of Kismet was that every graph was tied to a level. If you wanted to do any general purpose programming, such as mechanics shared across every level, you had to duplicate your graph for every single one of them. It was a very tedious and error-prone process.
Blueprint is leaps and bounds ahead of Kismet. It's built for general purpose programming out of the box. You can write your own classes, components, enums, and more. You can expose parameters to the Details panel so that designers and artists can easily tweak classes on a per-instance level. You can still write a graph tied to a level a la Kismet — this is called a Level Blueprint — but I find it's rarely necessary, if at all.
I remember trying UnrealScript because of Kismet's limitations. It was certainly more powerful and expressive, but shutting down the editor every time I wanted to compile was a real drag. These days I've gotten used to the fact that Blueprints are compiled on the fly by clicking a button in the editor, with no interruption to iteration. I can't imagine going back.
Unity is a black-box machinery with a C# interface bolted on. But as soon as you touch the limits of the black box, your sand castle breaks.
UE4 is the full but raw deal. If you stay within Blueprints, things are easy and predictable. But if you need to exceed its limits, then you have the C++ needed to recompile everything, but things are messy and ugly down in the basement.
As for Unity going public, my impression is that now they are spending much more resources on shiny things to show off instead of fixing bugs that actually affect their paid customers - who mostly do mobile games. Also, it appears that they improved their profitability by massively increasing prices and simultaneously reducing support.
Unity is primarily the renderer and physics engine, everything else is really easy to just write yourself as c#, and unity in no way hinders your ability to write everything else in c#. If you want to change the renderer or physics engine then you have a problem, yes, but unity isn't for people who wants to customize the renderer or physics engine.
Seriously, how can the most used game engine not add proper multiplayer support in 20 years. They announced Netcode for game objects this year which seems OK but even that has "Clientside prediction" in "under consideration" category, any proper realtime multiplayer game on the market has this feature and rollback netcode isn't even under consideration. So if they achieve their goals, they will have a system that is good for at most indie games after 20 years.
AFAIK, Netcode for game objects is merely a rebranded version of a previously existing third party plugin called MLAPI that Unity acquired and hired its developer.
It is very close to what they already had before and was probably mostly to reduce the amount of complaints from, well everybody, regarding their non existent multiplayer, the deprecation of their previous multiplayer solution (however bad) before having any sort of replacement and the semi recent addition of the low-level networking solution that is mostly way too complicated and poorly documented for most average Unity developers.
> "UE5 is very pretty because Sweeny is a rendering god. But its hell to do any real programming with. A project that took me two weeks or so in C# is taking months to reproduce in C++ and Blueprints.
Sweeney is the CEO of a company with over 1000 employees. I highly doubt he has had much (if any) time to write any rendering code for a long time now.
Mostly spot on, as someone else said: "Sweeney hasn't written any of that rendering code in a decade now." And probably more than that. He's got other stuff to attend to, than writing modern 3D pipeline code.
Unreal licensing is crazy compared to Unity. A % of revenue is millions of dollars potentially. You cant compare that to the fixed opex per developer seat with unity.
It’s a strategic design for a company to use one or the other. So far in all companies I’ve worked for and have consulted for attribute their choice to cost and ease of hiring.
Big publishers/game developers just negotiate a custom contract. But yes in general UE is more expensive then Unity but it also comes with a bunch of useful stuff like quixel mega scans for free if you are using the engine.
Not even big; I am aware of indie studios having unity source. It's not nearly as expensive as you might expect, but I'm not able to give hard numbers. :)
To underscore the sibling comment: at the point where a "% of revenue is millions of dollars" the company can easily afford to invest in an in-house solution if it's that important for their revenue goals. The tradeoff is hiring a sufficient number of skilled game engine programmers to make that work. It's not cheap.
They don't even need to do that. If they are large enough where it would become millions there is a different license for them that they can negotiate with Epic.
Just guesswork here, but I think they have an agreement that is cheaper and also includes CDPR engine developers contributing code back to UE that makes it better to use for open-world games.
In the UE5 Keynote it seemed more like a technical partnership than just CDPR licensing UE5 for a price.
Also it is not just making a game engine but you also have to build some kind of a editor, script/animation tooling, plug-in support, etc.
Basically if you are big enough that you can make your own engine the engine also has to be usable by non programmers making the actual content for your game.
Tools can be nearly as important as the engine. I've read several postmortems where the lack of good tools made the asset creation and testing pipeline take way longer than necessary, leading to delays and crunch to compensate.
Tiger Engine that Bungie uses in Destiny supposedly took hours to rebuild a level and didn’t do incremental builds or cache so fixing that one bad light on the map was potentially days of wait.
Still better than earlier versions of Frostbite Engine from EA Dice that took week if no cache was present and ran on server farm that took raw assets together with metadata and spit out final game assets.
>>U nreal licensing is crazy compared to Unity. A % of revenue is millions of dollars potentially
Sure but how many studios reach that level? And wouldn’t you agree that by then, having to pay that share of revenue would be, as the saying goes, “a great problem to have”?
IMO it makes more sense to focus on developer productivity because that drastically increases your chance of reaching those revenue numbers.
It's actually much better for indie developers because it's completely free to build and ship something and see if market wants to before worrying about subscription costs etc like in Unity.
For Unreal from thier website - "A 5% royalty is due only if you are distributing an off-the-shelf product that incorporates Unreal Engine code (such as a game) and the lifetime gross revenue from that product exceeds $1 million USD; in this case, the first $1 million remains royalty-exempt." - much better than Unity's pricing. The > 100k annual only give you Unity Personal whereas you can full powered Unreal at much greater threshold.
So it looks like there is a break-even point in revenue per developer above which Unreal is more expensive. The question is how often studios hit that.
I've worked with Unreal and Unity both, professionally and for many years. Several triple A games, indie titles, commercial sims, and social experiences. What sets unity apart by leaps and bounds is its asset store, community and educational materials.
Git handles binary files just fine without LFS. The point of LFS is to reduce the size of repository clones, by not cloning the full history of large files.
They both have different irritations, but for most things I would still recommend unity.
Much of the long-project pain with Unity comes from its biggest limitation, in comparison to Unreal: no source, and so you're stuck with Unity's default behavior, limitations and bugs, unless you plan on extending it, wrapping it or replacing it. Whereas Unreal making source available doesn't lend itself to safe boundaries and compartmentalization.
Weirdly, Unity's irritation is also something of a strength, because those wrappers and replacements tend to find themselves on the asset store, often for peanuts. Often with source.
There's serious differences at the extremes, of course. But unless you're working with eight, ten, or more figures of budget I don't think it will matter that Unreal has superior tech in numerous ways, because you won't have the teams of artists to make use of it.
I'm late to the game but I'll throw in the opinion of a hobbyist doing VR development.
I gave Unreal 4 a solid shot: did the tutorials, watched videos, learned simple concepts and advanced concepts alike. After months of learning one weekend I thought "I'm not having fun anymore" because 70% of my time was troubleshooting build errors and vague bugs (I actually counted). I'm no stranger to build errors (I'm an engineer) and even for me it was a difficult task to fix them. I would go down rabbit holes for hours fixing vague errors. Further, just about every tutorial I came across for UE4 was outdated and didn't work.
I swapped to UE5 a few months before they released their first public version. It was an absolute beaut of a system to use in comparison: better UI, drastically fewer bugs, tutorials were accurate, and no build errors. Quite a bit Just Worked, A+.
Ultimately I went to Unity because at least for VR, there were better tools that were better supported by the package maintainers. Adding a new third party Thing to a project in UE5 was a guaranteed recipe for troubleshooting weird bugs. In Unity, everything worked flawlessly. And personally, I dig C# more than C++.
So, I did the same learning process with Unity: simple/advanced tutorials, plenty of time dedicated to picking up all the concepts over several months. I'd say Unity for a hobbyist is still the better route if you are planning on doing game dev part-time. It's just easier to use and breaks less.
This is the opinion of a hobbyist doing VR development part-time though, and I fully believe other comments from industry pros saying Unreal is the way to go. I can't comment on that but I will say Unity was best for me.
Both asset stores were pretty killer and I spent WAY too much money on assets and scripts. Prepare to have a checkbook handy if you get started with either ;)
As a hobbyist I found Unreal to be far better than Unity. The technical debt that Unity has continued to accrue starts impacting you even as a casual user. It's a bit of a mess to be honest.
Unreal on the other hand has a very solid architecture and goes out of its way to be reliable and maintainable. Plus you have the full source available in your project to search through if you want to dig into the code. The code is generally well written enough that you can use the source code over documentation if you prefer. Blueprints are also great if you are prototyping things.
Also if you are interested in doing networked multiplayer, there is no comparison. Unreal's networking is fantastic, while Unity doesn't really have networking built in.
I can't take any hobbyist game engine that doesn't implement multiplayer out of the box seriously. It's so stupid. QuakeWorld had it in 1999, and because game devs are too afraid of networking, you get a bunch of people saying "Oh, it's too hard," or "Yeah, but your networking model is dependent on what game you're shipping."
No you dunces, you will always need to serialize something. You will always need some semblance of tickrate, or at least you will always need game events. The more simple features game engine developers don't write increase the risk for users who will inevitably not implement them themselves.
Unreal engine has native support for networking. You add some configuration to your objects to determine how they should be replicated over the net and flip a switch in the settings, and now you have a multiplayer game.
Beyond game engines one of the things that drives me crazy about commercial software is when I find a bug, document it thoroughly, and submit it to the company only to be ignored. Even with a support contract and on rather severe bugs it can be way too hard to get something fixed. I know I'm not the only person being bitten by this bug, it's all over the help forums and Reddit yet the company doesn't seem to care at all.
This is frustrating. I’ve been on both sides of it, what’s happening is that the team is likely juggling thousands of bugs in similar or greater severity, as well as their roadmap for new features. Some things just get deprioritzed over and over, even though everyone knows it sucks. It usually takes a rogue engineer in their extra time, or a dedicated “user love” budget (which I always implement on my teams) to fix it
I completely get all of that; it's just frustrating when you know exactly what the bug is, and can almost see the code causing it as well as the fix in front of you (conceptually), but ... you can't actually fix it.
For example I once spent weeks working around a memory leak in a piece of very expensive commercial software; it was not a fun experience and extremely hacky, although it did work (I later heard there were problems after I left though, causing subtle financial issues and which took quite a long time to find/fix :-/). I don't expect anyone to fix our problems for us, I just want to fix my own problems.
I don't expect everything to be Open Source; I'm fine if it's not. I also don't expect them to drop everything to fix this bug for me. But it is critical for our business, and please, let me sign an NDA or something and let me fix this bug. Everyone wins with this.
Yea it sucks. I assure you it's not discarded, it's just marked as Jira ticket #8563, and during some periodic planning it's never the highest priority compared to immediate clients filing ticket #8654, directors filing an epic ranging from #8700-8712, etc.
And it's not always something as easily implemented as the user thinks. Sometimes it goes that smoothly and everyone is happy. Sometimes it clashes with other future features the user isn't aware of yet or simply hit some nasty edge cases in testing. So it's now a low priority bug that is also non-trivial to fix. the worst kind.
All I can say is to try and get other users to file the issue. The more user pain it causes the more it'll get prioritized.
This speaks sooo close to the trends that pushed Microsoft to go create WSL, to become a viable healthy platform for multi-platform development: they had to. They had to create a platform people could use as they wanted to, had to support something that takes upstream pull requests. Simply shipping Ubuntu is basically the biggest possible fix they had for long term development, going where the puck is headed.
This discussion about whether a game engine is long-term supportable, whether it invests back in the gamedev, it parallels the conversation about development-experience in operating systems so closely.
I've made several games in Godot and continue to use it, but it has serious issues that hamper it from prime time. Here are some I've encountered in my latest project, a point-and-click adventure in the vein of Myst
- When playing non-OGV video files there will always be a black screen in the first frame of the video, no way around it
- OGV video streams suffer from sound stuttering problems on playback
- There are some performance bottlenecks around 3D and occlusion culling, which will hopefully be fixed in 4.0
- No browser web view so you cannot use HTML for markup or design, meaning making interactive pages (like an in-game wiki) is a massive slog
- Font-rendering issues with blurriness and lack of pixel-perfect sizing (if you are doing retro pixel art fonts they will suffer from anti-aliasing)
- Importing 3D assets is wonky and you still need to write custom import tooling scripts in order to make it even slightly usable. Even then you will most likely have to redo all the lighting on your models
I think Godot 4.0 will be a great leap forward and I'm very much rooting for them. But if you are trying to make a big 3D A-level game, you will spend a lot of time with your head in your hands. At least with Unity and Unreal they have large asset marketplaces and very active communities so you can get around a lot of frustrations. Godot is still quite small in that regard. However for 2D or smaller scoped 3D indie games, it's really powerful and versatile. I personally enjoy the Godot workflow with nodes and signals connecting them much more than my experience with Unity and prefabs, which I found to be a bit convoluted.
On the other hand, being fully open source means if you've got a good development team you may be able to hack Godot itself to work around whatever limitations are currently biting you the hardest, and your shipped product doesn't lock you into any sort of revenue share or subscription fees because of the engine choice. This seems to be the approach done for the Sonic Colors: Ultimate remaster and as Godot gets better it may get even more attention from teams developing an "almost certain success" like a new big-IP game.
But I agree that they're still the underdog, and people who were holding out until 3.0 might continue holding out until 4.0 if they're planning on doing a demanding 3D game. I'm rooting for them still too though.
Absolutely. I actually compiled my own version of Godot in order to enable a speech-to-text module (https://github.com/menip/godot_speech_to_text) for a project. While some might see that an overly arcane technical annoyance, the fact I was able to do so just shows the promise of a powerful open-source libre engine. Hope to contribute a patch to Godot proper someday. I also find it so cool that it's bootstrapped - that is to say, Godot is created using Godot!
I've started learning Godot to replace Unity for the prototyping role, but under no circumstances would I ship a game in stock Godot except for a game jam.
The stock editor workflow is solid enough and overall fairly pleasant, but the documentation is abysmal, features aren't up to par with the Unity of even a decade ago, and code quality is "improving". I also have absolutely no clue why the world needed an even worse rehash of python that has absolutely no compatibility with any of the python ecosystem. I've read their blog post. I still do not understand.
Godot 4 looks much more promising on the feature front, GDNative is passable, and at the very least, you can fix the engine yourself if you need to. I don't feel much of a sense of loss from ditching Unity.
This[0] appears to be the main project working on Python. As with all language ports, YMMV.
I personally would wait until after Godot 4 and the new GDExtension system are out and, if it's possible, people start making language support as plugins rather than needing to recompile Godot from source.
Yeah, I would not use unity or unreal. They're too big and too complex.
Godot is light and simple.
Unreal and unity offer sophisticated features for developers who can't take the time to do some low level.
But:
1. Inexperienced developers should not aim for high end graphics and features in the first place, so using those engines is irrelevant to them, they should learn to do simple things themselves. The big race for graphics quality belong to AAA games who don't use those engines.
2. Experienced developers are working for complex games, and are able to avoid the clutter of unity and unreal, because they know what game they want to do, or they work with custom made engines, tailored for their needs.
Unreal and unity are monsters, because they're generic and do everything at the same time.
Godot is the best solution in my opinion. Do small things if you can, avoid big things. If you want to do big things, have the ambition to do them right, and like actual professional developers, don't use unity or unreal.
It depends on your projects needs. I built a music visualizer in Unity, and have no idea how I would of done this in Unreal. It was a small project, and I'm already using it to make videos. My biggest issue with Unreal is how hard anything is outside of Blueprints. C++ is much harder than C#, for my project I both load audio files locally ( you select your own music to play), and download some from a server. I'm pretty sure this is impossible without writing code.
If Unreal allowed for Python scripting that would make it much more appealing. I've never worked on a big project in Unity, I'm not sure what issues arise then.
Again, it depends on your needs. I do think most people are better off learning to program with C# over using Blueprints. Ether way your going to need to invest a significant amount of time learning. If you learn C# you'll be able to easily get a job even if it's not in gaming( this is what I did, and it's worked very well for me). I'm not sure what job learning Blueprints will get you.
It seems like Unreal is a terrible fit for smaller projects where visual fidelity isn't a primary concern. Would I ever build a roguelike, city builder or 2d platformer in Unreal? Wouldn't something like Godot or Unity be a much better fit?
AAA level graphics in nice, but there are many game genres that have visual fidelity very low on their respective list of concerns. With the rise of the Steamdeck, I'm sure there will be a rise in efficient portable-friendly games that can get that 7 hours of battery life. Not sure I would ever consider Unreal for those types of projects.
As a hobbiest, even if visual fidelity isn't a concern I would use unreal over unity. Unity optimizes for making a block move around the screen, but becomes increasingly convoluted in design. Unreal doesn't feel like you are just hammering random different unrelated systems together as much. If I were to do a 2d game I would use godot though.
I tried Unity for a while for 2d game development and really hated the workflow, so I floundered for a couple years trying to figure out what path to take for some of my project ideas.
I've shipped 2 games in Phaser, but did not like the experience at all- optimization was a nightmare and structuring a non-trivial project was surprisingly hard. I've since switched to Godot which has been a dream so far. I would use Godot for 3d development as well, but I realize that anyone that prioritizes visual fidelity will likely look elsewhere. Godot 4 will have huge improvements there, but nothing at the level of Unreal or even Unity.
Hiring UE developers was a major issue at my last company. Not only are C++ game devs much scarcer, but they also seemed to gravitate towards AAA projects and were difficult to recruit for projects that didn’t fit that mold. Unity devs on the other hand are much easier to find. We ended up with a 5:1 ratio of Unity to UE developers, and all of our UE devs were remote.
Talking on sidelines, I really, really hope there is a new Unreal single player game that follow the veins of Unreal I. However, I do think given the complexity of post UE3 engines, it is extremely difficult for even a large community to push such a game out. Years ago I heard about a project that tried to recreate Unreal I in UE4 but never heard much about it. It just takes too much time and effort.
What's your call on this? Do you think it is actually easier for a small, dedicated team (say a couple of programmers, a handful of level designers and artists for example) to get the Unreal I remake in UE4 project done, maybe in a few episodes? The first episode could be from "Vortex Rikers" to "Terraniux", the second from "Noork's Elbow" to "The Sunspire", the third from "Gateway to Na Pali" to "Cellars at Dasa Pass", and the last from "Serpent Canyon" to "The Source".
Won’t ever come from Epic. Think with Fortnite their future has to be these mass multiplayer half social experiences where their advantage is just the speed they can ship content to it. It’s pretty impressive technically.
But if you want games like old school Unreal I suggest you google “Boomer Shooters” where there are a lot of indie FPS games now that imitate that era.
Yeah thanks I actually played some of them. Very interesting. Also agreed Epic will never make another Unreal I, neither a remake nor a new game. If one wants one has to build one's own.
If you are an indie developer and have never worked with C++ before, don't even think about UE5, if you plan on ever finishing your game. Stick with Unity.
Unreal makes money from royalties. Think about the odds of indie game developers generating more than $1MM vs an established studio who has shipped games/films before.
The reality is that the only tech all companies are hiding in plain sight is Skin Mesh Animation and Unity doesn't even implement that in a vertex shader!
They use a compute shader which means they have to send all meshes every frame.
Here Autodesk plays a huge role in bottlenecking the tool chain and that is all perfectly legal.
Monopoly by standardizing tech.
Everything else involved in making a game is much easier from scratch.
Combine that with the fact that all computers without keyboard and mouse are wasted energy and you'll quickly realize that if you only need to support Win on X86 and Linux on ARM your porting is trivial if you use OpenGL (ES) 3 which is the final GL with VAO.
Add HTTP, OpenAL and use .dae, .obj, .ttf, .wav, .tga and .zip and you're done!
Also don't use anything much beyond C and you can't fail.
I have used unity for 2 years - abandoned my first project because it became unmaintainable. But my second attempt has been much more successful.
I agree that unity is good for prototyping, and lots of people have experience with that. Turning it into a finished product is less well-trodden, but not impossible.
The best thing I learned was to keep it simple, but not simplistic. It's easy to be too clever, but when you have good boundaries of code and reasonable coupling, it's pretty alright.
My project is a bit unique in its simplicity, so i can't say someone with a more complex one wouldn't have more problems. But I'm not running to UE any time soon. Unity works surprisingly well for me, but there is a learning curve.
As a macOS developer I feel like there are a lot of parallels between Unity and Apple, and the way they manage their platforms. Opening things up has a lot of benefits, but I think it's probably hard for management to accept the risk when historically things have been working out just fine.
Hopefully the success of Unreal changes some minds.
UE is much more of a "batteries included" engine, so there are a lot more existing systems that you have to learn to integrate to make anything worthwhile. UE is a lot more inheritance-oriented than Unity. Unity's C# scripting is a lot more flexible and composeable. Also, even if you are an experienced C++ coder, learning Blueprints is absolutely necessary so that you can get a handle on all of the included APIs of the engine and common interaction patterns. Even if you do get a good grasp on the C++ APIs, it is much easier to compose a complex game object with Blueprints because there isn't really a "Prefab" concept like in Unity. (Some people will compare Blueprints to Prefabs, but I initially found them much less useful). The mental model for how levels work is also very different.
That said, I think UE is much more powerful overall, and worth learning if you take game development seriously.
The prevailing wisdom in my circle is that you just don't want to consider UE for 2d games. Godot is fine, but sometimes you just wish that you have that killer Unity asset that you have always been using.
The problem statement was unity projects are hard to maintain due to accumulation of tech debt. The answer is to give dev engine source access... I failed to see the connection here.
A platform which takes input, which is participatory, is probably going to do much better about the core thesis (in bold on the article):
> As impressive as UE5 is, I don't think the technology has to do with its appeal as much as the long-term user experience.
I agree there's not a ton of explanation & support for this point. The post does jump to a very specific topic, whether the source is open / takes PRs. For sure there's a lot more that goes into this question. The post explicitly says it leaves others to deal with a lot of the pain of the back-half of Unity development, so it's not even like there's a ton of winning moves UE has to play: they just have to not self-inflict grevious wounds.
It is, however- unsaid in the article but clear- incredibly much easier to keep yourself in a respectable, easy to use shape when you are open source. The post talks about a specific bug, but just things like improving the build toolchain or adding support for some new developer tool: developers will happily improve their quality of life in a product, if you let them.
What’s the story for developing in UE without C++ these days? Can you get along with just scripting and shaders? What sort of functionality would require new C++ and wouldn’t be possible in script?
What draws me to Unity is C# because learning C++ is a decade long project.
The main things found in many games would be procedurally generated assets like maps, and strategy game AI/pathfinding. Most other things should be possible in blueprint scripts or standard components if you can live with the performance, which you can if you can live with unity performance.
One thing that wasn't mentioned: (realtime) multiplayer. What's the story here for Unity these days?
There's still a lot required in Unreal to implement things like bullet or projectile latency-correction unfortunately, but the base infrastructure they provide here is huge. Last I used Unity, there was essentially nothing. There were some third-party things but nothing you'd ever want to use in a shipping multiplayer game that isn't turn-based.
Has anyone actually shipped a multiplayer (not turn-based) game with Unity that doesn't regret the decision?
I'm aware of some fighting games in Unity. These are real-time games but by convention they derive game states from sequences of input states from the players and use time travel to amend entire estimated game states (rather than e.g. estimated positions of individual objects). These games still face some unnecessary trouble imposed by Unity: it's not possible to handle all inputs and networking on a thread that's entirely separate from the thread that does rendering.
The networking in Unity is still terrible. Unreal is of course better but still not good enough out of the box. When Riot developed Valorant they had to rewrite the networking code to be more like Quake and Source.
At one point in the past, Unity had a legendary commitment to backwards compatibility, but that's gone now (maybe their internal promotion process rewards shipping new features over everything else?).
Old Unity would never have shipped a fiasco like URP. They'd have figured out a way to make incremental migration possible instead of having a global setting... I refuse to believe this would even be particularly difficult.
If you believe that then you have neither used or unsterstood the concept of the new scriptable render pipelines. Nevermind the fact that most people already switched over to either URP or HDRP.
I used to sell Blueprint code on the Unreal Marketplace so I am biased in preferring Unreal over Unity.
One nice thing about Unreal is how easy is it to give a modkit to users with Blueprint. You can keep all of your proprietary stuff compiled in C++ yet exposed to Blueprint which is pretty easy for any regular non-programmer to pick up. I have been playing around with the Conan Exiles modkit recently and you basically get access to everything that an actual salaried game developer would have access to. Heck, I could even turn it into a VR game purely with Blueprints (I'm actually working on this in my spare time, which admittedly, is few and far between).
Seeing the control flow of Blueprint live while debugging is also great for non-programmer, as it allows them to easily reason about what is and isn't happening.
You can talk about rendering pipelines and the marketplace all you want but Blueprint is the killer feature for Unreal Engine.
You could make Python scripting for gameplay logic a first class citizen in Unity, but even Python is harder to work with than Blueprint for less-technical creators and users.
as a professional Unity developer, I think Unity would be a much, MUCH better engine, if Unity Technologies would make commercial games with it, in-house. Just like Epic games do. Then they wouldn't tolerate all the crap unity devs have to deal with
I really want to like Unity.. but they make it hard.
There are a bunch of ways to do one thing, and those ways are probably deprecated. I really like their direction for DOTS, but their communication with their community is pretty much dead. They made a single post after a very long time with an update, and provide no real roadmap.
UE5 is pretty good, having not used UE4. I like how they keep everything backwards compatible, so it's pretty good. I like blueprints and how you can use their C++ bindings pretty easily from it.
I also like that UE5 is dogfooded by Fortnite, so they actually have skin in the game to make the editor better, instead of just relying on royalties.
Unity has changed their tact with features.
Dogfooding with Animation, Game Development, VR/AR. You name it, they have an open source project to start from: https://github.com/UnityTechnologies/open-project-1
New features include source access through Github, have QA testing statuses (Preview vs Verified), and have automated upgrade paths. I recently went from Unity 2019->2022 and it was seamless. Source code access is ubiquitous too.
This is all very different from the Unity 4 days where a patch version would break your project!
The downsides are that the Editor is mostly single-threaded, so in large multi-year projects, iteration time and navigation can be difficult. Unity have a “task-force” that are working to resolve these issues, but their communication is really lacking.
Unreal devs by comparison are much easier to get ahold of and have more open roadmaps. I’m hoping that Unity moves in this direction, but they’ve been burnt by this before: promising features in timelines that weren’t feasible (i.e nested prefabs)
As a long time Unity dev, now: Wait for a feature to exist for two major revisions. It might still be deprecated in a future revision, or removed entirely; but with two revisions they'll generally have smoothed out all the rough parts.
I think it comes down to two points: Unity has much better (real world) mobile support, , and there are many more people trained on Unity. IMHO chasing the elusive AAA carrot is Unity's biggest strategic blunder right now.
I wish "Unreal as a Library" existed in the same way it does with Unity; as we use the runtime to ship the cross platform AR component of a react native app.
Unreal is trash for 2D. However, if I was making a 2D game, I'd use Defold or Godot or GameMaker or raylib or libGDX, not Unity. Only reason to use Unity for gamedev these days is if you wanna get a job at a mobile game company
Also, both are FPS / TPAA engines. Unreal especially. Sure, you can make it do other things, but it's just not a natural fit for, say, an isometric 4X game....not that there's an openly available AAA quality engine for that at all
Unreal vs. Unity is pretty much the 'spaces vs. tabs' or the 'emacs vs. vim' debate at this point. Nobody who makes a living from gamedev is dropping their engine of choice thanks to a flashy demo or even a killer feature unless they're facing some kind of existential threat. Thus, the most knowledgeable folks can't fairly compare the engines, and the only people really making noise in this debate are amateurs with little to no skin in the game.
There are exceptions, such as where a studio that made the switch for reason X or reason Y is able to clearly articulate what they're doing and why, but these exceptions only serve to prove the rule since they're extremely rare to come across.
The more I read about these arguments the more I think it might be actually beneficial to male your own engines if you have 1) a small-medium size team and 2) not reaching for top notch graphics.
I'm unclear on the unity source availability. It's impossible to fix a bug because you don't have the source? But you're staring right at it, which implies you do?
If you're a big company (think publicly traded, not just big), you do have near realtime access to both Unity dev teams and the full up-to-date source, and you may even ship builds made with internally customized Unity versions, but it's such bad code that you wish you didn't. And they don't accept patches back for integration in any timeline worth considering, so it's really hard to maintain local changesets while still pulling Unity's improvements in patches releases.
What is your source on that? You do not have to be a publicly traded company to get source code Access, the source code is actually pretty well written and maintained. With the new approach of features being delivered in packages you get all the source directly in c#.
Unless things have changed drastically since I was at BigCo (and maintained a branch of Unity 4 for several teams, so was very familiar with the codebase, and their native code was horrific) unless you have serious sway you don't get engine source, and in my experience that's where a ton of the bugs that will screw you lie. In fact I'm dealing with a few right now at a smallCo that definitely doesn't have access (we've asked) to the important pieces of code that are making our lives hell.
I definitely agree that shipping more stuff in C# packages is a good thing, and those are mostly well written, I mostly just hate the actual C++ engine, which is frankly a disaster held together by bubble gum and spit.
Unity's source is not open source. They let you look at the C# code, but not modify it or redistribute it. You can purchase a license to get the source code including the engine code.
unity always required that you use a mouse to manually drag and drop certain things in its GUI interface (prefabs), and this is intolerable to people who feel like their entire project should be storable in simple (text) files. otherwise what are you supposed to do, take screenshots of the state of the editor when everything is dragged and dropped into the right place? it’s so bizarre
I'm new to Unity and game development, and I'm starting to feel like there's another problem alongside bugs: misinformation. I've been reading through the official manual/prose guides, and many of the chapters blatantly contradict the UI and behavior. Official samples from Unity make typical noob mistakes. Unity employees make incorrect recommendations in the forums. Bug reports will go unacknowledged for a long time, which makes it hard to trust anything you read.
So in addition to having to put in the effort to learn the tools and concepts, you have to be ready to distrust anything the docs and even the employees tell you. Unity itself is a force actively working against you.
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.