What Unity Is Getting Wrong

Unity has gotten so painful I&#x27;ve sworn off ever taking another Unity project. Since mid last year I am 100% exclusive on Unreal Engine.<p>Unity wants you to think this instability is temporary. It is not. Unity has been unstable since at least 2014 when I first worked with it. Every year there is a new-new thing, &quot;please stop using the old-new thing&quot;. Meanwhile those upgrades are always painful, not sometimes painful, but almost always.<p>Back in the Unity 4 to Unity 5 transition the studio I worked at had a contract to port a single game screen from NGUI to UGUI. NGUI being a plugin which used to the de-facto UI framework. UGUI being Unity&#x27;s inhouse clone. No upgrade path, just a rewrite required.<p>You want to know the juicy fact? Unity has more engineers than Epic. This despite Epic developing both a cutting edge game engine + Fortnite. Unity makes noise about needing price increases and extra revenue sources, yet that high headcount is not showing us as quality for the gamedevs.<p>With Unity you are paying for the &quot;build a bear&quot; of game engines; while Unreal is selling a batteries-included solid foundation.

I support CI for my team&#x27;s Unity builds. I don&#x27;t know much about the engine itself, but I can tell you that the tooling for automating Unity builds really sucks.<p>I had a long list of reasons why, but my impulse blocker cut me out. Oh well. Here&#x27;s a much smaller list:<p>- You have to jump through many hoops to run Unity in headless mode<p>- I cannot separate out build processes into discrete stages<p>- Linux version is behind. Windows is slow. Macs require you to use specialized cloud (such as MacStadium)<p>- License server is unreliable. It always goes down with a 500 error, every day for most of the evening (California time). That means I cannot easily elastically scale build servers.<p>- WebGL target means running emscripten, which means running a compiler in Python. It is slow. We sped it up by using a really expensive AWS instance size to run it.<p>- We built our own pipeline because Unity Cloud is even slower<p>I think it is like this because:<p>- We&#x27;re not Unity&#x27;s core market. We&#x27;re a team that can afford expertise on CI<p>- Unity doesn&#x27;t dogfood their own tools and build a game with it. They don&#x27;t fix the bugs that come from having to build a game.<p>- Unity Cloud probably cheats and uses a special version of the binary that does not talk with their license server. So there is no pressure to fix their license servers, and make it reliable enough to run elastic loads. (They probably don&#x27;t run it elastically because they use Macs for their build servers)<p>I look enviously on the folks who work with Unreal Engine. I also hear that Defold is now open source. Maybe people can use that instead.

I&#x27;m a full-time independent game developer who&#x27;s been using Unity for the last 6 years and sadly Garry&#x27;s very correct. The render pipeline debacle has been painful to watch, Unity announced that the Universal Render Pipeline (what is still planned to replace the default renderer) was &#x27;production ready&#x27; in early 2019, and it was lacking... so much. No ability to use multiple cameras (one for the game, one for the UI, for instance - a common use-case), they&#x27;ve rewritten the post-processing stack multiple times. Having more than one Directional Light was supported only very recently. Some of these have been and are being addressed, but it feels like Unity is in this odd no man&#x27;s land, grey-area between the old legacy parts of the engine, and the new ones that just aren&#x27;t ready for prime time, with many glaring gaps in the functionality. You would expect something as straight-forward as SSAO to be available out-of-the-box, it&#x27;s hardly cutting edge tech, but two (three?) years into URP&#x27;s development and it&#x27;s not in the Standard Assets yet.<p>I do sympathise, it must be very difficult to bring an old engine up-to-date, but it&#x27;s quite infuriating for developers like myself to work and know when to upgrade and when not to.

I&#x27;m so frustrated that Unity and Unreal are the only two real options. And it&#x27;s all because of console vendors.<p>Unreal is just way too inaccessible, as an individual, non-C++-veteran (used it a bunch in college, but modern C++ looks nothing like what I&#x27;ve seen), non-games-industry-veteran. It&#x27;s also fairly opinionated towards first person&#x2F;third person action games.<p>And then Unity is of course a dumpster fire. It&#x27;s much easier to get started and hack something together with, but you&#x27;ll be hacking and fighting with the engine for the entire project.<p>Open-source libraries&#x2F;engines exist, like Godot, but none of them properly support consoles because console APIs are apparently proprietary (??) because the console vendors are apparently stuck in backwards, draconian software practices from 2002.<p>The whole state of indie-accessible tooling is just deeply depressing.

