Sergi Vélez, our Technical Lead of Mobile, gave a talk at Betabeers Barcelona (held at La Salle Technova). The main topic was about how to manage multiplatfom games. Sergi gave useful tips to the attendees and he explained how things are managed in Social Point giving valuable examples about our games. Here you have the full presentation that Sergi used.

1. Creando
Dragon City Mobile
SergiVélez
@risdevs/sergi.velez@socialpoint.es

2. Presentación
🎩 Mobile Technical Lead @ socialpoint.
⚒ 9 años desarrollando profesionalmente.
⚒ Pascal, Java, Objective-C, C++.
♥ Git lover.
♥ Programación / Gadgets / Videojuegos.

3. socialpoint
• Creada en 2008.
• #3 Desarrollador mundial de juegos sociales.
• 8M DAU / 44M MAU
• 22@ Barcelona.
• 150 empleados.

4. Dragon City
• Juego de breeding.
• Dos mecánicas básicas:
• Coleccionismo de dragones.
• Batallas.
• F2P.

5. Dragon City Canvas: Algunos datos
• 1 año y 2 meses.
• 2º Juego con mejor valoración en Facebook en 2012.
• 6º Juego por Usuarios Activos Diarios en Facebook.
• 6M DAU.
• 25M MAU.

6. Dragon City Canvas

7. socialpoint
• Hace 1.5 años, entramos en el mundo móvil.
• Centrados en conseguir la misma
experiencia de juego en todas las plataformas.

8. Dragon City Mobile
• Re-escrito desde cero.
• “Única” alternativa.
• 6 meses de desarollo.
• Creación del equipo.
• Empezamos 2 devs, acabamos 8.
• Actualmente 5 devs manteniendo el juego.

9. • World Launch: Febrero 2013.
• 1M DAU.
• iOS
• Versión en Android la próxima
semana :)
Dragon City Mobile

10. Premios!
• Dragon City obtuvo ayer dos premios de la academia!

11. Objetivos
• Contaros nuestra experiencia durante el desarrollo
del juego:
Desarrollo QA Lanzamiento
Post
Lanzamiento

12. Code Reviews

13. Code Reviews
• One-man army no escalan demasiado bien.
• Invertimos más tiempo manteniendo código que
creándolo.
• Cuatro ojos ven más que dos.

14. Code Reviews: Beneficios
• Favorecen la transmisión de conocimiento.
• Mejoran la calidad del código.
• Mentoring.
• Collective code ownership.

15. Code Reviews: Nuestro método
• Git Flow.
• Cada cambio se hace en una rama separada.
• Pull Requests en GitHub para pedir la revisión.
• TODO el código es revisado por el equipo.
• Todo el equipo revisa código.

16. Code reviews: Consejos
• Code reviews pequeñas.
• Comentar el código e introducción en la petición.
• Autoridad basada en conocimiento, no en jerarquía.
• Cada developer tiene su solución.
• Hacer las revisiones en las pausas.

17. Code reviews: Consejos
• El código no es tuyo.
• Siempre hay alguien que sabe más.
• Preguntar antes de hacer un refactor.

18. Code reviews: Problemas
• No todo el código es divertido de revisar.
• Programadores con distintos conocimientos.
• Hay que saber cuando una revisión está aprobada.

19. Code reviews: Problemas

20. Tools

21. Creando DCm: Tools
• Importante trabajar con
buenas herramientas.
• Developers centrados en
el código.
• Bug Hunting.

22. DCm Build Pipeline
• Creación de la app: Jenkins.
• Distribución de la app: Test!ight.
• Informe de errores: Herramienta Interna.

23. DCm Build Pipeline: Jenkins
• Dos builds diarias (mediodía y noche).
• Dos tipos de build:
• Debug apuntando al entorno de desarollo.
• Production apuntando a producción.
• Avisos si falla el job

24. DCm Build Pipeline: Testflight
• La distribución de
aplicaciones, cómo debe
ser.
• Descarga de la
aplicación desde el
dispositivo.
• Acceso a versiones
antiguas.

