Diario di sviluppo: Problemi bloccanti!

Eccovi la traduzione dell’ultimo diario di sviluppo di Ole Herbjornsen, Lead Disegner di Age of Conan. Questa volta ci parla del team di sviluppo, di come si lavora durante la beta e come vengono affrontati i bug.

L’altro giorno stavo pensando al fatto che oramai siamo in beta da parecchi mesi e poi ho ripensato a quando ancoar non eravamo in beta e a tutti i cambiamenti che ci sono stati sia nel team di sviluppo che nell’organizzazione. C’e’ molta differenza tra la pre-produzione e la produzione come c’e’ molta differenza tra la produzione e l’essere in beta e una differenza ancora piu’ grande tra la beta e un prodotto “live”. Ma facciamo un passo alla volta 🙂

Quali sono le differenze chiave tra l’essere in produzione e l’essere in beta?

Prima di tutto e’ cambiato molto il focus delle riunioni che si tengono ogni mattina. Dalle 9 alle 10 ogni mattina, dal lunedi’ al venerdi’, tutti i capi si riuniscono per discutere gli argomenti piu’ importanti. In questa procedura ci sono stati due grandi cambiamenti; il primo e’ su chi e’ presente alla riunione e il secondo e’ sull’agenda della riunione. Mentre quando eravamo in fase di produzione ricevevamo visite dal QA solo qualche volta adesso che siamo in beta il numero di partecipanti esterni (non del team di sviluppo) e’ aumentato. Adesso abbiamo almeno un rappresentante del team QA presente ogni giorno oltre a qualcuno del team operativo (responsabile per i server) e qualcuno del team di gestione della comunita’ e del marketing (feedback da parte dei giocatori e del forum). Come ho detto prima la seconda differenza e’ relativa agli argomenti trattati e, mentre prima si parlava di funzionalita’ e design, adesso discutiamo dello stato della beta, dei bug importanti, di come risolverli e di quando mettere sui server una nuova versione che risolva bug critici.

Alcuni bug sono molto difficili da riprodurre, altri sono puramente cosmetici, alcuni sono in realta’ solo decisioni di design non valide. Come facciamo a decidere su cosa focalizzarci e cosa e’ veramente importante? Beh, per prima cosa abbiamo il livello del problema assegnato dal gruppo QA e che altro non e’ che l’importanza e l’impatto di un bug sul gioco:

  • Bloccante: deve essere risolto, crea grossi problemi al gioco o fa’ crashare i server, non si puo’ mettere su una nuova versione fino a che non e’ risolto.
  • Critico: deve essere risolto prima di mettere una nuova versione
  • Maggiore: deve essere risolto prima del lancio
  • Normale: deve essere risolto

Un altro cambiamento e’ relativo all’integrazione con il personale del QA direttamente nel team di sviluppo. Per capire l’impatto dovete prima capire come il nostro team di sviluppo e’ strutturato. Il team di sviluppo puo’ essere diviso in due grandi parti: tecnica e contenuti. La prima include i programmatori e il personale tecnico mentre la seconda include gli addetti alle animazioni, i designer, gli artisti e tutti coloro che non sono tecnici. I team dei contenuti a sua volta e’ suddiviso in altri team ognuno focalizzato su un’area differente. Questo include ad esempio i livelli 1-20, il combattimento e i controlli, gli oggetti e la magia o l’interfaccia del gioco. Ognuno di questi team al momento include una persona del gruppo di QA che sta’ insieme alle persone del gruppo e puo’ testare e controllare immediatamente i piccoli cambiamenti e la funzionalita’ delle soluzioni dei bug. Questo riduce drasticamente il tempo per risolvere e verificare i bug.

Un’altro cambiamento riguarda il come le versioni vengono create. Essendo in beta e dovendo risolvere parecchi bug ogni volta bisogna fare nuove versioni del gioco molto piu’ spesso rispetto a una fase di produzione. Dobbiamo essere sicuri che la versione che viene rilasciata in beta sia stabile e che non abbia (o siano pochi) i bug bloccanti che possono prevenire un test accurato. Per fare in modo che una versione sia abbastanza stabile bisogna limitare il numero di bugfixes inclusi (dato che una soluzione di un bug puo’ crearne un altro). Allo stesso tempo i bug devono essere risolti e quindi gli obiettivi di avere versioni stabili e risolvere piu’ bug possibili vanno in direzioni diametralmente opposte. La soluzione per questo e’ molto simile a quella di suddividere i team in gruppi piu’ piccoli descritta sopra ma questa volta quello che viene diviso e’ il codice. In questo modo possiamo limitare il numero di cambiamenti e il numero di persone che possono farli. Questo ci da’ un miglior controllo di quello che viene messo in ogni versione e ci aiuta a testare le funzioni dato che possiamo focalizzarci su parti molto piccole ogni volta.

Qualcosa che puo’ essere molto difficoltoso da sistemare e’ tutta la parte di dati che viene generata come risultato di una beta. Tutti questi dati o feedback devono essere collezionati e interpretati. Per esempio avere il tempo di leggere tutte le informazioni sul forum puo’ essere una grande sfida. Questo e’ il momento in cui entra in gioco il team di gestione della comunita’ che scrive dei report su quello che i beta tester pensano siano problemi importanti. Oltre a questo alcuni sviluppatori passano piu’ tempo di altri sul forum, ad esempio un designer che lavora sul bilanciamento delle classi e sullo sviluppo dei personaggi avra’ bisogno di discutere di talenti e abilita’ e sara’ in questo aiutato dai beta tester; un artista grafico che sta’ ripulendo alcuni pezzi di vecchie armature basandosi sul feedback dell’art director non avra’ bisogno di molti input da parte dei beta tester per fare il suo lavoro.

Mentre eravamo in fase di produzione non abbiamo passato moltissimo tempo a documentare tutti i cambiamenti di contenuti come nuove quest, cambio degli NPC, etc. Questo perche’ la persona che implementava e testava i contenuti era solitamente la stessa. Ma quando si e’ in fase di beta bisogna essere piu’ disciplinati e scrivere esattamente cosa e’ cambiato. Questa informazione e’ utilizzata per generare le patch notes di ogni versione. Le patch notes sono poi utilizzate dal team QA e dai beta tester per controllare che i problemi delle vecchie versioni siano stati risolti.

Ah… un’ultima cosa. Ho parlato molto riguardo il codice e la soluzione di bug del codice. E’ importante notare che i bug possono anche essere causati da dati incorretti: per esempio il premio di una quest puo’ mancare o un NPC in una zona puo’ avere il livello sbagliato e quindi essere troppo forte o troppo debole. Entrambi questi esempi sono dei bug ma risultano essere problemi di dati e non di codice. Alcune volte un bug puo’ essere la risultante di problemi sia sul codice che sui dati.

Adesso sapete un po’ di piu’ rispetto al nostro lavoro e sapete perche’ tiene noi poveri sviluppatori svegli durante la notte 😉

Fonte articolo

Annunci

~ di heruel su 24 aprile 2008.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

 
%d blogger hanno fatto clic su Mi Piace per questo: