Appunti e memorie di Ivan Venturi

Fare Videogiochi

 

Quando iniziai a fare videogiochi più di vent’anni fa, era (abbastanza) facile tenere sotto controllo la produzione del videogioco, cioè il tempo che ci si sarebbe speso a realizzarlo, le risorse da investire (per esempio in musica o grafica). Poi si sarebbe andati in duplicazione, e anche lì le cose, nonostante mancasse internet e l’email, erano (abbastanza) semplici.

Ora la cosa è un tantino più intricata. Prevedere il costo complessivo di un progetto è decisamente un’operazione più complessa. Prevedere tale costo quando ancora il progetto non è definito, lo è ancora di più.
Quando poi capita di dover definire, in pochi giorni, il costo complessivo di un videogioco zeppo di particolarità e di aspetti non completamente definiti (per esempio il tema del videogioco stesso) diventa proprio complicato. Specialmente quando tutte le cifre e le indicazioni che si daranno potranno poi diventare i parametri entro cui dover muoversi nel caso il progetto ‘passi’.
Nello specifico, mi capita abbastanza spesso ultimamente di dover definire in pochi giorni i costi di un progetto complesso, e di idearne le linee generali, perchè un cliente (o azienda a noi in qualche modo associata) sta presentando un progetto europeo, o a una fondazione, o ad altri soggetti che indicono bandi per la realizzazione di materiali di questo tipo.
Ne ho affrontate così tante ormai di situazioni del genere da aver sviluppato una sorta di metodo per non diventare matto e riuscire a definire tutto quello che è necessario alla presentazione del progetto, in tempi abbastanza rapidi.
Prima di tutto, se della cosa che mi richiedono non so davvero un tubo, lo dico chiaramente ed evito di accollarmi tale impegno. In caso il progetto richiestomi rientri nell’ambito dei temi di mio interesse, che sono quelli sociali e della cittadinanza, oppure relativi a un vecchio bastardo di inquisitore medievale, invece il modo lo trovo sempre. Per i temi di cui sopra, so bene il come cosa dove quando questo progetto verrebbe utilizzato, e quindi anche le cose davvero necessarie per la riuscita dello stesso. Per esempio, non è detto che al cliente finale di quel tipo di cosa (magari un insegnante che dovrà farlo usare agli studenti) interessi la tale caratteristica videoludica o tecnica. Magari non gliene frega proprio nulla, ciò che davvero gli interessa è qualcosa che non ha a che fare con l’ambito videoludico (per esempio la piena configurabilità, e il fatto che possa avere durate variabili, o una curva d’apprendimento ridotta all’osso).
Poi cerco di capire bene la struttura dell’intero finanziamento. Cioè: in casi come questi, il videogioco è spesso solo una parte di un progetto più ampio, che coinvolge tante persone, magari in più paesi se il progetto è europeo, e quindi la maggior parte degli investimenti se ne va in viaggi, formazioni, disseminazioni, ecc. Quindi mi studio TUTTO il progetto, non solo la parte che riguarda il videogioco, in modo da sapere quello che davvero conta e quello che invece è di importanza secondaria.
Poi vanno individuati i centri di costo principali, cioè i costi vivi, non modificabili, del progetto. Se un progetto comprende voci di personaggi di qualità, bisogna comprendere i doppiaggi (realizzati da una società esterna di professionisti). Se il videogioco è un browser game bisogna comprendere i costi di banda, dei server e delle persone fisse sulla manutenzione del sistema. Insomma i costi delle ‘forniture esterne’, cioè di quelle fasi di produzione non gestibili internamente o con i ‘soliti’ collaboratori.
Questo è importante, perchè in un progetto, per esempio, accorgersi che ci sono dei costi fissi, quindi tot al mese, per tutta la durata del progetto, quando invece non li si erano previsti (oppure previsti ma in maniera insufficiente), diventa una catastrofe in caso il progetto ‘passi’.
Successivamente, mi documento quanto posso su tutti quegli aspetti ‘tecnico-amministrativi’, cioè come funziona e quanto costa, dei principali centri di costo di cui sopra. Aumento di un pezzettino ogni volta il mio know-how specifico di quel tipo di cosa. E mi faccio un’idea, spannometrica, di quanto può valere ogni centro di costo, da un minimo a un massimo.
Dall’altra parte, mi faccio un’idea di quello che è il massimo budget sostenibile per l’intero progetto, cioè quanto può costare l’intero videogioco in proporzione anche a quello che sarà il finanziamento complessivo. Nonchè qual è il budget minimo, sotto il quale il progetto diventa troppo piccolo, troppo poco interessante.
E così sono arrivato a due estremi, ancora approssimativi: da una parte l’entità dei centri di costo, cioè i costi vivi di sviluppo (ancora comunque indefiniti in quanto non è definito il progetto e le relative quantità di materiali), dall’altra il budget massimale.
Ecco: per approssimazioni successive, bisogna fare poi in modo di avvicinare sempre più questi due estremi. Da questa operazione risulterà, per esempio, che si può spendere 20000 euro per la grafica, 10000 per audio e doppiaggi, 5000 andranno riservati alle traduzioni, 30000 alla programmazione, eccetera, e che un 20% (o 30%, meglio) sarà il ricarico. Ricarico nel quale poi bisogna tenere conto degli imprevisti. Passo dopo passo, togliendo mille di qua e aggiungendole là, si arriva alle cifre definitive e si definisce il corpo e il sangue del videogioco.
Una volta definite queste cifre, cioè il bilancio del videogioco, allora finamente comincio ad avere un’idea più concreta di come esso sarà, e sarò in grado di darne una descrizione, che non si discosterà molto poi dalla realtà. Idem sarò in grado di definire le persone (o strutture) necessarie, i tempi e le fasi di produzione.
Fatto tutto questo, normalmente poi fornisco anche varie indicazioni utili per l’intero progetto, ovvero come poi usarlo, questo videogioco, come farlo arrivare agli utenti previsti, eccetera.
Ed ecco qui pronti tutti gli elementi necessari per il business plan del videogioco da fornire al cliente.
La cosa complicata, come sta accadendo per esempio in questi giorni, è che a volte il cliente (o partner) impara del bando europeo il 20 del mese, scoprendo che entro il 30 deve presentarlo, e mi chiede di progettare tutto quanto sopra in 2-3 giorni al massimo (nei quali, tra l’altro, magari ho pure altro da fare). Possibilmente senza sbagliare, dato che poi le cifre che vado a definire saranno quelle che poi dovrò rispettare se il progetto ‘passerà‘, cioè verrà accolto.

