• Save
Betabeers BCN
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Betabeers BCN

on

  • 432 views

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 ...

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.

Statistics

Views

Total Views
432
Views on SlideShare
418
Embed Views
14

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 14

https://twitter.com 12
http://www.socialpoint.es 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Betabeers BCN Presentation Transcript

  • 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.
  • 45. 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.
  • 46. 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.