Jump to content
  • Advertisement
  • Remove ads and support GameDev.net for only $3. Learn more: The New GDNet+: No Ads!

  • 07/07/16 08:34 PM
    Sign in to follow this  

    Designing a Mobile Game Technology Stack

    General and Gameplay Programming

    rumargaming
    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.
    1. The mobile app
    2. The back-end API
    3. The cloud hosting stack
    This is a schematic overview of the stack:
    technology_stack.jpg

    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
    • 750 hours per month of EC2 time (so that's one instance for a full month)
    • t2.micro instance: 1 vCPU with 1 GB RAM (you can run Windows Core on this)
    S3
    • 5 GB storage
    • 15 GB data traffic
    • 20.000 Get requests
    • 2.000 Put requests
    SNS
    • Up to 1 million push notifications sent.
    Cognito
    • 1 million sync requests per month
    • 10 GB sync storage
    Production scenario I'm making the following assumptions:
    • You have 1.000 daily users.
    • Users generate 10.000 sessions daily.
    • Users generate 500.000 API requests daily.
    • Each daily user is unique (for sake of Cognito calculation)
    • A user profile contains 100kb of data.
    • Each user received 10 push notifications daily.
    • Each API request triggers 5 database requests.
    EC2
    • 500.000 API requests daily will average to around 6 requests per second.
    • Your API can run fine on a 1 vCPU / 4GB RAM system.
    • In that case a t2.medium instance will suffice, total costs: $56
    • Scaling works by adding more machines, thus multiplying these costs.
    Cognito
    • Monthly sync operations: 10.000 sessions * 31 days * 2 syncs per session = 620.000
    • Monthly charged: (620.000 / 10.000) * $0.15 = $9.30
    • Profile storage: 31.000 users * 100kb = 3.1 GB * $0.15 = $0.47
    • Free tier for the first 12 months!
    • After that: $9.80
    SNS
    • Monthly notifications: 31.000 users * 31 days * 10 notifications = 9.61 million
    • Monthly charge = 9.61 * $0.50 = $4.80
    DynamoDB
    • Total requests: 500.000 API requests * 5 databases requests * 31 days = 77.5 million
    • Total storage: 10 GB
    • Free tier for the first 12 months!
    • After that: $10 (very hard to estimate, but it's on the high end)
    MONTHLY COST: $60.80 (after free tier: $80.60) If your API requires redundant servers: $116.80 (after free tier: $136.60) Additional This is assuming your need blog storage for your game:
    • You need 1 TB of blob storage, each user does 100 put+get requests daily.
    • You want full backup of blob storage (highest price).
    S3
    • Storage: 1 TB = $30
    • Requests (100 GET + 100 PUT per user daily): 3.1 million GET + 3.1 million PUT = $31
    • Total: $61
    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! This article was originally posted, in slight different form, on the Rumar Gaming Blog.


      Report Article
    Sign in to follow this  


    User Feedback


    The stack seems highly scalable. I am not familiar with aws, but could you give some idea about cost?

    Let's say an estimation if you were to have a very small number of active users (***vs a large number.

    What would this configuration cost for a 50 daily active users vs 1000 daily active users.

    I know it might be implementation and API usage dependent but a rough estimate will give a better view for the people interested.

     

     

     

    On another note; in my opinion, I have built a lot of cross platform mobile games and apps. At the end of the day, you will be handling iOS and Android API calls in a different matter. My pref. is to go native.

    If you want a bit of a higher abstraction layer for graphics, use Cocos2D. But still go native. If you are doing the game, the only true cross platform calls are the openGL and game logic ones. That could be built into some kind of re-usable framework. Going native allows to optimise and to adopt new SDK features in an efficient matter. The fear (at least the one I had) of duplicating code or extra time spent "adapting" to another platform will not matter after the first project is done. 

    Share this comment


    Link to comment
    Share on other sites

    Hi jsaade,

    Thanks for the feedback!

     

    It's difficult to give a clear cut cost estimation because it depends on a lot of factors, but I will do my best to work out some scenarios as I understand it's very useful to people that read this article.

    I'll update the article later this week with the estimation.

     

    During development it won't cost you anything because the Free Usage Tier of AWS will be sufficient in most cases (assuming you're developing with a small team and your API does not take require massive resources).

     

    Good advice on the cross platform bit.

    It may very well be that I decide the same thing after a while :)

     

    Cheers,

    Ruud

    Share this comment


    Link to comment
    Share on other sites

    Article was good and the most of the part was well explained. I have been a part of Apps & Games  cost estimation team and we used to our whole mind into it to provide the best service in valid cost. I have just shared my [LINK REMOVED BY MODERATOR] which talks about apps cost estimation have a look into it and Please provide your valuable comments.

    Share this comment


    Link to comment
    Share on other sites

    I am higly interest in developing using xamarin, could you write some stuff about that ? Performance, tips, focus on game development etc, thanks :)

    Share this comment


    Link to comment
    Share on other sites

    I have just shared my blog which talks about apps cost estimation have a look into it and Please provide your valuable comments.

    Sharing relevant and helpful links is encouraged here, but I've removed your link as spam, because while it does "talk about apps cost estimation" it doesn't actually provide any useful information at all -- honestly it really just reads like you cut and pasted some basic information gleaned from trivial searches together, and didn't bother to add any value.  The way your post was written people would expect to find some information that would help them to estimate the cost of apps, and you didn't even attempt to deliver that.

     

    Please don't spam article comments unless you have a link that is both relevant and actually offers useful information.

    Share this comment


    Link to comment
    Share on other sites

    I am higly interest in developing using xamarin, could you write some stuff about that ? Performance, tips, focus on game development etc, thanks smile.png

     

    While development progresses I will blog regularly about it on the Rumar Gaming blog.

    If I feel that a certain topic is interesting enough for a bigger crowd I revise/extend the post about the topic and post it here on GameDev.

    So yes, I will write about that stuff in the coming months!

    Share this comment


    Link to comment
    Share on other sites


    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!