Poi, se il progetto viene accolto, si tratta ‘solo’ di realizzare il videogioco. Che però è la parte più bella!

Saludos!

Bookmark and Share

Scritto daadmin il 12/05/2009 in 1993, arcade, edicola, editor, metodo, moduli, ritagliatore con Nessun commento


Sempre in quel periodo (videogiochi da edicola), ci prese una vera e propria mania da burocrazia interna.
Inizialmente, mi sembra che Francesco avesse inserito in alcune procedure interne l’utilizzo di moduli.
In produzione iniziammo ad adottarli di buon grado, poi sempre di più, con selvaggia soddisfazione!
Avevamo un modulo (cartaceo) per tutto, in perfetto stile catena-di-montaggio qual era il ciclo di produzione del periodo: per la definizione della grafica degli arcade, per la logica, per le scene interattive, per i dialoghi eccetera.
Il bello era che funzionava benissimo! E che ogni volta che qualcuno aveva una miglioria da fare al ciclo di produzione, oppure c’era un upgrade software che consentiva di fare una certa cosa in più, bastava aggiornare il modulo, aggiungere una casellina da barrare, fotocopiarlo in 10-20 copie, e il gioco era fatto.
Avevamo, nello stanzone grande della produzione (nella sede grande di viale Berti Pichat), una scaffalatura tuuuuutta dedicata ai moduli. Lì c’erano i moduli pronti, già fotocopiati, per essere usati.
Tali moduli venivano compilati a biro (non c’era la rete LAN ancora…) e quindi la carta (e le fotocopie) erano comodissimi, anche perchè ogni modulo compilato poi finiva nel raccoglitore del singolo progetto, fino a formarne lo storyboard, che aveva nelle prime pagine i brevi appunti di Carlà sulla puntata, poi un mio soggetto ‘esploso’ con il (brevissimo) designe di produzione, chi faceva cosa ecc, e poi moduli e moduli e moduli e moduli. E ancora moduli. Fino alla definizione dell’ultima variabile.
Poi avevamo gli editor, che utilizzavamo (tramite operatori) per inserire i dati scritti nei moduli dentro il gioco vero e proprio. L’Editor Arcade per le sezioni arcade, e il “PLAYER” (realizzato da Marco Gregori e Stefano Dal Fiume) per quelle avventura. Avevamo nel tempo sviluppato uno script player, a misura di quelle avventure, che ci consentiva di produrre qualsiasi tipo di scena interattiva o dialogo in tempi brevi.
Ah, dimenticavo il ‘ritagliatore’. Altro oggetto senza il quale ci saremmo amputati le mani. Il ‘ritagliatore’ era il programma, sviluppato da Cristiano Montanari e Massimo Baraldi, che serviva a trasformare i vari files di grafica, così come uscivano dal Deluxe Paint, in frames di grafica ‘pappabile’ dal ns sistema. nonchè a provare le animazioni, rinominare e copiare i files eccetera. Anche sul “player” e sul “ritagliatore”, lavorare era una particolare delizia. Le riunioni con i programmatori in cui definivamo le nuove funzioni, che da lì a poco ci avrebbero enormemente migliorato la vita in produzione, erano il massimo del gusto, un po’ come decidere tutti i dettagli per la propria cucina, sapendo che ogni cosa ben pensata si sarebbe positivamente ripercossa nella vita di tutti i giorni.
…Che goduria gli editor e le utility!

