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!