Stampa

Effettua l'accesso o una nuova registrazione.
1 ora 1 giorno 1 settimana 1 mese Sempre
Inserisci il nome utente, la password e la durata della sessione.

[Emack]

Sfrutto l'occasione di un dibattito apertosi recentemente su Gamasutra.com per parlare di un argomento veramente interessante, di fondamentale rilevanza nell'ambito del game design.

Secondo Ernest Adams, sussistono cinque ragioni principali per cui i documenti di design sono importanti:

1) Gli investitori (publisher ed altri) li pretendono come prova del fatto che il designer conosca il suo mestiere.
2) Fungono talvolta da base per obblighi contrattuali.
3) Comunicano le intenzioni del designer al resto del team, consentedo a quest'ultimo di pianificare poi i suoi compiti.
4) Trasformano un'idea vaga in un piano particolareggiato.
5) Costituiscono un registro di tutte le decisioni prese.

Di tutt'altro parere invece Tadhg Kelly, il quale sostiene che, nella loro forma attuale, i documenti di design non sono per niente importanti. Ecco i motivi principali:

1) Sono scritti molto male.
2) Di solito sono molto noiosi.
3) Spesso sono troppo generici e non specifici.
4) Gli unici che si basano su tali documenti sono i designer che parlano nei meeting a persone appartenenti ad altre discipline, che non li hanno letti e che finiscono per chiedere al designer semplicemente cosa egli voglia.
5) Tenere traccia dei cambiamenti e delle decisioni prese importa solo agli avvocati.

Dunque, sempre secondo Tadgh Kelly, i designer dovrebbero semplicemente domandare "Cosa ti serve?" piuttosto che dire "Ecco la mia visione, solo se la leggi potrai capirla".
_____________________________________________________

Ammetto di essere sinceramente sconcertato. Tutte le mie letture (e i miei piccoli sforzi) concernenti il game design sono molto influenzati dalla corrente di pensiero esplicitata da Ernest Adams, e mai e poi mai avrei creduto di trovare opinioni radicalmente opposte come quelle di Tadhg Kelly - che comunque, a quanto mi è sembrato di vedere, sono minoritarie.
Un tale dissidio lascia presagire quanto, nell'industria, il processo di design (e anche quello di sviluppo, a questo punto) sia poco standardizzato e poco regolamentato; in altre parole, sembrano ancora latitanti delle solide basi teoriche in grado di fornire delle linee guida affidabili.

Voi che ne pensate? E cosa rispondereste alla domanda posta nell'oggetto del topic, ovvero: quanto contano i documenti di design?

[StM]

Di recente ho letto il "documento di design" ( - in realtà abbastanza riassunto) della serie a fumetti di Sandman, di Neil Gaiman. C'erano descritti i primi numeri, a grandi linee, ma il fumetto ha preso strade più interessanti.

Allo stesso modo, Alan Moore spiega in un articolo come è nato "V for Vendetta": è venuto fuori mattoncino dopo mattoncino, tra schizzi e bozze e proposte, e credo che fino all'ultima pagina dell'ultimo volume l'idea definitiva non si sia mai cristallizzata in un "documento di design".

Sottolineo che sto parlando di fumetti che hanno fatto storia.


Sono vere entrambe le posizioni. I documenti di design sono utili, ma se ne può fare a meno.


In molte realtà di sviluppo di software, la parte di "design" è, vero, ingiustamente trascurata: magari ti chiedono di cominciare subito a buttare giù qualcosa "per vedere se si può fare"; poi quando dovrai creare il prodotto definitivo avrai i tuoi grattacapi per avere qualcosa che non solo funziona ma è mantenibile, se non hai buttato nel cesso quello che hai dovuto fare di fretta. Però raccogliere tutte le specifiche subito non è mai facile. E una nuova specifica può invalidare tutto un documento di design, specie se non (o troppo) lungimirante.

Le "solide basi teoriche" potranno essere trovate da, e funzionare per, uno o due grandi cervelli in tutto il mondo (mentre i *geni* continueranno ad avere le migliori soluzioni possibili nelle loro tasche).

Bu.

[StM]

Certo è che buttare giù qualche idea è il primo test se tali idee possano effettivamente funzionare o meno.

[Emack]

Tadhg Kelly ha tutta la mia simpatia.

