Unity is very nice to develop actually. It's a lot more simple than UE4 for example, but UE4 is much better suited for more complicated games, but then again, Subnautica is made in Unity, so Unity is very flexible.
Neither is "bad" or "worse". Unity is obviously not perfect, but video game engines move and change all the time, that is the nature of the video game industry.
Unity is mostly used for mobile video games, to which UE4 is not that much suited because it's more complicated and requires a better phone + the apk size will be larger in the end.
Let's put aside everything that the two libraries actually do for a second, and just think about them in the abstract. React very clearly tries to guide the developer towards correct patterns and abstractions. It's clear that React developers have thought very deeply about how to lead engineers towards the happy path of code with fewer bugs in it. It throws loud errors and warnings if you do something that could even potentially lead to an error down the line. They deprecate and eventually remove broken features. And it almost goes without saying, but they finish the features they're working on, rather than leaving them in the codebase in a half-finished state.
Unity does none of these things. Unity doesn't mark old features as deprecated: you could be using a deprecated or obsolete API for months without ever recognizing it because the only communication Unity gives you is a post on the Unity blog post from years ago. (This has happened to be multiple times.) Unity doesn't tell you when you're doing something wrong - you can still StartCoroutine with a string, even though you should be using a function reference. Unity absolutely does not try to lead your code towards the happy path of fewer bugs - GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists, so if you forget and remove it later, your code will crash. React is very intentionally designed not to have problems like this.
I wrote like 4000 words on this topic, if you want more detail. Feel free to dig in if you'd like: https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...
I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.
IDEs like Rider will highlight and warn you about using GetComponent in performance critical contexts like your Update method.
https://blog.jetbrains.com/dotnet/2019/02/21/performance-ind...
>Unity has a number of methods that get called very frequently. For example, MonoBehaviour.Update is called every frame, as is LateUpdate, and FixedUpdate can even be called multiple times in a single frame. Rider treats all of these methods as performance-critical, and will highlight the method in the editor gutter.
[...]
>Once inside a performance-critical context, Rider enables a number of inspections:
>Avoid usage of GetComponent methods
>Avoid usage of Find methods
>Avoid usage of AddComponent
>Avoid string based method invocation (Invoke, SendMessage, etc.)
>Avoid Camera.main
>Avoid null comparisons for Unity objects
>The links above will take you to the documentation pages for each of the inspections, which provide more details of why the method calls are highlighted, and what you can do to avoid them. You can get to this documentation straight from Rider, like with many other inspections, with the “Why is Rider suggesting this?” Alt+Enter menu item.
The Unity editor also has lots of features that IDE’s have already, including a profiler, ability to inspect the world hierarchy, inspectors for components on that hierarchy, and ability to pause and restart execution.
If I was czar of Unity (ha!) I would never have allowed AddComponent and RemoveComponent to be a thing - I would have required the user to add all of the components they expect to need at edit time instead. The dynamism that Unity currently affords rarely improves my game, but it does lead to a lot of bugs. If users really want to turn components on and off, they could have an enabled flag.
Components do have an enabled flag.
https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h...
I mean, if you're adding a new component to a GameObject for every room in your dungeon or something, you're doing something very wrong. At least in my opinion!
Are you sure? My IDE (Rider) shows gives me a tooltip for any methods that Unity has declared deprecated. There's also console warnings and big notices at the top of the docs.
Package Manager also clearly marks certain packages as experimental or deprecated.
AssetBundles. Not marked as obsolete. Not marked as deprecated. Unity docs look fine, with no references to anything else you should do: https://docs.unity3d.com/ScriptReference/AssetBundle.html. They are in fact obsolete anyways. See here: https://learn.unity.com/tutorial/assets-resources-and-assetb... "this tutorial has now been deprecated. We now recommend using Addressables for your projects"
EditorUtility.SetDirty(). Rider says "Marks target object as dirty. (Only suitable for non-scene objects)" and it's not marked obsolete or deprecated. Seems fine, right? Nope, it's been deprecated since 5.3. To their credit, the full Unity docs do reference this, but who is going to consult Unity docs for literally every Unity function they ever use, in their entire project? It should be right in the IDE. Better yet, the function shouldn't even exist! Unity 5.3 came out over 5 years ago!
I can see that's a gray area (you are kinda deprecating it by doing this) but the strict definition of deprecation probably involves a pledge to remove that feature in a certain timeframe.
I'd be much happier to bitch about the stuff Unity has officially deprecated without having a good timetable for a replacement (Networking, Real-time GI) or done a terrible job of communicating the situation (Steam VR is "not officially supported" sounded pretty apocalyptic whereas it turned out to be not quite so bad - Valve had taken over responsibility for support and their solution was released to beta with a month of the doom and gloom corporate-speak announcement)
I've always thought that that is deprecation, but I could see your argument that it's not.
Fortunately I haven't had to deal with the officially deprecated features without a clear replacement. I can imagine that would be very frustrating.
You might have to use a superseded feature because you're maintaining old code. If Unity cares about backwards compatibility (admittedly, I'm not convinced they do), they need to keep supporting and documenting the old features even as they nudge you away from them.
Honestly most of the criticisms you've gave are you not understanding how something works - like GetComponent. I do agree with you on 'null' though! And how Unity uses it. I think that decision came from them trying to make it more beginner friendly to deal with destroyed/removed objects when it first started - then they had to live with it
Perhaps you should explain how I've misunderstood GetComponent.
The best practices that have sprouted up around GetComponent say "Use GetComponent<> only in Awake(), and don't use AddComponent or RemoveComponent at all." But once you start following all these best practices, you've lost all the benefits of having GetComponent be dynamic in the first place. So just enforce it at a code level, and give me the benefits of static typechecking and compile time errors when I screw things up.
I took the time to read what you’ve written. Just about every single point you made in that essay can be distilled to “Web developer with strong convictions about Web software engineering and expecting game development to look like familiar territory,” with only a couple exceptions. I read that essay and I walk away with “that person is going to have a hard time if they pursue professional game development,” not the intended conclusion you had about Unity’s lackings. That’s reflected in nearly every concern about Unity expressed in this thread because this is a Web forum.
Unity has deficiencies we are all aware of in the industry, but none of them are in your essay. Several of your points are misunderstandings, several are just wrong, and all of them paint a picture which also gives a lot of AAA shops pause about hiring Web folks (and that I’ve had to deal with): there’s a pretty strong strain among the Web industry of “if you don’t do software like FAANG does, you’re doing it wrong and your stuff is terrible.” Meanwhile, the stuff you call bad/terrible/worse is generating billions in revenue and employing thousands. Seriously, Unreal is worse than Unity? Nearly stopped reading there.
I’m reminded of a friend who does control development for factories and had someone come in straight from a Google internship who started trying to reimplement SCADA from first principles using Kubernetes. The Web is one way to do software engineering. There are others, and one of those others is reflected in the design of Unity.
Doubly so for an industry that still has high-profile, highly funded projects (Battlefield V, Anthem... etc) flounder because of technical debt and poor tooling. (And yes, these issues are all downstream of awful management for those particular projects, but that doesn't change the technical side of things!)
I'm not a game developer, but I like to keep an eye on how its done specifically because it is fundamentally different from how I typically do things in SAAS / mobile app land. Its a good way to get a broader view on development, and I learn new things _constantly_ by looking at game development.
I accept that Unity and Unreal Engine are doing fine financially and will probably continue to do so for a long time. That's no reason that they can also have issues.
> Several of your points are misunderstandings, several are just wrong
Like I said, I'd be happy to hear ways that I can improve. You saying that I am wrong but not providing specifics makes me feel bad without a way to improve my thinking.
> “that person is going to have a hard time if they pursue professional game development,”
You're passing judgement on my professional abilities, which makes me feel pretty bad. It's also an ad hominem: you've stopped attacking my argument and you've started attacking my professional character.
> “if you don’t do software like FAANG does, you’re doing it wrong and your stuff is terrible.”
Is it really necessary to include the thing about FAANG? I'm not even employed by FAANG. To me it feels like you're casting me out to be a FAANG elitist, which feels pretty alienating. It's also an ad hominem: you've stopped attacking my argument and you've started attacking me as a FAANG employee.
> all of them paint a picture which also gives a lot of AAA shops pause about hiring Web folks
Is the absolute "all of them" really necessary? That you dismissed every one of my points is pretty rough. Can you imagine if you wrote a 4000 word post and someone said "yeah I read it and every point you made gives me pause." and that's all they said, no further explanation? You'd probably be pretty frustrated, wondering what could possibly be wrong, but having no clue with which to even start understanding their different perspective.
> I’m reminded of a friend who does control development for factories and had someone come in straight from a Google internship who started trying to reimplement SCADA from first principles using Kubernetes.
You're comparing me to a friend that overengineers things. If you have specific things you think I'm overengineering, I'm happy to hear them, but a comparison like this without any concrete steps makes me feel bad without providing me a way to improve.
I was not accusing you of overengineering, I’m not accusing you of working for FAANG (I don’t even know you, come on), I was making the point that people default to where they’re comfortable, and if you’re going to put yourself in a a position of authority and claim that Unity is bad (and Unreal is worse), you need to be comfortable in the environment and practices in which they are intended to be used. There is a minimum level of comprehension required to criticize an implement of another profession, otherwise someone proficient in COBOL would pick up a torque wrench and ask “why is this necessary? This design is just bad.”
You used subjective indictment terms (“bad,” “worse”) to describe positions that you don’t have experience to develop. That’s fine. Elevate your argument and understand the why behind some of them. Example: we don’t give two shits about deprecations because they’re a distraction from a ship date and we ship vendored artifacts including the engine.
You selectively quoted more than one thing I said to twist a personal attack from them, by the way, but that’s your prerogative. It’s also odd to do when you’re crying ad hominem foul.
Edit: I took the time to read your essay, respond to it candidly, and we are ending this conversation with you lecturing me on tone, politeness, and productivity. Even in the face of great hems and haws I doubly endeavored to remain polite. One would be forgiven for thinking you are not approachable with criticism.
I understand your point about not elucidating the why. Thing is, I'm not an AAA developer, so often times I don't know.
All I'd like to know is a bit more on why specific points my essay were wrong. Like, if you don't think the thing about clearing the Debug window is correct, I'd like to know why that is.
FAANG literally spend billions of dollars on developer tools alone, not even including browser runtime itself. There are thousands of engineers who work full time to make web and tools both fast and easy to use. There is also tons of open source developers competing to create best tools for other developers. And let's be honest tasks that average web developer has it's not rocket science.
Gamedev is nothing like this: resources are ever limited, budgets are tights, and there is almost never ending crunch to release ASAP. Till recently every AAA company mostly used it's own tech and everything was not only proprietary, but always closed source so only papers were shared. Oh there also proprietary secret under-NDA targets called consoles where you cant just expect user to buy faster hw and more RAM. And skills you expected to have to work in AAA as C++ programmer can be more than in let's say SpaceX.
So first of all you don't see how much better gamedev tools became in last decade. Other issue is that no one gonna hold your hand and force you into best practices because all games are mostly built of hacks and if you gonna enforce some strict rules it's mean developers wont be able to get those extra FPS, or better network latency or some absolutely unsupported feature that no one ever needed before.
I don't necessarily disagree, but an interesting thing to point out here is that a lot of the inspiration for React in fact came from game engines!
The ideas around virtual dom diffs, figuring out the minimum necessary set of deltas, and only rendering those because that's the slow part, in particular.
It all depends what you are looking for in a game engine. If you want to be fast at having something nice looking on your screen , then yes Unity + asset store is great.
If you care about clean code, maintainability, elegence of concepts, abstractions, architecture, long term, etc. then Unity is very bad for that.
> video game engines move and change all the time, that is the nature of the video game industry.
No, a fast moving field is not an excuse for having a messy architecture, half abandoned features , a unintuitive UI, no planing, and puting all your budget in shiny features and marketing instead of long term robustness and coherence.
Look at Blender, they maintained coherence in fundamental concepts, architecture and UI over time yet they are in the top most amazing 3D softwares (and now 2D with grease pencil)
Unity definitely seems like it has lost sight of what made the engine rise to prominence in 2010-2015.
> I've honestly wondered a lot why Unity is successful at all
Unity was the least painful way to develop your hobby game and have it run on multiple platforms for people (artists, new game devs) who reasonably didn't want to leave a GUI.
> Why is it so hard to make a good game engine?
Really great question. I wonder if it's because the list of useful features grows so fast.
Imagine you make an engine from scratch. Great news! You have a 3D cube rendering successfully.
Now you'd like to walk around the cube. You now need a system to handle input.
Maybe you'd like to import geometry into the engine? You now need to write an import script.
Maybe you'd like a pbr shader on the cube. You've written a pbr shader, but artists don't want to edit the source of the shader. So then there's an ever expanding slider/node system as shaders get more and more complex.
Each of these small features quickly become giant wish lists filled with complexity.
One way to handle this complexity is to have a great open source community like Godot, which tirelessly develops feature and feature. In the last 10 years, the expected features of an engine have grow so large that it's hard for newcomers to compete.
In Unity it's not exceptionally easy to find the "correct" way of doing things because these engines are balls of mud, with system after system pilled on top.
Which is why we've ended up with hard to use large engines and easy to use small engines.
What made the engine rise to prominence in 2010-2015, in your view?
Jump to 2019, their networking solution, UNet is abandoned. Multiplayer is a perhaps a top feature developers/players want. A great open source library called Mirror picks up the slack, but Mirror wasn't made by Unity.
As other commenters have mentioned, easily compiling to iOS made it a clear winning choice for game app development.
Most of it is a lot more impressive than projects completed with React.
Unity has a high learning curve once you want to move away from tutorials. I believe React is the same, I kept trying to learn it but would get discouraged with the new tooling and eventually give up.
Your comparison was nonsensical in the first place, your entire take is painfully uneducated, but the comment you replied to is playing along. Then you're complaining they did?
Unity has created projects on a scale that would have failed if they were using a product that justifies hundred developer engineering departments to build crud apps with dynamic content...
> Unity to me seems like a team with a fantastic marketing department to contrast with a much weaker engineering department.
No one who has used Unity for any extended period of time would ever say this, and really this is where most people who use Unity would stop reading.
It hard to directly refute because Unity marketing was almost non-existent for years of their early success. It wasn't until they shifted to cloud based value-adds their marketing even had any teeth, and that was almost a decade after 2.0, which was where Unity really picked up it's stride
-
And that blog post, so much ignorance about the technology you're trying to bash!
You could find the answers to half your complaints by hopping on Stack Exchange or Unity Answers (yes, Stack Exchange, Unity Answers exists because there has an immense amount of knowledge that is Unity specific, and it predates Game Dev SO by years..
And half your complaints just read like someone who's used to a web framework that takes 1GB of ram if you leave it's creator's website running for too long.
Null behavior is due to the link between managed and unmanaged code, the two have separate lifecycles, so that's why it works that way. It's a reflection of the fact that a lot of what you use from Unity is written in unmanaged C++ so that you can actually do useful things with it...
GetComponent should be cached in Awake not because it's slow, but because that's common sense, you don't want to do more than you have to while the game is running. You want to be rendering at least every 16.7ms, why would you waste cycles peppering GetComponent calls everywhere?And as a bonus your complaint about missing editor references in code that's not called often becomes non-existant since your component fetch will fail immediately instead of at access
Also how old is this blog post, it's been half a decade since GetComponent didn't cache internally, and even before that it wasn't the reason for problems unless you were doing something really dumb, it was a best practice to cache, not a requirement for a performant game.
Really, for a title like "Unity is fundamentally broken" this list is almost comical. What's broken is your understanding of what it takes to make a game engine as widely useful as Unity, as confirmed by your first comment:
> why is it so hard to make a good game engine?
If you don't know why, you're in no position to be calling anything "fundamentally broken"
Traditionally, a video game has a point where development stops and is never resumed again. In the past this might have been lot check or "going gold"; today it might be a few post-release patches. There's a point where you don't keep working on your entertainment product and resources are invested elsewhere for more revenue. I think this means that the value of paying off structural technical debt might be always less than the revenue from your first month of sales. I think that changes the decision-making of management as their game's performance might be better off with a month of heroics and duct-tape rather than missing a holiday release date. I don't get the impression that profit incentives are the same with most typical web services.
There are big exceptions to this, of course. Many more games are service-based these days. I think we're starting to see them adopt more stable practices like the rest of software engineering at both big [2] and small [1] scales.
[1] https://www.youtube.com/watch?v=t9HRzE7_2Xc [2] https://www.gamesindustry.biz/articles/2017-08-04-bungies-13...
Here's another one I've had that I'll throw on the pile: video games are generally highly demanding of the CPU. They'll use every cycle they can get their hands on. Web apps, on the other hand, have a ton of downtime and generally don't need to hit 60FPS (with rare exceptions). This means that they can spend their extra cycles on better abstraction layers, like React and Redux. Using React to render a bunch of game entities would make no sense because just running the reconciliation step can take 16ms, which is your entire rendering budget.
Unity has a lot of warts like your article indicates, but it gets a huge amount of bang/buck producing a not-big-budget multi-platform title with a multidisciplined team. I think that provides a lot of value for developers; so much that it outweighs the snags involved in Unity's technical shortcomings. Unity's roadmap is probably about expanding shipability for smaller developers and why Unreal is trying to commoditize that with Godot.
I feel like Unity's "entity as a container of components, things are OO'd and there's a lot of polymorphic dispatch / existence checks / branching" is starting to feel out of fashion as of late, and the ECS approach is something folks have come around to.
I've been playing around with such an engine for a side project. Here's a quick video -- https://imgur.com/a/BcnWJha -- you can see what the in-game editor looks like + some of the physics of the game (the game and editor run both in web and natively). I think with the ECS-queries approach the code comes out to be quite ergonomic. For example, I've highlighted the logic that makes the player be obscured by objects in front of them here: https://gist.github.com/nikki93/8cc5d99e45ad74e7f1053dbef287... The game-specific code for the whole game is in that 'main.cc' file and comes out to about 500 lines. The game also includes custom inspector UIs for the 'Sprite' and 'Feet' components that are defined right in that file on line 288-314 and you can see them in the video.
I tend to agree, and I think it's something that doesn't get promoted enough as an advantage of ECS compared to cache hits and parallelism. When a programmer wants to add a new feature to a game, they can slot their system into the game's tick and avoid stepping on their peer's work as much. They won't need to edit `Entity.cs` or an inheritance tree, and it's much easier to reason about the order of updating game data per frame. It also makes code ownership and code reuse a bit easier to divide up too. I'd take an ECS system even with a performance penalty, as the organizational benefits really add up over time.
The engine code, while not up to modern C++ standards, can be pretty easily understood, modified, and then fully recompiled in just a few minutes. It's not suitable for a AAA 3D game, but it's the first engine I've found for 2D C++ development which actually helps me more than it gets in my way.
Look at MongoDB's performance since IPO in 2017 for perspective.
I know that this opinion goes against the hivemind, but I wouldn't call them weak in engineering by a long shot. They obviously made some questionable/bad decisions regarding defaults (write acknowledgements, security) in order to have a lower barrier to entry, but apart from that I've had a pretty good experience with it as a stable product and good timeframes for bug-fixes.
Unity is a stark contrast to that. The few years of using it sporadically for hobby projects has been a wild ride. Bugs/crashes seem to be everywhere, and when/if they are fixed just seem to be replaced with new ones. I don't know how full-time Unity developers can deal with that. Their speed of progress is also meh.
Overall, if they were to stick to their (mobile) gaming niche, that probably wouldn't be a problem. However it seems like they are looking to mainly grow via other industries, and with that shoddy engineering and their development pace, I don't see them making a lot of headway there.
EDIT: Never mind, I found it.
Unity and Unreal are the market leaders with approximately 15% & 25% market share respectively. Nothing else including Havok, Godot, Cryengine or Source even come close.
E.g. one of my past clients is using Viz4D for interactive architectural visualizations on their website for marketing purposes. For them that existing tool is already so integrated into their processes, and the feature set so well tailored to their industry, that I doubt Unity will be able to offer something competitive to what they have _today_ in the next ~3 years with their slow pace of development.
The MongoDB example is fascinating to me. I'd love to know why they're doing so well.
Full time I'm an SWE, and I realized the way you structure your code depends on you. Disclaimer: I didn't get VERY far and didn't make huge games so maybe things become extremely painful later on. But for learning, it's a really great tool
It's not a big deal to write an OOP engine where you just insert objects into a scene graph and each has a callback to draw itself, write a whole library of different classes for all kinds of purposes and ship it. The problem is that it's going to be much slower than a game written from scratch by a semi-competent programmer.
It's also not a very big deal to write an extremely efficient engine that will render, for example, streaming landscapes very fast and in great detail but won't render anything else nearly as well.
It's believed that neither of these would sell well even though id software has allegedly made much more money selling their specialized maze shooter engines than selling their maze shooter games. Though probably nowhere close to the money Unity/Epic makes.
Unity/Epic try to make an engine with OOP APIs in the front and optimized pipelines in the back. This is very hard and this is why they: a) don't have much competition an b) are not very good.
In my opinion, the only threat they both face is some yet unknown universal rendering technique appearing and making both obsolete. Till then, they will always have a customer base of studios who do not know/want to write their own game and not satisfied with naive OOP engines (and there used to be hundreds of those, even DirectX had one built in, called "D3D Retained Mode").
Game engines basically seem like magic if you compare them to other creative tools, being able to build and manipulate systems and tooling.
Imagine if Adobe products could work like that.
After all, Web has DOM tree as its fundamental data structure to fiddle with, while Games are just a series of objects that can orient/interact with each other however they like.
And obviously performance reason will affect abstractions as well, e.g. the Micro/Macro Kernel debate.
To say Unity isn't good enough because React is good at abstracting Web development away doesn't seem to hold too much ground in terms of logic coherence
https://bevyengine.org/news/introducing-bevy/
A lot of people with experience in React are influencing the UI design.
For example, React has a principle that components can freely be removed from the render path of their parents[1], since React (in the general case) does not allow parents to imperatively call methods on their children. Unity has no such prevention, so if you remove a child component you could be triggering a bunch of bugs when GetComponent<> calls fail to find the component you deleted.
It seems clear to me that the way that React guides the user towards avoiding writing bugs is a good strategy.
Why would we NOT compare these two? Why would we NOT say, "aha, it looks like React has a smart design that allows engineers to write code without unintentionally creating bugs, and so we should consider if something like that is possible, or perhaps think of a different way to solve this problem." Putting our heads in the sand and refusing to make comparisons between these two projects to see the similar issues that both projects run into means that Unity developers are doomed to repeat the same problems that React engineers have already solved.
[1]: https://overreacted.io/what-are-the-react-team-principles/
Unity to me seems like a team with a fantastic marketing department to contrast with a much weaker engineering department. I've tried to use Unity off and on for years and every time I spend time learning it, I regret it. I'm a full-time React developer, and the difference in engineering culture and best engineering practices between Unity and React is massive. The Unity experience is riddled with bugs, poorly-thought-out workflows, and half-finished or obsolete features. Simple tasks, more often than not, become an exercise in frustration. I've written a blog post about this[1], though it's incomplete (mostly because somewhere after writing the 2000th word I wondered why I was even using Unity at all) so I've never published it anywhere.
I've honestly wondered a lot why Unity is successful at all, and the only answer I can really come to is that their direct competition - Unreal Engine, and a few other studio-made engines like CryEngine - are even worse. (Which leads to another question: why is it so hard to make a good game engine? But that would be another thousand words, so let's not stray too far from the point...) Godot is a glimmer on the horizon, but it looks like it still needs a few years to catch up.
I also have a sneaking suspicion that Unity is successful because it is used by a lot of people as their introduction into programming, and they simply don't know that anything better is possible.
Still, I suspect that most developers who use Unity will eventually reach the same conclusion and move on, and this seems to be confirmed by the google trends graph, which has been sloping steadily downwards over the last 5 years or so[2].
[1]: https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...
[2]: https://trends.google.com/trends/explore?date=all&geo=US&q=%...