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].
Comparing a web library to game engine is a bit of a stretch.
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.
It's really not as much of a stretch as you might think.
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.
>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
I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.
You should usually only call GetComponent<> in your Awake function, then cache the result in a strongly typed instance variable. This is widely known standard operating procedure with Unity.
IDEs like Rider will highlight and warn you about using GetComponent in performance critical contexts like your Update method.
>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.
Totally and completely agree with everything you've said, but the fact that Rider - a 3rd party IDE - has to ensure all these things rather than them being baked into Unity is part of the problem.
But Unity isn't an IDE, it's a game engine. Totally different things. Better for Unity to spend their time and energy on the game engine and editor, not making yet another half-assed IDE. Developing an entire IDE simply isn't in their wheelhouse. While it's a lot easier for somebody like Rider who already has a full blown C# IDE to support Unity.
The thing is, avoiding usage of certain functions - like Find, Invoke, SendMessage, etc - does not have to be done at the IDE level. In fact, it shouldn't be, and the fact that Rider has to do these things is kind of a kludge already. These methods should be marked obsolete - or at the very least, they should have docstrings saying not to use them. Observe how the docs for SendMessage don't even discourage its use, for example: https://docs.unity3d.com/ScriptReference/GameObject.SendMess...
The Unity editor gives you compiler errors and warnings in its console window. Why shouldn’t it give you these warnings as well?
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.
I can't understand how this is the case. Unity is a game engine which keeps users mostly by instilling goodwill that it's a productive environment and is saving them time over using another engine or homebrewing one. It would therefore seem to be in its best interest to prevent them from creating bugs where possible.
That's true, but I've always thought that removing components at runtime is such a rare thing to do, and the cost of allowing it on an engine level - inability to statically verify components - is such a high price to pay that the tradeoff just doesn't make sense.
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.
Being able to add / remove components then query based on component sets an entity has is an important part of ECS data driven design, which Unity is trying to move to with eg. DOTS. Just leads to less branching etc. once your data is prepared. I'd rather just have my code express expectations upfront then query the entities that match, vs. needing to handle a combinatorial explosion of if/else based on existence checks.
Well so much for dynamic and procedural and data driven content, under your reign as Unity Czar. People use Unity for a lot more than Flappy Bird clones, you know.
Well, I would certainly hope that as my reign as Unity Czar would include guidelines for storing procedural content somewhere other than in Components :)
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.
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!
Hmmmm. Is it possible that a tutorial is deprecated without the actual feature itself being deprecated? i.e. there's no intent to get rid of AssetBundles in the near future but they don't want people who are just starting out to go down that path?
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)
Maybe we're talking about two different things? To me, once you add a new feature intended to replace an old one, the old feature should be deprecated and should eventually be removed. Even if you can use AssetBundles, there's no reason you ever should because they've been superseded.
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.
> Even if you can use AssetBundles, there's no reason you ever should because they've been superseded.
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.
Sure, but if that's the case, you should really be pushing new developers away from using the old thing and towards the new thing. Mark it obsolete in the editor. Update your docstrings to point towards the new thing. Maybe even give me a warning in my console if it's really serious.
The 'Addressables' are a abstraction layer on TOP of AssetBundles. AssetBundles aren't deprecated.
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
If X is built on top of Y, and I should generally be using X, then the docs for Y should absolutely say that. Burying that away in some hard-to-find tutorial is not good practice. We could argue for a while over the exact semantic meaning of 'deprecate' and whether Y is truly deprecated if 99% of the time when you use it you should really be using X instead. But I'd hope that we can both agree on the central point of my argument here, which is that in Unity it's often incredibly difficult to figure out which of 5 vaguely-similar-looking APIs you should be using, and it's a bad sign when the best source of info is a "coming soon!" message on an out-of-date tutorial not even linked from the documentation.
Perhaps you should explain how I've misunderstood GetComponent.
The whole purpose of using 'GetComponent' in code is to get the component reference at runtime. Saying it's a problem that it doesn't statically verify it exists, doesn't make any sense
I understand that GetComponent is a runtime lookup, and what I'm arguing is that Unity made the wrong choice. Runtime lookups lead to more bugs. They lead to slower code.
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.
AAA here. Actually, it is a stretch, because you’re expecting an entirely different discipline of software development to reflect the trends, knowledge, and assumptions of your discipline. We are a CryEngine shop but I’ve used Unity extensively for MVP pitches, spec work, and side projects. I also left the Web vertical to do this so I still have context from your side as well.
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.
Game programming isn't—or at least shouldn't be—so different from other fields that fundamental software engineering principles do not apply. It seems like discarding criticism just because it comes from outside the immediate industry is going to lead to an insular culture and get in the way of any real change or progress.
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!)
This goes in the other direction too: other fields can and should borrow ideas from game programming. At the end of the day the goals of different software projects are pretty comparable: we all want to produce quality code, minimize bugs and do it as quickly and productively as we can. The details and trade-offs aren't identical, to be sure, but at the end of the day different programming fields are far more alike than not.
Sure theres similarities, but game programming is usually at the bleeding edge of computing compared to most other areas. Its like saying engineering a space craft isn't/shouldn't be different than engineering a car. Sure, there's overlap, but the fundamental requirements differ so much that a lot of it is _not_ applicable.
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'll happily hear examples of things which are "misunderstandings" or "just wrong". As your post stands, it's nothing more than a long extended ad-hominem - it roughly boils down to "your post is wrong, but I'm not going to tell you why."
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.
Quote one sentence where I attacked you personally. I was quite careful to speak about your essay and its conclusions from the perspective of the intended audience, and if you think I’m going to engage after having that called an ad hominem, you don’t really understand the investment of time that would entail and why I’m strongly disincentivized.
A few quotes that I found particularly rough include:
> 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.
Perhaps your error is marrying yourself to your creative output and taking criticism thereof personally. Your essay is all over the place and plays a tune many folks in AAA have heard from many folks who got their start in Web development, and I was illustrating the broader context that, again, makes your intended audience develop that conclusion. Honestly, it reads like a projection of your expectations of software development, and that’s what I’m trying to tell you.
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.
I'm too lazy to write 1000 word essay from my phone, but having a bit of experience in both webdev and c++ gamedev on custom engine I certainly can say one truth here.
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.
> Comparing a web library to game engine is a bit of a stretch
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 may be your opinion, but after having used Godot I think Unity is horrible to develop with.
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.
It was easier to learn than the alternatives (UDK, any of the Java engines) and consistently added clearly useful features.
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.
I hear you that Unity has created some great projects, but that's kind of like saying that C is a better language than your favorite language because C was used to write Linux and your favorite language has never made any project that impressive.
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"
My biggest thought about game programming not necessarily having the same engineering culture as the web is due to the financial/business incentives for various engineering practices. I think React and a lot of other web tools are designed for programmers creating services that continually operate and generate revenue. Meanwhile, a video game's development is closer to a theatre production or a film.
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.
That's a really interesting thought. It makes a lot of sense.
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.
My general suggestion for programmers trying to understand something strange or seemingly odd in the games industry is to check for an economic/value incentive rather than a technical one.
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.
That point (keeping interactive rates) is basically one of the most important factors driving the architecture of game engines. I found this talk to be quite a good one regarding architecture for game engines (it's about the ECS in Overwatch): https://www.youtube.com/watch?v=W3aieHjyNvw
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 think with the ECS-queries approach the code comes out to be quite ergonomic.
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.
Glad to see some agreement there. I'm interested in building an ECS-based approach for a UI system at some point. The Yoga layout engine (implements flexbox -- https://github.com/facebook/yoga/tree/master/yoga) seems to actually be pretty amenable to just incorporating as a `Layout` or `Flex` component, then you could have components for platform-specific renderings (eg. `iOSTextInput`, `AndroidTextInput`, `DOMTextInput` in wasm, ...) that could read from cross-platform common components (`TextInput`). A core aspect would also be a `Hierarchy` component that just has a parent entity id and a list of child entity ids (that it keeps in sync properly). Then bind things to JS and allow you to code it from React, while still being able to eg. run an animation thread for some specific animations that just queries and reads/writes the `Layout` and `AnimationSpec`s etc. Interesting talk re: data oriented design for a webby animation engine here actually: https://youtu.be/yy8jQgmhbAU?t=620
I've been using Godot lately, and while it has many flaws (an over-reliance on strings as identifiers, for example), I think the fundamental design is sound and easy to work with: everything is a node in a scene tree.
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.
To provide more color to the parent comment, the scope of React vs the scope of Unity is several orders of magnitude different. (In fact, I've seen games that use React inside to manage their UI layers.)
After watching how many SaaS companies with "weak" engineering have soared to astronomical valuations, I would say I'm quite bullish on Unity (as a stock), irrespective of what developers think. At the end of the day, fantastic marketing is what gets CXO's and decision makers to buy-in.
Look at MongoDB's performance since IPO in 2017 for perspective.
> 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.
Well, who are the other leaders in the industry? Is there any other major player besides Unity and Unreal? (I'm not overly familiar myself?) What's their respective market share?
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.
Not the _other leaders_ in the industry, but the leaders in the _other industries_ they are pushing into, like architectural/automotive/simulation visualization. In each of those they have to face very different competitors with very different feature sets.
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.
It's because generally, software developers don't have to deal with the downsides of MongoDB, ops people do. At a lot of companies it seems to be mostly developers picking technologies, so especially if they're inexperienced then they tend not to consider the other side of their decisions.
Alternatively, I found Unity super intuitive and straightforward when learning game dev. I was doing some random 2D platformer tutorials on udemy, along with a bunch of others and I always thought it was almost..easy to build that kind of game. I'm sure 3D is a different beast.
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
From my experience of shipping a few AAA games: a universal game engine will always be suffering from trying to balance efficiency vs universality.
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").
Weirdly enough I got into Unity to give myself a break from the waking nightmare that front-end development seemed to be turning in to. I still dabble in back-end Django and a bit of framework-free front-end but I've been enjoying Unity/C# for non-commercial projects.
I don't think React vs Unity is the debate that we all cant wait for it to happen?
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
Very excited about Bevy. Course, if Godot is young, then Bevy is practically a newborn. :-) Still, I resonate very strongly with a lot of things that the Bevy authors care about.
sorry mate, most of these complaints come from a bunch of misunderstandings, mostly "this is not how I'd do things." Worse is saying you come from web then explaining why this engine running a completely different domain is "bad." Think you don't understand why web is the way it is and how many levels of complexity you're missing.
How can the people replying to you be so fucking stupid? My god, OP isn't comparing React and Unity at a code level. He's comparing the engineering culture surrounding the two pieces of software.
I've found nerds can be extremely literal about analogies when the two things being compared don't line up in every respect. Kinda misses the point of analogies.
Why not? It's easy to learn from the things that React does right and compare to see if Unity also does them right, or not.
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.
They were the first commercial game engine to offer iOS support and this pretty much cemented their place in the market. Unreal used to cost upwards of 6 figures to license per game and this left indies nowhere left to go.
Godot shows a lot of promise and has been steadily growing its userbase over the years, but its MIT license makes it really difficult to export to close source platforms and ultimately most devs want their games on consoles which are notoriously closed behind NDA's and other legalese. https://docs.godotengine.org/en/latest/tutorials/platform/co...
I don’t see how that’s caused by their choice of license. I read your link, there is nothing related to their license either. MIT is permissive, as far as I know it is commonly used by 3rd party libraries for games, even on consoles.
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=%...