What Engine Do Mobile Games Use?

This is a pretty common question that I get asked all the time. What engine do you use to make your mobile games? What engine does Clash of Clans use? What about PUBG? What engine does that mobile game use? As a veteran game developer, I’ll try and explain what’s the deal with the most common used engines for mobile game development. We’ll talk about the most commonly used engines, their advantages and strengths as well as home-grown, home-brew, custom engines and what it’s like to use your very own.

Your Answer Upfront:

Most mobile games use the Unity Game Engine which has an estimated market share of 50%. That means that half of the mobile games out there use Unity as their backend. The remaining games either use Unreal, Godot, Game Maker or more obscure or home grown custom engines. Studios like Gameloft for example, have their own internal game engines though even they sometimes rely on Unity or Unreal.

In this article we’re going to take a look at the most popular game engines that the vast majority of mobile games use. After that we’ll talk about custom engines that some games leverage and why they chose to do it that way together with some funny stories about the Game Engines that I personally wrote over the years. Finally, I’m going to list some game engines that I used together with their pros and cons. By the end of the article you’ll have a pretty good idea about what engine most mobile games rely on and use.

What Is A Game Engine?

A Game Engine is a set of tools, code and frameworks that help a developer write a game. Types of game engines vary from engines designed for a specific game type (FPS, RPG, RTS) to generalist engines that try to fill all the needs. They sometimes come with a Level Editor or a System for creating maps or in-game assets but it’s not a requirement.

That is a really broad definition of a game engine. Over the years the definition morphed as different developers and software studios increased their requirements and there’s a fine line between a Game Development Framework and an Engine.

Some people call Unity a Game Engine, because it offers an editor, a cross-platform rendering/input/sound/physics API and a well defined asset pipeline. But I’ve wrote tens of game engines in Unity so does that make it a Game Engine Engine? The fact of the matter is: there are as many definitions for what a game engine is as the amount of game engines out there. And there are a ton of game engines out there.

My personal definition? A game engine is a set of tools, code and assets that allows you to focus on the design and logic of a game and not on the low level details. Aka it saves you a ton of time when you don’t have to spend 80% of the time re-writing something that’s been done before.

In the next chapters of this article we’re going to take a look at the most commonly used engines for mobile game development. After that I’m going to talk about home-brewing your own custom engines and about my own engines. In the home-brew section I’ll go into more detail about different types of engines that don’t fit either definitions.

The Double-U Team: Unity and Unreal

Take out your phone and open up the App or Play Store. Go to a random category and download/install a Hyper/Casual game. Chances are, when it boots up, you’ll see the Unity Logo.

Now try your hardest to find a game that uses Unreal Game Engine. There are some, usually more higher quality games, like Mortal Kombat (Android, iOS). The game’s aren’t more high quality because they’re made with Unreal (as opposed to Unity). They’re more high quality because the types of studios that work with Unreal are veteran studios that have been licensing Unreal since the 2000’s. Unity only came along in 2010 ish.

Imagine spending 20 years of your time working with an engine (Unreal), improving it and knowing the ins and outs of it and then switch to a newcomer (Unity). You’d be throwing 20 years of experience, code and assets away.

A ton of people judge a game’s quality based on the engine but that can’t be further from the truth. Correlation doesn’t imply causation, as they say. There are more low quality games made with Unity because there are more new and inexperienced game devs using Unity than Unreal, due to Unity’s lower barrier of entry.

Let’s talk a bit about both engines before moving on.

Unity Game Engine

Unity is the game engine that earns my bread and butter. I’ve made tens of thousands of dollars with Unity-made games either as an Indie Game Dev or as a Freelancer/Work-For-Hire developer that makes client games.

I started using it in 2014 when I joined a Disney-employed studio to work on a game based on the Frozen IP. Up until that point I always made my own game engines and tools (level editors, character creators, asset pipelines, control schemes – you name it, I wrote it). What I loved about Unity is the abundance of resources available to the public. Got a question? Someone already answered it. Don’t know how to implement something? There’s a guide for that on the internet. Not sure how to export your build? There’s a system and a guide and a tutorial and 20 YouTube videos on the matter. Are you lacking 3D models, sounds or general assets? There’s a huge market place for it.

Unity made a name for itself based on convenience and ease of use. And this made it the perfect platform for everyone, from newbies who came onto the game development scene to the actual veterans who were making games since the early 80’s.

Unity basically does what a game engine should do and it fits the engine definition from earlier in the article perfectly: It does the basics for you and gets out of your way so you could program your own game logic and focus on design and production.

BTW, I wrote a big article that explains Why So Many Games Use Unity as a game engine! It’s a big article that delves into the engine in much more detail than this one and I recommend reading it to get some more insight!

Unreal Game Engine

