Social Point technical lead for mobile, Sergi Vélez, talks through the process we went through to launch Dragon City for iOS. In this slideshare he explains each step, challenges and solutions, and the principal learnings.

1. Making Dragon City
Mobile
Sergi Vélez
@risdevs / sergi.velez@socialpoint.es

2. Social Point
•
•
•
•
Founded in 2008.
Top #3 social games developer in world.
8M DAU / 44M MAU
22@ Barcelona.
• 180 employees.

3. Dragon City
• Breeding game.
• Two basic gameplay mechanics:
• Collecting dragons.
• Battles.
• F2P.

4. Dragon City Canvas: Some basics
Voted 2nd best game in Facebook 2012.
Ranks 6th for DAU in Facebook.
• 6M DAU.
• 25M MAU.

5. Dragon City Canvas

6. Social Point
• Social Point got into mobile in 2012.
• Delivering same gameplay experience
across different platforms.

7. Dragon City Mobile
The game was re-written from scratch.
• 6 months in development.
• Mobile team created.
• 2 developers in beginning - 8 at launch.
• 5 developers maintaining game.

8. Dragon City Mobile
✓ World Launch: Feb 2013
✓ 1M DAU.
✓ iOS
✓ Android Oct 2013.

9. Prizes!
• Dragon City Mobile picks up 2 prizes at
Gamelab

10. How did we do it?
• The development experience:
Dev
QA
Launch
Post
Launch

11. Code Reviews

12. Code Reviews
• One-man armies don’t scale well.
• You’ll spend more time maintaining code
than creating it.
• Four eyes see better than two.

13. Code Reviews: Benefits
• Enables knowledge sharing.
• Improves quality of code.
• Mentoring.
• Collective code ownership.

14. Code Reviews: Our Method
• Git Flow.
• Each change is made on a separate branch.
• Pull Requests on GitHub to request reviews.
• Team reviews the WHOLE code.
• The WHOLE team reviews the code.

15. Code reviews: Advice
• Small code reviews.
• Preface your review with a short introduction
- explain the need for changes.
• Authority stems from knowledge, not
hierarchy.
• Each developer has his/her own solution.
• Review when you are having a break.

16. Code reviews: Advice
• The code is not yours.
• There’s always someone who knows more
than you do.
• Ask before you do a refactor.

17. Code reviews: Problems
• Not all code is fun to review.
• Programmers have different skills sets/
knowledge.
• You must know when a revision has been
approved – or not.

18. Code reviews: Problems

19. Tools

20. Creating Dragon City Mobile: Tools
• It’s important to use
good tools.
• Keep developers
focused on code.
• Bug Hunting.

21. Dragon City Mobile Build Pipeline
• Creation of the app: Jenkins.
• Distribution of the app: Testflight.
• Errors Report: Internal tool.

22. Build Pipeline: Jenkins
• Two daily builds (day and night).
• Two types of build:
• Debug
connecting to the development
environment.
• Production
connecting to production.
• Warnings when job fails.

23. Build Pipeline: Testflight
• Applications
distribution the way
it should be.
• Direct download into
the device from the
app.

24. Build Pipeline: Jenkins +Testflight
• All of Social Point has access to Testflight.
• Used by all departments
• QA – to access the most recent version.
• Game Designers – to check changes.
• Product owner – to test new features.

25. Build Pipeline: Crash Reporter
• Detects a problem with the application once
it’s live.
• Activates following a crash, sends a report.
• In production – requests permission from the
user:)
• Report helps us identify and fix error.

26. Build Pipeline: Crash Reporter
• Report covers:
• Stacktrace at the moment of crash.
• Environment information at moment of crash.
• App data.
• Log of significant events.

27. Build Pipeline: Crash Reporter
• Reports on :
• “Most Wanted”
• % of users
experiencing
crashes.
• Crashes by user.

28. Creating Dragon City Mobile: Launch
• Important to test the
game in “real world”
• With real players
• External QA
• Professional
companies
• “Amateur testing”

29. Publishing
• Your first submissions to AppStore can be
complicated.
• Bear Apple’s recommendations in mind.
• Don’t base hypotheses on other (published)
apps

30. Size of the Application
• Keep the app size below Store limits.
• Incentivizes impulsive downloads.
• Hard limit in Google Play.
• Downloads in the first session.
• Avoids negative first experience of game.
• Avoids problems in mobile networks.

31. Downloading Assets in the Background
• Minimum subset assets needed to load
game.
• In-app placeholders on demand.
• First session assets included.

32. Placeholders

33. Soft Launch
1. Launched in two countries only.
2. Monitored.
3. Launched an update with corrections.
4. Monitored.
5. World Launch.

34. Updates
• More complicated than the first launch.
• We can’t launch updates in one country
only.
• Regression tests.
• Compatibility with earlier versions.

35. Forced Upgrade
• At start up, game sends version number to
Backend.
• Login only possible in latest version.
• If older version, user re-directed to Store update to latest version.

36. Forced Upgrade
• Saves testing time.
• Saves supporting multiple versions.
• Improves the player experience.
• Gives cleaner analytics.

37. Real world problems

38. Rate me!
• Important to remember reviewers.
• Haters gonna hate.

39. Fallacies of Distributed Computing
• The network is reliable.
• Latency is zero.
• Bandwitdh is infinite.
• The network is secure.
• Topology doesn’t change.
• Transport cost is zero.
• The network is homogenous.

40. Fallacies of Distributed Computing
• The network is NOT reliable.

41. Communication with Backend
• Each action in the game generates a
“command”.
• Local commands queue.
• Server processes commands, sends an
OK/KO.

42. Offline Mode
• We adapt this solution to DC Mobile:
• Persistent queue of commands.
• If there is an error keep trying until resolved.
• Once you have started the game, you can
continue to play offline.

43. Offline mode: Problems
• Only one active session per user.
• No session “merge”.
• Dangerous if you play on various platforms
simultaneously.
• Loss of session in offline mode.

45. Creating DCm: Portable Code
• When creating DC iOS, we did not take
Android into account.
• We created too much non-portable code.
• Time spent on re-writes.
• New bugs.
• Solving bugs twice.

46. Creating DCm: Portable Code
• Think multi-platform.
• If it works, you’ll want to bring it to other
platforms.
• Take advantage of desktop tools.
• Leaks.
• Analysis of code.