Non sempre i retrofront in un progetto sono negativi. Spero che anche in questo caso sia così. Come qualcuno di voi potrà facilmente notare, infatti, ho eliminato ogni tipo di pubblicità dal mio blog. Questo perché voglio continuare sulla linea della “passione” e non pensare a quanto mi possa aiutare questo o quell’articolo. Tanto quei quindici euro all’anno per l’hosting li posso mettere senza problemi.

Magari potrei mettere un piccolo pulsante per le donazioni, riportando ovviamente (se gradito) il nome di chi ha contribuito a mantenere questa piccola realtà viva.

Stavo pensando inoltre di cambiare tema al blog… vedremo un po’ se farlo, crearlo da zero o prenderne qualcuno già esistente.

In più ho sistemato, dove prima c’era la pubblicità a lato, un bel bannerone dell’iniziativa Internet For Peace, che trovo valida e fantastica.

Detto questo, tanti saluti e buon ferragosto (passato) a tutti

Ciao a tutti,

scusate se non ho scritto per un po’ ma diciamo che ho avuto qualche contrattempo. Come al solito il blog non viene abbandonato! Sono in un periodo di stallo in quanto ci potrebbe essere qualche lavoretto in vista (nel caso vada in porto lo annuncerò qua sopra).

Qualche tempo fa, inoltre, sui forum di IndieVault, cercavo ispirazione per un nuovo soggetto delle mie guide… il mio obiettivo era di imparare ad utilizzare discretamente un qualcosa di più potente, più vicino ad una realtà di livello maggiore.

La scelta, dopo una lunga indecisione tra Unity3D e l’UDK di Epic, è ricaduta sulla prima alternativa.

Ciò quindi vuol dire che presto inizierò a pubblicare qualche guida su Unity. Come da tradizione, cercherò di iniziare traducendo quello che leggerò sulla guida ed aggiungendoci qualcosa di mio; appena avrò più tempo invece cercherò di realizzare un piccolo progettino da solo e quindi insegnare qualcosa e allo stesso tempo imparare.

Buona Navigazione

Nell’ultimo articolo ci eravamo fermati, durante l’analisi della Proposta di Gioco (Game Proposal), alla cosiddetta “Analisi Tecnica” da parte del team di sviluppo. Ora possiamo proseguire nel nostro cammino, prendendo in esame l’Analisi Legale, Costi e Stime di Guadagno, Concept Art, Presentazione del Documento e Errori da Evitare, come promesso.

Osmos

Analisi Legale

L’Analisi Legale è semplice da spiegare: deve essere usata solo in cui in ballo ci siano copyright, marchi registrati e tutto quello che può entrare in questo ambito. Devono essere specificate anche eventuali licenze utilizzate durante la creazione del gioco.

Una cosa invece da evitare è specificare l’eventuale necessità di registrare il titolo del gioco ed il logo: sono cose piuttosto comuni e non c’è bisogno di dirle.

Costi e Stime di Guadagno

Nel caso di grandi aziende, questa parte del documento può essere compilata con l’aiuto del reparto finanziario e vendite. I dati contenuti in questa pagina devono dare al lettore una stima approssimativa del costo delle risorse necessarie alla realizzazione del progetto.

I Costi delle Risorse sono ovviamente variabili e vengono decisi in base alle necessità e disponibilità dell’azienda. La forma migliore per presentare questi dati è in forma tabulare, includendo il costo per mese, il numero di mesi di lavoro ed il totale calcolato per ogni risorsa.

Oltre alle risorse umane, all’hardware e il software dobbiamo tenere presente che ci possono essere dei costi aggiuntivi. Questo è il momento di specificare eventuali costi per licenze, contratti, testing e così via.

Bisogna quindi specificare il cosiddetto SRP, Suggested Retail Price (Prezzo di Vendita Consigliato). Ovviamente il prezzo deve essere deciso in vari modi, partendo dal prezzo di prodotti simili già presenti sul mercato per arrivare al valore effettivo del prodotto.

