Support NeoGAF

[Durante]

There has been a lot of discussion of the Unity engine here on GAF in the past, culminating in the position by many that a game using Unity is bad news for its performance unless proven otherwise. I've personally contributed to that, and simply judging by many of the results created using the engine it's hard to see it as a positive indicator.

For the past week or so, I've made a small VR game prototype with the latest version of the engine -- I initially only started experimenting with it because I wanted to try Valve's "The Lab" renderer (and it does provide spectacular image quality results). Anyway, while working with it I have come to the conclusion that you could attribute at least some of the frequent issues with Unity games to it being extremely successful at what it does. This probably seems counter-intuitive, so let me try to explain. I see one of Unity's overarching goals as providing a toolset which is easy to use even for non-experts -- a very admirable goal, which has been achieved to at least some extent and has democratized game development, something which we can probably all agree on being a net positive.

However, if you succeed in making a game engine non-experts can use, then what you will get are non-experts using your game engine. And if you do so for multiple years, you will in fact engender a user community which contains a large number of people who might have no formal training but a deep understanding of the toolset, and who propagate "best" practices to subsequent generations of newcomers. This can happen either directly through code (in one of the thousands of easy-to-import packages on the asset store), or just through advice.

As an example, obviously when you use a new toolset you will be googling a lot for answers to some questions as to its usage. I did the same, and one great thing about using a really popular tool is that you can quickly find a whole lot of answers to most common and even not-so-common questions. However, a few of the marked and highly upvoted answers I found were really bad. I could tell that they were bad because I've spent a lot of my life studying algorithms and data structures, but if a newcomer just trying to make their game idea work happens upon those answers, why would they not implement them? I don't think anyone can blame them -- and I wouldn't really blame the people providing the answers either, they just wanted to be helpful. For that reason I also don't want to go into too much detail here that would identify individual threads, suffice it to say that e.g. some of the ways proposed for storing and retrieving references to data are at best O(log(N)) when they could be O(1).


All that said, there's no doubt in my mind that many of the decisions in the Unity framework were made for (perceived) user convenience first, with stable large-scale software engineering being a secondary concern. But now I believe that those (all the way from the language choice to the propensity of liberally using string literals to identify objects and code) alone don't fully account for some of the issues encountered with Unity games, and that there is also a significant systemic (and not system ) component to it.

I guess how you could read this as a gamer is that just because some new project by a well-established developer is using Unity does not necessarily mean that it will be troubled -- if they know what they are doing they probably won't immediately forget all of it because they started using a different engine. Conversely, is something uses Unity then (because it is such a good tool) there isn't really the "guarantee" that you had when a game was released before when such tools were unavailable or uncommon -- the guarantee that the developers involved had at least the level of technical know-how that is required to build the basic fundaments of e.g. a 3D game. That barrier is greatly reduced.

 

[Greatest Ever]

Eh, the engine may suck, but I just wait for Durante to fix it.

 

[OldRoutes]

I'd say this has nothing to do with the Engine and more to do with the community.

If you had found those issues in the official tutorials, I'm sure Unity would be more than happy to make the changes.

 

[jooey]

phew good thing unreal isn't successful

 

[sinxtanx]

I use Unity professionally for game development

shit's gotta be wrangled hard to get good results

 

[tuxfool]

The issue here is that there are plenty of seasoned developers that have made games that perform badly.

I'll use Firewatch as an example. Most of that team has used a variety of engines and worked on a variety of games large and small. They seemingly landed on a smart way of developing their game, yet in the end it still did not work all that well. I'd say bad advice is only one aspect of where there may be potential failure.

 

[Durante]

I'd say this has nothing to do with the Engine and more to do with the community.

I don't fully agree with this, although I do thin the community is part of it.

It's not that it has "nothing" to do with the engine exactly, but that a lot of the results people are seeing and complaining about are not necessarily direct results of a lack of capability in the engine.

 

[Visualante2]

