Creating Dragon City for Mobile

17,744 views

Published on

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.

4 Comments
1 Like
Statistics
Notes
  • Free Download : https://www.mediafire.com/?8nz717bo19i6uv7
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Download Here :http://po.st/AnJAJa
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Free Download : http://www.mediafire.com/download/yfbh2lkl8a4z3vi/Setup
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Mediafire Download : http://www.mediafire.com/download/7aoel0kpzvwnzeh/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
17,744
On SlideShare
0
From Embeds
0
Number of Embeds
14,664
Actions
Shares
0
Downloads
13
Comments
4
Likes
1
Embeds 0
No embeds

No notes for slide

Creating Dragon City for Mobile

  1. 1. Making Dragon City Mobile Sergi Vélez @risdevs / sergi.velez@socialpoint.es
  2. 2. Social Point •  •  •  •  Founded in 2008. Top #3 social games developer in world. 8M DAU / 44M MAU 22@ Barcelona. •  180 employees.
  3. 3. Dragon City •  Breeding game. •  Two basic gameplay mechanics: •  Collecting dragons. •  Battles. •  F2P.
  4. 4. Dragon City Canvas: Some basics Voted 2nd best game in Facebook 2012. Ranks 6th for DAU in Facebook. •  6M DAU. •  25M MAU.
  5. 5. Dragon City Canvas
  6. 6. Social Point •  Social Point got into mobile in 2012. •  Delivering same gameplay experience across different platforms.
  7. 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. 8. Dragon City Mobile ✓ World Launch: Feb 2013 ✓ 1M DAU. ✓ iOS ✓ Android Oct 2013.
  9. 9. Prizes! •  Dragon City Mobile picks up 2 prizes at Gamelab
  10. 10. How did we do it? •  The development experience: Dev QA Launch Post Launch
  11. 11. Code Reviews
  12. 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. 13. Code Reviews: Benefits •  Enables knowledge sharing. •  Improves quality of code. •  Mentoring. •  Collective code ownership.
  14. 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. 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. 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. 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. 18. Code reviews: Problems
  19. 19. Tools
  20. 20. Creating Dragon City Mobile: Tools •  It’s important to use good tools. •  Keep developers focused on code. •  Bug Hunting.
  21. 21. Dragon City Mobile Build Pipeline •  Creation of the app: Jenkins. •  Distribution of the app: Testflight. •  Errors Report: Internal tool.
  22. 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. 23. Build Pipeline: Testflight •  Applications distribution the way it should be. •  Direct download into the device from the app.
  24. 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. 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. 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. 27. Build Pipeline: Crash Reporter •  Reports on : •  “Most Wanted” •  % of users experiencing crashes. •  Crashes by user.
  28. 28. Creating Dragon City Mobile: Launch •  Important to test the game in “real world” •  With real players •  External QA •  Professional companies •  “Amateur testing”
  29. 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. 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. 31. Downloading Assets in the Background •  Minimum subset assets needed to load game. •  In-app placeholders on demand. •  First session assets included.
  32. 32. Placeholders
  33. 33. Soft Launch 1. Launched in two countries only. 2. Monitored. 3. Launched an update with corrections. 4. Monitored. 5. World Launch.
  34. 34. Updates •  More complicated than the first launch. •  We can’t launch updates in one country only. •  Regression tests. •  Compatibility with earlier versions.
  35. 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. 36. Forced Upgrade •  Saves testing time. •  Saves supporting multiple versions. •  Improves the player experience. •  Gives cleaner analytics.
  37. 37. Real world problems
  38. 38. Rate me! •  Important to remember reviewers. •  Haters gonna hate.
  39. 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. 40. Fallacies of Distributed Computing •  The network is NOT reliable.
  41. 41. Communication with Backend •  Each action in the game generates a “command”. •  Local commands queue. •  Server processes commands, sends an OK/KO.
  42. 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. 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.
  44. 44. 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.
  45. 45. 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.

×