I’ve been making games since around 2007. I started learning how to do it in 2005 and it’s around that time when I discovered Unreal as a Game Engine. I wanted so badly to work with it and use it for my own indie games.

There was a problem though…

I needed about $300k to even get access to it. I’m not kidding, licensing the Unreal Game Engine was expensive. If I recall correctly, it was $350k to license the engine to make a game with it + you’d have to pay royalties. Or pay about $1 000 000 (yes, 1 million dollars) as a flat fee and no royalties.

It’s safe to say that for a high-school kid that was out of the question. So I never got to license and use Unreal myself. In later years, Epic Games started embracing more lenient licensing options and there are quite a few Indie Games out there that use it.

If you’re beginning your game dev journey, at this point, you could go with either Unreal or Unity and have a pretty similar experience and evolution. The problem is, Unreal has 20 years of legacy behind it, with its original intent being to help you make amazing shooter games.

And after so many years, by default, it’s still geared to do that.

Left: Fornite, made with Unreal Game Engine. Right: Cuphead, made with Unity!

Differences between Unity and Unreal that nobody talks about

In this day and age there aren’t many differences and features between the two engines. In 90% of the cases one’s features are supported by the other. If you’re choosing between the two of them based on paper specs and outlined features you’ll be in for a very bad journey.

The internet is filled with comparisons between Unity and Unreal and both engines have their own fanboys. From my experience, gathered at various studios over the years, Unreal is just a bit more harder to get started with. It has layers and layers of complexities and tweaks that you have to overcome if you’re trying to do something different than what it’s setup for.

A small tangent, back I saw more than one Gameloft game get cancelled after >1 year of production because the team just couldn’t handle moving to Unreal from their own internal engine (called Glitch, based on Irrlicht IIRC).

This is not to say that Unreal is a bad or a hard to use game engine. It just has its own way of doing things that is built and based on decades old mentalities. For a veteran game dev that grew up with Unreal? Making games with Unity would be a chore. And it’s the same thing between someone used to Unity and having to move to Unreal.

My rule of thumb when starting out and choosing between the two engines is this:

If you just want to make games for fun, quick or as a hobby to learn? Go for Unity. Between its asset packs, tens of hundreds of thousands of resources (YouTube videos, articles, blogs, tutorials, etc) and newbie friendly approach I consider it to be the easiest engine to get started with between the two.
If you want to work at a studio that relies on Unreal Engine or you want to use a veteran game engine that your hero developers used? Go for Unreal.

In the end it’s what makes you happy. They both support a ton of platforms. They both have visual game programming support (Blueprints for Unreal, Bolt for Unity) and they are both proven engines that people use to release games. If using Unreal as a game engine gives you more will and pleasure, go for it and don’t let anyone stop you.

Just remember this one bit: Finishing and releasing a game is more important than what engine you use. So use what ever helps you finish and release the game.

Custom Game Engines

This is my favorite part of this article. Custom game engines are something that’s incredibly personal and endearing to me. I wrote a ton of projects that can be considered game engines for various platforms like:

Windows PC (using DirectX)
Linux and Mac (OpenGL or software rendering)
Nintendo DS & GameBoy Advance (using DevKitPro as a toolchain)
Commodore 64 in plain C using GCC or CC65 as a toolchain/compiler
68K Macintoshes from 1984 to 1995

The thing is, I never set out to write custom engines. Usually it was more like “I want to make X game” and over the development I ended up with a set of tools that, together with a code base that decoupled game logic from rendering/input/audio, ended up being a nice little engine and tool set.

When I write a game I separate the game’s code from the framework code. Usually I make a little renderer that I cobble together with what ever I have at my disposal (articles, tutorials, guides or old books) and I embed a scripting language like Lua.

Rendering, Input Handling, Physics and Asset Handling is done in a language like C or C# and the game logic itself is in a scripting language like I mentioned earlier (Lua). This helped me take a set of tools or frameworks I wrote on one platform and port it to another while keeping the game logic intact and portable.

An example of my own custom home-brewed game engine

Here’s an old-school dungeon crawler I wrote in C + Lua using an OpenGL framework called MOAI a few years ago:

Ebony Spire Heresy on PC (Linux, Windows, Mac, SteamOS)

And here’s the same game logic running on a Mac from 1987:

Ebony Spire Quest running on a Macintosh SE/30

The game logic (monster AI, item types, item behavior, weapon handling, dungeon generation, etc) is the same between the games and with very very little modifications. The underlining rendering and input handling code? Totally different.

But if we are to go by the textbook definition of what a game engine is? The code for the game is basically a game engine in itself. The same code can now be taken and I can make a first person shooter that runs on both platforms.

This also runs on mobile with some Android specific input handling code thrown in.

Ebony Spire: Heresy running on an Android Phone.

