When it comes to game engines, the market is dominated by two giants: Unity and Unreal. It’s worth mentioning that they’re not the only actors in town, you can also find Godot, CRYENGINE, Amazon Lumberyard, UNIGINE, etc. But when it boils down to it, the question is: Unity or Unreal?

First of all, and to state the obvious, there’s no single answer to that question. Both are amazing tools with a wide variety of features. So we’ll focus on highlighting their differences, especially those most important when building a driving simulator.

Who’s using what?

One interesting thing to study is who’s using what in the existing driving simulation world. Historically, everyone was either running their own engine or OpenSceneGraph. However, things are changing in the past few years, and even though historic actors aren’t making a full move to new engines, they’re at least integrating them in their solutions.

• AVSimulation, PreScan, VI-grade, CARLA are using Unreal
• Metamoto, Cognata, LGSVL are using Unity
• IPG is using Unigine

If we look at the academic side, both NADS and ITS Leeds are using Unity. If we try to look for organisations that develop their in-house driving simulation platform (as we are), both Scania and WMG at the University of Warwick are using Unreal.

Target markets

This section might be more subjective, as it’s difficult to find objective data on this subject. It’s basically what I perceive from reading both engine’s blogs and Twitter feeds.

Unity is undoubtedly the mobile market king, and seems to invest heavily in that. It’s a bit more targeted towards small teams looking to make small to mid-range games. Even though it’s widening its target market beyond games, this move somehow feels a bit late.

Unreal has made a strong move to various industry sectors in the past years: automotive, arch-viz, military and lately virtual production. Even though games still are at their core, they’re serious about every market expansion they make. Their Build event, Automotive Field Guide, or just the fact that their Industry Manager is active on Twitter are great signs of their commitment.

Programming languages

One of the main difference between Unity and Unreal is their programming language. Unity uses C# (and now Bolt), whereas Unreal uses C++ and Blueprints.

The C# vs. C++ debate is a whole other topic that I’ll gloss over. Let’s just say that C# certainly is an easier language to get into. C++ might have a very slight performance edge, though it’s narrowing. For us, one important factor was that we had quite a few libraries with C++ classes, so working in a C++ environment makes our life easier by not having to interface our C++ classes to C#.

On the visual programming subject, I was heavily conflicted. On the one side, it’s easy to use, especially for some researchers that may not be too keen on writing code. On the other side, well, there’s a lot of other sides. Versioning can be difficult, spaghetti code can take a very literal meaning, etc.

CAVE rendering

Rendering the scene on a 360° screen comes with a specific set of challenges. Unless you’re doing desktop or VR-headset experiments, you’ll probably have to face those. Unity and Unreal both have very different ways of handling those problematics.

Unity is a bit messy on this subject. Historically, it had a feature called Cluster Rendering, which answered this problematic, but this features kind of disappeared, leaving many users wondering what to use instead. A replacement was announced for 2019, then 2020, and as I’m writing this in 2021, there’s no official word from Unity.

So in the meantime, external solutions were introduced. MiddleVR is the leading one, though the price might not be suitable for everyone. Then there’s UniCAVE, which is open-source, but from what I’ve heard, requires some extra work to get it compatible with Unity’s latest releases. Another one is VR Distrib, which I have no feedback on.

Unreal is straightforward with its answer to the problem: nDisplay. This solution is used across different application cases: simulation, virtual production, etc. The feature is well supported, with constant improvements since a big refactor in the 4.22 release.

Miscellaneous

Unity has a stronger foothold in education curriculum, meaning the available workforce is probably higher for Unity developers. Unity also has a more furnished Asset Store than Unreal’s Marketplace, though you’ll probably find anything you want for your driving simulation in both.

If you regularly browse Hacker News, it’s not uncommon to have people complaining about Unity. Here’s a recent example, which was also discussed on Reddit (r/gamedev, r/Unity3D). Even if Unreal Engine obviously has its pitfalls, it’s always interesting to read these discussions to get feedback from others users.

Unreal seems on the forefront of innovation, with Unreal Engine 5, MetaHuman Creator or realtime ray-tracing. However, Unity is not left behind, its Data-Oriented Technology Stack sure is a nice addition to the tool, for which Unreal has no equivalent (yet?).

Conclusion

So, what do you choose? Well, we chose Unreal. The main deciding factors were nDisplay and the easier integration of our existing C++ libs. Looking back, I still think we’ve made the right decision. But it absolutely doesn’t mean that Unity is not a valid choice for making a driving simulator. As mentioned, a lot of organisations have chosen it and seem quite happy with it. So the decision is yours to make, based on your specificities and requirements.