Diseño iterativo a gran escala.

Típicamente en el desarrollo del juego, el desarrollo lineal ( modelo en cascada ) está plagado de obstáculos que agotan la cordura del programador (el juego resultó horrible, no se puede rediseñar). Ingrese diseño iterativo . El diseño iterativo permite la creación de prototipos de varias posibilidades en el espacio de juego. Desafortunadamente, tiene una gran trampa. Tan pronto como un proyecto aumenta de tamaño, las iteraciones se vuelven tediosamente largas matando la ventaja principal: resultados rápidos.

¿Cómo se pueden acortar las iteraciones de diseño para proyectos a gran escala?

Creo que una buena infraestructura puede ayudarlo. Un ejemplo es tener un sistema de datos agradable y fácil de usar a través del cual los ingenieros puedan exponer fácilmente nuevos datos, y que los diseñadores puedan alterar rápidamente los datos y ver sus resultados. Otra buena es tener un lenguaje de scripting, como lua, que los programadores de juegos e incluso los diseñadores pueden usar para crear prototipos rápidamente.

Además, tener una buena línea de arte / activos que es fácil de usar y fácil de obtener activos en el juego.

Básicamente, elimine los obstáculos para que las personas hagan su trabajo y agilice sus flujos de trabajo.

Desafortunadamente, las soluciones estándar para esas cosas realmente no existen (incluso en los motores de juegos populares, estos no son todos problemas realmente resueltos), lo que significa que tendrá que invertir algo de tiempo de ingeniería para obtener esta agilidad. Entonces, lamentablemente, la respuesta es que tienes que dedicar tiempo para hacerlo para que puedas trabajar rápidamente, lo que de alguna manera frustra el propósito. Sin embargo, una vez que pasas el tiempo, las cosas van bien. Si puede reutilizar su trabajo para proyectos futuros, los dividendos son aún mejores.

Timeboxing significa que las iteraciones no se alargan

Preguntas cómo acortar las iteraciones. Pero eso implica que están tomando más tiempo, lo que implica que no estás aplicando el boxeo de tiempo. En cualquier iteración cuando la complejidad comienza a pesar más (o tiene otros contratiempos imprevistos), no cambia la longitud de la iteración. En su lugar, desapunta la adición incremental que planeaste al comienzo de la iteración. Algunos métodos iterativos sugieren hacer esta evaluación en medio de una iteración (antes de que sea demasiado tarde). Lea más sobre lo que sugiere OpenUP :

Administre los objetivos Cuando un equipo se está quedando atrás significativamente o se producen problemas críticos que impiden que el equipo cumpla con los objetivos de la iteración, puede ser necesario dejar de trabajar para garantizar que el equipo ofrezca un incremento útil del producto al final de la iteración, mientras maximiza valor de los interesados Trabaje con el equipo y las partes interesadas para revisar el Plan de iteración y, según sea necesario, reduzca el énfasis en tareas menos críticas posponiéndolas a una iteración posterior. En casos raros, si los objetivos de la iteración aún parecen imposibles de cumplir, el equipo podría considerar terminar la iteración o reformular la iteración a un nuevo objetivo.

Si observa el primer gráfico, puede ver que el valor agregado es menor en las iteraciones posteriores. Esto significa que las iteraciones aún duran tanto como antes, pero tal vez haya menos funcionalidad nueva (relativamente) dentro de cada iteración.

Como usted dice, la fortaleza de iterative es reducir el riesgo al recibir retroalimentación con frecuencia. Parece que estás hablando complejidad del proyecto que te persigue en las iteraciones posteriores? No estoy de acuerdo con que esto sea una debilidad de iterativo. Es una debilidad de la complejidad mal administrada.

Teóricamente, usted pone los mayores riesgos del proyecto por adelantado. Esto significa que tiene un proyecto muy inestable, pero a medida que gestiona los grandes riesgos, es supone que se estabilizará. La complejidad, por supuesto, es uno de los riesgos.

Los lenguajes de secuencias de comandos y los procesos automatizados ayudan a reducir el riesgo de complejidad, que se puede llamar complejidad "accidental" (y se analiza en otra respuesta). Los proyectos altamente iterativos pero complejos (Chromium es un buen ejemplo, incluso si no es un juego) tienen mucha infraestructura para gestionar la complejidad. Eche un vistazo a https://www.chromium.org/developers para ver muchos ejemplos de cosas como codificar consejos para BuildBot .

Lo que esta figura no muestra es la estabilidad del proyecto, que probablemente se parece a esto:

Hasta que se entiendan bien los riesgos técnicos, se trata de prototipos simples