Conception itérative à grande échelle

Typiquement dans le développement de jeux, le développement linéaire ( modèle en cascade ) est criblé d'obstacles qui drainent la raison du programmeur (le jeu s'est avéré horrible, ne peut pas être repensé). Entrez dans la conception itérative . La conception itérative permet le prototypage de diverses possibilités dans l'espace de jeu. Malheureusement, il a un gros problème. Dès qu'un projet prend de l'ampleur, les itérations deviennent fastidieusement longues, éliminant le principal avantage: des résultats rapides.

Comment raccourcir les itérations de conception pour les projets à grande échelle?

Je pense qu'une bonne infrastructure peut y contribuer. Un exemple est d'avoir un système de données agréable et facile à utiliser par lequel les ingénieurs peuvent facilement exposer de nouvelles données et que les concepteurs peuvent rapidement modifier les données et voir leurs résultats. Un autre bon est d'avoir un langage de script - comme lua - que les programmeurs de gameplay, et même les concepteurs, peuvent utiliser pour prototyper rapidement les choses.

De plus, avoir un joli pipeline art / actifs qui est facile à utiliser et facile à intégrer dans le jeu.

Fondamentalement, supprimez les obstacles aux personnes qui font leur travail et rationalisez leurs flux de travail.

Malheureusement, les solutions standard pour ces choses n'existent pas vraiment (même dans les moteurs de jeux populaires, ce ne sont pas tous des problèmes vraiment résolus), ce qui signifie que vous devrez investir du temps d'ingénierie pour obtenir cette agilité. Donc, malheureusement, la réponse est que vous devez passer du temps à le faire pour pouvoir travailler rapidement, ce qui va à l'encontre de l'objectif. Une fois que vous passez le temps, les choses vont bien. Si vous pouvez réutiliser votre travail pour de futurs projets, les dividendes sont encore meilleurs.

Le timeboxing signifie que les itérations ne s'allongent pas

Vous demandez comment raccourcir les itérations. Mais cela implique qu'ils prennent plus de temps, ce qui implique que vous n'appliquez pas la boxe temporelle. Dans toute itération où la complexité commence à peser plus (ou si vous avez d'autres revers imprévus), vous ne modifiez pas la longueur de l'itération. Vous décropez plutôt l'ajout incrémentiel que vous avez prévu au début de l'itération. Certaines méthodes itératives suggèrent de faire cette évaluation au milieu d'une itération (avant qu'il ne soit trop tard). En savoir plus sur ce que suggère OpenUP :

Gérer les objectifs Lorsqu'une équipe prend beaucoup de retard ou que des problèmes critiques surviennent qui l'empêchent d'atteindre les objectifs de l'itération, il peut être nécessaire de délimiter le travail pour s'assurer que l'équipe fournit un incrément de produit utile à la fin de l'itération, tout en maximisant valeur pour les parties prenantes. Travailler avec l'équipe et les parties prenantes pour réviser le plan d'itération et, si nécessaire, réduire l'accent mis sur les tâches moins critiques en les reportant à une itération ultérieure. Dans de rares cas, si les objectifs d'itération semblent toujours impossibles à atteindre, l'équipe peut envisager de terminer l'itération ou de reformuler l'itération en un nouvel objectif.

Si vous regardez le premier graphique, vous pouvez voir que la valeur ajoutée est moindre lors des itérations ultérieures. Cela signifie que les itérations prennent toujours autant de temps qu'auparavant, mais il y a peut-être moins de nouvelles fonctionnalités (relativement) à chaque itération.

Comme vous le dites, la force de l'itératif est de réduire les risques en obtenant fréquemment des commentaires. On dirait que vous parlez de la complexité du projet vous accable sur les itérations ultérieures? Je ne suis pas d'accord pour dire que c'est une faiblesse de l'itératif. C'est une faiblesse d'une complexité mal gérée.

Théoriquement, vous mettez en avant les plus gros risques du projet. Cela signifie que vous avez un projet très instable, mais que vous gérez les gros risques, il est censé se stabiliser. La complexité, bien sûr, est l'un des risques.

Les langages de script et les processus automatisés aident à réduire le risque de complexité, qui peut être appelée complexité «accidentelle» (et est discutée dans une autre réponse). Les projets hautement itératifs mais complexes (Chromium est un bon exemple, même si ce n'est pas un jeu) disposent de nombreuses infrastructures pour gérer la complexité. Jetez un œil à https://www.chromium.org/developers pour de nombreux exemples de choses comme des conseils de codage pour le BuildBot .

Ce que ce chiffre ne montre pas, c'est la stabilité du projet, qui ressemble probablement à ceci:

Jusqu'à ce que les risques techniques soient bien compris, vous avez affaire à des prototypes simples