Siempre se habla del secreto del éxito. Acá intentamos lo opuesto. Hablamos de todo lo que hicimos mal en nuestro pasado para compartir las piezas y aprender colectivamente. Ideas implementadas, observaciones, experiencias y mas.

1. Patrones
de éxitofracaso
Capital Federal-2019
Juan Pablo Chandias
Guillermo Averbuj

2. Temario
● Que es el éxito?
● Tu primer juego va a ser...
● Evaluación de riesgo
● Equipo o Lone wolf?
● Herramientas
● Metric driven design
● Metodología Cebolla
● Metodología de ReInversión
● Procesos Evitables vs Recomendables
● Perfil Profesional
● Scope
Si queda tiempo
● Polishing
● Indie o publisher?
● Trabajando con un publisher
● Quiero pasar a otro producto

3. ¿QUÉ ES EL ÉXITO?
para vos?
para tu equipo?
para tu inversor / sponsor?
están todos alineados?

4. ¿QUÉ ES EL ÉXITO?
Es como un transformer: Mucho más de lo que ven los ojos.

5. 90%+ chances: Tu primer juego va a ser una porqueria.
Pero si no lo terminas no vas a pasar al segundo.

6. * Nota: Números que aplican a emprendimientos. En Videojuegos es mucho peor.

7. El fracaso es el pavimento
del camino al éxito.
Toda esta gente la pasó mal y eso los
ayudó a llegar a donde querían. Estudia
su historia para nutrirte e identificarte
con los vericuetos de la vida.
En palabras de un célebre pensador
inglés:
“To the Gilation no Cabid”.

8. La falacia:
SOY ESPECIAL!
No lo sos...
...todavía.
“Ser especial” es un camino.
Recorrelo y Disfrutalo.
Romperte los huesos al intentar volar es
aprendizaje.

9. Hype / Motivancia
¡Nuevo proyecto! ¿Que puede ir mal?

10. Hype vs Realidad
La realidad es que 1 de cada 50000
personas es especial de algún modo
(números podrían ser estimativos).
La probabilidad de que esa persona seas
vos, es baja. Lo más probable es que
debas atravesar el mismo proceso que
todos los mortales.
En palabras de un célebre antropólogo y
filántropo griego:
“El que abandona no tiene premio”

11. La motivación

12. Evaluación de Riesgo
Evaluar el riesgo de un proyecto no es fácil. Sin
embargo hay forma de reducir a números el
análisis.
Claramente podemos fallar también en este
proceso.

13. Evaluación de Riesgo - probabilidad del riesgo x feature
Falta de
experiencia o
conocimientos
Falta de
herramientas o
codigo
Falta de
personal
Error
Cuantitativo
(mal scope)
Multiplayer
Online
si no si no
Shaders Únicos si si no no
Ch.
Customization
si si si si
...

14. Evaluación de Riesgo
Ligeramente Dañino
(1)
Dañino
(2)
Muy Dañino
(3)
Altamente Improvable
(1)
Riesgo Trivial
(1x1)
Riesgo Tolerable
(1x2)
Riesgo Moderado
(1x3)
Improvable
(2)
Riesgo Tolerable
(1x2)
Riesgo Moderado
(2x2)
Riesgo Sustancial
(2x3)
Puede pasar
(3)
Riesgo Moderado
(1x3)
Riesgo Sustancial
(2x3)
Riesgo Intolerable
(3x3)
Posiblemente pase
(4)
Riesgo Moderado
(1x4)
Riesgo Intolerable
(2x4)
Riesgo Intolerable
(3x4)
Desatender pero
monitorear
Considerar pero
con calma
Plan de Prevención
y Plan de Solución
Plan para Evitar y
Plan para Mitigar

15. Scope: Tamaño de un proyecto
4 variables influyen en el tamaño de un proyecto:
Cantidad de objetos : Los elementos del juego a producir, cant de espaditas, enemigos, power ups, ui, lo que sea
Cantidad de partes/Complejidad : Medida de la dificultad de producir cada elemento
Tiempo por parte : Horas hombre que se necesitan para producir una parte
Tiempo del recurso por dia : Horas por dia que la persona le puede dedicar al trabajo