Perché? Solo una tra le obiezioni che muove Kelly è sostanziale, cioé il fatto che non sembrano venire incontro alle effettive necessità del resto del team.
Le altre obiezioni dipendono semplicemente dalle capacità del designer, come il saper scrivere o il saper intrattenere il lettore.

Di recente ho letto il "documento di design" ( - in realtà abbastanza riassunto) della serie a fumetti di Sandman, di Neil Gaiman. C'erano descritti i primi numeri, a grandi linee, ma il fumetto ha preso strade più interessanti.

Allo stesso modo, Alan Moore spiega in un articolo come è nato "V for Vendetta": è venuto fuori mattoncino dopo mattoncino, tra schizzi e bozze e proposte, e credo che fino all'ultima pagina dell'ultimo volume l'idea definitiva non si sia mai cristallizzata in un "documento di design".

Sottolineo che sto parlando di fumetti che hanno fatto storia.

Ma nei fumetti non ti trovi a dover coordinare reparti differenti tra di loro. Inoltre il concetto di documento di design cristallizzato è superato: oggi assomiglia ad un ciclo iterativo, che segue di pari passo lo sviluppo.

Sono vere entrambe le posizioni. I documenti di design sono utili, ma se ne può fare a meno.

Secondo me se ne può fare a meno solo se stai scrivendo un nuovo Screamer o un clone qualsiasi di Mario, non se ti trovi a definire qualcosa di più articolato, come uno STALKER.

Le "solide basi teoriche" potranno essere trovate da, e funzionare per, uno o due grandi cervelli in tutto il mondo (mentre i *geni* continueranno ad avere le migliori soluzioni possibili nelle loro tasche).

Eppure anche i *geni* organizzano il loro lavoro in documenti di design: Romero, Perry, Miyamoto...

[StM]

Le "solide basi teoriche" potranno essere trovate da, e funzionare per, uno o due grandi cervelli in tutto il mondo (mentre i *geni* continueranno ad avere le migliori soluzioni possibili nelle loro tasche).

Eppure anche i *geni* organizzano il loro lavoro in documenti di design: Romero, Perry, Miyamoto...

Ma suppongo che ciascuno usi il proprio metodo. Quel che voglio dire è che non credo possano esistere solide basi teoriche generali. Ogni sviluppatore è diverso, ogni team ha una composizione propria; di conseguenza ogni documento di design, per essere usato come riferimento, deve essere strutturato e mantenuto in funzione dei destinatari. Le soluzioni generali possono anche esistere, e quei due-tre cervelloni al mondo potranno anche riuscire ad applicarle; la teoria la vedo altrimenti molto più fumosa, e cedente il passo alla prassi.

[Emack]

Ma suppongo che ciascuno usi il proprio metodo. Quel che voglio dire è che non credo possano esistere solide basi teoriche generali. Ogni sviluppatore è diverso, ogni team ha una composizione propria; di conseguenza ogni documento di design, per essere usato come riferimento, deve essere strutturato e mantenuto in funzione dei destinatari. Le soluzioni generali possono anche esistere, e quei due-tre cervelloni al mondo potranno anche riuscire ad applicarle; la teoria la vedo altrimenti molto più fumosa, e cedente il passo alla prassi.

