de expectativas a realidades, el proceso de desarrollo de un videojuego
TRANSCRIPT
Obstáculos - “Castillos en el aire” [Diseño de] - Iteratividad- Cambios en el proyecto- Roles en equipos multidisciplinares- Sobreingeniería- Planificación
Castillos en el aireGDD ( Game Design Document ) inicial :
- No es real, es una fantasía.
- Castillo en el aire basado en expectativas, no en realidades.
Castillos en el aireAl implementar descubrimos realidades :
- Limitaciones técnicas. Rendimiento...- Incongruencias- Features que no funcionan, aunque estén bien implementadas
- No se entiende facilmente- No es divertido- Marea, incómodo ...
Castillos en el aire
El GDD inicial que se cumple es el unicornio blanco del desarrollo de videojuegos.
Castillos en el aire Los desarrollos salen “bien” a la primera última :
- Hacer el GDD biblia inicial perfecto y que se cumpla
- Objetivos generales claros: Target, recursos, tiempo...
- Iterar y gestionar el cambio. Dar pasos cortos.
Castillos en el aire Necesidades de diseño :
- Diseño detallado, meditado y concreto de la actual iteración.
- Probar cada iteración. Diseño actualizado en base a realidades, no expectativas.
- Diseño detallado de muchas “features” y ampliaciones futuras
- Implementación actual improvisada y sin meditar
2. IteratividadConvertir expectativas en realidades lo antes posible.
- Mitigamos riesgos.- Tomamos decisiones basadas en realidades.
2. Iteratividad
- Priorizar tareas es clave, cambia el resultado final .
- El orden importa : destapamos realidades distintas, tomamos decisiones distintas.
3. Cambios- Al iterar, cambiamos.- “Cambios” durante un proyecto, una de las quejas más recurrentes- Descartar trabajo hecho “quema” mucho- Gestionar el cambio
3. Cambios- Un buen diseño / implementación nos permite avanzar más cada iteración- Hay cambios evitables, inevitables y equivocados- Cambios decididos en función de realidades descubiertas, inevitables- Cambios por razones existentes desde hace tiempo, evitables.
3. Cambio
- Evitar desarrollar “sobre la marcha” con cambios poco trabajados- Granularidad de cambio fija ( por ejemplo, un sprint )- Cambios que surgen de realidades que se ven en la última implementación
VS “cambios de opinión” sin fundamento
3. Cambio / placeholders- Hechos solamente para esta iteración, para ser sustituidos, no son finales.- Arte / código / diseño ...
3. Cambio / placeholders- Mal a propósito- “Dá igual cómo sean, porque se van a tirar”- Cuanto mejores sean más realidades descubrimos, más avanzamos.- Lo mejor que podemos hacer en X ( poco ) tiempo.
3. Cambios / placeholders- Evita bloqueos y dependencias.- Permiten integrar pronto ( hacer un monopatín )- En juegos no hay módulos independientes ( ruedas de coches )
3. Cambios / placeholdersSi os dáis cuenta, el desarrollo iterativo significa en realidad ….
- Que todo lo que desarrollamos es placeholder- El desarrollo es infinito, no hay versión final- Cada versión/ placeholder es importante, aunque vaya a cambiar
3. Cambios vs añadirViñeta de Dilbert:
Dilbert : Estos requisitos de usuario tienen 400 features. ¿ Te das cuenta de que nadie será capaz de usarlo con esta complejidad ?
Jefe : Tienes razón. Mejor añadimos a la lista “que sea fácil de usar”.
3. Cambios. ¿ Bug o feature ?
- ¿ Importa si es bug o feature ?. Semántica.- Priorización según importancia.
3. Cambios. Pulido
- No cambian lo fundamental de una feature- La feature debe funcionar “bien” sin pulido- Mucha relación valor / coste- Reservar tiempo en planning.
3. Cambios / Roles y responsabilidades - Equipos multidisciplinares- Interconectados : decisiones en cada campo afectan al resto- No son piezas independientes de un puzle.
3. Cambios / Roles y responsabilidades - Responsabilizarse del resultado final- Entender todas las decisiones que nos afectan- Participar en las decisiones que nos afectan- Para conseguir buena calidad, hay que iterar
3. Cambios / Roles y responsabilidades - “Integrarse” en el desarrollo. Capacidad de integrar, probar, iterar y modificar
por sí mismos.- Herramientas pensadas para el uso multidisciplinar ( Unity, etc... )- Repositorio del proyecto ( Git… )
Sobreingeniería
- Principio KISS “Keep it simple stupid”.
“La mayoría de sistemas funcionan mejor si se mantienen simples que si se hacen complejos; por ello, la simplicidad debe ser mantenida como un objetivo clave del diseño”
Sobreingeniería
“Pienso la solución a todos mis problemas presentes y los que creo que tendré”
“implemento” → uso → encuentro nuevos problemas
Perseguir arquitecturas perfectas
Usar arquitecturas imperfectas que funcionan
Sobreingeniería- Implementación completa y flexible para usos futuros- Implementación mínima para nuestras necesidades ahora
Sobreingeniería
- No significa bajar la “calidad de código”, sino hacer la implementación más simple en cada momento.
- Calidad del código es clave en cambios e iteractiones.
Sobreingeniería- Early optimization / Late optimization
- Optimización basada en la realidad ( profiler … ) / expectativas
- Lo más óptimo : lo que no se hace
Planificación- Desarrollos no predecible : no sabemos lo que vamos a hacer- Necesidades de negocio : fechas y recursos fijos
¿?
Planificación- Desarrollamos en función del tiempo que nos queda
- Micro / macro decisiones
- % tarde según importancia de fecha
Planificación- “Modo crunch”, se suele avanzar mucho.
- No es por las “horas extra”
- Decisiones, prioridades, foco
PlanificaciónA pesar de cumplir el Deadline :
- No es gratis
- Realidad != expectativas
- Podemos desarrollar un producto insuficiente para nuestros objetivos
Planificación
Implementar features es “fácil y rápido”. Lo difícil es conseguir que funcionen bien ( cumplir expectativas y objetivos )
- El 10% restante que se lleva el 90% del tiempo de desarrollo
- Iterar lleva tiempo
- Desarrollar cosas nuevas complejas tiene riesgo.
Planificación- Hitos no definidos por sus tareas ( no las sabemos ), sino por el nivel de acabado.
Sin bugs
Pulido
Content complete
Juego autónomo
Prototipo divertido