Infine, si arriva alla proiezione dei guadagni. Dovrebbero esserci tre tipi di proiezioni: il caso pessimista, in cui le cose vadano male, il caso normale ed il caso ottimista. Nel caso ci sia un budget assolutamente certo allora lo si può specificare.

Tutto il resto è fuori.

Concept Art

Nel caso il Concept di Gioco scarseggi in termini di Concept Art, questo è sicuramente il momento migliore per inserirne un po’.

Fate in modo di eliminare qualsiasi Art non realizzata direttamente dagli artisti del team. Includete degli schizzi, anche semplici, di protagonisti, unità varie, palazzi o qualsiasi cosa possa avere importanza.

Ancora più accettate sono le immagini di azioni vere e proprie.

Un Consiglio? Immaginate che chi leggerà il documento valuterà il tutto solo guardando questa sezione. Cercate di presentare il meglio che avete a disposizione tra gli Artwork, mi raccomando.

Ed infine c’è la Presentazione. Tutto il documento dovrebbe essere stampato e rilegato con cura, in più copie. Il documento sarà presentato a gente che cerca il dettaglio anche in queste piccole cose.

Nel caso sia tu stesso a presentare il documento, fai in modo di essere vestito per bene e prepara anche qualche slide con PowerPoint od OpenOffice.

Quest’ultima idea può aiutarti a concentrare l’attenzione dei lettori su pochi punti focali che vuoi usare come perno per il tuo successo.

Cosa Bisogna Evitare?

Anche per questo tipo di documento ci sono un sacco di cose da evitare. Vediamo un po’ quali sono:

• Analisi basate su numeri assurdi.

Stai presentando qualcosa che avrà a che fare con soldi, forse pure tanti soldi. Non inventarti cifre se non sai precisamente di cosa parli, perché poi dovrai spiegare tutto.

• Annoiare i lettori.

Stai presentando qualcosa che devi VENDERE. La presentazione non deve essere noiosa ma deve invogliare l’ascoltatore/lettore ad interessarsi al tuo lavoro.

• Essere insicuri e sensibili verso la critica.

Dovete dare l’impressione di avere a che fare con qualcosa di solido, un’idea che sa il fatto suo. Dovete crederci fermamente, a prescindere da come andrà a finire la presentazione.

• Fare una proposta non flessibile.

Potrebbero esserci dei cambiamenti da fare, ma il gioco, per come è strutturato, non lo consente. Questo è sicuramente un punto a vostro sfavore. A volte, per sopravvivere, bisogna cambiare.

Anche questa parte è andata. Ringrazio tutti per la lettura!

Una volta realizzato il Concept di Gioco e dopo averlo presentato, si passa alla fase successiva di questo importante insieme di documenti. Stiamo parlando della Proposta di Gioco, o Game Proposal. Ma che differenza c’è tra Game Concept e Game Proposal?

Dunque, stando alle parole del buon Tim, la cosiddetta proposta di gioco è qualcosa di più formale, utilizzata per assicurarsi i fondi e le risorse richieste dal gioco. Per evitare perdite di tempo, dovrebbe essere preparata esclusivamente per i progetti più promettenti, in quanto appunto deve essere realizzata con la massima cura e precisione.

La Game Proposal è anche un insieme di ricerche: in una grande realtà addirittura sarà necessario contattare il dipartimento di Marketing, per cercare informazioni sul target del gioco. O ancora, sarà opportuno raccogliere più dettagli possibile su eventuali licenze da pagare.

Il lavoro non finisce qui: i programmatori e lo staff tecnico, tramite le persone dei Senior Programmer, devono effettuare una cosiddetta “valutazione tecnica” del concept. Il loro obiettivo è comprendere fino a che punto è fattibile il progetto e quali aree del loro lavoro chiederanno un approfondimento. Questo quindi consentirà di definire le task più importanti del progetto (Major Tasks).