17. Scope: Tamaño de un proyecto
Proyecto para la facultad : Tiempo de entrega 4 meses
Beat em up :
1 Personaje
10 Enemigos
10 Armas/Power Ups
20 Achievements
TOTAL : 0,5 MES

18. Scope: Tamaño de un proyecto
Ajustando valores
Tiempo del recurso :
Se tiende a sobreestimar el tiempo disponible para una tarea, se tiende a perder el foco en distracciones, requiere disciplina y
conocimiento de la capacidad de atención de uno mismo
¿En que estoy gastando el tiempo?
TOTAL : 1,4 MES

19. Scope: Tamaño de un proyecto
Ajustando valores
Cantidad de Elementos :
Los diseños tienden a crecer, los juegos se vuelven más complejos que el prototipo,agregar elementos a una producción puede
provocar caos en los tiempos, una feature fácil para un programador puede significar meses de producción de recursos para un
artista, el feature creep es de lo más común en el proceso de desarrollo, aprender a buscar la esencia del juego si encariñarse
demasiado con cada parte, se arregla pasando la tijera
TOTAL : 7,2 MES

20. Scope: Tamaño de un proyecto
Ajustando valores
Cantidad de Partes / Complejidad :
El diseño artístico de un juego define en gran medida la dificultad para producirlo, una misma idea puede ser representada de
múltiples maneras, lograr el equilibrio entre entre visión artística y complejidad es fundamental, pequeñas decisiones de diseño
en este punto pueden generar grandes ondas a lo largo del proyecto
TOTAL : 13,2 MES

21. Scope: Tamaño de un proyecto
Ajustando valores
Tiempo por parte :
Cuánto cuesta construir una parte de un elemento está dado está dado por factores humanos como la experiencia o seniority de
la persona y por factores técnicos como las herramientas disponibles o los pipelines en uso
Dedicar tiempo a identificar los cuellos de botella en la producción de recursos resulta en grandes beneficios
TOTAL : 17,2 MES

22. Scope: Tamaño de un proyecto
Resumen
Experiencia/ Tools: Permiten más complejidad y scope
Disciplina: Permite más horas de trabajo de mejor calidad
Equilibrio: Permite balancear la complejidad con el tiempo y la experiencia
Tijera: No aferrarse a features, mantener siempre presente cuál es la esencia del juego
Cantidad: ¿Cual es la esencia del juego?
Horas por dia: ¿En que estoy gastando el tiempo?
Complejidad: ¿Que diseño es óptimo para la producción?
Tiempo de producción: ¿Cuales son las actividades que llevan tiempo? Implementar pipelines

23. Lonewolf? Equipo?

24. Lone Wolf
● Alta Disciplina necesaria
○ Levantarse a la mañana
○ Enfocar en los objetivos reales
○ Aprender otras profesiones
● Alta Autolimitación necesaria
○ Duración del proyecto
○ Features
○ Contenido
○ Calidad
● Agujeros que llenar
○ Sin equipo, so-voh
● Independencia
○ Objetivos propios
○ Nadie te corre
Equipo
● Alinearse como equipo
○ Objetivos
○ Capacidades
○ Esfuerzo
○ Compromiso
● Ser honesto con las capacidades propias.
○ La semilla del profesional
○ Focalizo en lo que mejor hago
● Empuje grupal
○ Presión social
○ Reciprocidad
○ Soporte anímico
○ Control y autolimitación, mutuos
○ El poder de la turba iracunda
Lonewolf vs Equipo

25. La turba iracunda
El poder de la turba iracunda: Explicación gráfica.