This has been a cultural problem at Unity for a long time. They introduce half-finished features and then never improve them. A great case in point is their VideoPlayer component which can&#x27;t open a video without dropping frames because 4 years on it still can&#x27;t load things asynchronously. Where&#x27;s the dev assigned to that component been and what have they been doing all this time? People have been complaining for years and there&#x27;s zero attention to detail.

&gt; They hid all the hard stuff in c++ so we didn&#x27;t have to think about it. The more time has gone on, the more bullshit has crept to the forefront. The&#x27;ve gone from hiding the hard stuff to moving more and more stuff into C#.<p>I love that they are moving more and more stuff in C#. It&#x27;s a good thing. The C# code is available for developers to view and modify, but no one is forcing you to.<p>The problem is that a lot of Unity&#x27;s early choices that made it so accessible to novice game devs making simple games, made it to inflexible or slow for bigger or more complex projects.<p>If you were building a high performance procedurally generated game, you were already fighting with all of the &quot;easy stuff&quot;.

I&#x27;ll just sit back and eat popcorn as I work with my custom handmade game engine. None of this is a concern for me, and it has been refreshing to work directly with the graphics pipeline and in lower level languages that give me direct control. If something is wrong, it&#x27;s my own damn fault.<p>For those who want to get away from being totally dependent on third-party frameworks and tools, check out Handmade Hero. It was life-changing for me, the difference between making a game I&#x27;m happy with vs. not.<p>I also have a YouTube series discussing how to get setup on a Mac, if that&#x27;s that platform you&#x27;re starting with.<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;M5l6CvHwWsc" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;M5l6CvHwWsc</a><p>I&#x27;m not really sure why more people don&#x27;t do their own thing. It has been really satisfying for me. Overall, the process of making games is way more rewarding, and I think I&#x27;ll have something better on the other end of all of this.<p>Plus I&#x27;m getting better as a programmer, which helps with other aspects of employment.

100% agree with this.<p>Everything they’ve done in the last 5 years I’ve been using Unity has felt half baked. You’ll try any number of the things they’ve released recently (networking, 2d animation, and vector graphics are the ones that come to mind for me) and they’ll work fine for their demo case but then fall apart with so many cases that you need to actually ship a game. I think one of the bigger problems with the company is that they’re not actually making games themselves and eating their own dog food.

I got stuck into a few unity projects recently, and I&#x27;ve been surprised how poorly documented and undiscoverable things can be.<p>Why is the whole rendering pipeline stuff such a mess? I&#x27;ve bumped into far too many unexpected gotchas because a pipeline doesn&#x27;t support a particular feature, or it renders stuff in such a way which isn&#x27;t clearly documented. And whats worse is there is no real easy way to debug it since there seem to be no in-built debug tools for rendering.<p>Also their webgl implementation is terrible if your doing anything more advanced. Often I&#x27;m scratching my head trying to figure out why something suddenly doesn&#x27;t work, only to find out for some reason it&#x27;s still using old resources. And I&#x27;m often working around yet more undocumented implementation details like render targets getting their alpha channels wiped somewhere in the spaghetti code rendering pipeline.<p>It strikes me that there is a real big gaping hole in the market for something like unity but which has a flatter, more comprehensible system. I think there is some hope godot will be that, but I don&#x27;t think its quite there yet for some scenarios (like their webgl implementation being even worse than unity).

A great demonstration of how unity is bloated: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=tInaI3pU19Y" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=tInaI3pU19Y</a><p>Unity is targeting students and gamedev wannabees. You don&#x27;t make a game with a framework. Programming is not simple. Same debate of framework vs libraries.<p>I&#x27;m even against Godot, which you cannot even use as a rendering library. You end up being too dependent on those platforms and all their assets and plugins.<p>Of course if you intend to make a game that&#x27;s not too ambitious, if it revolves around the graphics, unity might be ok, but it&#x27;s just a sophisticated RPG maker 3D.<p>I strongly advise against learning unity or godot. A huge problem is that unity&#x2F;unreal made it difficult for classic engines&#x2F;renderers to keep thriving, and it&#x27;s hard to find a good engine nowadays. There are some, of course, but their community is non-existent, which makes things much harder in open source.

