How did we end up going with Unreal Engine 5 for our next game?
We have a very clear vision of the game we are making. We knew we would do a AAA open-world game from the start, perhaps not surprising given our background. However, this post will focus on the technical aspects of picking an engine for doing a new open-world game today.
When doing open-world, streaming is super important. Even though the new nvme/SSD hardware has made it much more accessible, an engine has to allow loading and unloading of assets without the game grinding to a halt or forcing loading screens to be shown.
In 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 middlewares 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 what we did 18+ years ago when development started on Just Cause 1. The landscape has changed quite a bit 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 doing a AAA game we want it to be released on consoles as well as on PC. In our case, we are targeting PS5, Xbox, and PC. Even though the current-gen console platforms are very similar, we still need the 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 man-years.
No matter how well documented an engine, 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 that 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.
Art Support and Tools
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 need to be APIs to allow us to build and expand on pipelines ourselves.
History of Shipped Games
We don't want to be first. When we pick an engine, I want to know it has been used for real to ship a game. Anyone who has been through a full game production cycle knows that the most challenging part of production is the end - to wrap 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 where you discover the real practical issues and fix them.
A large AAA game takes something 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 is not 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 changes that are needed for shipping the game.
So let’s assume we want to look at whole game engines. There are plenty to choose from.
- Unity, 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 (https://unity.com/dots ).
- Unreal Engine, 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.
- Our Machinery, C engine, looks promising but also very new and not yet proved in shipped 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 around the world 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.