Technology stack design
Because I want to publish several games within a reasonable time frame, it makes sense to have them share as much logic and technology as possible.
I have designed a technology stack that should be able to support all the games I’m planning to release within the first four months and possibly for many more months after that.
Stack overview
I have separated the stack into three main layers and I’ll discuss each one of them in more detail.
- The mobile app.
- The back-end API.
- The cloud hosting stack.
1. The mobile app
When I decided to start Rumar Gaming there was no doubt that I would be using Xamarin.
Because I’d like to support both iOS and Android, I need a cross platform development environment and Xamarin is by far the best option in my opinion.
Add the fact that I’m an expert at C# and already have experience developing games in Xamarin and it’s a done deal.
This layer consists of three tiers:
Rumar Framework
The framework contains the interfaces and logic that is shared by all the games.
Its main responsibility is communication with the API to handle, among other things, device registration, session tracking, high score registration, in-app purchase and advertisements.
Game-specific logic
This tier contains cross platform game-specific logic.
I will try to put as much game logic in here as possible so I only have to create and manage it once for both platforms.
iOS/Android-specific logic
Finally there must be some logic that is specific for one of the platforms.
For example, in-app purchase will work differently in iOS and Android.
2. The back-end API
The games need a back-end that handles registration of devices, push notifications, highscores, etc.
I’m leaning a lot towards using the .NET Web API framework for this, but it’s still open for debate.
3. The cloud hosting stack
No one can predict if one of the games will become a hit, but if one does the back-end must be scalable; it should not matter if I have 1 user or 1 million.
In order to be scalable the back-end will be hosted in the cloud.
Since I already have experience with AWS (Amazon Web Services) and I’m really satisfied with it, this is the obvious choice for me.
EC2
The API will be hosted on EC2 instances.
They can be automatically scaled up and down depending on traffic and performance requirements.
Cognito
Cognito is used for authentication and user management.
When someone starts a game session I can start storing user data (such as game preferences) on the device.
If the user gets authenticated at some point – by creating an account or using a social login provider – the offline user data will be stored in the cloud.
S3
Whenever a game requires storage for larger amounts of data – for example, images or videos – it will use S3. The keyword here, again, is scalability; I don’t need to worry if I store 1 asset or 1 billion, it will just work.
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.
DynamoDB
DynamoDB is AWS’s answer to No-SQL databases.
It will be used to keep track of game sessions, progress and high scores.
Honestly, I don’t have a lot of No-SQL experience yet and I would prefer to use SQL Server, but that will get really expensive when it needs to scale.
So taking that into account – scalability and cost – DynamoDB seems to be the best choice.
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 is “do you have any game ideas yet?”.
Yes, I have some arbitrary ideas, but that’s not what I will focus on in the beginning.
I will take a bottom up approach, meaning I start with setting up the cloud hosting stack, then the API and work my way up to the game logic.
Even though I’m really excited to start working on actual games and it’s the most fun thing to work on, in order to create something that will scale and is future proof, I must start at the bottom.
To be continued
As I’m working my way through developing this stack, I will update the blog with my progress.
If you have any comments, suggestions or questions, I would love to hear them from you!
