I've been developing in Unity since V1.0. Back then you could ring David Helgason and complain about the water shader not working when you run it for 12 hours straight - and get it fixed.
It blows my mind how much they've grown - but not just that - the tool itself is capable of AAA these days. The only real competition at that level is probably Unreal - and that's so very different to get into if you're an old-school unity developer. When you compare the Asset store (where you can practically buy any solution to your common problem) and compare it with Unreal's store - it doesn't really compete.
These two points make me think Unity has such a moat built around developers mindspaces that it's probably super-hard to dethrone at this point.
I'm interested if anyone else has an alternative point of view on unities sustainable competitive advantage.
Game engines live or die based on how they adapt to the constantly changing landscape. Unity made sense of the mobile landscape first and that led to their ascendancy. With mobile gaming on the decline and a looming new console generation, Unity will be put to the test.
Even when game engines don't fail themselves, they can become obsolete. As a general rule: love no language, engine or platform. They all come and go over the span of a career and that's especially true in an industry like gaming which constantly sits at the bleeding edge.
Some of Unity's innovations like the asset store will endure no matter what engine is on top. But the next iteration will probably just look more like a package manager.
> These two points make me think Unity has such a moat built around developers mindspaces that it's probably super-hard to dethrone at this point.
While Unity is great, I think you are a little bit skewed in perspective by your love for Unity. The legacy Unreal has (just look at the insane list[0] of past and present notable games built on it) with developers makes it the king to dethrone for anything AA or AAA.
I guess the point I was failing to make is that Unity has a percentage of developers that have grown up around the architecture. Perhaps they started in Javascript, and ventured into c# when it was depreciated - but the object model of unity - I postulate - is a pattern well ingrained into developers minds. The new ECS architecture is stumping many old-school developers that I know - because it’s just so different.
Don’t get me wrong - I don’t have a huge love for Unity. It’s just I’ve been using it for such a long time. For some retro game projects I’ve used C++ and XNA - which is great fun - but if you ask me to consult on a 3D title that needs all the bells and whistles, Unity is my skill set.
I’ve tried a few times to learn unreal, it’s rendering engine is fantastic - but maybe I’m getting older - but it didn’t grab me.
Again, I’ll reiterate I’m not a unity fanboy - many times I’ve found myself at the fringes of what’s possible - doing things in Unity that break it in ways the support team has never seen. It’s a pain in the proverbial. It’s bloated, it has a render pipeline that has become so amazingly complicated, and when something really doesn’t work because it’s a problem deep in the engine - it’s an absolute nightmare. For example, recently I had to port a project from another language - a 2d retro game that needed to run a 60fps solidly. You’d be amazed that Unity can’t do this without doing timed Co-routines outside of it’s traditional Update() function. That blew my mind. Unity has become so amazingly complicated that it’s at times extremely painful. I was, however, an XNA fanboy before Microsoft discontinued it. However that’s another story altogether...
Jeez.. you called me a fanboy and I went on a rant... soft spots ;-)
I'm gonna offer you another angle. Custom engine. You CAN almost always beat these general solutions if you specialize with your engine. Question is, should you? Would that specialization offer an advantage vs developing something with a general solution like that?
From personal experience custom engines offer more flexibility, assuming they're not 20 year old monolithic behemoths that tens (or hundreds!) of developers added their little piece and nobody bothered to remove much over the years. IF they're not that, it becomes easier to mold them to what your game(s) need (especially if you focus on similar genres, at least from a gameplay/engine requirements perspective).
Also from a tools perspective, big generic engines like Unreal and Unity have their established ways of working internally that may make writing good tools either hard or suboptimal (meaning that you can do something but since it isn't how the engine likes things it would not be fast). It is usually good enough for most uses, but if you want to make something very specialized you'll have a better time doing it with an engine you have control over, otherwise it'll be an uphill battle (there are cases with Unity for example of people having tools outside the engine and just import the final data, using Unity as little more than a scriptable renderer with asset manager and physics).
On the other hand, custom engines mean custom tools and more often than not tools get the short end of the stick in custom engines. It is a double edged sword, on one side you can make some simple and great tools that focus exactly on what your game is all about (something like Unreal is similar to C++: there is a lot of stuff that you can ignore but they still provide mental overhead even when you ignore them), but on the other side you have to make tools (and just in case, using Blender or 3ds max or whatever as your level editor is the perfect road to inflict pain on everyone involved, often leads to low performance with little visibility on why - and unless you have a vendetta against level designers do not even consider using dummy objects for level scripting, the only thing worse than that is asking people to paint triggers on a grayscale terrain texture using Photoshop).
(note that i'm assuming you have access to source code here which rules out Unity for the majority of developers using it - and of course i also assume that you have the know-how for working on custom engines)
I think it comes down to budget and what you're trying to develop. Developing your own full-blown engine with all the bells and whistles; scene management, physics, animation, ik solving, audio, video, asset importing, networking, scripting, UI, VR and so on is what used to be one of the biggest investments a game developer would make. ID software's engine generated a lot of revenue for for them back in the day - because was cheaper to pay 250k than do it yourself. At the end of the day as a gaming company you're trying to provide a unique experience - and as you say - a custom engine can be a way of doing that - but after you've created the engine, then you've got to create the game on top of that. So I think these generalised engines have satisfied a market need that wants to focus on the game itself rather than engine development.
As mentioned below in the comments - tools are also extremely important. If you're going to support standard tools (e.g. Maya etc.) for asset generation there's more work involved. The entire art pipeline has to be considered. It's a huge job. Making your own editors etc. again lots of work. If you have your own engine - you've probably got your own GUI and asset management system at this point for artists.
So this is a long way of coming around to "should you develop your own game engine?" If your use-case means that it's cheaper to do that than extend Unity or Unreal - and you've got the capital and talent - I guess it makes sense. But if you look at the majority of really successful games these days - they're using 3rd party engines. Even rockstar started with using Renderware - and now they have their internal engine with probably really good reason (super deep pockets and use case). But I guess if you're not Rockstar - and you're trying to make something AAA - it's expensive enough without trying for your own engine. Let's not even get started on making the engine cross-platform.
Of course, if you're making space invaders and know how to talk to the graphics API directly - none of this is required ;-)
Just my IMHO.
Something that i haven't seen mentioned much is that some people just prefer to work on custom engines (i'm willing to bet that the main reason John Carmack made his own engines was because he liked working on his own engines rather than the costs of licensing). I know of at least a case (i wasn't part of it myself) where after a developer decided to switch from their custom engine to Unreal, almost the entire engine team quit.
FWIW personally when judging potential workplaces i bias towards those using custom engines since there is way more room for having an actual impact on the project and i am more likely to learn something new from a custom codebase than the 482th Unreal fork.
The fact that people often feel the need to justify working (almost always in a defensive stance) with a custom engine shows that they simply prefer to work with a custom engine despite other concerns.
Also there isn't really a clear cut distinction between AAA and smaller studios using custom and generic engines - while indies are more likely to use something like Unity, that is mainly because there are way more indies than big teams and many indies do not have the knowledge for a custom engine. But there have been many successful indie and small studio games with custom engines and AAA studios with licensed engines to say that if you're Rockstar go with custom, if you're small go with 3rd party engine.
Honestly i think the people involved are way more important (and likely to affect the choice of an engine) than any budget or size concerns (i'm not even considering the game type as most custom engines are used to make games that could also be made with 3rd party engines and the game type is rarely the driving factor for that choice).
Back when Id started, games middleware still wasn't a thing regarding game engines and it was highly seen as an additional needless cost.
The industry was mostly focused on buying libraries for specific tasks instead.
It was around this time that companies like FMod and Bink started.
Nowadays with budgets and teams that rival Hollywood ones, it is a much higher risk to do everything from scratch, before starting to do the actual game given how middleware has turned the table and is now widely accepted, hence the defensive stance.
My point is that the defensive stance shows that many developers want to work on custom engines despite other factors and that is driven by personal preference rather than any sort of cost/benefit calculation.
And it makes perfect sense and you see it all the time in other fields too with people switching companies and/or start (side)projects so that they can work with specific frameworks, languages, etc.
>Most of the value of Unreal or Unity is that the tools are already there and they more or less Just Work and a lot of people know how to use them
This is a very good point I missed above - people - the fact that lots of developers and artists are already experts with the tools lets you hit the ground running and focus on the game. With a custom engine you've got all the training involved to use your custom toolset.
This is something I generally miss in game engine discussions. Good tooling for an engine feature is two or three times the effort of the feature itself on average. So ypu can probably bould an amazing engine runtime in your spare time, but doing anything interesting with it is painful because creating the tools is incredibly fiddly.
The format is somewhat open. Unity stores a lot in plain YAML files. Unreal has a wild serialization framework that is part of the freely accessible source cide (but tons of strings attached - so be careful!). So you might get some reuse out of these editors, but the catch is that they are extremely engine specific (with UE, I can't quite tell if the editor is built for the engine or the engine for the editor). So you'd just set yourself up to replicate the same engine design because it makes handling the output of these editors easier.
Formats tend to be tied in some strong nature to the way the engine works. Think of it this way: you could create your own engine, but then every difference between your engine and Unity is a bug from the artist's perspective (thing works correctly in Unity but does not in your engine).
There's no sense in using the same format for your engine if you don't implement every single last checkbox and dropdown.
Nonetheless, having access to the source gives you insights how things work, build by yourself. With more experience, you can customize it, or suggest PRs. This can be a game changer.
It depends on whether you have the technical prowess of Jonathan Blow or not? He was able to create game aspects in custom engines that would have been impossible otherwise. E.g. low level sound control in Braid, some amazing use of lighting and reflection in The Witness.
I don't think Unity3D has anywhere to go from here but down. Which doesn't mean it's dead, since there is a long sunset in sight - but the gamedev workforce turns over in cycles of under five years, which means that training as an economic moat is only locked in for about that long, too.
The problem is threefold:
1. Almost no game will use all of its features. For any one project a competitor with slightly more niche positioning can find a way to pull ahead - a death of 1000 papercuts.
2. The underlying tech only becomes more of a commodity. Some of the biggest things that Unity solves are things that are still important, but not very differentiating now: having an asset store; having cross-platform deployment options; having modern rendering capabilities.
3. Unity isn't designed for sustainability. Interest in long-term maintanence has become increasingly important for developers who are able to continue marketing the same game, with the same tech, more-or-less indefinitely in today's digital marketplaces. Unity's approach is of the "move fast and break things" sort, which has served it well to grow, but makes it a business risk for developers: updating Unity versions is a perilous exercise.
Unity Plus costs $35/mo for 50 concurrent users, and UNET was a fumble. Grid (https://www.planimeter.org/grid-sdk/) is free, and was built multiplayer-first.
The last time I checked, I couldn't build a project OOTB and in 5 minutes have a multiplayer game to mod and hack on. That's been a feature I've provided for years.
I think the appeal of PBR workflows for 3D games is what Unity and Unreal capitalize on, but for 2D hobbyists, there are much better solutions with far less overhead, and fewer expenses.
It blows my mind how much they've grown - but not just that - the tool itself is capable of AAA these days. The only real competition at that level is probably Unreal - and that's so very different to get into if you're an old-school unity developer. When you compare the Asset store (where you can practically buy any solution to your common problem) and compare it with Unreal's store - it doesn't really compete.
These two points make me think Unity has such a moat built around developers mindspaces that it's probably super-hard to dethrone at this point.
I'm interested if anyone else has an alternative point of view on unities sustainable competitive advantage.