De expectativas a realidades : el proceso de desarrollo de un videojuego

Diego Bezares @diegobez

De expectativas a realidades

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

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 vs añadir

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¿ Por qué llegamos normalmente a los hitos a tiempo, o un % tarde ?

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

Gracias!