3
\$\begingroup\$

I'm developing a mobile social game, it's a puzzle with a social layer similar to the one in Candy Crush Saga (limited lives, can send life requests to friends, facebook leaderboards, etc). I know all top mobile social games have a backend, but I don't understand what's the purpose of it, is it only to persist game data? Assuming I'm not interested in persist game data online, do I need a backend server?

My idea was to handle all players' interactions through facebook (life request, leaderboards, etc). Is this possible without my own backend?

Any information on what are the benefits of having a backend for a mobile game is welcome.

Improve this question
\$\endgroup\$

4 Answers 4

Reset to default
5
\$\begingroup\$

There are several reasons why to use a backend. Without backend, you can't really have states in your game. That means players start all over when they refresh the web page. The facebook API stuff that you mentioned also comes from backend. You can do lots with facebook API, but it's not even pretending to cover all the cases. Facebook recommends Parse.com for your backend needs.

Backend is used:

  • To not give all the code to your users
  • To run some game logic at backend, so cheating is harder
  • In App purchase item ownership data that should be kept out of players' reach
  • To port the game to multiple devices. Logic running at backend makes it easier
  • To fine tune game without shipping new client all the time
  • To collect data about user behaviour
  • To store player progression

This is just what comes from top of my head, I'm sure there are more reasons. It depends on your game if it really needs backend, but most likely it does. There are multiple web services that offer backend as a service (BAAS) if you lack the knowledge or will to make your own.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

You should see the back-end as a centralized component for storage and processing. This structural component is used for various reasons.

  • Storage: the state of your game will be stored on the back-end. "State" refers to all parameters that need to be stored persistently. For example, you need to store the level progression of the player. You have two options here: either you store the state on the user's device, or on a centralized back-end. The back-end offers various advantages. First, the user will be able to resume the game from any device (eg. he could start playing on his computer and switch to mobile device the next day). Second, other players can see the player's score. This is a requirement for leaderboards ... etc.

  • Communication: your game might require a form of inter-player communication. You mentioned messages to friends. Sending lives to other players, playing with or against them, ... are also often available in games. When it comes to messaging, the devices of you and your friend don't communicate directly. Instead, your message is sent to the server, so that your friend can receive it once he is online. This means that you don't both need to be online in order to be able to communicate. Furthermore, by passing messages via the server you could apply filtering for spam ... etc.

  • Security: code that is stored on a back-end server is "safer" from hacking than an all-client application. The back-end serves as a black box. This means, your game client sends messages to the back-end, and the back-end sends a reply. How the request is actually processed in the back-end is not visible from the outside world. This could be useful if you, for example, want to give players a limited amount of lives per hour. Using app purchases to give them more lives. By storing the number of lives left on the back-end server, hackers can not simple spawn in extra lives by tinkering with the save file on their device. An option for hackers would be to write a server emulator, but this is far more complex than client-side hacking.

There are numerous other advantages, but overall using a back-end component in mobile game architectures has proven to be advantageous (if not essential). Not that you referred to using Facebook instead of a custom back-end. Technically, facebook would be your back-end component in this case, aka. a centralized platform for storage and processing. A custom back-end is prefered as you can incorporate all funcitonality your app requires. The facebook API is a more general purpose back-end, not tailored to fit your application.

To summarize, a back-end component has so many benefits, that it is almost impossible to avoid using one in mobile games. While using the facebook API is possible for general-purpose operations, a custom back-end is recommended to tailor it to fit the needs of your application.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

I recommend you look as some of the many BaaS available for mobile game developers. Some are free for non-commercial use or pre-launch development. Here's a few (there are many more):

  • brainCloud
  • Gamedonia
  • GameSparks
  • Gamua Flox
  • PlayFab
Improve this answer
\$\endgroup\$
0
\$\begingroup\$

Most use an established back-end to abstract over the boring stuff and the long term overhead of building and running your own back-end stack. Pass it off to someone else, pay them a few cents a day, so you can focus on monetizing your game instead of busywork (OS patching, capacity planning, etc.).

I don't understand why anyone would consider building their own back-end when so many good and affordable mBaaS solutions exist. We have been using such a service at our company for about 3 years; it removed lots hassle pretty much overnight. All our techs are now focused on good stuff rather than up to their armpits in DevOps.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .