Design iterativo su larga scala

Tipicamente nello sviluppo del gioco, lo sviluppo lineare ( modello a cascata ) è pieno di ostacoli che drenano la sanità mentale del programmatore (il gioco si è rivelato orribile, non può essere riprogettato). Inserisci il design iterativo . Il design iterativo consente la prototipazione di varie possibilità nello spazio di gioco. Sfortunatamente, ha un grosso problema . Non appena un progetto aumenta di dimensioni, le iterazioni diventano noiosamente lunghe eliminando il vantaggio principale: risultati rapidi.

Come accorciare le iterazioni di progettazione per progetti su larga scala?

Penso che una buona infrastruttura possa aiutare questo. Un esempio è avere un sistema di dati piacevole e facile da usare attraverso il quale gli ingegneri possono esporre facilmente nuovi dati e che i progettisti possono modificare rapidamente i dati e vedere i loro risultati. Un altro aspetto positivo è avere un linguaggio di scripting - come lua - che i programmatori di gameplay e persino i designer possono usare per prototipare rapidamente le cose.

Inoltre, avere una bella pipeline di arte / risorse che è facile da usare e facile da ottenere risorse nel gioco.

Fondamentalmente, rimuovere gli ostacoli alle persone che svolgono il proprio lavoro e semplificare i flussi di lavoro.

Sfortunatamente, le soluzioni standard per quelle cose non esistono davvero (anche nei motori di gioco popolari, questi non sono tutti problemi davvero risolti), il che significa che dovrai investire un po 'di tempo ingegneristico per ottenere questa agilità. Quindi, purtroppo, la risposta è che devi dedicare del tempo per farlo in modo da poter lavorare rapidamente, che tipo di sconfitte lo scopo. Una volta che passi il tempo, però, le cose vanno alla grande. Se riesci a riutilizzare il tuo lavoro per progetti futuri, i dividendi sono ancora migliori.

Timeboxing significa che le iterazioni non si allungano

Chiedi come accorciare le iterazioni. Ma ciò implica che stanno impiegando più tempo, il che implica che non stai applicando il time boxing. In qualsiasi iterazione quando la complessità inizia a pesare di più (o si hanno altre battute d'arresto indesiderate), non si modifica la lunghezza dell'iterazione. Decopri invece l'aggiunta incrementale pianificata all'inizio dell'iterazione. Alcuni metodi iterativi suggeriscono di fare questa valutazione nel mezzo di un'iterazione (prima che sia troppo tardi). Maggiori informazioni su ciò che OpenUP suggerisce :

Gestire gli obiettivi Quando un team è significativamente indietro, o si verificano problemi critici che impediscono al team di raggiungere gli obiettivi di iterazione, potrebbe essere necessario decifrare il lavoro per garantire che il team fornisca un utile incremento del prodotto entro la fine dell'iterazione, massimizzando valore degli stakeholder. Collaborare con il team e le parti interessate per rivedere il piano di iterazione e, se necessario, ridurre l'enfasi su compiti meno critici rimandandoli a una successiva iterazione. In rari casi, se gli obiettivi di iterazione sembrano ancora impossibili da raggiungere, il team potrebbe prendere in considerazione la possibilità di interrompere l'iterazione o riformulare l'iterazione verso un nuovo obiettivo.

Se si osserva il primo grafico, è possibile notare che il valore aggiunto è inferiore nelle iterazioni successive. Ciò significa che le iterazioni impiegano ancora più tempo di prima, ma forse ci sono meno nuove funzionalità (relativamente) all'interno di ogni iterazione.

Come dici tu, la forza dell'iterativo è di ridurre il rischio ottenendo feedback frequentemente. Sembra che tu stia parlando della complessità del progetto che ti sta attenuando nelle iterazioni successive? Non sono d'accordo che questa sia una debolezza dell'iterativo. È un punto debole della complessità mal gestita.

Teoricamente, si mettono in primo piano i maggiori rischi dei progetti. Ciò significa che hai un progetto molto instabile, ma mentre gestisci i grandi rischi, dovrebbe stabilizzarsi. La complessità, ovviamente, è uno dei rischi.

Linguaggi di scripting e processi automatizzati aiutano a ridurre il rischio di complessità, che può essere definita complessità "accidentale" (ed è discussa in un'altra risposta). I progetti altamente iterativi ma complessi (Chromium è un buon esempio, anche se non è un gioco) hanno molte infrastrutture per gestire la complessità. Dai un'occhiata a https://www.chromium.org/developers per molti esempi di cose come consigli sulla codifica per BuildBot .

Ciò che questa figura non mostra è la stabilità del progetto, che probabilmente assomiglia a questo:

Fino a quando i rischi tecnici non saranno ben compresi, hai a che fare con semplici prototipi