La ricerca è all’ordine del giorno.

Tutte queste ricerche hanno un effetto sul Concept originale. Imprevisti come la carenza di risorse, problemi legali e tecnici possono portare a scalare le dimensioni del Concept, in modo tale da adottare soluzioni adatte alla situazione aziendale e tecnologica.

Come suggerito da molti, questi cambiamenti non devono ASSOLUTAMENTE buttare giù il designer o scoraggiarlo: d’altronde è una situazione che può verificarsi spesso e questo consente di comunicare col proprio team e capire in anticipo cosa c’è che potrebbe andare storto. Uno strumento da non sottovalutare assolutamente, insomma.

Ora, vediamo un po’ da cosa è composta una tipica Game Proposal:

• Game Concept Rivisitato
• Analisi di Mercato
• Analisi Tecnica
• Analisi Legale (se necessaria)
• Costi e Stime di Guadagno
• Concept Art

Abbiamo già spiegato la funzione del Game Concept rivisitato… vediamo un po’ gli altri punti a cosa servono.

• Analisi di Mercato

Nel caso esista un dipartimento di Marketing nella compagnia in cui ci si trova, si deve compilare questa sezione di analisi. Se invece la realtà in cui si lavora è piccola, o addirittura sei tu che stai compilando queste informazioni, evita assolutamente di tirare ad indovinare su numeri e cifre.

Nell’analisi di mercato dobbiamo parlare senza dubbio del Target a cui stiamo puntando. Il target è un fattore definibile dal genere del nostro gioco e dalla piattaforma, dati sicuramente già definiti nel Concept di Gioco. Una buona mossa è cercare i titoli che meglio rappresentano il genere, in modo tale da avere punti di riferimento.

Potrebbe essere opportuno specificare anche il tipo di cliente medio: età, sesso ed altre caratteristiche chiave.

Una ricerca altrettanto utile dell’Analisi di Mercato è la ricerca dei cosiddetti Top Performers, ovvero case produttrici e titoli che hanno reso meglio per quanto riguarda il nostro stesso target. Evidenziare le vendite in termini numerici e possibilmente anche in termini temporali, parlando delle date dei periodi di vendita.

Ragionare in termini di piattaforma. Per esempio: dobbiamo sviluppare un gioco di calcio per Playstation 3. Possiamo evidenziare il caso dell’ultimo Pro Evolution Soccer per PC, ma non dobbiamo tenerlo come principale riferimento in questa sezione. Il primo della lista potrebbe essere Pro Evolution Soccer nella sua versione per PS3, anche se magari ha venduto molto di meno rispetto alla controparte per PC. Tenete a mente il vostro Target.

La fase successiva è quella di Comparazione delle Caratteristiche (Feature Comparison): il nostro compito qui è quello di prendere in esame i Top Performers e considerare ognuna delle caratteristiche di ogni titolo, confrontandole con quelle del nostro concept.

Un esempio? Nel gioco xxx ed yyy, strategici a turni considerati top sellers, il giocatore poteva eseguire le azioni A,B,C e D. Nel nostro progetto, zzz, il giocatore potrà eseguire le azioni A,B,C,D,E,F e G, senza considerare la quantità enorme di unità a disposizione e la caratterizzazione dei personaggi principali.

Tutto chiaro? Passiamo avanti.

• Analisi Tecnica

Come potete ben immaginare, l’Analisi Tecnica deve essere scritta da un programmatore piuttosto esperto, che sappia quello che fa e quello che dice senza incertezze. La cosa migliore è che a scrivere questa parte del documento sia un lead programmer, o ancora meglio un direttore tecnico.

Starcraft 2

Questa parte è decisamente importante, in quanto coloro che dovranno visionare questo documento baseranno molte delle loro scelte su questa sezione. D’altronde qui si parla di tutto quello che si può realizzare in maniera effettiva. In più, questa analisi dovrebbe rendere i “revisori” ben disposti ed ottimisti nei confronti di un successo del gioco.