In February, Unity changed their asset store license retroactively and took away our rights to let our freelancers use our assets. Their support was apparently telling users their freelancers could use their purchased assets only days before the change. It was a massive abuse of the “we can change these terms at any time clause”

As a Unity user emphatically sharing these frustrations, I&#x27;d be really curious to hear from long-time Unreal devs whether the grass really is greener on the other side.<p>How&#x27;s Unreal&#x27;s<p>- API stability?<p>- Editor stability? (I have some old experiences of it being quite crashy too, and you know, C++ ...)<p>- Backwards compatibility and upgradeability?

There are two main reasons to avoid Unity:<p>1) As your project grows, it becomes unmanageable because the resource pipeline is hidden and you want to be able to improve that.<p>2) Skin mesh animation, which is the main point of using Unity in the first place, uses a compute shader which means they send all meshes from the CPU to the GPU every frame!<p>On the other hand Unreal takes 5 hours to compile and even Godot takes the same time as Unity ~30 min.<p>The only option is to fold your shirt sleeves up and build your own engine. It&#x27;s not that hard really.

I&#x27;m a hobbyist game dev. I picked up unity one day and just started making stuff, learning C# on the fly. I&#x27;m not great but I can do what I want. I was really interested in Quixel for Unreal so I spent the first half of today trying to learn it. I think I&#x27;ll be going back to Unity. Unreal did not feel approachable at all. I&#x27;ll probably keep trying for a couple days... but yeesh.

The are all primarily organizational, not engineering problems. Like many other tech companies, I feel that product managers at Unity are rewarded for launching new shiny features (that quickly fall apart outside the scope of beautiful demos), not maintaining and improving existing ones.<p>But despite that, it still stays a very good choice for many different scenarios, and definetly the best for mobile 2d games. The original design choices are solid. The most important components are in good enough shape. And it stays just in the right place between being too complex and too primitive. So, from a business perspective, when you want to build your match3 or hyper casual title, there&#x27;s no much of a choice in terms of engine.

I&#x27;ve spent the last three years working in Unity. By the time I&#x27;ve learned enough to make honest-to-goodness good quality games with it, I&#x27;ve reimplemented so many things that are supposed to be core features of Unity, that I would have just been better off starting from scratch on my own.<p>So that&#x27;s what I&#x27;m doing now. There is a .NET Standard 2.0 library called Veldrid that gets you open source graphics code. There&#x27;s another netstandard2 library called NAudio that will get you most of what you need for audio. Xamarinn will get you the platform-specific stuff for user input. Networking can be done with just regular, ol .NET sockets. If you care about VR (which I do), there are C# wrappers around all of the major VR APIs; you&#x27;d have to do a lot of platform specific and conditional compilation wrangling to get good VR working on Unity anyway.<p>And you can use a sane build system, with a sane dependency management system.<p>It&#x27;s just so much better than constantly fighting Unity&#x27;s stuff that was all designed for demoing at Unite and then never finished.

Curious question:<p>I have a few years experience with Unity. When I first grabbed it, I assumed the engine having C# scripting would give me rich tools to make game state serialization (save games, streaming open worlds etc) a relatively easy task, thanks to its reflection capabilities. This turned out not to be the case due to my false expectations, the programming model game objects use and the asset pipeline needing too much plumbing. Official ECS packages made it easier later but they also broke the entire authoring workflow by effectively deprecating `GameObject` in practice.<p>I&#x27;ve never used Unreal Engine but if serialization is a solved problem there, I want to try.<p>Does anyone here have experience with similar use cases?<p>Are there other AAA-ready engines good at this? Giving value types first class support, promoting data oriented design and building the artistic authoring tools around these priorities is what I will appreciate the most.<p>I don&#x27;t care if the high level scripting language is non-existent, C++ heavy or Brainfuck. That can be circumvented by building muscle memory in a few months.

I&#x27;d add this the lack of a solid 3rd party developer ecosystem on their Asset Store. The fact that they don&#x27;t have a subscription model for assets or any support for managing per-seat licenses is ridiculous and is the direct cause of multiple popular assets ending support. It doesn&#x27;t make sense economically to sell any kind of service on their store.