Even in some of the tutorials from Unity evangelists you see them using things in really hacky ways that ultimately break in later versions or become glitchy. This isn't to show how things are best done, but rather to show a wide range of tools. But these become standard.

I spent months making a prototype for using SendMessage because that's all the basic tutorials taught, instead of actually writing a C sharp function call.

I get the impression Unity thinks their users would behave in a certain way anyway, so they are going ahead and bringing everything under one roof (assets, community, recruiting) to save people time. And I think there's something to be said about going to Google, evaluating what is out there, how things are done differently in different engines and then deciding for yourself how to best do it with the tools you have.

 

[Tain]

Awesome post, and it's nice to hear that a lot of the performance issues that I've been assuming are part of the foundation of Unity may actually not be.

As someone that's been using and loving UE4 since release but doesn't have a ton of experience in Unity, I'd love to hear your thoughts on how the two compare.

 

[Durante]

phew good thing unreal isn't successful

Unreal is, but Unreal also doesn't have a huge existing community built primarily on the premise of "easy game development".

Unreal also, and this can not be underestimated, is less likely than Unity to provide you with an "easy" way to accomplish something that will subsequently perform terribly. That's what I was getting at with the "there's no doubt in my mind that many of the decisions in the Unity framework were made for (perceived) user convenience first, with stable large-scale software engineering being a secondary concern" part. In UE4, these goals are weighted differently.

 

[Jobbs]

Unity is a great engine. It's a miracle. Anyone who thinks it's bad because people make bad games on it should also bemoan Photoshop for people making bad art

Ori and the Blind Forest was made using unity. The engine is just a tool, it can't guarantee you make something good with it. That reasoning is asinine.

 

[ZeroX03]

However, if you succeed in making a game engine non-experts can use, then what you will get are non-experts using your game engine.

Damn if that isn't true for RPG Maker. Years of being readily available for amateurs to make games quickly using provided assets (so generally crap) gave it a poor reputation. Now that it's finally evolved into a much stronger tool for making a specific kind of game pretty damn well and deploy to multiple platforms, it's still immediately dismissed on reputation alone.

 

[Durante]

Awesome post, and it's nice to hear that a lot of the performance issues that I've been assuming are part of the foundation of Unity may actually not be.

As someone that's been using and loving UE4 since release but doesn't have a ton of experience in Unity, I'd love to hear your thoughts on how the two compare.

I've used both to at least make playable prototypes now, and I'd say that the difference is quite fundamental.

Unity is a framework which was created for the purpose of making the development of smaller-scale games as painless and appealing as possible, and then improved and iterated upon to also support larger-scale development. However, the goal of developer convenience remained paramount throughout.

UE4 was developed from the ground up to be a high-performance engine, with literally decades of experience creating such engines influencing its design. Once that goal was achieved it was then attempted (with quite impressive success) to make it as easy to use as possible.

I think one way these differences manifest most clearly is in the separation between "core" programming and "design" work which is very straightforward and demarcated in UE4, and basically doesn't exist in Unity. I think this clearly goes back to the expectation that underlies UE that you have a team with dedicated programmers who will work in C++ and provide functionality to dedicated designers and artists working with other tools (and the game-specific tools implemented by the programmers). In Unity, on the other hand, it seems very natural for a designer to attach some script to an object to achieve some purpose -- the same way a programmer would ultimately interact with and see the engine.

Unity is a great engine. It's a miracle. Anyone who thinks it's bad because people make bad games on it should also bemoan Photoshop for people making bad art

Ori and the Blind Forest was made using unity. The engine is just a tool, it can't guarantee you make something good with it. That reasoning is asinine.

True, but I think it's fair to recognize that a tool can inherently favor (or discourage) bad practice -- especially since game development is both art and engineering.

 

[LordRaptor]

I've defended Unity before and will continue to do so, because I think the benefits of democratisation of game development vastly outweigh any possible negatives, but there's all sorts of factors at play unrelated to the engine.

