Why We’re Developing in Unreal Engine 5

We have a very clear vision of the game we are making. We knew we would create a AAA open-world game from the start, perhaps not surprising given our background. This article will focus on the technical aspects of picking an engine for a new open-world game today.

When building an open world, streaming is super important. Even though the new nvme/SSD hardware has made it much more accessible, an engine has to allow the loading and unloading of assets without the game grinding to a halt or forcing loading screens to be shown.

When building a big world, tool support to quickly create a lot of assets, likely using procedural techniques to some degree, is also a key consideration. At Liquid Swords, we also want to rely more on systems, like physics, rather than one-off custom content.

We could, of course, build our own engine, creating something genuinely custom-made for our game. A custom solution, in the end, could probably be more performant. Not because we are more skilled than the people working on generic engines but because we can build something perfectly suited for our game.

A custom engine could still use middleware for some domains, like Havok for physics or WWise for audio. So, while it wouldn’t be necessary to build a complete engine from scratch, it would still be a massive distraction from the focus of actually creating our game.

It would also force us to build a game on a rapidly moving platform. A custom engine might be a great fit for doing a small game or want to focus on engine development for a few years, prior to creating a game.

Custom engines were historically the way forward, and that's what my former team at Avalanche did over 18 years ago when development started on Just Cause 1. The landscape has changed since then, and now it's quite the opposite. Let’s look at the criteria we considered when we made our choice.

As we are creating a AAA game, we want it released on both console and PC. In our case, we are targeting PS5, Xbox, and PC. Even though the current-gen console platforms are very similar, we still need support for them, and doing that work in a potential custom-made engine is not negligible. Simply adding support for one new platform on a commercial-class game engine takes several years.

No matter how well-documented an engine is, the truth is in the source. We want to understand how things work in the source, step all the way down to where things happen, and understand what is going on. We will run into performance issues during a project, and no matter how great the engine is, it will have bugs. Even if the goal is not to change anything in the engine, it will probably be needed to work around some issues to ship, so we want source access, and we need to be able to compile the engine from the source.

If we run into issues and get stuck, we want to have the option to get support. A vibrant online community is good, but access to real engineers who have worked on the systems is even better. When working with middleware, support is usually part of the deal, which can help ensure you use the middleware the right way and make it shine.

Just as important as code is that the whole team of content creators can work efficiently. We want the engine we pick to be well integrated with the critical content packages our artists want to use, or there needs to be APIs to allow us to build and expand on pipelines ourselves.

We don't want to be first. When we pick an engine, I want to know if it has been used to actually ship a game. Anyone who has been through a full game production cycle knows that the most challenging part of production is the end – wrapping up the product to handle the edge case and do the polish. When we pick an engine, we want to know that it has been hardened and gone through that phase of discovering the real practical issues and fixing them.

A large AAA game requires around 4 years of development. You need to consider the longevity of the engine you are picking. Are you sure it will survive your project? That it won’t be canceled or bought up by a big studio? This has happened before, the most well-known example is probably when then-dominant middleware RenderWare was bought by EA in 2004.

This is especially true for an engine where you don’t have source access and the freedom to make changes to the engine, fix bugs, or make other necessary changes for shipping the game.

So, let’s assume we want to look at whole game engines. There are plenty to choose from.

• Unity: A C# engine that is used in most of today's mobile games. Unity supports all consoles, but it is more common in practice for smaller games and not so much for AAA games. In the past, Unity has been criticized for performance, but they are working on resolving that.
• Unreal Engine: A C++ engine used in many AAA games. They support all consoles but have traditionally been mostly used for linear level-based games. Unreal 5 promises much-improved support for open-world games.
• The Godot Engine: An open-source engine, but does not have established console support.
• Amazon Lumberyard: An open-sourced and improved version of CryEngine.

We decided to go with Unreal Engine 5. Unreal has been proven for high-quality AAA games, both by Epic themselves in the case of Fortnite and by other game studios worldwide shipping amazing games on Unreal. With Epic making improvements toward open-world development, we get full access to the source code, and the integrations with other software and pipelines are excellent.