I once tried using Unity for creating a little game during a game jam of approximately 8h. The team wanted to make a small game, where one could mix ingredients and create magic potions. Initially I suggested we could simply use some JS and make it a web app, specifically, because I anticipated problems, if we relied on some software like Unity, but no, unfortunately the team majority decided they wanted to use Unity.<p>For the Windows users it apparently worked. However, one friend and me, this choice excluded us. Here is why:<p>Unity did start the first time, but then crashed, resulting in some lock file being there, so that I could not start it again. Took a while to figure that one out. After figuring that out, I was able to remove that lock file manually, enabling me to start Unity again. That alone in itself already seems ridiculous. However, I could still not use it, because it kept crashing and not working. So my friend and I could not participate at all. She was running some Mac laptop, where it also had issues. I tried reinstalling multiple times, updating graphics card drivers, switching between proprietary and Nouveau, all kinds of shenanigans, I tried for at least 2 hours to get this stuff working before giving up. Of course I searched online for solutions. None to be found.<p>This was a few years ago, so the situation might have changed, although many comments here lead me to thinking, that it might be just as bad. However, that is why I stay clear of using Unity. What I&#x27;ve seen of Unity makes me think it is a huge bloated thing. I&#x27;d rather choose some small 2D game engine and write a lot of code myself than trying to use Unity again. Once bitten ...

This blog has a looping, resized background video with a CSS blur filter. For anyone else experiencing performance problems because of it, I recommend reader mode.

There is also Amazon Lumberyard. Which is totally free, you only have to pay if you use AWS for multiplayer. It is a fork of CryEngine. It looks really nice.

Overall I love unity, but one thing that drives me insane is how many weird UI quirks they just don&#x27;t fix, like how incredibly primitive editing arrays in the inspector is (its a nightmare to reorder anything) or dealing with asset imports that take forever. They take these huge projects on, the great rendering features and such, and theyre impressive, but somehow they won&#x27;t fix small things that are seriously aggravating in day to day use.<p>Also while I do love c#, I think it was the wrong language choice, because you end up having to write code in a really constrained way to get around garbage collection issues. Its getting better, but for games id prefer a non gc language

I spent so much time figuring out stuff in Unity (physics <i>cough</i>) or implementing stuff I thought were subpar (a remoting stack based on LiteNetLib) that I simply got tired of it. And every new feature adds more complexity on top of an already huge engine, which takes insane amounts of time to keep up with.<p>In anger I drew this comic [1] and really, my relationship with unity kinda broke as soon as they introduced dots and the new rendering pipelines.<p>[1] <a href="https:&#x2F;&#x2F;www.zubspace.com&#x2F;comic&#x2F;unity-vs-godot" rel="nofollow">https:&#x2F;&#x2F;www.zubspace.com&#x2F;comic&#x2F;unity-vs-godot</a>

