Pubblichiamo un guest post di Francesco Carucci, programmatore esperto nel settore 3D, specializzato nello sviluppo di videogiochi su varie piattaforme hardware.
In una recente intervista Mark Healey, uno dei fondatori di Media Molecule, reputa le dimensioni del team di sviluppo un fattore fondamentale per la buona riuscita dell’attesissimo Little Big Planet.
Il gioco, un platform tridimensionale sui generis per PS3, sta ricevendo amplissimi consensi sia dalla critica sia dai giocatori che hanno messo le mani sulla demo rilasciata di recente. Sony punta molto su questo titolo in chiave “Console War”, individuandolo come grimaldello nei cuori dei casual gamer conquistati da Nintendo, prima che Microsoft riesca a metterci le mani sopra a colpi di “price cut”.
Mark, riguardo al team di sviluppo, parla di circa trenta persone, come limite massimo oltre il quale “smette di divertirsi”. Al di là del divertimento, le dimensioni dei team odierni sono diventate un grosso fattore limitante nell’Industry:
è opinione tanto diffusa (quanto sbagliata) che per produrre più contenuti, sia in termini di game play sia puramente estetici, basti aggiungere persone su persone a team già pachidermici, facendo lievitare i costi e aggiungendo crescenti difficoltà di comunicazione.
E così questa generazione vede giochi sempre più costosi, sempre più in ritardo e sempre meno curati. Il risultati sono patch dopo patch, poi tagli e ancora patch a coprire enormi buchi lasciati durante le ultime, affrettate, fasi di sviluppo affidate a programmatori e artisti stremati.
La soluzione è forse, come spiega Mark, ridurre le dimensioni dei team, aumentarne l’efficienza, migliorare le metodologie di sviluppo, divertirsi? Se Little Big Planet avrà successo, potremo ritenerlo un inizio.
Concordo. Tra le leggi di Murphy, e’ definita come “legge dell’orda mongola”
Se per fare un muro, un muratore impiega 100 giorni, 10 muratori impiegheranno 10 giorni, 20 muratori 5 giorni. Ma 100 muratori non ci impiegheranno 1 giorno, e 200 muratori non lo finiranno mai, arrivando probabilmente a prendersi a mattonate a meta’ dell’opera.
Si applica a qualsiasi lavoro di squadra.
Sante parole.
@Ilruz
in realtà basta dividere il territorio a metà e creare 2 team da 50 lavoratori.
Idem nel software, basta rendere modulari i vari “reparti”. Le cose si complicano solo se una miriade di persone devono far capo ad un unico responsabile. O, al contrario, se ci sono 3000 responsabili ogni 10 lavoratori.
L’idea di dividere un grosso team in sotto team “indipendenti” che decidono del loro destino, interfacciandosi al resto del team come una sola entita’, e’ interessante e qualcuno nell’Industry ci sta gia’ provando. Le cose si stanno un po’ muovendo.
@Brightsoul
Allora secondo te “dividendo il territorio” in 100 parti, il muro viene su in un giorno? e se ognuno fosse responsabile di se stesso solamente … detto muro verrebe su piu’ in fretta?
Dissento :P
Il mio sopra era un esempio per far capire che i team devono essere dimensionati “il giusto”: il metodo Ilruz prevede che ogni team sia composto da una piccola parte di “di inutili”, non piu’ di due “primadonna”, un solo “genio”, un solo “creativo”, non piu’ di due “capi” e una decina di “operai” a testa, per ogni capo.
Fatti il conto, e arriveremo ad una cifra vicina al “30” di cui parlava l’articolo, che condivido pienamente.
Gruppi di lavoro piu’ grossi sono gruppi alienanti, che portano ad un regime di lavoro giapponese, dove quel che conta e’ la produzione, non importa se ti viene il karoshi.
p.s.: avere nel gruppo un tot di “inutili” e’ fondamentale.
Prima di gridare al miracolo e strapparsi i capelli fatevi un giro alla beta.
Un editor fantastico … ma manca il gioco!
E’ di un banale e semplice che non vi potete immaginare!
Lo prendo … ma usato.
Non li vale 70€. (come gioco)
Al di la’ della bonta’ o meno del gioco che e’ un fattore anche soggettivo (un gioco semplice non e’ necessariamente un brutto gioco), il nocciolo della questione qui e’ spostato piu’ sulle problematiche relative allo sviluppo di un videogioco e le dimensioni ottimali del team. LBP e’ giusto un esempio.
I giochi che hanno venduto di + nella storia sono esattamente quelli semplici, se proprio dobbiamo andare a vedere il capello :D
Il ragionamento cmq di rendere flessibili oltre che le metodologie di sviluppo anche i team e l’organizzazione degli stessi credo sia sensata.
Una volta, quando i costi erano decisamente più contenuti e non dico da uno scantinato ma quasi poteva uscire un buon prodotto allora ci si poteva permettere di sprecare risorse, ora che per sviluppare un titolo e cercare di venderlo nel mass market occorrono cifre a 6-7 zeri è impensabile.
Già due, tre persone messe da qualche parte a non fare niente sono ore uomo-lavoro che fanno la differenza sull’uscita di un prodotto, senza contare tutti i problemi di comunicazione e di gestione del team che si hanno in situazioni di sovrabbondanza (ad esempio si fa un 4 un lavoro di una o due persone, che magari non sono sincronizzati al 100% con tutti i problemi che ne derivano). Posso immaginare su numeri più consistenti.
Un delirio.
Mi piace l’idea della modularità del team. Certo bisogna sperare che sia introdotta prima che in Windows altrimenti sto fresco mi pare di capire :D
I tempi in cui un Geoff Crammond da solo tirava fuori un gioco sono un lontano di ricordo, ma l’opposto (un team enorme) a quanto pare porta più problemi che benefici. :D