For competition in the mobile gaming industry getting fierce, mobile game developers now face tough challenges including handling a different service landscape and working on a tight time budget. These obstacles lead the developers to seek handy solutions to abstract away development complexity and to reduce overall development cycle. This talk will focus especially on the back-end side of mobile game services. It will first review issues in mobile game services, then highlight the requirements of back-end services for the services. Finally, the talk will propose a vertically-integrated back-end platform.

1. Designing a Pragmatic Backend
Service for Mobile Games
DK Moon (dkmoon@ifunfactory.com)
November 13 2013

2. Cliche: Mobile Game Segment Growing Super Fast
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
2013 2014 2015
Video Game Market Revenue Growth
Mobile Games Video Game Console PC Games
Source: Gartner (October 2013)

3. Game Development Ecosystem
Game
Server
Game
Client
Internet

4. Game Development Ecosystem
Game
Server
Game
Client
Internet
Game concept
Game logic design
Game balance

5. Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance

6. Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset

7. Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너

8. Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너
Client app impl.
Game logic impl.

9. Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너
Client app impl.
Game logic impl.
소프트웨어 엔지니어

10. Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너
Server app impl.
Game logic impl.
Client app impl.
Game logic impl.
소프트웨어 엔지니어

11. Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너
Server app impl.
Game logic impl.
Client app impl.
Game logic impl.
소프트웨어 엔지니어
소프트웨어 엔지니어

12. Data center
DB
Server
Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너
Server app impl.
Game logic impl.
Client app impl.
Game logic impl.
소프트웨어 엔지니어
소프트웨어 엔지니어

13. Data center
DB
Server
Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너
Server app impl.
Game logic impl.
Client app impl.
Game logic impl.
소프트웨어 엔지니어
소프트웨어 엔지니어
Server mgmt
Server monitoring
Log analysis
시스템 엔지니어, DBA

14. Data center
DB
Server
Game Development Ecosystem
Game
Server
Game
Client
Internet
게임 기획자
Game concept
Game logic design
Game balance
Game graphic asset
게임 그래픽 디자이너
Server app impl.
Game logic impl.
Client app impl.
Game logic impl.
소프트웨어 엔지니어
소프트웨어 엔지니어
Server mgmt
Server monitoring
Log analysis
시스템 엔지니어, DBA

15. Who is the key player?
Mobile game is an entertainment business targeting end users.
Hence, game designer and graphic designer are important.
• They determine look & feel. Also, game logic.
• But it assumes your engineers do not break anything.
Unfortunately, they will.
Engineers cannot guarantee success, but can lead to failure.
• Software reliability is crucial.
• But very hard to find decent, experienced engineers.

16. Resource Requirement to Build a Mobile Game
Depending on game scale
• Casual games vs. mid-core games vs. hard-core games
If building a casual game…
• Around 300M KRW investment
• less than 10 members
• 6-9mo development
• 6-12mo service

17. Sorry, Buddy. Things Are Getting Worse.
Competition getting fierce
Need to design bigger games
• More people & time. Hence, more cost…
Need to shorten time-to-market
• More people. Again, more cost…

18. Efforts to Reduce Development Cycle
Client-side
• Relying on client engines (e.g., Unity3D, Cocos2D, …)
Server-side
• Hardware: using IaaS cloud for server provisioning. (AWS)
• Software: leveraging web server technologies.
• Game features: Adopting external components/services.
(e.g., leaderboard, community)

19. Incompleteness of existing server-side solution
IaaS helps, but to a limited extent
• Installing OS is not what engineers spend most of time.
• Converting into game server is the most time-consuming and error-prone.
Not all games are built on top of web server
• HTTP works on a request-response basis.
 Complex games require complex communication patterns.
• Web server is stateless in general.
 Even trivial operation should hit database.
Integrating into external service takes time.
• Also gives learning curve.

20. Backend Service for Mobile Games
A set of hardware resources and software components accessible
via API to resolve issues in building mobile game server and related
infrastructure.

21. Mobile Game Backend Design Space
Infrastructure
Game server core
In-game components

22. Design Consideration #1: Infrastructure
Cloud storage
• For player profiles and game achievements
• Exposing DB interface vs. providing API?

23. Design Consideration #1: Infrastructure
IaaS
• Game developers manually configure machine.
• Tools are at the granularity of machine (CPU, RAM, Disk, Traffic, …)
• Bare-metal provisioning vs. VM provisioning?

24. Design Consideration #1: Infrastructure
PaaS
• Cloud instance is pre-configured as game server.
• Tools are at the granularity of game (#sessions, #items, …)
• Might include push server, player mgmt tools, etc.

25. Design Consideration #2: Game Server Core
Networking
• Message format (custom format vs. Protobuf/Thrift/JSON/…)
• Operating layer (session layer vs. transport layer)
• External integration (authentication, billing, …)

26. Design Consideration #2: Game Server Core
Database abstraction
• Explicit database calling vs. transparent database handling

27. Design Consideration #2: Game Server Core
Library vs. Framework
• Actively call into vs. Passively invoked.

28. Design Consideration #2: Game Server Core
Programming model
• Procedural vs. Event-driven vs. Declarative vs. …

29. Design Consideration #3: In-game Components
Components implementing game features
• Leaderboard, Chatting, Virtual currency, Matchmaking, AI
• Genre-specific in-game components
• …
Components architecture must be extensible
• Tightly-coupled vs. loosely-coupled
• SDK approach vs. API approach

30. Short Survey on Backend Solutions
PlayerScale OpenKit Scoreoid Player.IO
Google
(App Engine /
Compute Engine)
In-game components
Yes
(leaderboards, chat,
virtual currency,
matchmaking)
Yes
(leaderboards)
Yes
(leaderboards, in-
game notifications,
achievements)
Yes
(lobby, chat)
Yes
(leaderboards,
achievement)
External integration
Payment
Authentication
Authentication Authentication
Payment
Authentication
Analytics tools Yes Yes Only for error logs Yes
Cloud Storage Yes Yes Yes Yes Yes
Player management Yes Yes
Game server core Only for Flash
Infra support other
than cloud storage
* Information gathered from official sites.

31. Short introduction on my work
Funapi
• Game server framework.
• Developers implement only game logic. Then, Funapi does the rest.
Argus
• PaaS cloud specialized in mobile games
• Developers focus only on game server. Then, Argus does the rest.

32. Lessons from designing a backend service
Must be fool-proof
• Not all game developers share the same skills set.
• Do not blame game developers.
• If they fail, double-check if fool-proof.

33. Lessons from designing a backend service
Must be out-of-the-box
• Extremely tight time budget in game development.
• Do not expect game developers to eagerly go thru learning curve.
• If your backend service has high learning curve or
requires extensive integration work, it is less likely to be adopted.

34. Lessons from designing a backend service
Think deployment scenario from the beginning
• Extremely difficult to pull back once deployed.
• Versioning should be in place from the beginning.
• Package manager like Debian APT is worth referring to.

35. Questions?
dkmoon@ifunfactory.com