Come ti prepari per il creep?

Come posso prepararmi per il creep durante la pre-produzione?

Il creep è quando sei in fase di produzione e decidi "Sarebbe bello se questa fosse una caratteristica!" Ciò aggiunge n ore al tempo di sviluppo che non sono state prese in considerazione e, a meno che tu non sia Blizzard, non abbia tempo. Non puoi prevedere che sia una caratteristica interessante durante la pre-produzione, perché la funzione viene scoperta solo durante la produzione.

Cosa posso fare durante la pre-produzione per rendere conto o prevenire o preparare lo scorrimento delle funzionalità?

Devo consentire lo scorrimento delle funzionalità e tagliare le funzionalità meno desiderate? O questo creerà un problema poiché l'architettura non è progettata per le nuove funzionalità? Devo dire nessuna funzionalità a meno che non si adattino all'architettura esistente?

So che questa è una domanda ampia, ma spero che non si chiuda in quanto tale. Questo è un grosso problema nello sviluppo del gioco e dovrebbe essere considerato.

Mentre ovviamente non ci sono regole rigide quando si tratta di pre-produzione, ci sono una varietà di euristiche per aiutare. Alcune caratteristiche sono naturali e necessarie: nessun piano sopravvive al primo contatto con la realtà e potresti non sapere cosa sarebbe "bello" fino a quando non lo vedrai.

Innanzitutto, metti in scena il tuo sviluppo. Disegna il tuo contorno in una mappa delle caratteristiche, quindi cerca modi per raggruppare le tue caratteristiche in iterazioni verificabili , ognuna con una scadenza . Una volta avviata un'iterazione, resisti all'aggiunta di nuove funzionalità. Eventuali esigenze tecniche impreviste dovrebbero ovviamente andare nell'iterazione corrente, ma nuove idee per le funzionalità dovrebbero essere incluse in un elenco per future considerazioni. È quindi possibile considerare se aggiungerlo o meno a un'iterazione una volta completata quella corrente.

Ciò deriva dal metodo MoSCoW , in base al quale categorizzi le funzioni in questo modo:

• Must have - caratteristiche che sono vitali affinché l'attuale iterazione sia stabile , vale a dire testabile . Se l'iterazione non funzionerà senza di essa, è un must.
• Dovrebbe avere - caratteristiche che dovranno essere fatte ad un certo punto, ma se l'iterazione si protrae nel tempo può essere inserita nell'iterazione successiva . Le cose richieste da un editore, per esempio, potrebbero andare qui.
• Potrebbero avere - funzionalità che ritieni possano essere importanti per l'attuale iterazione ma che potrebbero essere eliminate dal progetto. Questi sono tutti importanti caratteristiche polacche .
• Non ci saranno - elementi che potenzialmente alimentano l'arretrato , caratteristiche identificate in questa iterazione da prendere in considerazione per le iterazioni successive.

Idealmente, vuoi che lo sviluppo sia un perfezionamento progressivo, non tutto o niente. Lavorando entro una scadenza finale, le caratteristiche meno importanti dovrebbero essere spinte alla fine, quindi qualunque cosa tu non arrivi sarà roba che va bene tagliata. Assicurati di stimare il tempo impiegato da ciascuna funzione per sviluppare e perfezionare tali stime mentre procedi. Non comprimere mai il programma per fare spazio a più funzionalità. Resistete a spingere le scadenze (iterazione o finale) nel futuro - spostate o tagliate le funzionalità, se possibile. Se stai arrivando alla tua scadenza e il gioco è ancora un casino invendibile, allora sai che è tempo di rivalutare seriamente le tue decisioni e considerare la cannibalizzazione del progetto prima che si trasformi in un pozzo di tempo / denaro.

• Pianifica di utilizzare una frazione del tempo di pre-produzione disponibile per il set di funzionalità di base.
• Le funzionalità di base dovrebbero essere funzionalità a basso rischio e ad alta ricompensa, quindi non devi preoccuparti quelli
• Il set di funzionalità di base è minimo e non negoziabile - devono essere presenti - altrimenti nessuna base solida su cui lavorare e sarai pieno di dubbi personali / sindrome di "dovrei sostituire questa"
• Assicurati che le prime iterazioni del tuo gioco siano abbastanza attraenti da permetterti di strisciare. Un gioco sostanzialmente insignificante non sta andando lontano, figuriamoci con il brivido.
• Sapere in anticipo quale margine di scorrimento può permettersi, quindi è possibile utilizzare saggiamente quel margine.
• Usa una tecnologia precostruita e altamente generalizzata come Unity e usala canonicamente per migliorare la flessibilità in modo che lo scorrimento delle funzionalità non abbia un impatto eccessivo sull'architettura esistente
• Non creare sottosistemi complessi: una programmazione eXtreme qui è adatto approccio di
• Chiedi ad altri (designer e programmatori) i cui cervelli puoi toccare periodicamente per aiutarti a dare la priorità alle funzioni che ti permetteranno di strisciare, fai in modo che qualcuno abbia rivisto il tuo codice come punto di partenza principale per queste domande.
• Dovrai comunque limitare lo scorrimento delle funzionalità, quindi stabilisci costantemente le priorità e sai dove tracciare la linea

In definitiva, non è qualcosa che suggerirei ai principianti, perché devi essere in grado di prendere la decisione giusta in ogni fase e non è facile nemmeno per i più esperti. Se non sei sicuro di quali siano le decisioni giuste, allora segui una rigorosa politica "non andare oltre questo punto".

Puoi anche vedere come il primo punto e quello sull'uso di una tecnologia che conosci bene significano che hai bisogno di un'esperienza sostanziale sia nella prototipazione rapida (inceppamenti del gioco) che nel set di strumenti che hai scelto.