La prima parte di questa sezione riguarda le caratteristiche sperimentali del progetto: è all’inizio che dobbiamo parlare di eventuali tecnologie mai testate, di innovazione. Non bisogna assolutamente includere caratteristiche che sono già state usate in altri titoli.

Ovviamente non bisogna neanche parlare di caratteristiche sperimentali nel caso di features comuni ma nuove al team. Esempio pratico: il nostro team di sviluppo non ha mai lavorato su un sistema audio surround e questa è la prima volta. Questa NON È una feature sperimentale. Il nostro team di sviluppo sta lavorando su un sistema di rendering utilizzando delle tecnologie nuove e mai usate prima. Questa È una feature sperimentale e merita di essere aggiunta.

È necessario parlare di tempi di realizzazione per queste features: queste aree di sviluppo infatti richiedono spesso la maggior parte dei tempi richiesti dal progetto nella sua totalità.

Nota Importante: mettete a vostro agio chi leggerà il documento. Molte compagnie hanno quasi paura di progetti a lungo termine, dato che richiedono un’infinità di risorse. C’è da dire però che una feature sviluppata in modo eccezionale ed unica nel suo genere possono cambiare tutto.

Dopo questa parte è opportuno specificare nel dettaglio quali saranno le cosiddette Major Development Tasks, ovvero tutte le cose più importanti da sviluppare per il nostro gioco. Non utilizzate un linguaggio tecnico, in quanto deve essere comprensibile per tutti.

Per i tempi da proporre, bisogna considerare il caso in cui si abbiano tutte le risorse necessarie ad un corretto svolgimento delle attività. “Major”, come dice il buon Tim, significa “Mesi di Sviluppo”. Intesi?

Facciamo un esempio pratico di uno di questi punti:

• Parser di Script per l’Intelligenza Artificiale: richiesti dai tre ai quattro mesi di lavoro, due programmatori. Il parser trasforma gli script in logica di basso livello, in istruzioni eseguite in tempo reale.

Si passa quindi a parlare dei Rischi. Si, in un progetto ci sono anche quelli. Intendiamo infatti tutti quegli elementi con i quali il team può avere difficoltà, per uno o più motivi dei più disparati.

Il nostro team non ha mai sviluppato un gioco di corse? Questo può essere un rischio. Il nostro team non ha mai avuto a che fare con una certa tecnologia? Anche questo è un rischio, assolutamente da non sottovalutare. Insomma, può essere di tutto, da un genere ad una piattaforma, passando per librerie, API ed Engines.

Ed ecco una delle parti più ostiche: bisogna specificare, nel caso i nostri intenti fallissero, di quanto la data di uscita del gioco slitterebbe. Per esempio, un uso errato di una libreria potrebbe far slittare il tutto di un paio di mesi? Bisogna specificarlo.

Non fatevi ingannare, questa sezione non deve portare pessimismo, tutto il contrario! Se si sanno quali sono i rischi, il progetto è sotto controllo in tutti i suoi aspetti.

Dopo i rischi specifichiamo anche le Alternative. Nel caso una feature si riveli troppo rischiosa, questo è il posto giusto per proporre qualcosa di alternativo, permettendo quindi una scelta più ampia a coloro che leggeranno il documento e dovranno prendere delle decisioni. Per ogni alternativa specificare Pro e Contro.

Subito dopo troviamo una Stima delle Risorse. Qui c’è da fare una lista di qualsiasi tipo di risorsa sia necessaria alla creazione del progetto. Persone, software, hardware e tutti i servizi collegati, non si deve lasciare fuori niente.

Parlate di loro in termini di tempi d’uso, ignorate il costo, per ora.

Infine c’è da parlare dei Tempi Stimati. Bisogna parlare del ciclo di sviluppo, delle milestones del progetto, introducendo anche una data per l’inizio dei lavori ed altre date per l’arrivo in Alpha, Beta e Gold Master.

