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)
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.
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).
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.
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.
OTOH, it is very difficult to build a full tool pipeline that supports that engine.
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.
And the guys who dev it are cool as.
There's no sense in using the same format for your engine if you don't implement every single last checkbox and dropdown.
https://github.com/Unity-Technologies/UnityCsReference?files...
Create Epic account, link to Github, receive access to UE4 repository. Probably can be revoked easily.
Or get it via launcher, after log in into your account.
Also, you cannot post online more than 30 lines of engine code (forums, stackoverflow,etc).
I'm not a lawyer.
Edit: launcher part.
Open source means you can use it and redistribute it freely.