I have been using Unity since 2008 version 2 before the Unity iPhone even and I have to agree. It is a mess.<p>There has never been a time in Unity where systems aren&#x27;t changing.<p>APIs should be simple facades to ugly systems underneath, abstracting away the pain, but Unity puts it right in your face. Their editor is pushed over code first solutions.<p>I thought when they went subscription that it would calm down, as before that it was a mad rush to justify you upgrading to the next version. It has only gotten worse. From the dual particle systems (which Shuriken wasn&#x27;t even code accessible for a time), killing off simple legacy animation APIs, the UI years and years of delay and still not really as good as NGUI in terms of simplicity and mobile performance, the multiplayer systems have never been great they should have just kept RakNet&#x2F;enet based reliable UDP and been done with it only Photon is worth it, the bulky editor first solutions that really should be code first and then editors that use that and on and on.<p>Compare that with Unreal that is wonderful in terms of networking&#x2F;replication, solid platform that is C++ first, decent platform support, Unity has more but lots of issues.<p>Unity is what we develop most games on but Unreal starting to become more regular. Unity is caught in a pickle. Unreal is winning high end, Unity wants to be them, but they are leaving their smaller developers that do mobile&#x2F;2D&#x2F;simple 3D and making everything overly complex, while Godot is out there taking that space. I&#x27;d be worried if I was Unity. They still win on platforms available and they are making good efforts, but right now, and many times in Unity&#x27;s history, there are so many systems now that it isn&#x27;t simple for the low end, and high end you&#x27;d be amiss to not go with Unreal. This is coming from a Unity developer since 2008 Unity 2, before they even had Unity iPhone, back when it was just WebPlayer (which I miss the simplicity) and Desktop.<p>Unreal is doing high end much better than Unity [1] and Unity is losing what made it hit huge, mobile, web and desktop games and simplicity. At this point Unreal is more simple because the systems work and there aren&#x27;t these one direction only changes or dual system problems. So much of the Unity API is in flux right now and you never know if they are going to drop them. UI was worked on for YEARS and now they are doing UIComponents and don&#x27;t even try trusting a Unity networking solution.<p>Back in 2013 Unity was going to go C++ [2] and I wish they had, it was when Apple forced AOT on everyone and they backed off but Unity went into IL2CPP just a year or so before Mono was bought by Microsoft and had AOT baked in. They spent so much time not wanting to pay Mono&#x27;s license but later it was all moot and not needed fully. Since that time Unity has been a constantly changing beast, and not for the better, painful wholesale updates with little or no benefit, only to see that system disappear soon and on to the next.<p>Unity needs to calm down, lock down API signatures&#x2F;facades, focus on atomic operations, make simple APIs as abstractions and change the underlying systems when it evolves. They do parallel changes which is good, but the surface changes quite a bit. Unity has become one big leaky abstraction. I have used it almost everyday since 2008 and it would be fine if they made things more simple, but even the transition is painful. Like when they removed their legacy particle system (which had a decent API) and one day just pulled it from a new build, every old game just crashed on open, no warning. They are getting better at that but it should not be like that.<p>I am in the middle of a bunch of NGUI to UnityUI upgrades and that is already going to be replaced with UIComponents ... UI constructs (types, textures, fonts) really don&#x27;t change that much and they spent years on that UI update. Why are users having to concern themselves with surface changes?<p>A major difference between Unity and Unreal is Unity doesn&#x27;t build games on their engine, Unreal does. While that sometimes makes Unreal solutions more FPS&#x2F;BR format and closer to their games, it makes for a solid engine.<p>Another difference is leadership, Unity was extremely simple and small before, once they got John Riccitiello it become a management&#x2F;business focused company over engineering leaders in terms of power and direction.<p>Unreal has Tim Sweeney, and old school guy that understands how to make a game engine and has done it over and over. They learned alot from Unity, and are now doing it better than them once they turned towards simplicity over complexity.<p>When Unreal 4 swapped out UnrealScript for C++ it went into overdrive in terms of performance and clean. Unity is nice that it is C# as well, but the extra weight of constant changing systems that seem half done and not code first is tiresome.<p>I love Unity, I make a large part of my living from it, I hate to see them not understand that breaking changes constantly, gets a bit old and it essentially offloads technical debt to every user of the system. I am using Unreal more because of some of these issues.<p>People use a market engine to offload the engine team. That engine team should do whatever it takes to make transitions easy, and when difficult there needs to be immense benefits. Some of those are questionable in recent years. The desire for Unity to want to be Unreal is losing the mobile side and web is essentially not even a focus anymore which is more the whole market not Unity&#x27;s fault. Unity started really as a better Flash, now they want to be Unreal. Right now Unreal is winning that and the Unreal 4 rewrite with C++ backed is really clean. Unity still more simple but with the new DOTS&#x2F;Rendering Pipelines it is not.<p>Unity, let the engineers&#x2F;product people lead over the managers, you are losing a good thing.<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=oDQl9gw_fRM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=oDQl9gw_fRM</a><p>[2] <a href="https:&#x2F;&#x2F;blogs.unity3d.com&#x2F;2010&#x2F;07&#x2F;02&#x2F;unity-and-ios-4-0-update-iii&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.unity3d.com&#x2F;2010&#x2F;07&#x2F;02&#x2F;unity-and-ios-4-0-updat...</a>

Looking at its adoption by Hollywood and TV channels for 3D based animations, Unity is getting lots of stuff right.<p>I guess there is always Godot for those that don&#x27;t feel the same way.

Godot Engine <a href="https:&#x2F;&#x2F;godotengine.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;godotengine.org&#x2F;</a> is much more user-friendly in my experience.