This gens consoles really cheaped out on their CPUs - to the extent that mid-life upgrades are incoming, which is basically unprecedented - and the multi-core paradigm (for whatever reason) never really took off in gaming, which is where most of the vitriol from console owners towards it comes, because I think a lot of people don't want to acknowledge that their expensive new console has worse single cpu performance than last gen consoles had.

Unity also inherits much of its features and sensibilities from its original design (as in fact Unreal does) which is primarily as a mapping tool for Level Designers with the capabilities for scripted events - you can see newer tutorials and functionality moving further and further from this purpose, but that's what Unity was originally built to do; make levels for third person games. The prevailing concepts of attaching things within the editor window and its support for things like javascript make a lot more sense when you look it as a tool for level designers, not for coders.

 

[johnvr]

nailed it.

 

[sinxtanx]

legitimate complaint: Unity does not expose all of its functionality to the scripting layer

I'm looking at you, ParticleSystem

 

[James Coote]

Really depends on the game. Some just don't tend to push a system to its limits simply by their design. But for sure, at some point, you can't optimise any further due to Unity being a bit of a black box.

I'm making a Unity game for Wii U at the moment, and when I recently swapped out all the placeholder art for the "final" assets, performance tanked. I know the game logic underneath is taking only a tiny fraction of the time it takes to render.

Now I need to decide if I redesign the levels just for Wii U (less open spaces, fewer high poly models), or cut features, or cut effects, or redesign assets. Or even drop the platform altogether. I wouldn't say though, that it's inherent to Unity, nor a case of amateur developers. There are a number of low framerate UE4 games on the Wii U, but I can't really resent the devs for at least trying to get their games on a platform that doesn't really support the engine.

Ultimately, the decision to support X platforms using Y engine, given Z scope and game design is a project management decision.

 

[M3d10n]

I was spoiled during my years working with Torque Game Engine (and modifying the shit out of it) thus I can't help feeling powerless when working with Unity and its lack of source code access, so UE4 was a blessing for me, despite the 5% fee.

 

[Kyuur]

It's really no different than people developing games using garbage-collected languages because its easier than learning how to manage memory. I wouldn't really call it a 'victim' though. The subsection of people who will avoid games due its use is already so niche that your game probably either doesn't appeal to those people in the first place or is large enough that the hit doesn't particularly matter.

 

[Durante]

legitimate complaint: Unity does not expose all of its functionality to the scripting layer

That absolutely is a legitimate complaint.

I'd go further and say that in the face of the alternatives available today, the simple fact that "normal" users get no full source access is already a legitimate complaint.

Edit:

I was spoiled during my years working with Torque Game Engine (and modifying the shit out of it) thus I can't help feeling powerless when working with Unity and its lack of source code access, so UE4 was a blessing for me, despite the 5% fee.

Exactly.

 

[sinxtanx]

and Input!

uuuugh who did that WHO DID THAT

they're at least in the process of making a new input system based on the same philosophy they used for upgrading their Network system; one low-level api, one high level api that uses the low-level api, as it should be

 

[BiggNife]

However, if you succeed in making a game engine non-experts can use, then what you will get are non-experts using your game engine

Yup, exactly.

I don't think Unity is a bad engine, and I think the fact that it's accessible to amateur/novice game devs is awesome. But that also means you're going to get projects made by amateurs and novices that probably aren't well optimized.

It reminds me a whole lot of the whole "ugh, it looks like a Flash game" stigma from the early 2000s. Flash was very often associated with games that had god-awful art and/or terrible animation, but stuff like Canabalt and WinterBells proves that you can make Flash games that don't look/feel amateur.

Likewise, the fact that something like Ori was made in Unity with pretty much zero performance issues is proof that not all Unity games are doomed to be buggy messes.

 

[jasminlovesyoux]

I think the OP hit the nail on the head. The framework is easy enough to use but if theres a performance issue some devs may not know how to fix it.

 

[Durante]

