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