12 ms·

I'm quite bearish on Unity in the long run. Unity to me seems like a team with a fantastic marketing department to contrast with a much weaker engineering depa

by johnfn 6y ago

I'm quite bearish on Unity in the long run. 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-e3b1474e7afb42bdb05cadcd3c2dbd77 https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af... [2]: https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F0dmyvh https://trends.google.com/trends/explore?date=all&geo=US&q=%...

volkk 6y ago
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
- nabla9 6y ago
  Is Unity still "Easy to build, impossible to maintain", always breaking code after you upgrade?
  - ezconnect 6y ago
    Yes, that's why you can have different versions of it on your development PC and run the version you are using.
OneGuy123 6y ago
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.
- davnicwil 6y ago
  > 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.
- johnfn 6y ago
  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. 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-e3b1474e7afb42bdb05cadcd3c2dbd77 https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...
spyke112 6y ago
Why on earth would you compare Unity to React?
- Pfhreak 6y ago
  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.)
- johnfn 6y ago
  Again, I'm talking about the engineering culture fostered by the two projects. I'm not literally comparing a game engine to a web rendering library.
- tutino 6y ago
  Not comparing Unity to React. Comparing Unity's culture, management and engineering to the ones of React.
adamnemecek 6y ago
Unity is nothing like react.
- johnfn 6y ago
  Again, I'm talking about the engineering culture fostered by the two projects. I'm not literally comparing a game engine to a web rendering library.
  - deleted 6y ago
    [deleted]
  - adamnemecek 6y ago
    Right however Unity is much more complex so it's not a fair comparison.
    - johnfn 6y ago
      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. [1]: https://overreacted.io/what-are-the-react-team-principles/ https://overreacted.io/what-are-the-react-team-principles/
- iaml 6y ago
formalsystem 6y ago
If you go through this list https://store.steampowered.com/curator/31285130-Unity-Engine-Games/ https://store.steampowered.com/curator/31285130-Unity-Engine... 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.
- johnfn 6y ago
  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.
  - BoorishBears 6y ago
    What? 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"
synaesthesisx 6y ago
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.
- johnfn 6y ago
  Honestly, that's a good point. As an engineer I can definitely get a little too focused on the engineering side of things. The MongoDB example is fascinating to me. I'd love to know why they're doing so well.
  - bcrosby95 6y ago
    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.
- hobofan 6y ago
  > 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.
serverholic 6y ago
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.
- johnfn 6y ago
  Lol, thanks.
- TillE 6y ago
  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.
ingenieros 6y ago
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/consoles.html https://docs.godotengine.org/en/latest/tutorials/platform/co...
- dgellow 6y ago
  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.
andybak 6y ago
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.
TillE 6y ago
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.
abj 6y ago
> I'm quite bearish on Unity in the long run 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.
- appleflaxen 6y ago
  > Unity definitely seems like it has lost sight of what made the engine rise to prominence in 2010-2015. What made the engine rise to prominence in 2010-2015, in your view?
  - abj 6y ago
    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.
deleted 6y ago
[deleted]
whywhywhywhy 6y ago
>why is it so hard to make a good game engine? 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.
danbolt 6y ago
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. [1] https://www.youtube.com/watch?v=t9HRzE7_2Xc https://www.youtube.com/watch?v=t9HRzE7_2Xc [2] https://www.gamesindustry.biz/articles/2017-08-04-bungies-13-year-battle-to-kill-crunch-culture https://www.gamesindustry.biz/articles/2017-08-04-bungies-13...
- johnfn 6y ago
  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.
  - nikki93 6y ago
    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 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 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/8cc5d99e45ad74e7f1053dbef2874e56#file-main-cc-L195-L213 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.
erlend_sh 6y ago
If you’re interested in Rust, you might like Bevy: https://bevyengine.org/news/introducing-bevy/ https://bevyengine.org/news/introducing-bevy/ A lot of people with experience in React are influencing the UI design.
- johnfn 6y ago
  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.
pandaman 6y ago
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").
tanilama 6y ago
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
gloryless 6y ago
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.

by johnfn 6y ago

volkk 6y ago

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

nabla9 6y ago
Is Unity still "Easy to build, impossible to maintain", always breaking code after you upgrade?
- ezconnect 6y ago
  Yes, that's why you can have different versions of it on your development PC and run the version you are using.

OneGuy123 6y ago

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.

davnicwil 6y ago
> 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.
johnfn 6y ago
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. 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-e3b1474e7afb42bdb05cadcd3c2dbd77 https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...

spyke112 6y ago

Why on earth would you compare Unity to React?

Pfhreak 6y ago
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.)
johnfn 6y ago
Again, I'm talking about the engineering culture fostered by the two projects. I'm not literally comparing a game engine to a web rendering library.
tutino 6y ago
Not comparing Unity to React. Comparing Unity's culture, management and engineering to the ones of React.

adamnemecek 6y ago

Unity is nothing like react.

johnfn 6y ago
Again, I'm talking about the engineering culture fostered by the two projects. I'm not literally comparing a game engine to a web rendering library.
- deleted 6y ago
  [deleted]
- adamnemecek 6y ago
  Right however Unity is much more complex so it's not a fair comparison.
  - johnfn 6y ago
    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. [1]: https://overreacted.io/what-are-the-react-team-principles/ https://overreacted.io/what-are-the-react-team-principles/
iaml 6y ago

formalsystem 6y ago

If you go through this list https://store.steampowered.com/curator/31285130-Unity-Engine-Games/ https://store.steampowered.com/curator/31285130-Unity-Engine... 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.

johnfn 6y ago
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.
- BoorishBears 6y ago
  What? 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"

synaesthesisx 6y ago

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.

johnfn 6y ago
Honestly, that's a good point. As an engineer I can definitely get a little too focused on the engineering side of things. The MongoDB example is fascinating to me. I'd love to know why they're doing so well.
- bcrosby95 6y ago
  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.
hobofan 6y ago
> 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.

serverholic 6y ago

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.

johnfn 6y ago
Lol, thanks.
TillE 6y ago
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.

ingenieros 6y ago

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/consoles.html https://docs.godotengine.org/en/latest/tutorials/platform/co...

dgellow 6y ago
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.

andybak 6y ago

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.

TillE 6y ago

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.

abj 6y ago

> I'm quite bearish on Unity in the long run 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.

appleflaxen 6y ago
> Unity definitely seems like it has lost sight of what made the engine rise to prominence in 2010-2015. What made the engine rise to prominence in 2010-2015, in your view?
- abj 6y ago
  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.

deleted 6y ago

[deleted]

whywhywhywhy 6y ago

>why is it so hard to make a good game engine? 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.

danbolt 6y ago

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. [1] https://www.youtube.com/watch?v=t9HRzE7_2Xc https://www.youtube.com/watch?v=t9HRzE7_2Xc [2] https://www.gamesindustry.biz/articles/2017-08-04-bungies-13-year-battle-to-kill-crunch-culture https://www.gamesindustry.biz/articles/2017-08-04-bungies-13...

johnfn 6y ago
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.
- nikki93 6y ago
  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 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 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/8cc5d99e45ad74e7f1053dbef2874e56#file-main-cc-L195-L213 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.

erlend_sh 6y ago

If you’re interested in Rust, you might like Bevy: https://bevyengine.org/news/introducing-bevy/ https://bevyengine.org/news/introducing-bevy/ A lot of people with experience in React are influencing the UI design.

johnfn 6y ago
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.

pandaman 6y ago

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

tanilama 6y ago

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

gloryless 6y ago

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.