26. Herramientas
Planificacion: Trello.com
Avanzados: / Hacknplan.com / Monday.com / Ftrack.com / ShotgunSoftware.com / KanbanTool.com
Muy Avanzados: GanttProject.biz / MSProject
Simulaciones: Machinations.io
Diagramas: Bubbl.us / Mindmeister.com / SimpleMind.eu
Avanzado: Lucidchart.com
Repositorios: Git / Svn / Sourcetree
Comunicación: Slack / Discord
Tracking de tiempo: Toggl.com
Documentos Colaborativos: Google Drive / MSOneDrive

27. Metric Driven Design
Proceso que reduce la incertidumbre, al probar el
peor caso de desarrollo para medir la métrica de
producción.
Se suele hacer durante la preproducción y termina
dictaminando los tiempos MÁXIMOS de producir
cada pieza de arte, cada pedazo del juego.
Hay casos imposibles de medir, cómo son los
one-off, o código específico en el que el equipo no
tiene experiencia trabajando (ver riesgo).
Metric Driven Process
1. Definimos cómo lo vamos a hacer
a. TDD? o una charla de equipo? se define una
técnica? herramienta? etc...
2. Lo hacemos 2 veces.
a. La primera falla, y funciona como exploración
b. La segunda sirve como métrica. De hecho esta
va a ser la peor métrica de todas. La gente
mejora con cada iteración del mismo proceso.
3. Se define el tiempo disponible a dedicar.
4. Se divide el tiempo definido por la metrica
para saber CUÁNTAS VECES se podrá repetir
este proceso.

28. Metric Driven Design
Ejemplo. Proceso Modelar un personaje
Artista promedio:
● 1er personaje: 12 días
● 2do personaje: 10 días
● Métrica oficial 10 días + 15% (colchón) = 11,5 días
Ejemplo Proyecto: 5 meses
● 1er mes de prepro + último mes de post
● Quedan 3 meses de producción (o sea 60 días hábiles)
● Se pueden hacer 5 (5.2) personajes
● Si tenemos 2 artistas, esto se multiplica a 10 personajes
idealmente, aunque por “ripple effect” podrían ser 8.
“Colchón”
Tiempo adicional dispuesto por el PM para
calcular imponderables incalculables. este tiempo
VA a ser utilizado por enfermedades, paros,
cortes de luz, y otro tipo de eventos de carácter
apocalíptico.

29. Proceso tradicional
En nuestra mente todo se reduce a este esquema, sin embargo la experiencia dicta que atravesando este
esquema se encuentra la necesidad de atar con alambre la planificación para ser precavidos y poder cumplir
con las fechas de entrega. Siguientes slides con ejemplos de metodologías probadas con algún nivel de “éxito”.

30. Proceso iterativo
Todos conocemos el proceso iterativo.
Sino lo conoces, Google.
En el siguiente slide proponemos una
forma de llevarlo a cabo pensado desde
una perspectiva más vertical y
holísticamente aplicable.

31. Metodología “Cebolla”
El objetivo de esta metodología es poder
cortar en “cualquier momento” y aún así
tener un producto viable.
Tengo que garantizar cada capa para pasar a
la siguiente. Las capas las defino LUEGO de
encontrar el core gameplay y verificar que es
entretenido.
Core Gameplay entretenido.
Paquete: Gameplay y Contenido
adicional que no rompe el core
gameplay
Paquete de mejoras #2 que no
rompe lo anterior.
Paquete de mejoras #3 que no
rompe lo anterior.

32. Encebollando - Engorde
Básicamente es una técnica de engorde luego
de haber concebido el producto básico
mínimo de venta.
● Permite cortar con el desarrollo en
cualquier momento garantizando un
producto funcional.
● Para eso, se debe desarrollar en etapas
verticales:
○ Hago el Proto y me aseguro de tener
algo copado
○ Hago el MVP y me aseguro de tener un
producto vendible que cumpla con los
objetivos.
○ Comienzo el engorde el tiempo que
tenga disponible sin afectar lo anterior.
○ Cierro contenido y paso a Debug.

33. ● Desarrollo iterativo entre
productos
● No perder de vista lo que va a
venir
● Reutilización tecnológica,
como base para el crecimiento.
ReInversión (parece obvio no?)