It's really no different than people developing games using garbage-collected languages because its easier than learning how to manage memory. I wouldn't really call it a 'victim' though. The subsection of people who will avoid games due its use is already so niche that your game probably either doesn't appeal to those people in the first place or is large enough that the hit doesn't particularly matter.

I used "victim" more for its reputation in the small group of ultra-enthusiast, not because I imagine that there's any real financial repercussions to it for games. And Unity is clearly very successful financially.

 

[eot]

As you say, these are inherent issues with the type of functionality that Unity aims to provide. You see it in any accesible commercial grade tool: the majority of the user output will be garbage. Better learning resources is always a good idea, but ultimately people are going to want to make their games with as little effort as possible and becoming a skilled programmer takes years. I guess the real problem is when people do things in ways that are literally orders of magnitude slower and completely ruin their performance.

 

[Haly]

I think it might bother people with actual training in computer science but it seems like it wouldn't matter in the long run. Who really cares if Unity indie game #4256 is optimized poorly? Chances are it won't tax most modern rigs.

The case might be different for Unity games released to mobile, however.

 

[Durante]

I think it might bother people with actual training in computer science but it seems like it wouldn't matter in the long run. Who really cares if Unity indie game #4256 is optimized poorly? Chances are it won't tax most modern rigs.

The case might be different for Unity games released to mobile, however.

I feel like that's understating the problem. There have been at least a handful of Unity games released on consoles with severe performance issues, and dozens more which performed worse than they should. The same even happened (to a less severe extent) on PC.

That's where the general impressions of the engine come from, and those observations are valid.

I guess the real problem is when people do things in ways that are literally orders of magnitude slower and completely ruin their performance.