Art di Fable III

Adesso cervello in pausa! Nell’ultima parte dell’articolo parleremo di Analisi Legale, di Costi e Stime di Guadagno e Concept Art, senza ovviamente tralasciare qualche consiglio sulla Presentazione del Documento e tutti quegli errori da evitare.

Ciao!

Aggiorno velocemente per informarvi con grande piacere che molto presto su questo sito vedrete dei tutorials tradotti, provenienti direttamente dal blog di Emanuele Feronato, programmatore Italiano che però scrive in inglese. Con altrettanto piacere aggiungo che Emanuele mi ha chiesto di poter tradurre alcuni dei miei articoli…

Che dire? Spettacolare!

Bye!

Bene, iniziamo a parlare di Concept di Gioco, o Game Concept in inglese. Di cosa stiamo parlando? È quella “parte” del nostro Design Document che ha il compito di esprimere l’idea alla base del gioco, nel suo nucleo fondamentale. Tutto parte da qui: il Game Concept verrà sottoposto ai piani alti, come anteprima della Proposta di Gioco vera e propria (altra parte che vedremo dopo).

Gli elementi che vengono presentati qui sono molteplici e riguardano il gioco nella sua interezza, senza tuttavia lasciare indietro i dettagli più importanti che rendono unica l’idea. Una volta sottoposta l’idea al direttore del team di produzione, quindi, verranno decisi quali di questi dettagli dovranno diventare realtà e quali no.

Unreal Tournament 3

Ovviamente, in questo modo vengono raccolte in un solo documento tutte le idee inerenti al gioco, rendendole consultabili ed eventualmente modificabili. Il documento in questione inoltre è piuttosto corto, con una lunghezza di circa 2-3 pagine.

Ma vediamo nello specifico cosa compone un documento di Game Concept:

• Introduzione
• Background
• Descrizione
• Caratteristiche Chiave
• Genere
• Piattaforma/e
• Concept Art

Introduzione

L’introduzione è sicuramente una delle parti più importanti in un documento di questo genere. Dovete considerare, infatti, che queste parole saranno le prime ad essere lette, e penso sia chiaro che devono essere piuttosto efficaci, tanto da attirare il lettore al punto di farlo continuare.

Verranno incluse tutte le informazioni più importanti, che devono essere mostrate subito: titolo, genere, piattaforma, cosa lo distingue dagli altri titoli del genere e così via, in base alle esigenze.

Un esempio? Vi ripropongo quello dell’articolo di Tim Ryan:

“Man or Machine è uno sparatutto in prima persona per PC, che usa l’affidabile motore di Quake II per portare il giocatore nei panni di uno space marine androide, in un epica guerra tecnologica interstellare nel 37° secolo.”

Si parla di piattaforma, si parla di genere… proprio come avevamo detto

Background

Ritenuto opzionale (dubito che ci possa essere SEMPRE la necessità di spiegare il Background di un gioco di carte), serve ad espandere la descrizione data nell’introduzione. È senza dubbio la parte migliore per parlare di progetti, prodotti, licenze e proprietà che si, sono importanti, ma non così tanto da essere utilizzate nell’introduzione.

Facciamo un esempio anche qui. Per un nostro progetto abbiamo usato l’UDK (Unreal Development Kit) nella fase di sviluppo. Questo è il posto giusto dove parlarne. Ancora meglio, oltre a parlare del tool utilizzato possiamo anche accennare a due o tre success stories che riguardano questo tool! Di sicuro può aiutare a convincere i piani alti

Descrizione

Questa è ovviamente una parte che non possiamo saltare. In pochi paragrafi o perché no, anche una pagina, dovete spiegare l’idea del vostro gioco. Descriverla attentamente, come se i lettori fossero innanzitutto giocatori del vostro futuro prodotto.

Il vostro obiettivo è rendere la lettura di questa sezione invitante, eccitante e deve far venire la voglia di provare il gioco al vostro lettore. Un’ottima idea è senza dubbio quella di ripassare la trama del gioco descrivendo esattamente ciò che il giocatore può fare.

Decisamente opportuno, inoltre, evitare tecnicismi quali “pulsante del mouse” o parlare di “tasto x della tastiera”. Il lettore/giocatore deve immergersi per bene nell’esperienza.

Pro Evolution Soccer 2011 – In un’introduzione per questo gioco di sicuro si può parlare di realismo

Caratteristiche Chiave (Key Features)

Ogni gioco, dal momento in cui viene concepito nella mente del designer, ha un suo punto di forza. Magari ne ha anche più di uno: questa è la sezione in cui parlare di questi pregi particolari. Le caratteristiche chiave sono infatti una lista di features del nostro prodotto che vogliamo evidenziare agli occhi di tutti.

Molto spesso, questo elenco di punti è lo stesso che appare dietro le scatole dei giochi. Per portarvi un esempio pratico, riporto alcuni punti trovati sulla scatola di Hitman 2 : Silent Assassin, vecchia gloria.

• Numerose soluzioni disponibili per portare a termine una missione;
• Effetti dinamici di caduta dei corpi e degli oggetti;
• Presenza di un contatore che mostra il livello di sospetto stimolato nelle persone che si incontrano nel gioco;
• Nessun tempo di caricamento all’interno delle mappe.

Ovviamente, stilare con precisione una lista di questo genere può essere più difficile di quanto si pensi. In realtà è un gioco di equilibri: bisogna evitare di presentare solo uno o due punti (e se il gioco ne ha effettivamente uno o due di punti salienti, beh, devono essere veramente eccezionali), ma bisogna evitare anche di compilare due pagine di peculiarità.

Ricordate, inoltre, di essere leggermente modesti. La vostra grafica è bella ma non eccezionale, dato che puntate su un comparto audio stupendo? Allora parlate di straordinari effetti sonori e un capolavoro di colonna sonora, ma non della grafica strabiliante che vi farà uscire gli occhi dalle orbite.

Genere

In parole povere, spiegate qual’è il genere del vostro gioco. Per andare sul sicuro usate le classificazioni base che trovate su un qualsiasi magazine videoludico. Sport, Strategia in tempo reale, Sparatutto, Puzzle, Simulazione di Corsa, Avventura, Gioco di Ruolo… e così via.

Volendo potete anche raffinare la cosa, specificando un “settore” specifico del genere. Per esempio, che tipo di sport? Oppure, che tipo di ambientazione per il nostro sparatutto? Steampunk o da Seconda Guerra Mondiale?

Ci siamo capiti.

Piattaforma/e:

Giusto due parole per spiegare per quali piattaforme sarà sviluppato il vostro gioco. Volendo potete indicare quale delle piattaforme sarà la “preferita”, nel caso ci sia, oppure questo è anche il posto giusto per specificare l’eventuale presenza di servizi di rete (giochi in multiplayer online).

Concept Art:

Altra voce opzionale per questo documento, può rivelarsi sicuramente un aiuto nel caso si abbiano già idee ben definite per quanto riguarda una caratteristica, un personaggio, un luogo particolarmente adatto ad essere mostrato in prima linea.

Come esempio vi lascio questi due splendidi artwork di Assassin’s Creed 2.

Niente male, vero?

Cosa può andare storto?

Le cose, come ben sapete, non sono sempre rose e fiori. Un fattore qualsiasi può pregiudicare tutto, per cui dovete stare attenti, molto attenti, quando si parla di un documento di design e della sua creazione e successiva proposta.

Più di dieci anni fa Tim Ryan specificò cosa bisogna assolutamente evitare prima e durante la scrittura.

Vediamo un po’:

• Proporre dei concept fuori portata per la realtà in cui si lavora.

