RSS
Credo che il lavoro di cui più si parla ma meno si sa sia quello di game designer.
Esistono corsi che spiegano come diventarlo, ma qui lo dico e qui lo confermo, prendendomi tutta la responsabilità di questa frase: i corsi (universitari o meno) per diventare game designer sono una perdita di tempo e di soldi. Non fateli e non supportate chi li fa: vi ruba tempo e soldi.
Bene, detto questo, cosa fa un game designer? Beh, la Leggenda vuole che
il Santissimo Game Designer plasmi i sogni e ne faccia ludo.
La Leggenda non è troppo distante dalla realtà, ma vediamo cosa fa esattamente il game designer (da ora GD).
Prima di tutto pensa all’idea, ovviamente. Fatto questo, la stende utilizzando documenti standard, in modo che il lettore saprà dove trovare tutto quanto.
E questa è la parte breve.
Poi viene la parte lunga: il tuning. Il GD, una volta che ha in mano un prototipo, lo gioca fino ad averlo in odio e lo rende il più giocabile possibile, tunando i valori che vengono forniti. Spesso (SPESSO) ne chiede di nuovi, poiché dopo aver visto com’è il gioco, di certo vorrà altre cose.
Quindi come deve fare un ragazzo per diventare GD? Deve laurearsi in lettere? Ma va’ là! Deve giocare. Deve giocare a tutti i giochi del mondo e deve saper capire cosa va bene e cosa no.
Poi deve entrare in una piccola società, magari che fa giochi per cellulari. Da lì potrà partire.
Taluni hanno raggiunto lo scopo grazie a concorsi (tipo quello di TGM di qualche anno fa).
Ma è tutto sollazzo? No, anzi: quando vi chiederanno di mettere giù un design per i menù, facendo delle semplici bozze di ogni pagina, vorrete aver scelto di fare il tappezziere. Tutti i lavori hanno la loro parte pallosa, dopo tutto.
Ora vediamo il maggior nemico del GD: se stesso.
Perché? Perché ogni GD ritiene di avere l’idea definitiva per il gioco incredibile e perfetto. Molto spesso questa idea richiederebbe un budget pari al PIL annuale dell’America, ma lui sa che se qualcuno lo facesse, allora venderebbe moltissimo.
Il GD deve quindi avere bene in mente cosa significa “fare un gioco con un dato budget”, quindi saprà che ci saranno cose che non ha senso chiedere.
Ad esempio, supponiamo che mi arrivi questo design:
“Voglio fare un gioco tipo Oblivion, ma più ricco e complesso”. Poi seguono 300 pagine di spiegazione.
Purtroppo lo cestinerò, anche se magari sarebbe un gioco pazzesco.
Sembrerebbe quasi che il GD debba conoscere le evoluzioni della tecnologia. Verissimo, ma lui deve sapere cosa sono ad un livello molto alto. Se non conosce le nuove potenzialità, allora parlerà con il capo programmatore, per sapere cosa può chiedere e cosa no. Oppure chiederà e si vedrà le feature tagliate.
Un’altra cosa che il GD deve sapere è che un gioco deve essere DIVERTENTE. Non REALISTICO o SIMULATIVO o SUPERFIGO.
La prima parola deve essere sempre “DIVERTENTE”. E’ divertente un simulatore perfetto di intestino? No.
Ma sarebbe divertente un simulatore del corpo umano con gli omini tipo “Esplorando il corpo umano” e facendolo tipo “Warcraft”? Boh, forse sì, se si mette giù bene.
Veniamo ora al modo di lavorare.
Nessuno si aspetta che il design venga chiuso il giorno X e non venga mai più riaperto. Sarebbe una grave mancanza di esperienza da parte della produzione. Il designer può apportare modifiche, tagliare feature e generalmente fare cambi alle interfaccie durante tutta la vita del prodotto.
Quello che è MOLTO bene non faccia è cambiare quelle parti che richiedono un completo ripensamento. Prendiamo un esempio: da sempre, da design, un’avventura grafica sarebbe dovuta essere a “tempo statico”, cioè il tempo non passa in gioco e gli eventi accadono grazie a dei trigger.
Di colpo il designer decide che invece il tempo sarà effettivo e gli eventi accadranno in vari momenti del tempo, che noi ci siamo o no. Questo richiede, ovviamente un cambio completo del gioco. Questo cambio potrebbe essere semplicemente tagliato, ma avrebbe portato a tempo perso del designer: tempo che poteva dedicare al tuning degli hotspot (in un’avventura grafica sono fondamentali).
Molto più grave è una cosa del tipo: “Sarebbe figo avere in gioco dei personaggi non giocanti, che facciano cose semplici, niente di complesso”, sempre nella nostra avventura grafica. Bene, se prima non era previsto, significherà che i programmatori dovranno aggiungere un elemento “alla bell’emmeglio”, poiché tutte le strutture dati ed i salvataggi non prevedevano una cosa del genere.
Il problema di queste richieste “vorrei una cosa semplice, così tanto per” non andranno mai bene, perché una feature appena abbozzata fa SEMPRE schifo. Quindi, dopo che si saranno ficcati questi personaggi nella nostra avventura grafica, è praticamente sicuro che faranno schifo ed il loro comportamento sarà sì semplice, ma orribile.
Finale della storia: i personaggi verranno tolti e si sarà perso tempo. Il tempo è danaro, quindi si saranno persi soldi.
Quindi è assolutamente fondamentale che il GD sappia identificare quelle tematiche che fanno da “mattoni portanti” del videogioco. Quelle feature non dovranno mai essere toccate, perché nel momento in cui si decide di NON fare qualcosa, gli ingegneri ottimizzeranno il tutto intorno a quella mancanza.
Bisogna anche saper identificare cosa invece NON è un mattone portante. Tutti gli asset grafici, ad esempio, non lo sono.
Credo che questo insegnamento sia forse uno dei più importanti che possano essere trasmessi.
La critica potrebbe essere che forse sarebbe meglio anticipare il cambiamento, facendo dei framework molto duttili. Questo è vero, ma la duttilità, se troppo spinta, si paga in complessità, molto spesso “complessità di utilizzo”.
Quindi riassumiamo cosa deve fare il GD:
- Scrivere il documento di design (ci sono ottimi esempi su GPI)
- Tunare il gioco, chiedendo modifiche
- Progettare le interfacce
Cosa bisogna fare invece per diventarlo?
- Entrare in piccole compagnie che si occupano di entertainment
- Giocare a centomila giochi
- Capire cosa è divertente e cosa invece no
- Capire cosa è importante e cosa invece no
Alla prossima!
Non sapevo di avere un curricul ottimo per fare il game designer 😀
ah, no… mi piace anche leggere… nun se po’ fare 😀
Ottimo articolo, specialmente per il sottoscritto che sta studiando per i fattacci propri proprio per diventare game-designer. Una cosa è certa, non credo sia comunque semplice diventarlo, specialmente perchè di gente che “ha giocato centomila giochi” ce n’è parecchia. Monops, domanda: ma un’azienda, in base a quali requisiti assume un completo “neofita” in game-design? Tu hai parlato di aziende che fanno giochi per cellulari, ma penso che anche queste abbiano più o meno dei requisiti o delle linee guida. Dubito che assumano il primo cristo che si presenta da loro dicendo “ho giocato centomila giochi”, ho questo titolo di studio, etc… oppure…?
Diciamo che le richieste sono in genere “l’esperienza”. In genere, se si è dei neofiti totali, va meglio tentare appunto in aziende piccole (giochi per cellulari o flash) allegando al curriculum un design per un gioco semplice, che sia nel target dell’azienda.
Facendo corsi, si potrebbe scrivere sul curriculum, ma comunque senza nessuna esperienza non vale nulla. Non crediate: di persone che hanno giocato tanti giochi e li hanno anche analizzati cercando di capire il processo di creazione non ce ne sono poi tantissimi. Ovviamente il fatto che avete giocato una barca di giochi non andrebbe sul curriculum in “Esperienze Lavorative” 😀 Però è un requisito fondamentale.
E ti pareva se non c’era la frecciata agli umanisti =D
Aggiungo anche che ormai gli spunti più interessanti ed accessibili per un dilettante, un neofita o un freelance si hanno proprio sul fronte web/mobile/flash.
Una cosa che forse Alex ha sottolineato poco è che è molto meglio se un GD abbia almeno una vaga idea (meglio se una buona idea) di cosa voglia dire programmare e sviluppare un gioco, e, in particolare, delle potenzialità del team in cui lavora.
Spesso un sacco di problemi vengono fuori proprio perché il GD, oltre a non tenere conto del budget, non tiene conto di cosa è realistico aspettarsi da un team di sviluppo di un determinato tipo. Di contro, il GD non deve MAI fare il tecnico: la sua visione deve essere di più alto livello, altrimenti crea dei pastrocchi implementativi feature-driven tipo EVE Online!
Un grande articolo, che parla direttamente agli interessati. Secondo me la cosa più importante sottolineata dal Monops è il fatto di rimanere con i piedi per terra, capire i limiti (sia propri, sia economici che tecnici).
Per quanto riguarda la divisione tecnici/umanisti… beh, per quel che mi riguarda (come in tutti i campi della creatività) il GD è migliore se ha una mente poliedrica. Più comprende il significato di ogni comparto di gioco, sia da un pdv tecnico che estetico e meglio sarà.
Esempi come Yu Suzuki sono emblematici (tra le mille cose è pure pittore ed espone in gallerie d’arte…).
Essendo il videogioco un’opera multimediale, spero che si arrivi presto a una corrente di pensiero neo-rinascimentale in questo campo. 😉
@Monops
Si ma, come può un neofita avere “esperienza lavorativa” se è per l’appunto, un neofita? Dalla discussione che abbiamo avuto in privato tempo fa mi sono messo a leggere articoli sul game-design, raccogliere materiale vario e ora sto pian pianino organizzando le idee per scrivere i miei primi documenti di design (per “allenamento”, e per imparare), ma mi chiedo fino a che punto fare l’autodidatta possa aiutare.
Autodidatta o meno, non cambia niente 🙂 Ti dicevo: un buon modo è allegare al curriculum un design che teoricamente andrebbe bene a quell’azienda. Per non mettere idee particolarmente “preziose”, il mio consiglio è fare il design di un gioco classico, pensandolo per Flash o per il cellulare.
Domanda polemica: che tu sappia, è già capitato che un’azienda freghi l’idea all’aspirante game designer (cioè scartando il candidato ma riprendendo l’idea per conto proprio?). In che misura può esistere questo rischio?
Da noi no, perchè facciamo solo giochi di corsa 😀 Purtroppo non ho idea di altri casi. Nella musica ho sentito spesso di “idee rubate”, ma nel game design non troppo.
Però non escludo il rischio, in particolare se si punta ad entrare in software house che fanno giochi originali, con IP proprietarie o basati su tecnologie nuove.
In quei casi secondo me l’attenzione non è mai troppo: io gli manderei un design di uno “Zuma” con qualche bonus nuovo, ad esempio. Al massimo ti fregheranno l’idea del bonus.
Una cosa sembra certa, diventare game-designer (o almeno mettere piede dall’altra parte della barricata) non sembra essere così semplice come alcuni potrebbero pensare…
Io una cosa che ho capito del game designer, giocando, studiando o guardando più o meno commenti, documenti di design o altro che ci giri attorno è che il GD è una persona che può arrivare dal contesto più disparato e aver studiato chissà che cosa. Da quel che ho visto, nei giochi che reputo capolavori, il GD mette ogni sua esperienza di vita nella creazione di idee da usare nello sviluppo del videogioco.
Insomma da un certo punto di vista può richiedere le stesse caratteristiche di un buono scrittore.
Questo è vero per i videogiochi con una forte componente artistica o innovativa. Per tutti gli altri tipi di gioco potrebbe essere necessario invece un design che ricorda di più una fredda analisi.
Molto spesso sarà questo che viene chiesto ad un designer: diagrammi di flusso dei menù e degli stati di gioco.