Creating your own engine vs middleware?

invictis

Newcomer
While most companies nowadays forgo creating their own game engines to just licence on like UE, Unity etc, there are still some they do create their own such as Techland and Asobo for instance.
It had me wondering. Asobo for instance isn't a large company (around 100 employees when they built their engine), so how much work is involved in creating their own engine? The results with A Plague Tale is quite amazing, so the end result of creating your own engine easily match the best of Unreal Engine 4 games visually. GG games with Decima, is another that looked every bit as good.

What benefits are there for a company to create their own engine vs using UE for instance?
Will we see more companies leave Unreal to make their own engine?
Is it the case that open world games arnt suited to UE and so games that are open world need a custom engine?

I was playing Halo Infinate and I have to say I wasn't impressed by the Slipspace engine at all. Sure it kept 60fps, but the amount of pop in even using the XSX SSD was really bad. I was wondering why they just didn't lease an engine and put the time and effort into optimising vs making the engine.

Another question was if say when 343 were creating the Slipspace engine, how much other work would have been held back waiting for it to be completed?
How long would it take a company like 343 to make an engine?
Is it a different skill set to create an engine vs just developing a game? Like would 343 had to employ specialists to come in and make the engine and then they left once it was done? Or would those employees then moved back to other tasks like building the actual game?
 
There are different purposes behind either decisions ...

Creating your own engine is about retaining control over technology. Dependency management becomes easier since your not outsourcing the engine technology to an outside party. Implementing features to your own engine is also easier as well. A proprietary in-house engine can be easier to maintain because it's own developers have the best technical understanding over it. Non-commercial proprietary engines are often smaller in scope as well which makes them simpler to maintain and is thus arguably more sustainable. If an engine doesn't have any customers then it doesn't have to worry about any "design by committee" misadventures or other external politics ...

The goal of using a middleware is to increase productivity. Middleware usually gives developers a lower barrier of entry to create their own product. Middleware often provides an already existing rich set of features that developers can use at their disposal. Since the development of external middleware is subsidized by many other parties this arrangement can be useful for extracting cost savings to your own project as well as many others. Middleware helps the industry to reduce redundancies since it encourages sharing implementations ...

There are far more important reasons outlined above behind both options as opposed to purely the argument of licensing costs between them ...
 
Is it the case that open world games arnt suited to UE and so games that are open world need a custom engine

That is one of the areas being address with UE5 and was hilighted in a few of the tech dives.
 
That is one of the areas being address with UE5 and was hilighted in a few of the tech dives.
Is that due to apparently moving to a 64-bit coordinate system finally?
 
Is that due to apparently moving to a 64-bit coordinate system finally?
Part of that was in UE 4.25 or 4.26? But there was larger changes in UE5 for the dev plugins and tools. There was also some work done in 4.x so object properties are lightweight and don't automatically pull in the other referenced objects.

What I had in mind was more of the dynamic zone structure in UE5, even if some other devs commented how their engines have had that for years. I don't have direct reference to it, but have the images/slides and tweets in mind.
 
Is that due to apparently moving to a 64-bit coordinate system finally?

Here's section of Open Worlds, they call it "World Partition". And here's their doc page on it @ https://docs.unrealengine.com/5.0/en-US/WorldFeatures/WorldPartition/

World Partition is a new data management and distance-based level streaming system that provides a complete solution for large world management. The system removes the previous need to divide large levels into sublevels by storing your world in a single persistent level separated into grid cells, and provides you with an automatic streaming system to load and unload those cells based on distance from a streaming source.

Open worlds

One of our ongoing goals is to make the creation of open worlds faster, easier, and more collaborative for teams of all sizes. With Unreal Engine 5, a new World Partition system changes how levels are managed and streamed, automatically dividing the world into a grid and streaming the necessary cells.

Team members can now also simultaneously work on the same region of the same World without treading on each other’s toes, thanks to a new One File Per Actor system, while with Data Layers, you can create different variations of the same World—such as daytime and nighttime versions—as layers that exist in the same space
 
...
Is it a different skill set to create an engine vs just developing a game? Like would 343 had to employ specialists to come in and make the engine and then they left once it was done? Or would those employees then moved back to other tasks like building the actual game?


To me it's one of the main reason why some devs team chose to use an "external" engine. Because it's a crazy hard job to make a good one. But if you have a bunch a devs who have the skills to do so, then it can be a good solution for that studio. Plus it can be "custom made" for the need of the game, vs a "generalist" engine. Let's be honest, some Unity and UE based game have weird performances because the team don't know how to use it and tweak it to their needs.
 
Based on my experience, a small team of experienced engineers could create a good game engine in about a year of work - though this could vary a lot based on how complex it is. The engineers working on the engine are usually separate from the engineers working on gameplay, though there could be some overlap - especially at smaller companies.

The advantages of using middleware are that production work can start immediately, you don't have to have an engine team (you still need one if you need to make any significant changes), and you can hire people already familiar with the middleware or outsource work more easily. The disadvantages are that your game can end up looking similar to every other game built on the same middleware, performance can be awful if you are trying to do something the middleware was not designed to do, making significant changes can be can problem if you want to update to a newer version, and the cost of the middleware - though this is probably the least significant.

The best choice probably depends on the game. It is pretty hard to say if we will see more or less games using custom engines in the future.

I don't have much insight into the development process at 343. I would imagine that they used a lot of the code from previous Halo games rather than starting from scratch.
 
When you say "create a game engine" that doesn't include any art assets or does it?

Typically, the engineers building the engine are not making art assets. It is import that the people building the technology work closely with the people building the art (and gameplay) so that the engine makes building stuff easy and supports the art style and so that the art makes the best use of the engine. Good technology without good art taking advantage of it won't end up looking good in the end. Part of what makes creating a good game hard is that you usually need good technology, good gameplay, good art, good sound, etc.
 
Back
Top