Se l’azienda per cui lavoriamo ha nei suoi piani dei lavori legati ai titoli di strategia in tempo reale, potrebbe rivelarsi uno spreco di tempo andare a proporre l’fps dell’anno realizzato con il motore di Unreal 3.

• Il gioco che vogliamo realizzare chiede questo mondo e quell’altro in termini di risorse.

Si, anche a me piacerebbe svegliarmi domani mattina, installare il nuovo Cryengine che non ho sul mio modesto portatile e lavorare al titolo dell’anno. Ma no, per ora non posso farlo.

• Il documento scarseggia in termini di contenuti.

Vero, non bisogna esagerare andando nel superfluo, ma fate in modo che non manchi assolutamente niente. Ricordate il gioco di equilibri di cui vi parlavo prima? Ecco.

• Il gioco non è divertente.

Sembra quasi brutto da dire, ma può capitare un sacco di volte. Un esercizio utile?  Prendete in considerazione ogni verbo che rappresenta un azione fattibile dal giocatore: sparare, correre, comprare, costruire, immaginando come il giocatore possa compiere ognuna di queste azioni.

Vi sembra divertente? Se si, andate avanti, altrimenti c’è qualcosa di sbagliato. Ah, e siate obiettivi.

• Il documento presenta una grammatica scadente e povera in termini di linguaggio.

Controllate fino ad essere sicuri di ogni singola parola, non fate la figura degli imbecilli. Evitate parolacce e cose troppo spinte: il manager politicamente scorretto che visionerà il documento potrebbe essere particolarmente diligente sul lavoro… per cui occhio.

• I designer smettono di proporre.

MAI, e dico MAI fare questo errore. Bisogna continuare a proporre nuove idee, nuove visioni, fin quando è possibile. Evitiamo di far morire un progetto prima che parta, no?

Bene. Una volta che il nostro Concept di Gioco è pronto (e magari viene anche accettato) è tempo di fare un passo avanti. Nel prossimo articolo di questa mini serie parleremo della Proposta di Gioco, o Game Proposal.

Ciao!

Su questo blog, molto spesso, ho parlato di giochi. Anzi, quasi sempre diamine, è un blog tematico. Se avete seguito i tutorial voi stessi avete visto che anche per un gioco dei più semplici come TicTacToe c’è un momento in cui mi fermo e dico: ok, prima di scrivere del codice fermiamoci un attimo a pensare.

Anche per giochi di una volta, come il Tetris, era necessario pensare, ponderare su quello che si stava per fare. Bisognava pianificare tutto e molto spesso gli sviluppatori avevano, letteralmente, a disposizione tonnellate di appunti.

Le cose, ovviamente, sono cambiate col tempo. Gli strumenti che vengono usati per la progettazione di un gioco si sono evoluti. La figura stessa del programmatore si è dovuta adattare a questi cambiamenti e si è dovuta “specializzare” in un ramo ben preciso: Audio, Grafica, Reti, Intelligenza Artificiale, e così via.

I casi in cui un programmatore fa tutto da solo, quindi, per un gioco di un certo livello, sono praticamente impossibili da trovare.

Così si formano i team. Squadre di persone in cui ognuno ha un compito. E si arriva quindi al punto in cui bisogna comunicare. Qui arriviamo al perno del nostro articolo: il Documento di Design.

Quando viene concepito un progetto, il designer che l’ha ideato deve essere capace di metterlo nero su bianco, su un documento da mandare in giro ai vari settori dell’azienda, in modo tale da far capire a tutti ciò che si deve realizzare, come lo si deve realizzare, con quali mezzi e, possibilmente, in quanto tempo.

Nonostante agli occhi di un neofita come me, inizialmente, la cosa possa sembrare quasi inutile, nelle grandi realtà è roba comune, di tutti i giorni, e necessita di una certa attenzione.

Mass Effect 2. Si, è una realtà molto grande questa.