What do folks here think of Panda3D (<a href="https:&#x2F;&#x2F;www.panda3d.org" rel="nofollow">https:&#x2F;&#x2F;www.panda3d.org</a>)?<p>Its just a game engine without any IDE. So the typical workflow would be to build your assets and scene in Blender (or Maya, etc.) and then code up the game mechanics in Python or C++. I am tinkering with it for non-gaming (Reinforcement Learning) use cases and I was curious what game devs think of it.

What&#x27;s the primary draw of Unity? Valve, Epic, and id learned a long time ago that the real money to be made is in engine licensing rather than actually making games (unless the goal of said game is to show off your engine).<p>What is it that Unity has that these companies have been so unable to replicate? Surely they don&#x27;t want another player in the scene to compete with their engines.

I&#x27;ve been reading Garry&#x27;s blog for about 15 years, good stuff.

This resonated with me: &quot; If you&#x27;re searching how to do something, the first 5 answers you find are going to be out of date - and they&#x27;re usually from Unity&#x27;s own documentation. &quot; Unity seems to be going in too many directions at the same time.

It often feels like if Godot hired one really, really good documentation specialist, they could run away with things, especially in the mobile, indie, and lower-spec spaces.<p>Unity&#x27;s documentation is bad, but unlike Unreal&#x27;s, it exists.

In my brief time trying out Unity (as a non-game-developer) I found the programming paradigm very frustrating. I wanted a more object oriented approach. But what I found was to get things to work in a performant way, you&#x27;d end up with very leaky abstractions. At the core, my thinking is it has to do with everyting coming down to handling on a per &quot;tick&quot; basis rather than as an event. Maybe I just did things wrong... but this seemed to be the direction you&#x27;re guided in. If you do try and build a good quaility event model, the performance was terrible.

Just try doing basic rendering with Unity and you will understand how bloated it is. Try to do some kind of fast line drawing &#x2F; loading fbx &#x2F; etc. Anything that a basic engine does pretty good.

DOTS is in fact a major step up. It can&#x27;t be done in engine code the same way you can&#x27;t handle say oop to functional programming conversion in engine code.

Lol that Unity ECS ends up in a &#x27;getting wrong&#x27; article considering that ECS style programming has been the direction that game development has been moving for a good while now.<p>At some point sooner than later people will be complaining about how they can&#x27;t do ECS in Unreal.

The multiplayer thing is my biggest gripe. It is unfathomable to me that Unity has seemingly ceded multiplayer functionality to Photon, considering the most valuable games on the planet right now are all multiplayer-first.

Smells a lot like a continuous second system syndrome.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Second-system_effect" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Second-system_effect</a>

At this point, Unity is a WIP engine with a boat load of alpha packages.

Your webpage, in particular the barely visible animated background of it, consumes 100% of GPU on my 2012 Macbook Pro. This is bad website design from an energy point of view.

Unity does miss on a lot of things, but I&#x27;d like to point out one of its best qualities: the pricing model. Compared to Unreal, Unity is a steal. Despite Unreal&#x27;s recent changes to not collect royalties on the first $1m of gross revenue, its license can get quite expensive if you have a successful game.<p>* Unity: $1800 &#x2F; year, no royalties. (Unity Pro)<p>* Unreal: 5% of gross revenue.

Pretty much everything. Godot is where it&#x27;s at.

No mentioning of the asset store - almost got scammed by the author of a popular terrain shader author. Fortunately Unity issued a refund, but the person has been quite bullish on their forum and is still selling there. As a fee forum admins told me - stay away from the asset store, or at least buy from companies you can hold accountable.

As I had mentioned in a previous thread that has come up recently with regards to UE5 and being open sourced, one of the greater sins of Unity is that it is mostly closed source.<p>In reading through the blogs of some of their developers, they seem to have a contrived idea that people &quot;shouldn&#x27;t have to know how it works&quot;, which, while it&#x27;s a noble gesture, is bullshit because by prohibiting reading the implementation you can&#x27;t know how it works anyway, whether or not you want to.<p>The domain model in Unity is fundamentally broken because it forces you to tie a lot of logic to a Component. People end up embedding all kinds of unrelated bits and pieces of functionality to the Camera because, well, where else are you going to specify it? This is a batshit crazy way to write software. Yet here we are.<p>Lastly, engines are leaky abstractions. Most software is a giant leaky abstraction as bugs and other things tend to creep up from beneath you, and knowing how something works down to the minute details is a huge advantage when it comes to not only debugging, but developing (architecture, style, optimization, whatever).