Game Engines: Part 3 - Troubles of Commercial Engines
Money doesn't always talk
For the last two articles I’ve painted quite a dour picture of in-house engines, which might lead readers to believe that a commercial engine like Unity, or Unreal, is the correct choice for your game.
However, the message I really want to communicate is that there are so many pitfalls with any engine, in-house or otherwise, that success comes not from the engine but how you approach it.
Commercial engines have plenty of their own downsides, and while a large number of studios are rushing to adopt Unreal Engine 5, this isn’t necessarily a sign that this will be the future, the industry swings back and forth, and there’s a reason for that.
In this edition, i’m going to dive into the history, the controversies, and realities of commercial engines, and probably leave you a bit confused as to which is the best avenue to pursue.
Historically not good
The all around accessibility of Commercial and Open-source engines are a very recent thing. While commercial engines have been around a long time, their previous iterations were not good, enough. Which is why we have a long history of in-house engines.
Early versions of Unity and Unreal, were rough. These are iterative products and so while now they have all the features and refined workflows, they had to start somewhere.
If you’re familiar with any type of creative software, Blender, Photoshop, etc, you will know that these software have their way of doing things. Even now, you need to make your game in the Unity or Unreal way, to get the best out of it, and that can sometimes be at odds with the product you are trying to create.
This has lead to games missing features or not executing on their vision they way they want because the engine was missing the support needed. These engines, by their nature of being a bit of a ‘one-size-fits-all’ can’t be perfect for every game idea, and sometimes that only became apparent mid-way though development.
While updates to these platforms came regularly, that was a double edged sword.
Maybe your game was being developed on version B, and a feature you really needed was in version C.
It’s not that simple to just upgrade, as version C may have added and changed so many other things, that by upgrading you would introduce a boat load of bugs that might take you a few weeks, if not a few months to remedy.
This is often why games lock-in to the version of the platform they started on, and don’t upgrade during development. It’s often easier to work around the missing feature than to upgrade.
You’re not always promised that the thing you need is coming in the next version either. These platforms have their own vision for how they want to prioritise their development and they are going to look to develop features that support the most games or their own internal desires.
This, historically, has made commercial engines, specifically Unreal, difficult to use, and easy to muck up. For a while, the industry had studios dedicated to supporting other studios with Unreal development. Rocket League developer, Psyonix, used to be one of those studios, assisting with the development of games like Gears of War.
Whilst, now, plenty of developers have Unreal engine experience, it wasn’t that uncommon for a studio to need to get help in to show them how to make their game in Unreal.
Because of the ‘one-size-fits-all‘ nature of these engines, they tend to be a bit bloated with features and systems. These systems can, over time, become at odds with each other, and tend to result in larger… everything. Larger working files, larger asset files, larger code bases, and often, larger end result. The tricky spot for some more indie studios or games of smaller scope, has been that Unreal and Unity make for a quicker and potentially easier development process, but potentially a larger game size that may struggle to run on lower hardware.
This history of issues with commercial engines has also led to a reputation by proxy. Gamers are quick to label engines the ‘reason’ why a game is bad or slow, something I’m trying to rally against with this series of writing, however once a reputation is established it’s hard to shake, especially given the engines logo shows up at the load-up of a game.
Unreal Engine 3 and 4 had their own performance issues (Stutterstrugle), exacerbated by the fact that Unreal is often used for high quality 3D games where performance is key. This lead to many players bemoaning the fact that their favourite upcoming game was an Unreal Engine product.
Unity, on the other had, had a counter problem. Due to it’s business model of being cheap to use and easy to get assets for lead to a deluge of low quality games being created using it. This led to a reputation that Unity games were bad, causing reputable studios to seek to try and hide the fact their game was developed on Unity.
It’s really only now, that commercial engines are mature enough with features, workflow, and porting support, that they are becoming worth the down sides, however, as I will go on to explain, it still doesn’t always make them the right choice.
Mafia style pricing model
As discussed in part 1, a commercial engine comes with a financial model that will affect you for the life of your game.
Whilst this has been generally accepted as part of doing business and keeping the engines funded to keep growing, we recently got a very real look of how it can go horribly wrong.
In 2023, Unity, announced a new licensing model that rocked the development world. Instead of charging their fee based on sales, which was standard, they sought to charge a fee based on usage. This meant that the fee would increase based on how many times your game was installed, leading many developers to fear on going viability of their own revenue model given games get re-installed multiple times in their life.
Unity’s reputation prior to this incident wasn’t high to begin with and the general consensus was that this was a move based on sheer greed. The resulting knock-on effects had many notable developers public claiming to not use Unity, or in some cases any other commercial engines again.
The relationship between a developer and a commercial engine is one based on trust, and in a few short weeks, Unity damaged the trust so badly, the development community is still reeling from it.
Whilst Unreal has made changes to their revenue model, even making it more attractive in recent years, the Unity incident still affected them.
This debacle reminded developers that commercial engines are still SaaS products and we are seeing an increasing enshitification of SaaS services across the world, primarily due to shareholder greed.
Because developing a game requires years of investment and money, many developers realised that they could potentially be too late in a games development to avoid any greedy license changes Unreal or Unity could do.
Whilst, Unity’s change caused a mass exodus of developers to adopt Unreal, it also caused a lot of interest in open source development tools like Godot.
This scenario notably impacted Indie and smaller developers, a large studio was unlikely to be using Unity in the first place, let alone consider Godot as a viable development tool. However, as larger companies consider what their options are, this will still have an impact on that decision.
Unreal Engine is owned by Epic, the company currently printing a billion dollars a minute thanks to Fortnight, however, those days won’t last forever.
Unreal at any point could change their fee strategy, which any major game in active development will be forced to accept just to release the game.
Unity’s fragrant greed has permanently damaged the trust between game developers and the licences software they pay to help develop their game. This incident will stay in the mind of all companies when it comes down to deciding what engine they develop their next game on.
Engine Direction
I’ve talked about how the commercial engines have their own strategic direction and both Unity and Unreal haven’t been coy about where they want to go.
Let’s start with Unity making a mistake again. Former Unity CEO and full time scum bag John Riccitiello said in an interview after Unity acquired IronSource, an unpopular ad-tech company, that developers who railed against micro-transactions in video games were “f**king idiots”.
This clearly set the tone that Unity’s focus was be supporting the development of games with enduring revenue models, which of course meant more money for Unity. Traditionally Unity was popular with indie games, a genre not really known for micro transactions, and so this made those developers feel like the engine wasn’t going to prioritise their needs.
Another direct both engines are keen to pursue at the cost of traditional games development is moving into support visual effects for TV and Movies.
Both studios made considerable upgrades and acquisitions to position their game engines as viable options for visual effects for streaming and cinema. Developers who rely on these engines to put up new features and updates to the engine for the purposes of their game development could feel that their needs were no longer a priority. Especially if their game wasn’t trying to be realistic or cinematic.
Finally, we come to the large elephant in the room, generative AI. Use of AI in games is a contentious topic as often these AI tools are trained on stolen property and threaten to put many of the industries professionals out of a job. This has lead to pushback from the community who view games that use AI as ‘bad’ and gaming platforms like Steam taking a difficult stance against games made with AI.
Despite this both commercial engines continue to develop AI features for their tooling, putting developers in a difficult position. Some, want to be able to make a game without AI, and some want to make sure that if they are using AI that the tools aren’t using stolen property that might cause negative backlash against their product.
Relying on a commercial game engine to develop your game puts you at the whim of their financial mode, their strategy, and their reputation, any of which could change against you and your game at any moment.
Whilst, plenty of titles have been developed using Unity and Unreal with little to no drama, the threat always remains and factors into a developers decision as to what engine to develop their next idea on.
That concludes part 3 of the series, stay tune for part four next week!
If you have enjoyed this piece or any of my other pieces of writing feel free to share I your channels!