34. Me van a robar mi idea?
No.
● Es caro ejecutar una idea.
● Todos tenemos ideas geniales.
● La idea por si sola no vale nada
(ver siguiente slide)
Así que No.
Imagen desmotivadora sin relación al contenido.

35. A continuación la
fórmula para
calcular cuánto vale
económicamente
hablando tu
“maravillosa” idea:
Entonces… cuánto vale mi idea?

36. El tipo de idea se convierte en un multiplicador
● IDEA HORRIBLE = -1
● IDEA DÉBIL = 1
● IDEA MASOMENOS = 5
● BUENA IDEA = 10
● GRAN IDEA = 15
● IDEA BRILLANTE = 20
Lo que hagas con ella se convierte en el número base
así que estos son los tipos de ejecución:
● SIN EJECUCION = $ 1
● EJECUCIÓN DÉBIL = $ 1000
● EJECUCIÓN MASOMENOS = $ 10,000
● BUENA EJECUCIÓN = $ 100,000
● GRAN EJECUCIÓN = $ 1,000,000
● EJECUCIÓN BRILLANTE = $ 10,000,000
* Derek Sivers, “Anything you want”
A continuación la
fórmula para
calcular cuánto vale
económicamente
hablando tu
“maravillosa” idea:
Entonces… cuánto vale mi idea?

37. La fórmula entonces queda:
TIPO DE IDEA x TIPO DE EJECUCIÓN
=
VALOR DE LA IDEA
Ejemplos:
● idea horrible con una buena ejecución =
$-100.000
● idea masomenos con una gran ejecución =
$5.000.000
● idea brillante, sin ejecución =
$20
El tipo de idea se convierte en un multiplicador
● IDEA HORRIBLE = -1
● IDEA DÉBIL = 1
● IDEA MASOMENOS = 5
● BUENA IDEA = 10
● GRAN IDEA = 15
● IDEA BRILLANTE = 20
Lo que hagas con ella se convierte en el número base
así que estos son los tipos de ejecución:
● SIN EJECUCION = $ 1
● EJECUCIÓN DÉBIL = $ 1000
● EJECUCIÓN MASOMENOS = $ 10,000
● BUENA EJECUCIÓN = $ 100,000
● GRAN EJECUCIÓN = $ 1,000,000
● EJECUCIÓN BRILLANTE = $ 10,000,000
* Derek Sivers, “Anything you want”
A continuación la
fórmula para
calcular cuánto vale
económicamente
hablando tu
“maravillosa” idea:
Entonces… cuánto vale mi idea?

38. Procesos
A evitar
● Comenzar el desarrollo sin tener definido y
prototipado todo el core gameplay
● Comenzar la producción con dudas sobre cómo
hacer todos los features y todo el contenido
● Hacer contenido sin tener probado el gameplay
● Redefinir procesos establecidos en preproducción
● Esconder el desarrollo herméticamente. “Me pueden
robar la idea!”
○ Eventos
○ Devblog
○ Comunidad temprana
○ Early Access
● Dejar el feedback para el final
● Primer proyecto: innovador, ambicioso.
Recomendables
● Llevar un registro de las decisiones técnicas y su
justificación
● Desarrollar áreas del juego en equipos (escuadrones)
multidisciplinarios con objetivos claramente
definidos.
● Reuniones semanales de status y de objetivos como
equipo + anuncios parroquiales (15 minutos).
● Reuniones diarias de objetivos diarios (5 minutos):
○ Qué hice ayer
○ Qué haré hoy
○ Qué problemas puedo encontrar
○ Qué necesito de otro miembro
○ Objeciones de otros miembros
● Desarrollar documentación en el formato
específico que requiera cada equipo.
● Integrar contenido muy seguido, ahí es
donde aparecen los problemas. Hacerlo al
final es fórmula de fracaso.