Exactly. Unity might be "inherently" 30% (or 20%, or even 50%, the exact number doesn't matter for the argument) slower than e.g. UE4 for some scenario, but that really wouldn't matter for most any Unity release. It starts to matter when important features are implemented in an algorithmically worse fashion

 

[M3d10n]

A skilled dev could sidestep a lot of performance problems by offloading a lot of logic to a C++ plugin, but that throws a lot of the convenience out of the window.

It's really no different than people developing games using garbage-collected languages because its easier than learning how to manage memory. I wouldn't really call it a 'victim' though. The subsection of people who will avoid games due its use is already so niche that your game probably either doesn't appeal to those people in the first place or is large enough that the hit doesn't particularly matter.

I think when Durante says it's a "victim" he means the large amounts of non-experts propagate bad practices and thus can hinder the development of other developers who work solely with Unity, because it makes it harder to locate good advice. This is specially hard on those starting on VR games, which require high performance.

 

[laxu]

You have to remember that no matter the platform, framework or language, most of the people using it are not going be great programmers. The majority won't even be good programmers. Game programming generally requiresa lot of knowledge so it's no wonder there's plenty of stuff out there that doesn't work or perform well.

I'm a web developer and if/when I find the time to make a game, I'd probably pick up Unity simply because I feel it is going to be more accessible than the competition so I would be able to get a game running without tons of initial effort. As I get further I'll probably find stuff that is not as easy to use or understandable as it could be but that happens with every framework when you get to very specific use cases.

 

[Purple Cheeto]

I would say it's a combination of a lot of amateur developers using it with no understanding of the internal workings of the engine (I cringe at every foreach loop I see), the fact that the source code to the engine isn't available, Unity's continued reliance on an old ass version of Mono (because of their falling out with Xamarin) and Unity over extending them selves on the number of supported platforms. The engine is constantly behind on updates for all the different hardware they support.

 

[Haly]

I feel like that's understating a the problem. There have been at least a handful of Unity games released on consoles with severe performance issues, and dozens more which performed worse than they should. The same even happened (to a less severe extent) on PC.

I forget there are Unity games on consoles now. I can see how that would be a problem.

Maybe Unity should start introducing prepackaged, optimized algorithms/structures that can be adapted for different use cases? I haven't touched it in a while and don't know if they already do this.

 

[LordRaptor]

Unity's continued reliance on an old ass version of Mono (because of their falling out with Xamarin)

It's more likely its still using older MonoDevelop as a result of more pressing business concerns that need fixing first; deprecation of NPAPI plugins killing webplayer, Apple dropping OGL in favour of Metal are two pretty obvious ones.

Bear in mind the vast majority of Unity games are in the mobile and web space, not the desktop or console space and why continued IOS support is treated as a top priority makes a lot more sense.

 

[M3d10n]

About the source code, I doubt Unity's source can be made available to normal licensees without major hurdles. Back in the UDK days, you didn't get source code access unless you paid large sums of money (like Unity nowadays) since the UE3 source code depended on 3rd party licensed code for many features (Scaleform, for example).

It was made possible in UE4 because it was re-written with that objective in mind, shedding away all 3rd party dependencies that could require additional licensing fees. Unity would need to go through such a rewrite before source code could be made available for all.

A middle road would be to split some core components into C++ plugins and offer the source for those.

 

[arit]

I forget there are Unity games on consoles now. I can see how that would be a problem.

Maybe Unity should start introducing prepackaged, optimized algorithms/structures that can be adapted for different use cases? I haven't touched it in a while and don't know if they already do this.

That would still require the knowledge to decide when and why to use said optimized structures, which would then probably still lead to pollution of the accessible knowledgebase.

 

[Purple Cheeto]

I forget there are Unity games on consoles now. I can see how that would be a problem.

Maybe Unity should start introducing prepackaged, optimized algorithms/structures that can be adapted for different use cases? I haven't touched it in a while and don't know if they already do this.

They don't, and the over head in using mono and certain data structures is a huge part of the performance issue on console. I saved 30ish ms on the game I'm working on by replacing a part of code that was constantly creating new arrays, resulting in garbage collector calls every time it got hit. This code shipped on multiple mobile phone games without it being considered an issue.

It's more likely its still using older MonoDevelop as a result of more pressing business concerns that need fixing first; deprecation of NPAPI plugins killing webplayer, Apple dropping OGL in favour of Metal are two pretty obvious ones.

Bear in mind the vast majority of Unity games are in the mobile and web space, not the desktop or console space and why continued IOS support is treated as a top priority makes a lot more sense.

This just goes back to my point that Unity is over taxes on the number of platforms they're supporting. The documentation and samples for XBox One are abysmal right now and only marginally better on PS4.

 

[_machine]

The issue here is that there are plenty of seasoned developers that have made games that perform badly.

I'll use Firewatch as an example. Most of that team has used a variety of engines and worked on a variety of games large and small. They seemingly landed on a smart way of developing their game, yet in the end it still did not work all that well. I'd say bad advice is only one aspect of where there may be potential failure.

As a developer, this is an argument I can't agree with.

Just because Campo Santo has very seasoned veterans, that do have experience in optimization of their respective areas of expertise, doesn't mean that they possess the total skillset of a AAA developer like EA or have the resources and priorities necessary to match the performance of their previous work. Ultimately, as an indie developer you are much, much more likely to be concerned about getting the game done, matching your gameplay vision (or just vision of the product), surviving the production of the game than ensuring a very polished technical experience. That, to me, plays an immensely larger part in the end result than the potential of Unity as an engine. Which is also why we also have seen some UE4 games run not so well (a PS4 sidescrolling platformer at least, can't remember the name right now).

 

[soco]

I think it might bother people with actual training in computer science but it seems like it wouldn't matter in the long run. Who really cares if Unity indie game #4256 is optimized poorly? Chances are it won't tax most modern rigs.

The case might be different for Unity games released to mobile, however.

I've watched exactly that happen. You can easily write a script on most of the scene algorithms that run calculations against all others on every update that's horribly inefficient.

However, optimization isn't really the worst case. A shitty algorithm with a filesystem delete gone wrong could be a nightmare.

 