Ogni modulo mi sembra avesse la bella firmetta di chi l’aveva compilato. Era sempre fondamentale inquadrare chi era il responsabile di cosa.
I vari progetti DD seguivano il loro iter inarrestabile e diventavano master.
Tali storyboard ‘a moduli’ erano comodissimi per il debug. Quando c’era un problema di strani comportamenti logici (il software ormai era piuttosto stabile, non riservava praticamente mai brutte sorprese), bastava armarsi di santa pazienza, prendere lo storyboard e spulciarselo, trovando la variabile definita male o il passaggio sbagliato nella logica degli script.
Il metodo ‘moduli’ ci diede grosse soddisfazioni, perchè ci consentiva di tenere sotto controllo un ritmo forsennato di lavoro, incasellando al massimo ogni cosa e pilotando ogni processo.
Anche per questo, gli adventure-arcade da edicola, sono diventati poi tutti uguali!

Saludos!

Bookmark and Share

Scritto daadmin il 25/02/2009 in 1988, maturità, metodo, rimbalzi, simulgolf con Nessun commento


Dopo Bocce, poi trasformato in Bowls, Carlà mi indicò il nostro progetto comune: Simulgolf. Ancora una simulazione sportiva, di uno sport minore ancora mai simulato. Certamente uno sport non di massa, del quale io stesso conoscevo a malapena l’esistenza.

Lavorai a Simulgolf durante il mio quarto anno di liceo: ero quasi maggiorenne, avevo ormai qualche anno di esperienza e il mondo aveva incominciato a interessarmi molto più di prima, la mia classe IVB, amiche e amici, esperienze di tipo nuovo e fantastico, obiettivamente ben superiori a quelle che avrei mai potuto provare realizzando i miei giochi. Insomma, la primordiale sete di creazione digitale si era un po’ placata mentre quella della vita si faceva sempre più importante. Fu per questo che trascinai la creazione di Simulgolf fino oltre l’esame di maturità.

Lavoravo ormai in modo diverso rispetto ai primi progetti. Ora veniva naturale dividere il progetto in fasi, che andavano affrontate una dopo l’altra. Un primo embrione di analisi, mista a bozzetti di layout, di mappe e della successiva realizzazione grafica, prese forma e iniziai ad abituarmi a una metodologia di lavoro.
Francesco Carlà, che vedevo ogni due tre mesi, mi forniva consigli preziosi dall’alto della sua esperienza videoludica e produttiva. Io ero abituato a fare prima possibile, Francesco mi inculcò (da lì agli anni successivi) il metodo.
Uno dopo l’altro, progettavo le 18 buche del minigolf digitale, l’effetto della palla che scompare nell’ombra della buca, la grafica metallica e giocattolosa della quale ero decisamente fiero, il sistema di puntamento col quale si colpiva la pallina, gli effetti speciali collegati alle varie costruzioni di queste piste simili a micro-luna park.
Ebbi alcune difficoltà coi rimbalzi, che avevo già affrontato faticosamente ai tempi di bocce: dovetti studiarmi la trigonometria un paio d’anni prima del programma scolastico per capire dove diavolo dovevano andare a finire quelle bocce. Escogitai alcuni algoritmi abbastanza empirici, che sicuramente avrebbero fatto rivoltare Gauss nella tomba, ma funzionavano, e questo bastava. Mi diede una mano anche un amico di Carlà.
Certe cose è meglio studiarle che arrivarci empiricamente. RICORDATELO TUTTI VOI PROGRAMMATORI SMANETTONI.