Eppure, ad ogni GDC, vedo molti sforzi tesi proprio a cercare di creare un metodo standardizzato convincente, una sorta di scienza galileiana applicabile al mondo dei videogiochi. Forse che ci si sta concentrando su un aspetto sbagliato? Forse la vera standardizzazione sta nel ridisegnare il ruolo del designer e dei documenti di design, come sostiene Kelly (il quale, comunque, non ne rigetta l'utilità di per sé, ma semplicemente afferma che, così come sono pensati dalla maggior parte della gente, secondo lui sono inutili)?

EDIT: ecco come devono essere dei buoni documenti di design secondo Kelly: http://particleblog.blogspot.com/2007/04/eight-steps-for-good-game-design.html

[Emack]

Hai detto niente . Poi toglierei quel "semplicemente"... si vede che non è tanto semplice e che non riesce a molti, e va tenuto presente.

Non è tanto semplice anche perché al design viene dato uno spazio strano nello sviluppo: piuttosto che fare il suo lavoro, al designer viene spesso dato il compito di redigere documenti inutili.

L'intervento di Tadgh Kelly lo vedo appunto nel senso di una "sburocratizzazione", insomma più "cannoni" e meno pianificazione iperdettagliata e maniacale di ogni scorreggia

Nella mia - sicuramente insufficiente - esperienza di gruppetti amatoriali, programmatori e grafici hanno sempre voluto sapere con precisione cosa andava fatto, perché una descrizione non dettagliata di un qualcosa può portare a risultati non soddisfacenti.
Come devono essere implementati i danni in un clone di GTA2? Come bisogna creare delle mappe modificabili dinamicamente in un RTS?
Sono tutte domande le cui risposte vanno affidate a trattazioni esaurienti.

convincere gli investitori che hai qualcosa in mano,

Per quel che ne so, un semplice documento di design può convincere solo Nintendo a sbloccare dei fondi per Miyamoto. Per tutti gli altri comuni mortali, un documento di design non accompagnato da una base tecnologica (una demo, insomma) è assolutamente inutile. E' un di più, insomma.

ma già iniziare iniziare un gioco (quindi un qualcosa di divertente) a partire da scartoffie pallosissime che nessuno vorrebbe mai leggere, addirittura con rigorosità scientifica, è qualcosa che mi lascia perplesso

Beh, ma devi tener presente che un gioco è ormai un software molto complicato. Ho visto diagrammi UML in gruppi semiprofessionisti, figuriamoci in produzioni da tripla A.

Mi sembra un modo per imbavagliare la già tragicamente scarsa creatività che c'è nel settore... Penso anch'io poi che (anche fortunatamente) la teoria alla fine ceda un po' il passo alla pratica... e che i risultati finali siano piuttosto diversi dalle intenzioni iniziali. Con una metafora un po' ardita, alla fine la partita la vinca (soprattutto) Baggio che salta otto giocatori, non l'allenatore che si fa le pippe con videocassette e schiemi alla lavagna (mentre i giocatori pensano a chi si tromberanno quella sera in discoteca)

Purtroppo l'esito di una partita, leggendo i vari postmortem di titoli grossi, è determinato dalle esigenze e dalle scadenze di produttori e publisher, non dalle pippe dei designer (comunque, ripeto, è superata - non penso neanche abbia avuto mai successo - la visione del documento-bibbia che anticipa lo sviluppo: oggi il design è un processo continuo).

EDIT1: E comunque non tutti possono permettersi Roberto Baggio; e, ancora, neanche la squadra che lo possiede può dare per scontato che scarti 8 giocatori e vada a rete ogni domenica.

EDIT2: Stabilire un metodo non significa ammazzare la creatività. Architetti, scienziati, matematici: ognuno di essi segue delle regole, eppure geni come Renzo Piano, Enrico Fermi, e Renato Caccioppoli hanno saputo esprimersi.

[Monkey Soft]

EDIT: ecco come devono essere dei buoni documenti di design secondo Kelly: http://particleblog.blogspot.com/2007/04/eight-steps-for-good-game-design.html

Condivido.

[Emack]

EDIT: ecco come devono essere dei buoni documenti di design secondo Kelly: http://particleblog.blogspot.com/2007/04/eight-steps-for-good-game-design.html

Condivido.

Sono punti condivisibili, ma dopo averli letti mi sento ancora più confuso. I suoi consigli sono gli stessi di Miyamoto, e del tanto biasimato Adams. Mi aspettavo una posizione più lontana... Che le sue lamentele siano di stampo politico, di "sburocratizzazione", come dice ABS?

[Monkey Soft]

A me sembra molto chiaro nella lettera che ha mandato a Gamasutra: ogni persona, ogni ruolo nel team di sviluppo necessita di informazioni diverse. Secondo lui è molto più utile scrivere documenti separati specifici per i diversi "lettori" piuttosto che un unico, grosso documento che contenga tutto e spesso più di quello che effettivamente serve. Perchè alla fine ognuno legge solo la parte che gli interessa. Se la trova.


Posso dire una cosa fuori dai denti, a margine? Quelli che dicono "Ho un'idea stupenda per un gioco! Ecco la storia: ..." non hanno capito un cazzo.

[Monkey Soft]

Leggevo altri post del buon Tadhg, questo sul ruolo del designer è molto interessante:

http://particleblog.blogspot.com/2007/03/whats-my-job.html

Look at many modern games that are now coming out. They are over-featured because coders always program features. They are over-visualised, using bloom all over the place and creating cling-film-o-vision or Uncanny Valley simulators. They are tedious, unadventurous and basically dull. Why? Because coders like features, artists like prettiness and producers like visions that can be sold. Nobody is saying "This just doesn't work" with the authority to change it.

That's where I come in to the equation.
What's my job? My job is to say no.

My job is to say "nice idea but it doesn't work". My job is to say "yes I understand that the desired visual effect is not being met, but no, you can't chop the levels into 1/10th their size". My job is to say "there are only 11 mechanics in this game and no more". My job is understand the gameplay of the desired game (whether it be my own or someone else's), define what the game is and what it is not, craft the design constraints of the project and then ram them down the throats of people who just want to exercise their discipline without consideration.

Il lavoro del designer è dire no.
Concordo in pieno.

[Emack]

A me sembra molto chiaro nella lettera che ha mandato a Gamasutra: ogni persona, ogni ruolo nel team di sviluppo necessita di informazioni diverse. Secondo lui è molto più utile scrivere documenti separati specifici per i diversi "lettori" piuttosto che un unico, grosso documento che contenga tutto e spesso più di quello che effettivamente serve. Perchè alla fine ognuno legge solo la parte che gli interessa. Se la trova.

Ma Adams non ha mai proposto una game bible illegibile. Anzi, ha sempre proposto un sistema equilibrato che spiegasse per bene le meccaniche di gioco, e che fosse finalizzato alla programmazione dello sviluppo.

A project manager can’t create a schedule, task list and staffing allocation - and follow their progress - without knowing exactly what needs to be built, and that information must exist in written form.

Questo mi sembra un assunto incontestabile.

Posso dire una cosa fuori dai denti, a margine? Quelli che dicono "Ho un'idea stupenda per un gioco! Ecco la storia: ..." non hanno capito un cazzo.

Al design contest erano quasi tutte così, le proposte

Il lavoro del designer è dire no.
Concordo in pieno.

Non sono d'accordo, tant'è vero che anche Kelly dopo usa un verbo per esplicare meglio le sue intenzioni: il lavoro del designer consiste nel definire cosa è gioco e cosa non lo è. Una definizione non la si fornisce dicendo esclusivamente no.

[Monkey Soft]

Il lavoro del designer è dire no.
Concordo in pieno.

Non sono d'accordo, tant'è vero che anche Kelly dopo usa un verbo per esplicare meglio le sue intenzioni: il lavoro del designer consiste nel definire cosa è gioco e cosa non lo è. Una definizione non la si fornisce dicendo esclusivamente no.

Ovviamente prima va definito chiaramente il gioco e scritto il doc. Lì parlava di quello che dovrebbe fare il designer durante lo sviluppo vero e proprio. E' un po' limitativo, ma rende l'idea.

[StM]

Ho aggiustato il quote nel post di Monkey, non capivo come faceva a non essere d'accordo con sé stesso

[Joe]

Non sono quasi per niente d'accordo con quanto espresso da Tadhg Kelly, il/i documenti di design sono necessari e vitali per tracciare una mappa su cui va costruito il videogioco, la sua storia, la struttura e soprattutto le sue regole. Per me non è assolutamente fumo, è sostanza, in molti casi diventa un calderone di idee più o meno organizzate da cui attingere per realizzare uno o, a volte, più giochi. Probabilmente lui fa riferimento a quando si scrivono veri e propri libri, un pò come la Doom Bible di Tom Hall da cui Carmack e soci attinsero ben poco, rispetto al malloppo realizzato dal buon Tom. In tal caso non ci trovo niente di male, se chi scrive ha molta fantasia è bene che completi il tutto inserendoci tutte le sue idee pertinenti al contesto del videogioco in sviluppo.

Inoltre spesso l'idea per un videogioco viene portata da un solo individuo, per rendere chiara la sua visione ai membri del suo team è bene che metta tutto su carta, in questo modo il designer stesso si può rendere conto se certe idee possono funzionare o meno.

Questo è il mio pensiero basato anche su alcune mie piccole esperienze in proposito (purtroppo non ho mai avuto un artist decente, anzi uno solo e mi ha abbandonato, e mi sono arenato).

Lasciamo stare le canne a zio Yak, con tutto il rispetto.