[Purple Cheeto]

There's also the fact that debugging on hardware with Unity is still a sketchy and unpredictable process, and handling crash logs from QA is not particularly helpful at times.

 

[jooey]

Unreal is, but Unreal also doesn't have a huge existing community built primarily on the premise of "easy game development".

Unreal also, and this can not be underestimated, is less likely than Unity to provide you with an "easy" way to accomplish something that will subsequently perform terribly. That's what I was getting at with the "there's no doubt in my mind that many of the decisions in the Unity framework were made for (perceived) user convenience first, with stable large-scale software engineering being a secondary concern" part. In UE4, these goals are weighted differently.

Unreal has... maybe not huge, but a pretty big community, and enough similar peripheral parts to it that, yes are all weighed differently, but will only make it seem more like Unity over time. This argument needs more than a reasonable acceptance of democratized development that then flip-flops around knocking Unity's internals but maybe also the people who give bad solutions, or not, I don't know -- because it's sounding dangerously similar to the "sure it's great anyone can make a game, but real developers know how to optimize!!" narrative that creeps up from the engineer side, because god forbid a person create in something other than a blank IDE window.

The cream rises to the top. Someone who only seeks the easy, done-in-a-day answers and doesn't have an organizational mind to begin with won't go far whether they use an engine or not.

 

[TimeKillr]

legitimate complaint: Unity does not expose all of its functionality to the scripting layer

I'm looking at you, ParticleSystem

Some developers have access to the Unity source code, though, to do what they want with it. I know of quite a few who do. If you had a problem with ParticleSystem there, you could go in and do whatever you wanted.

Unity in itself isn't a bad tool like Durante said (I've been working with it professionally, as a designer, for 5 years now) and it does enable an incredibly high level of control from non-programmers very quickly. What it does do, however, and Durante again is right, is that it is mostly pushed towards non-developers or beginners who will do things definitely the wrong way, costing a LOT of cycles doing really basic stuff that could be done in very few (SendMessage() is one of those things where it's super convenient to send messages between GameObjects but at the same time it's SLOW AS HELL and using a C# messenger would be much faster, but it's something more advanced).

You just have to know what you're doing, as with every engine. The big difference is that non-developers can use Unity to make stuff just as developers can use Unity to make stuff. The performance difference will be there, though.

As for the guy who's final assets tanked his performance, it's quite likely that you just need to properly compress and scale your assets and you'll be fine (unless it's actual models with much higher poly counts and not mostly textures and such). But that's a problem you would have run into using any engine - using placeholder low-poly assets will definitely have an effect on performance when you use your high-rez assets later on during development. That's just something you learn about as you do it.

 

[tuxfool]

As a developer, this is an argument I can't agree with.

Just because Campo Santo has very seasoned veterans, that do have experience in optimization of their respective areas of expertise, doesn't mean that they possess the total skillset of a AAA developer like EA or have the resources and priorities necessary to match the performance of their previous work. Ultimately, as an indie developer you are much, much more likely to be concerned about getting the game done, matching your gameplay vision (or just vision of the product), surviving the production of the game than ensuring a very polished technical experience. That, to me, plays an immensely larger part in the end result than the potential of Unity as an engine. Which is also why we also have seen some UE4 games run not so well (a PS4 sidescrolling platformer at least, can't remember the name right now).

Sure. I could see that. It could also be that the easy nature of the engine fooled them into not considering some things until it was late.

It is a shame you can't remember the name of that sidescroller. I recall some dev team was making one such game entirely in Blueprint, I'd be curious to know if it was that game.

 

[Jacksinthe]

As someone making a PS4 and PC game in Unity and being the ONLY programmer - I have zero issues.

I don't use assets or other people's "solutions". Most of the time I see devs building a game like they are working with Legos and just gluing different assets and store bought tools together.

This is bad on so many levels.

I write my own tools and extensions. I update all of my own tools and extensions.

