Embedded games in mobile apps: Make your app more attractive

If a developed product was exclusively a game, we would use existing game frameworks such as Unity, Unreal Engine, or the slightly lesser known Godot or Cocos2Dto develop it. There are many of these frameworks, and we would find even more libraries. Nonetheless, our focus will be on a slightly more specific topic: How to embed a game into an existing application?

* The difference between a framework and a library is excellently described in this article.

What is an embedded game?

From an embedded game, we expect several specific features/abilities:

• we can open the game from any part of the application,
• the game will run within the application - it will not launch a new standalone application,
• two-way communication between the game and the app - the ability to send data from the native app to the game and vice versa.

Of course, additional questions may arise... Will the game only take up part of the screen or will it be fullscreen? Will it be 3D, 2D, or utilize physics like collisions or free fall?

Native development

The classic problem with native development is duplicate implementation. Everything we code for Android must be coded again fot iOS. At the same time, if we wanted to create an app even slightly more complex than a memory game, we'd have to use a helper library (or write the entire game cycle and physical engine ourselves). These helper libraries have different interfaces for mobile platforms because they are language specific. Android would have to use LibGDX, or Korge, while iOS would probably utilize SpriteKit.

That's a brief overview of limitations, or rather, disadvantages. The advantage, of course, is the extremely good integration between the app and the game. Basically we have unlimited possibilities. Some of them require minimal effort, while others could drive you to gray hair.

Multiplatform development (Flutter)

An alternative to native development is multiplatform development. Personally, I consider only Flutter, Kotlin Multiplatform, and in some cases React Native to be viable multiplatform solutions. React Native is not always a good choice due to performance (debatable), Kotlin Multiplatform is suitable for shared application logic, and although we already have Compose Multiplatform, we definitely can´t talk about suitable support for game development. With this method of elimination, we're left with Flutter and the game library Flame.

Multiplatform development will solve the problem of the number of programmers working on the game. With an experienced programmer, it will also reduce the time required for development, but there´s a catch:

• Harder programmer substitutability. Flutter programmers are fewer than native programmers.
• The size of a multi-platform application is slightly larger (article on this topic for the Flutter framework).
• Adding a game to an existing native application is more problematic (documentation for the Flutter framework).

However, multiplatform game development is advantageous from a time perspective. But in case we are not sure about the mentioned substitutability, we avoid it completely.

Game engines (Unity)

If we wanted to use more familiar tools for game development, we should reach for game engines. So let's look for alternatives.

We won't need to search for long. Maybe someone might correct me, because I haven't gone down this path yet, but only the Unity Framework seems to come into consideration. It comes into consideration because it's the only one that is able to function as an embedded engine with two-way communication with the native application. The other engines are unable to receive commands from the native application, send results from the game to the native application, or neither.

So, Unity and its disadvantages:

• Unity must display the UNITY logo at startup,
• The app size is the largest compared to the other options,
• It´s unnecessarily extensive for smaller games.

However, within this framework, we can create anything. The C# language is more pleasant than Dart in Flutter, and there are plenty of enthusiasts who have created at least a basic game in Unity. Why we don't choose it is usually the app size, the unnecessary extensiveness, and a bit of unfamiliarity with the language.

Conclusion

If we want to embed a game into an existing application, we have 3 alternatives:

• Native development (Android - Kotlin, iOS -Swift)
• Multiplatform (Flutter)
• Game engine (Unity).

We reach for native development if the game is very tightly integrated with the app and we can afford to use two people to "duplicate work". Once the game gets a bit more complex, developers of both platforms seem to lose the ability to control each other as well, due to the huge differences in the tools used.

The Flutter is a middle path, which we have taken a couple of times as well. We get rid of duplicate work, even the big hammer of huge game frameworks. However, we will suffer from the difficulty of the language and learning a relatively unknown game engine.

The Unity is a great solution if the game is to become a core element of the application or be more complex. Developer representability may not be a disaster, but for most embedded games Unity is unnecessarily large. If you want to make a game in 3D, you probably can´t avoid using Unity.

We don't have a definitive winner for all types of apps, but we have at least an approximate idea of how to decide. If you have personal contributions to embedded games, we welcome every constructive thoughts.