39. Comunicación
A medida que tu equipo crece, tenes que tomar
medidas para incrementar y asegurar la
comunicación entre todos.
Habiendo participado en un proyecto de 65
personas, hemos medido el tiempo en que cierta
información importante se distribuye entre todos
los miembros del equipo. El resultado fue 5 días.
No subestimes la necesidad de comunicación en
cualquier estructura.
- Programador: Che! me costó pero finalmente
terminé el flubbergush qué pediste.
- Game Designer: Pero eso lo eliminamos la
semana pasada!

40. Perfil del profesional
● La tarea no termina al pasar un entregable,
sino al corroborar que lo realizado está
dentro del juego funcionando.
● Las fechas de entrega que nos
comprometimos son inquebrantables.
● Hay que ser conscientes al hacer cambios o
arreglos, de qué todo lo que toco puede
afectar a otros.
● Respetar religiosamente las reglas de uso de
los repositorios.
● No apoyarse en el departamento de QA para
encontrar y documentar errores.
● Jugar el juego con frecuencia, no importa el
puesto, ni los objetivos.
Ownership: YO soy responsable por la calidad del
producto. TODOS lo son.
● Aca teniamos que poner bocha de material,
pero no llegamos. La próxima

41. La ley del Malón = Mas gente, mas kilombo.
Caso de análisis genérico: Tengo un problema y me
dan la opción de ampliar el equipo para poder
solventar la falta de experiencia o bien la falta de
tiempo por mal estimación.
MAL. Aplica la ley del Malón:
Más índios no va a ordenar el kilombo, sino lo
contrario.
Hay un punto específico donde más gente en el
proyecto no implica mejoras en los tiempos.
...sin contar que sumar a alguien nuevo que no sabe
implica que alguien que SI sabe no va a estar
trabajando dado que tendrá que estar explicándole.

42. Ripple Effect
1 personaje = 10 días
1 p + 1 p = 25 días
1p + 1p + 1p = 40 días
La Fe en el Ripple Effect: sin saber de qué forma
(hay forma pero no hay tiempo en este ppt de
explicar) a veces agregar features o contenido
aumenta anti-naturalmente el tiempo de
desarrollo. Hay un punto de no retorno donde
hacer este tipo de cambios es asesinar el proyecto
y al equipo.
Pasado cierto punto, menos manos hacen menos ruido.

43. Ripple Effect
Consecuencias imponderables.
A veces menos manos es mejor.

44. Aprende de los fracasos
La única forma de utilizar los fracasos a tu favor es seguir estos 5 pasos:
1. Llamale al fracaso de otra forma.
a. Cada intento, cada proyecto, cada prototipo sin éxito, es EXPERIENCIA.
2. Usa el fracaso como una piedra fundante de tu próximo paso.
a. Identifica lo que sabés que hiciste mal.
b. No conozco a nadie que haya tenido éxito con su primer producto. No lo esperes pero buscalo.
3. Nunca falles en soledad
a. Es más difícil comprender qué fue lo que paso si analizas tu experiencia en soledad.
b. Un socio te puede ayudar a evitar los mismos errores.
4. No ocultes tus fracasos
a. Enorgullecete del riesgo que tomaste. Abrir tus experiencias a otros abre la puerta al aprendizaje.
5. Redefine tus objetivos
a. Somos animales emocionales. La lógica no genera motivación. Analiza lo que te empuja a actuar.
Quizás necesites redefinir tu criterio de lo que es un “éxito”.

45. Para convertirte en millonario tenés que cumplir estos 5 Quests que son bastante
hardcore:
● Discovery: Cómo te van a descubrir los clientes?
○ en Android Playstore se publican 6140 juegos x día -2018-
○ en Apple Appstore se publican 500 juegos por dia -2016-
● Customer Acquisition: Cómo logras que la gente se baje tu juego?
● Engagement: Cómo haces que tus jugadores se apasionen por tu juego?
● Monetization: Qué porcentaje de tus jugadores van a pagar? (en F2P)
Cómo ser millonario?

46. Contactanos (si ganas la lotería)
J.P.Chandias
chandias.juan@gmail.com
Guille Averbuj
guille.averbuj@gmail.com
Capital Federal-2019