A mio malgrado, per la maggior parte dei progetti assegnati al mio team, il documento di design è già stato scritto da qualcuno (nel senso di "esterno al team") e non ho idea del criterio con cui venga redatto (imho, un po' alla c***o ). Spesso, quel documento è nel formato che tu chiami "fisso".

Tuttavia, in un'occasione ho avuto il piacere di sviluppare e testare l'early prototype cartaceo di un concept. Sono sempre stato un fan di questo approccio e mi ha reso estremamente felice rendermi conto che funziona Sempre in quell'occasione, abbiamo utilizzato la wiki aziendale per hostare i documenti di design.

Hai ragione Stefano, non mi sono spiegato. Parlavo di prototipazione rapida contro un tipo di procedimento, che mi pare a naso ancora molto usato, che introduce il testing solo quando il prototipo è già a uno stadio piuttosto avanzato.
Ovviamente sono d'accordo con te, il testing è più che fondamentale (e ci mancherebbe).

L'articolo di Costikyan invece era piuttosto chiaro; mi riferivo soprattutto alla parte finale:


E ancora:

Non si tratta solo di incompetenza o inerzia, ma anche di inesperienza.
Tempo fa, parlando col fondatore di C******** circa il loro ultimo lavoro, mi è parso che il loro design fosse un po' debole, sensazione poi suffragata una volta acquistato il gioco.

Vien da dire che più iterazioni in fase di prototipo avrebbero aiutato, ma non lo credo. Le meccaniche in questione non erano nulla di nuovo, ci sono tanti esempi già belli e pronti sotto forma di giochi, solo in teoria già nel bagaglio del loro designer. Dico che se non si sà perchè una meccanica funziona, si finisce per testare e sperare.

Costikyan afferma che il game design è un processo di iterativo raffinamento e aggiustamento tramite il testing, che permette di far combaciare l'idea con l'esperienza finale del giocatore.
Dall'esempio portato sopra, aggiungo che se non si da sufficiente peso alla fase cartacea, si finisce per sprecare solo tempo e risorse. Non ha senso re-inventare la ruota ogni volta.


Nota: non era Costikyan ma Patrick Dugan.

Mah, un wiki resta comunque un documento, di certo più dinamico di certe monolitiche bible. Era su questo che ragionavo. Non capisco proprio il senso di:


Se faccio un wiki lo faccio di comune accordo con il team e tutti sanno che a quello devono fare riferimento.

Eheh Luca, grazie, ma non è che faccia nulla di particolare. Mi faccio domande, più che altro.

Io trovo che un Wiki fatto bene, impostato fin da subito con un certo criterio possa essere molto organico, invece.

Ma mi son fatto 5 anni buoni di puro web, ho imparato a usare un po' di strumenti e magari la mia opinione è biased. Ciononostante, nei piccoli progetti a sfondo ludico affrontati in questi anni il wiki ha funzionato molto bene (vedremo in quello più grosso che si profila all'orizzonte).

Credo che il problema grosso del Wiki, invece, sia il team che lo usa. Se non si è orientati a un certo tipo di lavoro, pronti a usare la comunicazione in rete e via dicendo, si rischia di usare male lo strumento (come dice Giovanni, usare un martello per avvitare).

Comunque la parte della mia domanda sulla quale sono più curioso resta quella relativa alla prototipazione. Soprattutto a quella su carta, fatta senza scrivere ancora una riga di codice per capire se le core mechanics funzionano. Giovanni fa un'osservazione interessante in proposito. Per esempio: come fai a prototipare un ARG?

Ho usato GoogleDocs per diversi progetti e lo trovo lento, scomodo e farraginoso.
Tutte le volte che me l'hanno chiesto ci abbiamo provato, ma alla fine abbiamo sempre abbandonato.
Molto meglio, a mio parere, mettere i documenti in questione sotto controllo versione ed usare eventualmente le revisioni di word.

Parlo di mie personali opinioni, tenendo conto anche del fatto che sono un utente di Word piuttosto avanzato (script, revisioni, stili, compare, ecc.).

Dovesse interessare a qualcuno questa discussione (che però si è spostata più sul wiki che su quello che davvero mi interessava ovvero la prototipazione rapida e su carta), qui c'è un ottimo articolo che sviscera i pro e i contro del wiki.
Per quello che vedo, molti dei contro (ad eccezione della stampabilità) sono facili da superare se si sa usare il mezzo.