The result is a hiccup-free, locked 60fps game.

On the flip side, Unity does have its quirks which you need to be mindful of and the community "answers" to common questions are definitely cringewortht and, for the most part, should be largely ignored. A huge component to that issue is the "copy pasta" crowd who just want snippets of code they can just paste into their game without any understanding of how it does what it does, ultimately leading to sub-par results down the line when deprecation and major changes occur.

I really do hate the hate for devs that use Unity without even a glance at their products because of a few bad apples. Not everyone is perfect but man, I'm making sure I don't fuck this up.

BTW, Durante, I did call you out on this eons ago for not investigating since people like to parrot you ad nauseum. You were one of the first vocal opponents of Unity without due diligence and the hate for it just followed naturally here. Not cool to be a dev working your ass off because you KNOW eyes are on you just to be torn apart not because of your work, but your tools.

Unity has issues that can be avoided, like any engine. It's just an easy punching bag due to its popularity.

 

[Mechazawa]

But ultimately, developers are still pushing out games with terrible performance of their own accord.

I can definitely see the correlation between Unity fostering a community with amateur developers and the resulting shortcuts that become common for them to use, but when push comes to shove, if you release something like, I don't know, Broforce on PS4, at the end of the day that's just straight negligence. Negligence that I'm sure would've manifested itself in some other manner if a developer was forced to use a diferent engine.

 

[Purple Cheeto]

But ultimately, developers are still pushing out games with terrible performance of their own accord.

I can definitely see the correlation between Unity fostering a community with amateur developers and the resulting shortcuts that become common for them to use, but when push comes to shove, if you release something like, I don't know, Broforce on PS4, at the end of the day that's just straight negligence. Negligence that I'm sure would've manifested itself in some other manner if a developer was forced to use a diferent engine.

Unity makes it a lot easier to ship something that is shoddy. You're right that it still takes a competent developer to make a good game, the difference though is that Unity lets people who aren't competent make things that appear to be completed. It enables bad practices (and sometimes encourages them in its samples and documentation) while inhibiting people's ability to find and see the faults.

 

[Infinite_Daremo]

There are some aspects of the engine I was never happy with but overall I think its still a solid engine. I would have liked some more control over memory and graphics objects like VBO/IB allocation.

Its mainly down to the community and Stack bloody Overflow. I received a few projects from clients which were performing poorly supposedly developed by bigger companies and the rookie shit id encounter made me want to scream. GetComponent calls every frame, GameObject.Find every frame, fucking LINQ... LINQ!!!!!!, string comparisons against KeyCodes instead of using the bloody enum.

Theres also just general macro optimisations that you'd only ever discover by trial and error or profiling. Something as small as a foreach over a list on non POD's can allocate each iteration.

Id definitely agree with you that its a victim of its own success but its far from a bad engine.

 

[sirap]

I agree wholeheartedly. I was trained as an artist—I can model, texture and animate. What I can't do is program, but Unity and Unreal allows me to bypass that entirely with the Unity Store and blueprints.

Optimizing game assets can only take me so far. If I wanted to squeeze the most performance out of my game, I know I'll have to hire an experienced programmer.

 

[Purple Cheeto]

There are some aspects of the engine I was never happy with but overall I think its still a solid engine. I would have liked some more control over memory and graphics objects like VBO/IB allocation.

Its mainly down to the community and Stack bloody Overflow. I received a few projects from clients which were performing poorly supposedly developed by bigger companies and the rookie shit id encounter made me want to scream. GetComponent calls every frame, GameObject.Find every frame, fucking LINQ... LINQ!!!!!!, string comparisons against KeyCodes instead of using the bloody enum.

Theres also just general macro optimisations that you'd only ever discover by trial and error or profiling. Something as small as a foreach over a list on non POD's can allocate each iteration.

Id definitely agree with you that its a victim of its own success but its far from a bad engine.

GameObject.Find, Linq and ForEach are three things Unity needs to get rid of ASAP. Dumping these would force people into better practices that would improve most Unity games.

 