In Simulgolf c’erano le diverse irregolarità delle piste, angoli strani, curve lungo le quali la pallina doveva poter scorrere, scivoli, salite, tunnel: mi inventai una sorta di mappatura dei rimbalzi relativa a ogni pixel del bordo pista. Praticamente calcolavo a ogni ciclo di gioco se la pallina era in una certa posizione e che direzione aveva. In base alla posizione andavo a pescare un valore direzionale, che incrociato con quello della direzione della pallina determinava in che direzione sarebbe dovuta rimbalzare la pallina. Fu abbastanza macchinoso definire tutti i punti traiettoria possibili, ma alla fine il risultato fu piuttosto buono, dato che la struttura dei rimbalzi era verosimile ma conteneva vari elementi di sorpresa ‘inseriti a mano’, insomma le leggi della fisica riscritte con un po’ di spezie aggiunte, per arricchire creativamente i rimbalzi, importantissimi nel gioco del minigolf.
Avvicinandomi all’esame di maturità, dedicai sempre meno tempo a Simulgolf, che praticamente abbandonai per qualche mese. Da quando avevo comprato il computer, non mi era mai successo di smettere di programmare per così tanto tempo. Era estate, avevo diciott’anni appena compiuti e avevo scoperto un’infinità di cose meravigliose da tentare e scoprire.
L’esame di maturità, grazie a una commissione esterna che falcidiò tutti a causa soprattutto di un insegnante di storia dell’arte obiettivamente disadattato, fu un’esperienza molto forte. Giornate bellissime, di legame strettissimo con amiche e amici, di impegno negli esami e relativo timore, di primo sole estivo, durante le quali riuscii a rovinare il mio esame orale perché ebbi una discussione in merito alle opinioni artistiche con il suddetto insegnante della commissione esterna, che col voto mi punì severamente. Mi resi conto in quei giorni di quanto ero impulsivo e di quanto sarebbe stato necessario ‘maturare’. In conclusione, mi affibbiò un bel ‘3’ che affondò la mia votazione finale (io che ero sempre stato uno di ‘quelli bravi’) che fu quindi di 39/60.
Quando lessi il voto non ci potevo credere.
Quattro anni di impegno, un esame condotto bene in tutte le materie tranne per gli aspetti diplomatici di una di esse, ed ecco il risultato, il tutto grazie a un’unica mattinata sotto le grinfie di un’insegnante astioso e di un ego (il mio) troppo ingenuo. Uno shock che i bagordi della festa successiva alla maturità mi fecero dimenticare solo in piccola parte. Maledetto pezzo di carta. Mi resi conto di punto in bianco che a) avevo appena concluso una scuola professionalmente inutile b) il ‘sistema’ ti poteva fregare in un lampo se non sottostavi alle sue condizioni, cosa della quale io non avevo la minima voglia c) era un sacco di tempo che non programmavo d) fare videogiochi sì che era un bel modo di vivere e) avevo l’occasione per crearmi il mio lavoro ideale f) non dovevo perdere tempo!

Dopo qualche giornata catatonica mi rimisi all’opera non più per portare avanti Simulgolf, ma per concluderlo, per mettere tutti i coperchi sulle varie pentole che avevo creato.

Era l’estate del 1988.

Bookmark and Share

Nel 1987 ho fatto il primo videogioco della Simulmondo, prima software house italiana. Da allora ne ho fatti altre migliaia.
Dalla fine del millennio scorso faccio videogiochi educativi ed ora anche simulatori di guida e avventure di inquisitori medievali.
Poi nel 2003 ho fondato Koala Games, ora diventatata TIconBLU. E mi occupo di un bel po' di altre cose videoludiche varie.
E...VIVA I VIDEOGIOCHI ITALIANI!