Nota Importante: la traccia che vi proponiamo nei prossimi articoli è, appunto, una traccia. Non è obbligatorio seguirla ed è solamente uno spunto per avere una certa linearità.

Quali sono, quindi, gli scopi che ogni documento di design deve raggiungere?

• Eliminazione dell’ “Hype” : è una dura realtà. Quando abbiamo a che fare con società abbiamo a che fare con dei soldi. Non tutti i progetti sono realizzabili. Il primo scopo del D.D. (Design Document) è quello di definire gli elementi principali del gioco, in modo tale da trasformare in maniera coerente i sogni in qualcosa di fattibile.
• Chiarezza, Certezza : usare un D.D. di sicuro offre una chiarezza che altrimenti non si potrebbe avere. Creando un’uniformità si hanno dei documenti più facili da leggere e sia coloro che scrivono che coloro che leggono sanno cosa aspettarsi.
• Facile Creazione di Task e Test : una volta che si definisce un buon D.D, tradurre il tutto in un insieme di task da portare a compimento è decisamente più semplice e praticamente intuitivo.
• Variazioni : a volte, durante la realizzazione di un concept particolare, si può abbandonare la propria traccia per rendere il progetto adatto ad un’altra. Capita molto spesso. C’è inoltre da dire che molto spesso alcuni elementi di gioco non devono essere per forza riportati. Un esempio pratico? Le regole del gioco del poker, che già si conoscono, oppure i dettagli di un progetto di porting di un gioco già esistente.

Fatte le dovute premesse possiamo andare avanti. Nel prossimo articolo parleremo del primo dei due documenti trattati nell’ambito del D.D: la spiegazione del Game Concept, ovvero l’idea vera e propria nella sua forma più astratta.

Finalmente rieccomi qua, a scrivere qualcosa per questo blog. Non è passato molto tempo dall’ultimo articolo, certo, ma fa sempre piacere. Oggi siamo qui per parlare di Game Design, e non in termini di guide pratiche per la creazione di giochi.

Stavolta permettetemi di “esulare” un po’ dal nostro filone più classico. Stavolta parliamo infatti di “teoria”: qualche giorno fa sono capitato per caso su Gamasutra ed ho letto un interessantissimo articolo, dedicato allo studio della cosiddetta “Anatomia di un Documento di Design”.

Beyond Good And Evil 2

Dopo averlo letto e spulciato un po’ (ed averlo trovato decisamente utile), potete ben immaginare a cosa ho pensato… perché non scrivere qualcosa di simile in Italiano? Ho così scritto a Tim Ryan, autore dell’articolo datato 1999.

Più di dieci anni fa, ma pur sempre valido. Fa quasi strano vedere come certe cose non cambiano nel tempo in un settore la cui evoluzione è tremendamente veloce.

Tim purtroppo non mi ha risposto, evidentemente l’email segnalata sul sito non era quella che ha adesso… così ho cercato ancora ma niente, sembra che anche un altro indirizzo che ho trovato sia inattivo.

Fatto sta che non mi arrendo, per cui tradurrò lo stesso questo documento, aggiungendo al tutto, magari, qualche riferimento vero e proprio a livello di impaginazione del documento e, perché no, potrei portare anche qualche esempio pratico.

Dopo questo annuncio quindi vi lascio, mettendomi al lavoro sulla guida vera e propria. A presto!

Approfitto, prima di partire in mattinata, per fare un annuncio su una fesseria che però mi ha fatto molto piacere. Come avete potuto vedere in questo ultimo periodo ho portato avanti un bel po’ di tutorials su Flixel (no, non mi sono scordato dell’ultimo, sto solo facendo qualcosa di più serio da proporvi).

Bene, stamattina cercando su Google la parola chiave “Flixel” ho scoperto che siamo in prima pagina, subito dopo flixel.org e il repository su github.

Click per Ingrandire – Thanks Google!

Meglio di così