Designing a Mobile Game Technology Stack

A lot of technology goes into developing stable, scalable mobile games. At Rumar Gaming we have invested a lot of time in building a solid platform before even thinking about game ideas. Our goal was to be able to develop a large variety of games in a short period of time by sharing the underlying technology stack.

This article describes the technology stack that we designed and that allows us to release new games rapidly without having to worry about non-gameplay functionality, databases or API hosting.

Stack overview

We separated the technology stack into three main tiers, each consisting of several sub tiers and I’ll discuss each one of them in more detail.

This is a schematic overview of the stack:

1) The mobile app

When we decided to start Rumar Gaming there was no doubt that we would be using Xamarin for our mobile development. Our games need to support both iOS and Android, so using a cross-platform development environment can cut our development times significantly. In my opinion, Xamarin is by far the most mature option for cross-platform mobile development. Add the fact that I’m an expert at C# and already have experience developing games in Xamarin and it was a done deal.

The mobile app itself consists of three tiers (from the bottom up):

Rumar Framework
This is our custom framework which contains the interfaces and logic that are shared by all the games.

Aside from holding some utility classes, its main responsibility is communication with the API to handle - among other things - device registration, session management, score registration, in-app purchases and advertisements.

The framework is mainly cross-platform, but has some platform-specific functionality on top of it as well. For example, in-app purchases need to be handled differently in iOS and Android.

Game-specific logic
This tier contains cross platform, game-specific logic. We try to put as much of the game logic in here as possible so we only have to develop and manage it once for both platforms.

iOS- & Android-specific logic
You will always need to have separate projects for each of the supported platforms because of platform-specific logic that is required.
 

2) The back-end API

The games need a back-end that handles things like registration of devices, session management, push notifications, authentication and score tracking. Again, the goal here is to share as much logic as possible through one framework API, but some game-specific functions will get their own API.

We’ve decided to use the .NET Web API framework for this, mainly because of our long history with .NET. The main alternative for us was node.js, which would be somewhat easier to scale, but because of a limited development timeframe we decided not to take the risk of choosing a technology we are not yet comfortable with.

By hosting the API on Windows Server Core instances, we are still able to cut down on hosting costs. More on this will follow in the next section.
 

3) The cloud hosting stack

No one can predict if (one of) our games will become a hit, although we are certainly doing our best covering all grounds to increase our chances. If a game does become successful, the back-end must be highly scalable. It should not matter whether we have 10 users or 1 million users, the back-end should perform in the same way and it should not require a lot of effort (ideally, not any effort) to scale it up.

So we are hosting the back-end in “the cloud” and we have chosen Amazon Web Services (AWS) for this because we have been really satisfied using it in the past. I’m definitely not suggesting you should not look into other services like Microsoft Azure or Google Cloud Services! AWS was the best fit for us, but it may be different in your situation, so I encourage you to do a comparison yourself first.

Let’s take a look at the moving parts of our cloud hosting stack.

EC2
The API will be hosted on EC2 instances. EC2 stands for Elastic Computing Cloud and offers you virtual machines to host your application. They can be automatically scaled up and down depending on traffic and performance requirements, meaning that – during upscaling - new instances are automatically deployed and added to the load balancer.

By hosting our API on Windows Server Core instances we save money on both licensing and computing. Core instances require less system resources, are deployed faster and because you don’t get a full Windows interface you pay less money for their license (which is integrated in the costs per hour). 

Cognito
Cognito is used for authentication and user management. It offers several authentication providers and out of the box functionality for user data synchronization.

When a player starts a game session, we can start storing user data (such as game preferences) on the device. If the player gets authenticated at some point – by creating an account or using a social login provider – the offline user data will be synchronized to the cloud.

S3
Amazon’s Simple Storage Service (S3) is used when an app requires to store blob data such as images or videos. The keyword here, again, is scalability; we don’t need to worry if we store 1 asset or 1 billion assets, it will just work and we only get billed for what we use.

SNS
SNS stands for Simple Notification Service and it’s used to register devices for push notifications and to send the notifications. It supports both iOS and Android so that’s perfect. You only pay when you are sending out notifications and even then it’s free for the first million notifications.

DynamoDB
DynamoDB is AWS’s answer to No-SQL databases. It will be used to keep track of game sessions, progress and high scores. No-SQL doesn’t necessarily have to be the best choice when developing a mobile API, but it is certainly the easiest to scale and very cheap in use. So taking that into account – scalability and cost – DynamoDB seems to be the best choice for us.
 

Bottom up approach

When talking about developing games, most people expect you to start with a game idea and design the rest around that. The question I get the most from my acquaintances is “do you guys have any cool game ideas yet?”

Well yes, we do have some rough ideas, but that’s not what we are focusing on in the beginning. We are taking a bottom up approach, meaning that we start with setting up the cloud hosting stack, then we develop the framework API and we slowly work our way up to the game logic. 

Even though we are really excited to start working on the actual games – which is definitely the most fun thing to work on - in order to create something that will scale and is future proof, we must start at the bottom.
 

Cost estimation

The monthly cost of this stack depends heavily on the size of your userbase and the requirements of your API, but I have worked out an estimation based on some assumptions.

Development
During development you're good to go with the Free Tier; the free tier is available for the first 12 months.
The numbers below are based on monthly use.

EC2

S3

SNS

Cognito

Production scenario
I'm making the following assumptions:

EC2

Cognito

SNS

DynamoDB

Monthly costs: $60.80 (after free tier: $80.60)
If your API requires redundant servers: $116.80 (after free tier: $136.60)


Blob storage scenario
This is assuming your need blog storage for your game:

S3

I hope you enjoyed this article and can put it to good use during your own mobile game projects. As development of Rumar Gaming progresses, I will regularly write new articles on what we are doing and how we are solving common issues to you run into during (mobile) game development.

Any comments and questions are more than welcome and I’ll be happy to give you my feedback on them!