[benny_a]

Hard to disagree.

It's also not something unique to Unity. The same is true for a lot of tech. (Maybe it's even more generalized.)

You find this in programming languages, like higher level scripting languages.
You find this in electronics that is aimed at makers, like Arduino.
You find this in sysadmin with things like Docker.

All the above get results quickly and opens up the space for more people to try out and bring good ideas. That is certainly true for games made with Unity that have great concepts.

Overall these things get more people into a space which can be a great thing. When those things are then transitioning into production the wheat is separated from the chaff.

 

[CalamityPixel]

I've never really been able to get into Unity. I've made games with people using the engine, but I myself have not been able to make good use of it.

Right now I've become addicted to using Unreal 4. Blueprint is a godsend as I primarily work as a designer instead of programming.

 

[Durante]

I think when Durante says it's a "victim" he means the large amounts of non-experts propagate bad practices and thus can hinder the development of other developers who work solely with Unity, because it makes it harder to locate good advice.

Well said. And succinct too!

Unreal has... maybe not huge, but a pretty big community, and enough similar perphieral parts to it that, yes are all weighed differently, but will only make it seem more like Unity over time. This argument needs more than a reasonable acceptance of democratized development that then flip-flops around knocking Unity's internals but maybe also the people who give bad solutions, or not, I don't know -- because it's sounding dangerously similar to the "sure it's great anyone can make a game, but real developers know how to optimize!!" narrative that creeps up from the engineer side, because god forbid a person create in something other than a blank IDE window.

The cream rises to the top. Someone who only seeks the easy, done-in-a-day answers and doesn't have an organizational mind to begin with won't go far whether they use an engine or not.

I'm not exactly sure what you are trying to say. I never used the word "real developers" or even implied any such thing.

I don't see anything wrong though with stating that real engineers know how to optimize -- or, perhaps more importantly, how not to use algorithms which have a significantly worse runtime complexity than what is required to accomplish a given goal. And Unity, in achieving its goal of ease of use, has made it so that you can create a game without having dedicated engineers on your team. This is obviously a good thing in its democratization of game development, but that doesn't mean we have to pretend that it doesn't have any potential drawbacks.

You were one of the first vocal opponents of Unity without due diligence and the hate for it just followed naturally here.

That's not historically accurate. Tons and tons of Unity games were released with performance issues, or at the very least stuttering, and I simply agreed that this was a readily apparent issue and also indicated that I wasn't surprised due to a lot of reasons -- all of which were true at the time, and many of which are still true.

Frequent instances of bad performance on Unity were first and the driver for its reputation, blaming it on me is both ignoring that mountain of evidence and vastly overstating my influence. I've also posted at least 3 times about how impressive Assault Android Cactus is, as an example of a non-trivial Unity game with no performance issues and perfect framepacing.

Not cool to be a dev working your ass off because you KNOW eyes are on you just to be torn apart not because of your work, but your tools.

If your work is solid then I don't see why anyone would complain.

Unity has issues that can be avoided, like any engine. It's just an easy punching bag due to its popularity.

I think you are completely absolving the engine of responsibility a bit too easily here. There were severe issues in Unity, and it still does make it more easy than it would need to be to implement bad practices -- or harder to support good ones. Those are engineering issues.

GameObject.Find, Linq and ForEach are three things Unity needs to get rid of ASAP. Dumping these would force people into better practices that would improve most Unity games.

I think there's no need to get completely rid of any of those.

In fact, e.g. foreach allows you to write very expressive code, which is generally a good thing. You can write basically the same thing in C++ and have it perform 100% on par with a traditional loop -- and the same goes for a semantic equivalent of a Linq expression.
As someone who has a day job working on a compiler, I'd argue it's the tool's job to make sure those perform well

Find is a different case. I think a good way to go would be to generate warnings when features like that are used every frame (e.g. in update or similar), but not e.g. on startup.