There is this general assumption that engines get better just by having the engine maker also use the engine to make games. I want to add some thoughts to that.
At Unity, one of the main arguments against making games was “we do not want to compete with our customers.” That is just nonsense, because literally nobody is concerned with a company that has never made games successfully suddenly starting to make games. The underlying idea must have been that if they started making games, they would obviously be good at it and hence also successful, with some market relevance. That, if anything, should just convince you that whoever utters these words has a very romantic idea of the work and expertise required to make games, and maybe also whether making a good game would even be sufficient to be relevant.
A more generous reading of this “don’t compete with our customers” argument would be that they refer to internal competition: Our customers say they need X, but the game we are building needs Y, and we only have limited resources. So now we compete over development resources. I do not believe that to be a relevant concern either: First, if you find massive gaps by building a game yourself (assuming that game is representative of what your users are building), your customers likely also noticed those gaps and would like to have them filled. But second and more importantly, this would just mean that eventually you will stop making games: the engine company makes money by being the mediator for ads in mobile games making an engine, and you are now considering putting lots of resources into something that is neither the main business of your company nor a buzzword that you can sell to people who don’t know better. That is why when you need to cut, you first cut the internal samples teams who make games. If the game you are making is not relevant to the bottomline of the business, then over long or short the same thing will happen to it that happen to all the other big cost centers that don’t directly drive business. Add to that that making games is expensive and difficult, and you know where this is going. (Maybe this is something that a stubborn CEO or a visionary leader could still drive, but I find it very unlikely: the cost landscape that they need to navigate will always work against them and pull them into local optima instead.)
OK, then maybe you should partner with other people to make games. Great idea, how is this going to go? Oh, you are going to take those consultants you hired and you place them on those customer projects? You do realize that the consultants you have are not the developers of your engine, right? Some of them are highly proficient users of your engine, but they do not write the engine code. Your consultants already know the pain points, because they experience them daily. It’s not news to them that waiting for 15min every time you click a button is painful. Actually, it’s not news to your engine developers either. The problem here is that you can’t outsource “user pain”: the decision makers need to feel that pain themselves, or alternatively that pain needs to be translated into business-pain (“not fixing this loses us more money than implementing this shiney new feature over there will bring in”). Even at game companies it usually takes a good bit of pressure to move engine developers into a place where they work directly in the game. It requires pressure because you bring pain to the engine developers, and those engine developers are now also going to be slowed down. Working inside of the actual game is always going to be more painful than working in the small testbed that the engine folks built once they realized that working in the full game is painful. At least now the engine organization has the same incentive as the game organization, and the game organization is the only thing that actually matters because that is where the actual business of a game company is.
On a related note, it is worthwhile to consider where an engine such as Unity comes from: The previous motto of the company was “democratize game development.” This is all about answering the question of “How should games be made?” It’s about challenging existing notions about how games are made, allowing more people to create them. Compare that to “We’re a game company, our game ships next Thursday, what do we need and what do we cut?” The answers to these two questions are just very different, and Unity happens to have been built to provide a new answer to the first question. Unity got a lot of things right, by intuition, by conviction, and probably a good dose of luck. Unity succeeded in democratizing game development, which is why more people now use Unity to ship their games and hence require answers to the question of “what do we need until Thursday?” If you look at things from the perspective of “what should this be in a perfect world, actually?” you come to very different answers, you make different compromises, or maybe even convince yourself that no compromises are necessary at all. This is to say that Unity’s DNA and culture is not one of pragmatism.
The reality of making games however is always going to be somewhat ugly. Among the most useful things I know are runtime toggles and knobs (“console variables” in Unreal Engine parlance), easily filterable logs, and informative asserts. All of these are there to deal with the imperfections of reality, and Unity has none of these three. (Granted, asserts are more useful when you have full source access.) Unity has a habit of pushing these imperfections out to the user, maybe because it would be nicer to have a solution that is at least conceptually perfect (and having for example tons of runtime toggles and options is clearly an admission that there is no one perfect solution – it’s a symptom of reality, so to speak). DOTS arguably suffered from a similar problem: it was meant to be a new way of how you write games, not a pragmatic compromise of how to get better frametimes.
All of this is to say that I understand the request for Unity to write their own games more as a request for more pragmatism (on top of making things that are not obviously bad). Its users are better served by a better tool rather than a nicer product.