So I work at a big AAA company that maintains a few big AAA engines(I'm sure you can guess which one it is), and while there are loads of drawbacks, the benefits are worth it for us. Basically it boils down to - we control the engine, we control the release schedule for features, we don't need to wait for permissions or licences from another company, and there is no risk of being screwed over by a changing cost or licence restrictions.

As an example - right now as next-gen consoles are slowly heading towards release, we need to have several games ready for launch. If we relied on external companies to provide say PS5 support, this might have not alligned with our schedules and company goals. In fact, since different projects are in different stages of development, things like PS5 support have been developed independently by few different teams for different engines. This might seem wasteful on the outside, but in fact that allows us to pick the best implementation afterwards, or the best implementation for the genre of the game that we're building. We've done the same with the Switch when it first came out - multiple implementations appeared on different projects but nowadays there's only one or two that are considered "gold standard" within the company. You don't get this flexibility with external engines - you get one implementation, and it either works for you or it doesn't. You can make a request to change something, but it might or might not happen, and you usually don't know the timescale. With your own engine you control the timescale.

>> I imagine that Unreal is more advanced than these homegrown engines

Uhm no, it is and it isn't. Unreal as a commercial product has to serve many many goals, which means that for some it's just not the best engine to use. With your own engine you can tailor it to exactly the type of game or the system you're building for and achieve maximum benefit.

>>Ps: Doom Eternal runs really great, but I'm sure with tuning Unreal can produce similar results

Like, maybe Epic could do this internally. As an outside studio you have 0 chance of doing the same.

Makes sense, thanks a bunch for the explanation!

> Ps: Doom Eternal runs really great, but I'm sure with tuning Unreal can produce similar results, right?

Absolutely NOT! UE4 has great tools and awesome APIs for creating content from the perspective of an artist. The runtime, unfortunately, is mired with legacy code from a bygone era. It is also restricted by the need to maintain mobile support. Compared to an engine like what idTech has, or Activision, or Ubisoft, etc. the UE4 runtime is probably 10 years behind. There are numerous techniques such as those mentioned in the linked post that are simply not possible in UE4 because of how dated the RHI layer is.

I’ve worked with UE4 professionally for several years - this is absolutely true. It’s hard to get really good performance out of the engine. Furthermore, it’s a beast. The codebase is large and old enough that making deep modifications is very difficult and time consuming.

That said, the tools are (mostly) great.

Competitive advantage. On the PS4 at least, Doom 2016 and Doom Eternal are the some of the best-looking games which are capable of running at a constant 60FPS on the platform. Additionally, the team will have a tonne of institutional knowledge built up over the engine's lineage and content creation tooling, making switching a costly proposition.

It's worth noting that after Carmack's departure, the engine development is now headed by Tiago Sousa, the guy responsible for the Crytek engine. He's very much a worthy successor IMO.

Perhaps a more historical point of owning the rights to your own engine is the ability to relicense it under something like the GPL for others in the community to learn from (once it has outlived its useful commercial life). Id is well known for doing this (see their GitHub repo), driven by Carmack's altruism, and there is a thriving community of ports and code review breakdowns (Google Fabien Sanglard) for their historical products as a result. It's unfortunate that this trend did not continue past Doom 3.

The direct $$$ cost of maintaining an engine is probably not as high as you think, as it really needs a small team to move fast enough and have the customizability advantage over COTS engines.

The value question can't be answered in general, it depends on what the engine is specialized to, how well it's executed compared to the alternative, what are the cultural factors surrounding the idea of using in-house tech, how well the support tooling supporting creatives is executed etc.

The standard curve applies, most in-house engines aren't very good, but few are.

Value wise, it's potentially a competitive advantage. Product differentiation, facilitate specialist niches that the commodity engines don't.

The performance advantage is real. Getting to 85% of the visuals there is 'easy'.

The last 15% is where the waters get muddy, the predators fierce and the black obelisks loom high.

For most teams, most projects, it's probably a boondoggle. As an indie, your use case basically needs to be really simple and performance dependent.

You think the company that made Wolfenstein, Doom, and Quake should use the Unreal Engine?

Is it still the same company? The new team seems pretty great but they’re still a different team with different strengths.

If you replace all components of a car one by one over a long period of time, will it be still the same car?

More apt comparison would be a sports team rather than a car. And if you replace all players in the team over a long period time, usually it wouldn't be considered as the same team, sometimes just replacing one player is enough(Bulls minus Jordan etc)

> What's the value?

Business alignment. The engine is optimized for the needs of your company not others.

Unreal is optimized for Fornite, as Fornite produces a lot of money for Epic.

e.g. If there is bug that affects Fornite and another that affected Doom Eternal. Epic would fix first the one that affects most of their revenue, for later on fix (or not) the one affecting Doom Eternal depending on other priorities.

The same happens with new features, or moving to new technologies or platforms.

While the point about business alignment is true when done right, it can also be a net negative when done wrong.

I used to work for one of the biggest publishers of AAA games. They have their own engine which all their studios must use. It's been a big source of issues because that engine was in many ways behind others on the market and the team in charge of it did not feel the necessary pressure to address issues since all their "customers" were required by management to use it.

Depends on what game you're trying to build and if the engine is tuned to that use case.

The needs of an open world vs corridor vs highly instanced simulation will drive a lot of the core design of an engine in different directions.

Yeah, UE seems general purpose, which inevitably makes it sub-optimal for a lot of use cases.

I'm going to respectfully disagree with most of the other replies to your question.

There isn't much value in maintaining your own engine. All you have to do is look at the top games made with Unreal 4 and compare to the top games made without it and you'll see it's mostly irrelevant to have your own engine. The tech geeks and engine creators will all claim otherwise but sales and users don't care. They care that the game is fun. Just like in movies they don't care what brand the cameras are, what software was used to render the CGI, what software was used to edit it together. They only care that it's good movie. At last 1/2 of fellow AAA game devs have switched to using a 3rd party engine and so it will likely continue.

I don't write in-house game engines, but I do write in-house devops tools and I assume the reasons are similar. Instead of reaching for things like Jenkins, Docker, Kubernetes, et. al., we developed a unified software solution that ties all of these concerns together in a way that aligns perfectly with our business objectives. Our biggest concern has always been the turnaround time of our software changes. We are at a point of doing multiple builds per day per customer, and pushing further into this realm requires some machine assistance.

For me, having 100% visibility of the entire vertical in code is the most compelling aspect. I can set a breakpoint somewhere in business logic and then step into the low-level if I need to. This sort of approach makes it really easy to spot things that are conceptually tricky. E.g. After stepping into an internal library method you discover that you are using ASCII and not UTF-8 encoding which is resulting in loss of fidelity of persisted business data. If this library method was in some external source you have no control over, it would either be entirely invisible to you, or taunting you with its unchanging gaze. For us, we simply edit the low level problem, push a commit, and its done. Knowing that we can step into the lowest level code encourages us to do so. F11 takes us all the way to the bottom of the rabbit hole. Debugging is a lot easier when you have confidence that you are passing the correct byte sequences into database/os/framework libraries. This also means that stack traces are very useful since you can view the source behind everything.

There is obviously a cost associated with maintaining this solution. We have found that it is substantially more expensive to maintain than just using a set of existing tools. For our case, 1 full-time developer is approximately what it takes to maintain all of this infrastructure. However, there is also the angle of opportunity and efficiencies. With the custom tools we have built, we are now able to cycle our software development process 4-5x faster than before. Our project managers can click a few buttons in a web UI to trigger a build of our software followed by automatic packaging and scheduled release to selected customer environments. This also includes the ability to review all errors (fully-automatic reporting) combined with snapshots of business state at time of stack trace generation. We have the ability to click on a commit hash and see a list of all errors which occurred on that tree up to that point in time. All of this links back into our source control tool. I would say that our devops process is ~95% full-auto at this point. I have not seen anything like what I am describing offered in any public marketplace.

Sometimes if you want something really nice, you are just going to have to build it yourself. Many times, the cost of in-house custom will not be justifiable at face value. You have to look beyond this and consider the higher-order consequences of your decision over longer time frames. Our solution started out very humble and gradually grew into the comprehensive monster that it is today. If we hadn't taken the leap away from Jenkins 3 years ago in favor of implementing the build logic in code, we would have never had the opportunity to incrementally add all of the other amazing stuff that we did.

Sorry to say, but this was the completely wrong approach and I’m amazed the business let you do it.

Some poor bastard is going to have to undo all your mess down the road, I hope you buy them a beer if they ever track you down. I mean, at what point do you make the call that writing your own in-house copy of _DOCKER_ is a smart move? Let alone Jenkins.. The ‘magic’ abilities you describe this platform as having are utterly standard features and are yours as soon as you install e.g gitlab...

Of course, you actually have to spend some time and learn them and how to use them properly, but that time is VASTLY less than learning how to implement them badly and minuscule compared to the amount of time it’s going to take to migrate off your in-house pile..

We did not write a 1:1 replacement for docker. We made technology choices which allowed for us to completely sidestep the conversation.

See: .NET Core Self-Contained Deployments and the inherent advantages of SQLite.

Just because we don't use a particular vendor's product does not mean that we have made the decision to re-implement 100% of their feature sets.

Ho, sounds exactly what I'm in the process of laying down at work!

Do you push to on premises deployment or is it pure saas? The former is obviously harder to tackle, and unfortunately that's the case here.

We push to each of our customers' environments from our centralized administration tools. Each customer environment can vary wildly (on-prem, AWS, Azure, etc) and ultimately just needs a small component installed for communication with our mothership. We do not worry about the actual hardware or hosting, but do have tools that allow for us to inspect the health of whatever host we are running on from our remote perspective.

Longer term, we have considered shipping appliances (physical or VHD) to our customers so that they do not have to take the extra step of configuring a new windows or linux host each time we want to stand up a new product environment.