25. DCm Build Pipeline: Jenkins +Testflight
• Todo socialpoint tiene acceso a Test!ight.
• Usado por todos los departamentos
• QA para acceder a la versión más reciente.
• Game Designers para probar cambios.
• Product owner para comprobar nuevas features.
• ...

26. DCm Build Pipeline: Crash Reporter
• Avisa cuando ha habido un problema con la
aplicación.
• Al arrancar después de un crash, envía un informe.
• En producción, antes pide permiso al usuario :)
• Este informe ayuda nos ayuda a encontrar y
corregir el error

27. DCm Build Pipeline: Crash Reporter
• El informe contiene:
• Stacktrace en el momento del crash.
• Información de entorno en el momento del crash.
• Datos del dispositivo.
• Registro de eventos signi!cativos.

28. DCm Build Pipeline: Crash Reporter
• Informes de:
• “Most Wanted”
• % de usuarios con
crashes.
• Crahes por usuario.

29. Creando DCm: Lanzamiento
• Importante probar el
juego en el mundo real
• Con jugadores reales
• QA Externo
• Compañías
profesionales
• “Testing Amateur”

30. Pusblishing
• Las primeras submissions a la AppStore pueden ser
complicadas.
• Importante tener en mente las recomendaciones de
Apple.
• Otras apps ya publicadas no sirven para alegar.

31. Tamaño de la aplicación
• Mantener el tamaño de la aplicación por debajo del
límite impuesto por la store.
• Incentivar las descargas compulsivas.
• Hard limit en Google Play.
• Descargas en la primera sesión.
• 1ª experiencia en el juego terrible.
• Problemas en redes móbiles.

32. Descarga de assets en 2º plano
• El juego contiene los assets imprescindibles para
cargar el juego.
• Descargas in-game bajo demanda.
• Placeholders.
• Assets de inicio incluidos.

33. Placeholders

34. Soft Launch
1. Lanzamos en sólo dos países.
2. Monitorizamos.
3. Lanzamos un update con correcciones.
4. Monitorizamos.
5. World Launch.

35. Updates
• Más complicados que el 1r lanzamiento.
• No podemos lanzar los updates sólo en un país.
• Pruebas de regresión.
• Compatibilidad con versiones antiguas.

36. Forced Upgrade
• Al arrancar, el juego envía el ID de versión.
• Sólo puede hacer login si es la última versión.
• En caso contrario, se le redirige a la Store.

37. Forced Upgrade
• Nos ahorra tiempo de testing.
• Nos evita soportar múltiples versiones.
• Mejoramos la experiencia del jugador.
• Tenemos las analíticas más limpias.

38. Problemas en el mundo real

39. Rate me!
• Importante recordar a la gente que valore la
aplicación.
• Haters gonna hate.

40. Fallacies of Distributed Computing
• The network is reliable.
• Latency is zero.
• Bandwitdh is in"nite.
• The network is secure.
• Topology doesn’t change.
• Transport cost is zero.
• The network is homogenous.

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

42. Comunicación con backend
• Cada acción del juego genera un “command”.
• Cola de comandos local.
• Servidor procesa los comandos, envia OK/KO.

43. Offline Mode
• Adaptamos esta solución a DC Mobile:
• La cola de comandos es persistente.
• Si hay un error, se sigue enviando hasta que se
consigue.
• Una vez has iniciado sesión, puedes jugar sin
conexión.

44. Offline mode: Problemas
• Sólo una sesión activa por usuario.
• No hay un “merge” de sesiones.
• Peligroso si juegas en varias plataformas.
• Pérdida de sesión en modo o#ine.

46. Creando DCm: Código portable
• Al crear DC iOS no nos preocupó la versión Android.
• Demasiado código no-portable.
• Tiempo de reescritura.
• Nuevos bugs.
• Solventar bugs dos veces.

47. Creando DCm: Código portable
• Pensar en multi-plataforma.
• Si funciona, querréis portarlo a otras plataformas.
• Herramientas desktop.
• Leaks.
• Análisis de código.