The funny thing about this engine that I wrote for a hobby/indie game all those years ago? It’s being used by other developers as well. The principle behind the engine’s structure and logic is based on a SDK or game framework called MOAI. Ebony Spire started as a game that used MOAI to handle the rendering, input and audio handling with the game logic being Lua code.

Later on, as I ported it to more and more systems, I couldn’t actually port MOAI’s code directly. However when I re-wrote my game for 68K Macintoshes and 1992 Commodores I followed similar conventions in the engine’s/framework’s architecture like MOAI did.

I then took the engine and I used it to write other games for Linux and even some handhelds (like the Nintendo DS). There’s no code used from MOAI on the Nintendo DS or Macintosh versions of my engine but spiritually they’re pretty similar.

Here’s the kicker!

The code that I wrote for the Nintendo DS game I mentioned? One of my clients had that ported over to Android for another game pretty similar to what I did for them. And now there’s quite a few games in the wild, on Android, written in C++ on a code based written for Nintendo DS lifted from a Macintosh 68K dungeon crawler game engine inspired by code written for a old school dungeon crawler developed on a mobile game dev framework that was used to make a PC Linux Game 😵‍💫. Can’t get any more bootstrap game dev shenanigans than that.

And you were wondering why I find the topic of Game Engines so endearing and personal :). It’s a pretty fun topic.

A List of Mobile Game Engines that I’ve used or bumped into over the years

Here’s the meat of the article and probably the reason you are here. Here’s a list of game engines that I personally used over the years with their pro’s and con’s, from my perspective.

Unity Game Engine
- Pro: Proven and offers a ton of resources. More than 50% of the mobile game devs actively use and release games with Unity, consistently.
- Con: it lures you into a false sense of security with its assets and templates. The ease of starting new features or integrating new ones is a feature creep trap that most beginners fall into. Remember: It’s always better to cut features than to never ship a game!

Unreal Game Engine
- Pro: Robust, highly proven, used by legendary developers, veterans and indies alike. A huge community, documentation spanning over decades and more powerful than most offerings out there.
- Con: it has decades of legacy design decisions and requires much more expertise in fiddling with it and getting to know it. It will take longer, when you are starting out, to make a game with it. Most of your early development time will be spent wrestling and learning the engine itself.

Godot
- Pro: A darling truly independent engine for the modern age made openly with the community. The amount of documentation, resources, tutorials and features for Godot is increasing day by day with more and more developers using it.
- Con: tentatively unproven yet. I don’t know many block busters and devs using it but this is due to change pretty soon. A lot of indie devs in my circles are moving to it from Unity due to Unity’s recent corporate approach.

Game Maker Studio
- Pro: Proven, easy to get into, great for quick 2D and 3D games. It allows you to focus on the game and less on the technology side. Used by many successful mobile game devs out there (like Vlambeer).
- Con: A bit different than traditional game engines. More of a designer tool than a coder’s playground (which, shouldn’t technically be a bad thing. Depends on what you want to do)

AppGameKit
- Pro: Developers behind AppGameKit have been making game engines, game frameworks and game tools since the late 90’s. I personally started out making games with their Dark Basic programming framework in 2004-2005 and moved over to DarkGDK (C++ + DirectX wrapper with a DarkBasic-like syntax) in 2007. An amazing yet little known community of game creators with veteran developers.
- Con: Obscure, not extremely well known. It’s more of a Niche game engine for people used to the GameCreator’s software. Powerful and ever evolving.

Most mobile games use the Unity Game Engine which has an estimated market share of 50%. That means that half of the mobile games out there use Unity as their backend. The remaining games either use Unreal, Godot, Game Maker or more obscure or home grown custom engines. Studios like Gameloft for example, have their own internal game engines, though even they sometimes rely on Unity or Unreal.

Where To Next?

This is the sixth article in my series of articles about being Game Development in the Mobile Gaming Industry. You can read the other articles in this series:

If you want to learn more about mobile game development you can checkout my article series on Game Development on this blog. As for more mobile gaming content I have you covered on all areas, from Reviews to Resources that can help you find new amazing mobile games.

I write extensively about the mobile gaming industry, their tactics and how greed influences a game’s design. I believe that you might be interested in more articles about the mobile gaming industry. So if you want to stick around, you can check out “What’s the difference between Fremium, Free To Play and Pay 2 Play“, “Why Voodoo Games Are Popular” and “Why Do Mobile Games Take So Much Space“.

There’s also a monster post (about 4000 words) that answers the question: “How Hard Is It To Make A Mobile Game“. It goes in depth with actual examples on how Experience, Resources and Financials affect the difficulty of developing and releasing new mobile games!

If you like our content and want to stay up-to-date, you can subscrie via the mailing list widget on this page! Or give us a follow on twitter. Is there something else you’d want covered on our Best Smartphone Games blog? Let us know in a comment below.