ArsLudica.org Forum
Cogitare => Somnia => Topic aperto da: Emack - Agosto 04, 2007, 19:54:41
-
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 (http://www.gamasutra.com/view/feature/1522/the_designers_notebook_why_.php?print=1), 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 (http://www.gamasutra.com/php-bin/letter_display.php?letter_id=1438), 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?
-
Di recente ho letto il "documento di design" (:asd: - 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.
-
Certo è che buttare giù qualche idea è il primo test se tali idee possano effettivamente funzionare o meno.
-
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" (:asd: - 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...
-
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.
-
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
-
Hai detto niente :asd: . 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 :asd:
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) :asd:
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.
-
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.
-
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?
-
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.
-
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.
-
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 :look:
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.
-
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.
-
Ho aggiustato il quote nel post di Monkey, non capivo come faceva a non essere d'accordo con sé stesso :look:
-
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.
-
Quanto contino questi documenti di design è molto soggettivo. Adams ha sperimentato la loro utilità e ha portato esempi precisi del loro campo di applicazione, mentre Kelly sembra celarsi dietro una presa di posizione, affermando che tutti i documenti vengono scritti male e quindi non servono. Premetto d'aver letto l'originale articolo di Adams, ma non quello di Kelly, per il quale mi rifaccio al post introduttivo di Emack.
Personalmente parto sempre da un'idea cui cerco di dare forma nella mia mente. E' inevitabile che una moltitudine di pensieri s'affollino e s'accavallino creando una certa confusione. Mettere per iscritto i tratti salienti del proprio concept aiuta a non perdere il filo. Per me funziona come un flusso continuo di pensiero, per rubare malamente una definizione alla letteratura. Se non tenessi una traccia cartacea sarei perduto. C'è poi da sottolineare che i cosiddetti creativi non stanno segregati in oscuri pensatoi, isolati da ogni fonte di disturbo: spesso si pensa al gioco successivo quando si sta completando ancora quello precedente, con la necessità di rispondere a domande di vario genere, ecc. In tal senso Kelly ha ragione, piuttosto che andarsi a leggere il testo, si preferisce chiedere al designer o allo scrittore, magari nella stanza accanto!
Dopo aver "schizzato" l'idea grezza, viene il momento per dare forma razionale... dicesi carta e penna!
Alla fine potreste aver fatto tutto questo lavoro a mente, ma arrivati al momento d'istruire il team, vi sarete preparati un discorso o parlerete a braccio, anche avendo innanzi potenziali finanziatori? ...carta e penna!
Non nego di non lesinare sulle parole se posso, ma è impossibile che qualcosa non vada messo nero su bianco.
Più che le opinioni del singolo vedo in questi due i rappresentanti di due correnti di pensiero non necessariamente opposte.
Ernest Adams, come molti altri (vedi Warren Spector), cerca di dare un fondamento accademico a questa neonata disciplina, distaccandosi dalla cognizione di un design creativo puramente artistico e come nato dal genio del singolo, per introdurre invece un metodo razionale, possibilmente condivisibile (il genio artistico invece non si può condividere).
Tadhg Kelly tiene in considerazione solo il lato pratico della faccenda, non avendo tutti i torti quando afferma che i documenti sono scritti male e inutili, ma proprio perchè manca un fondamento accademico, molti non sono in grado di sapere come impostare un testo così vitale e importante.
Non ha pregio che vi sia un prolificare di scuole di gamedesign o simili, perchè da sempre università e industria sono due mondi che comunicano poco e in differita. E' infondato e retorico dire che tutti i docenti sono designers mancati, come si dice degli insegnati di scrittura, ma forse a qualcuno il dubbio resta...
Il mio modo di operare mi fa propendere pesantemente verso quanto afferma Adams, ma non è un caso che cercando, si trovino ben pochi esempi in rete di moderni siffatti documenti: gli interessati dovrebbero mettervi insieme un pacco di fogli e post-it, correggere errori, ordinare gli argomenti, e così via. Non è questione di segreti da custodire, diciamo solo che la "mega bibbia suprema" non esiste nella forma comunemente intesa.
In definitiva, per rispondere alla domanda, i design-documents contano quanto a contenuti e non a come sono stesi.
Pensiero finale: se Adams è del genere amanuense allora è certo che Kelly sia tra i più ciarlieri.
-
Ottimo intervento Galdr.
Soprattutto qui:
In definitiva, per rispondere alla domanda, i design-documents contano quanto a contenuti e non a come sono stesi.
-
Benvenuto Galdr :D
Più che le opinioni del singolo vedo in questi due i rappresentanti di due correnti di pensiero non necessariamente opposte.
Ernest Adams, come molti altri (vedi Warren Spector), cerca di dare un fondamento accademico a questa neonata disciplina, distaccandosi dalla cognizione di un design creativo puramente artistico e come nato dal genio del singolo, per introdurre invece un metodo razionale, possibilmente condivisibile (il genio artistico invece non si può condividere).
Tadhg Kelly tiene in considerazione solo il lato pratico della faccenda, non avendo tutti i torti quando afferma che i documenti sono scritti male e inutili, ma proprio perchè manca un fondamento accademico, molti non sono in grado di sapere come impostare un testo così vitale e importante.
Sono d'accordo. Del resto, lo stesso Adams nel suo famoso libro sostiene che il design di un gioco non è né esclusivamente estro creativo né rigoroso metodo scientifico.
[...]Game design is not purely an art because it is not primarily a means of aesthetic expression. "Artistry" comes into envisioning the initial concepts and ideas, but once that is done, it's time for the real work of defining and refining how the game will function. Nor is game design purely a science; it doesn't posit hypotheses or seek truth. It's not bound by rigorous standards of logic or formal methods. The goal of a game is to entertain through play, and designing a game requires both creativity and careful planning.[...]
Poi, usa una parola, "elegance", per sintetizzare l'equilibrio tra aspetti artistici e istanze razionali:
Interactive entertainment is an art form, but like film, television, and theater, it is a collaborative art form, with no single person entitled to call himself the artist. In fact, most designers don't think of themselves as artists at all. Designing games is a craft, like cinematography or costume design in Hollywood. A game contains both artistic and functional elements: It must be aesthetically pleasing, but it also must work well and be enjoyable to play. The greatest games combine these attributes brilliantly, achieving a quality for which the only word is elegance. Elegance is the sign of craftsmanship of the highest order.[...]
Come non condividere?
Ad ogni modo, penso che non vi sia un dissidio sostanziale tra Kelly e Adams...
Il mio modo di operare mi fa propendere pesantemente verso quanto afferma Adams, ma non è un caso che cercando, si trovino ben pochi esempi in rete di moderni siffatti documenti: gli interessati dovrebbero mettervi insieme un pacco di fogli e post-it, correggere errori, ordinare gli argomenti, e così via. Non è questione di segreti da custodire, diciamo solo che la "mega bibbia suprema" non esiste nella forma comunemente intesa.
Infatti la mega bibbia suprema è stata superata già dal finire degli anni Novanta. Giovanni Caturano su Playfields.net afferma che esistono titoli da dieci milioni di euro con game bible da 20 pagine...
Comunque Kelly ha lavorato con sua maestà Molyneux in The Movies... Tanto ciarliero non è. :asd:
-
Ciarliero per dire che predilige la comunicazione orale, come davo dell'amanuense ad Adams perchè sostiene i documenti scritti.