Il lavoro più agognato

Game designer

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!

Flipside of the Divine

Sviluppato da The Flipotechs | Piattaforma PC | Rilasciato nel 2008

Flipside of the Divine è un platform/puzzle game che si svolge nel regno dei cieli.

Lo scopo di ogni livello è quello di guidare un eroe non ben identificato per fargli raggiungere un portale, superando una serie di ostacoli sfruttando i poteri di un’aquila che fa ruotare alcune piattaforme e ne distrugge altre.

Questo è quanto. Flipside è intrigante, intricato, appassionante, vario, cervellotico, a tratti frustrante, ma sempre capace di proporre qualche novità in ogni livello tenendo desto l’interesse.

I primissimi schemi sono meramente dimostrativi e servono per apprendere le basi del gioco e i diversi modi per risolvere gli enigmi, ma le cose si fanno serie dal quarto in poi in cui bisognerà iniziare ad usare il cervello.

Quello che colpisce fin da subito è la sospensione dello scenario in un mondo etereo dai confini invisibili o incerti. Gli elementi decorativi sono pochissimi ma sono usati con gusto e rendono il minimalismo visivo che caratterizza i livelli insolitamente affascinante, nonostante la banalità di fondo del tema visivo scelto per l’ambientazione.

Probabilmente è l’accostamento fra la geometrica razionalità delle mattonelle con l’aleatorietà dei fondali a creare quell’armonia/disarmonia visiva che caratterizza tutti i livelli, regalando un sublime senso di indefinitezza al giocatore impegnato a risolvere i diversi livelli e regalando a Flipside uno stile visivo peculiare che sembra ripescare alcune suggestioni presenti nei vecchi titoli a 8/16 bit spesso caratterizzati dall’essere ambientati in un non-spazio più che in un ambiente definito.

Per il resto non vi resta che scaricarlo (è freeware) e provarlo da voi.

flipside-2008-02-29-13-29-43-62.jpg

flipside-2008-02-29-13-30-50-96.jpg

flipside-2008-03-13-16-10-22-61.jpg

flipside-2008-03-13-16-15-54-58.jpg

flipside-2008-03-13-16-16-33-72.jpg

flipside-2008-03-13-16-23-08-68.jpg

flipside-2008-03-13-16-24-27-91.jpg

FLIPSIDE OF THE DIVINE

Nextgame e l’assenza di voto: Alberto Belli ci spiega perché

Alberto BelliDopo esserci resi conto con un bel po’ di ritardo che Nextgame, uno dei siti nazionali più importanti dedicati al videogioco, ha eliminato i voti dalle recensioni, abbiamo pensato di chiedere il motivo di questa scelta senza precedenti nella stampa di settore.

Alberto “Eldacar” Belli è giornalista, Amministratore Delegato di Pulsar Communication e responsabile delle comunicazioni del Gruppo Leader, oltre che publishing director di Videogame Edizioni quindi responsabile del magazine Nextgame (più una marea di altre figure professionali che vi lascio scoprire sul suo blog senza peli sulla lingua intitolato EldaStyle 2.0).

read more

Introduzione ai MMOG: ruoli e personaggi

L’idea di questa serie di articoli di introduzione ai MMOG è quella di spiegare le basi di design del genere ai moltissimi neofiti che magari ne sono stati incuriositi ma che non hanno mai potuto o voluto approfondire in prima persona l’esperienza su questa tipologia di giochi online, apparentemente simile ma in realtà radicalmente diversa dagli RPG single player.

paragonsIn questa prima puntata parleremo della creazione del personaggio, uno dei limiti di design più grandi dei MMOG. La creazione di un personaggio, infatti, è spesso una scelta non banale e presuppone la conoscenza di almeno i rudimenti del gioco. Per un neofita essere subito messo di fronte a scelte decisive e per nulla intuitive può rivelarsi una esperienza intimidatoria o penalizzante sul lungo o medio termine (perché ad esempio sceglie un’archetipo sbagliato per la sua idea di gioco divertente), lasciandolo a volte con una idea del gioco del tutto negativa e con la convinzione (a volte molto sbagliata) che quella esperienza di gioco sia comune a qualsiasi altra scelta lui abbia fatto.

In questa fase si può notare la drammatica differenza tra i MMOG ed un semplice RPG per computer: spesso leggere il manuale non basta ed è difficile generalizzare un giudizio osservando il gameplay solo da uno dei molteplici punti di vista possibili. I MMOG hanno ambientazioni molto complesse, dinamiche sociali e politiche intricate e che spesso si ripercuotono direttamente sulle scelte del giocatore. A tutto questo si somma il lore, ovvero quell’insieme di conoscenze, tradizioni o consuetudini che i designer e le comunità dei giocatori hanno contribuito a creare nel server in cui giocherete. Nel lore rientrano moltissimi elementi di gioco come ad esempio il ruolo che gli archetipi copriranno, le storyline principali (che spesso culmineranno in imprese leggendarie compiute in prima persona dai giocatori) ma anche i codici di comportamento da utilizzare durante il gioco in gruppo, i percorsi di sviluppo considerati di riferimento per i giocatori, le faide tra gruppi di giocatori rivali e tanto altro. In un tessuto così complesso, che entra ed esce dal gioco per passare attraverso l’elemento umano con disinvoltura, quando si sceglie un personaggio, in realtà si sta facendo molto di più che scegliere l’avatar che sembra più figo: si sta abbracciando un universo culturale.

Ho parlato di limite perché creare un nuovo personaggio in un gioco online (o rollare un nuovo personaggio, italianizzando il verbo to roll, in ricordo degli RPG da tavolo dove si usavano dei dadi per determinare gli attributi), presuppone l’avere già un’idea ben precisa della collocazione del PG (Personaggio Giocante) nelle dinamiche di gruppo (altrimenti detto party, dalla nomenclatura tradizionale di Dungeons and Dragons) ed in quelle socio/economiche del gioco. Questo tipo di meta-gaming è distintivo dei MMOG: una volta chiuso il client si può continuare a giocare documentandosi, interagendo sui forum, scambiando esperienze o indizi per tesori particolarmente ghiotti con gli altri giocatori. In questo modo la controparte umana dietro il personaggio non si limita semplicemente a controllare ludicamente l’avatar ma trasferisce anche parte delle proprie capacità cognitive su di esso.

Quasi tutti i MMOG utilizzano un sistema di creazione del personaggio basato sulla scelta di una razza, di una classe (il ruolo che il personaggio ricoprirà nel gioco), di alcune skill (le abilità che definiscono le capacità del personaggio) e, in alcuni casi, di una professione (in inglese tradeskill, ovvero una professione artigianale che aiuta il personaggio nel procurarsi equipaggiamento e soldi, commerciando materiali utili a sé e agli altri). Ovviamente questa distinzione è del tutto macroscopica ed ogni gioco implementa queste meccaniche in maniera differente (a volte chiamandole anche con nomi diversi) ma i concetti di base rimangono sempre questi. Anche giochi che apparentemente non contengono il concetto di classe, come Ultima Online o EVE Online, hanno comunque dei sistemi che limitano i giocatori dal ricoprire qualsiasi ruolo con la massima efficienza, ricreando quindi, anche se in maniera più implicita e fluida, un sistema basato sui ruoli. In questi giochi la creazione di un personaggio è tutt’altro che banale e presuppone una buona conoscenza dei meccanismi e del design, per evitare di creare personaggi che inizialmente partano con svantaggi eccessivi rispetto a configurazioni (o build) molto più ottimizzate e competitive.

ritualistsAl giorno d’oggi, scegliere una razza ha un valore principalmente estetico e narrativo. La razza influenza solo marginalmente le statistiche di base e, solitamente, preclude la scelta di alcune professioni o classi. In moltissimi giochi, inoltre, la razza è associata ad una determinata fazione, che avrà alleati e nemici, limitando l’accesso ad un sottoinsieme di contenuti a cui il giocatore potrà accedere. Razze diverse hanno solitamente storyline diverse (se il gioco prevede una struttura narrativa), ambientazioni diverse e, a volte, anche un’apparenza radicalmente differente non solo per il personaggio ma anche per l’equipaggiamento, le tecnologie e i manufatti che esso utilizza. EverQuest ed EverQuest 2 sono due giochi molto famosi per i loro intricatissimi sistemi di fazioni e razze che permettono una discreta varietà e profondita nella fruizione del lore del gioco. In World of Warcraft o Dark Age of Camelot, invece, la scelta di una razza è principalmente una scelta strumentale per giustificare lo scontro competitivo tra gruppi avversi di fazioni (detti anche reami) comprendenti sia giocatori che NPC (Non-Player Characters).

Tornando al tradizionale sistema a classi, i ruoli che di solito sono identificabili nella quasi totalità dei giochi online sono essenzialmente tre: il tank, l’healer ed il nuker. Questi archetipi, non esenti da commistioni e contaminazioni reciproche, affondano nella tradizione dei giochi di ruolo da tavolo e suddividono idealmente i tre aspetti principali del giocare in gruppo: difendere, supportare ed attaccare. Nessuno dei ruoli che potrete scegliere sarà autosufficiente in tutto e per tutto.

Originariamente (come nei MUD, in Ultima Online o in EverQuest), la creazione del personaggio, come negli omologhi RPG da tavolo, presupponeva l’allocazione di punti in alcune statistiche che descrivessero le proprie capacità fisiche e mentali. Negli ultimi anni è stata fatta una scelta di accessibilità (secondo me molto sensata) che ha prediletto una allocazione automatica delle statistiche di partenza sulla base della razza e della classe scelta. Su questa prima allocazione di punti, che evolverà durante l’evoluzione del personaggio in maniera automatica (sempre per evitare sbilanciamenti o scelte errate), il giocatore potrà intervenire solo in maniera indiretta, tramite l’utilizzo dei bonus derivanti dagli oggeti equipaggiabili, l’acquisto di nuove skill o l’allocazione di punti per migliorare l’efficacia delle stesse. Questo sistema limita la frustrazione che si prova nell’investire ore di gioco su una build per poi scoprire che è irrimediabilmente sbagliata (chi abbia mai giocato a Dofus sa cosa vuol dire) ma lascia comunque spazio ad una personalizzazione reversibile (non senza penalità) con una complessità che cresce gradualmente di pari passo con la familiarità con il gioco che viene accumulata dalla controparte umana.

Detto questo, vediamo le tre categorie di archetipi in dettaglio, aiutati dalle schermate che Lord Of The Rings Online propone ai giocatori durante la fase di creazione dei personaggi. Per realizzate le schermate ho scelto la razza umana, quella che ha il più ampio ventaglio di scelte possibili per quanto riguarda gli archetipi (questo pattern di design è comune in quasi tutti i MMOG: gli umani non hanno particolari vantaggi razziali ma possono ricoprire un numero maggiore di classi rispetto alle altre classi, di solito più specializzate).

ScreenShot00001

Nella categoria dei tank, rientrano tutti quei personaggi in grado di fornire uno scudo umano al resto del gruppo di gioco: un tank è in grado di attirare l’attenzione dei nemici (in gergo si dice fare aggro management, gestire l’aggressività dei nemici), dirottandola dai componenti più deboli e meno protetti del party (gli squishies, i mollicci, perché possono portare al massimo armature leggere e sono molto vulnerabili) ed è di solito la classe più dipendente da un buon equipaggiamento: ha bisogno di armature robuste, buone armi e di moltissimi bonus alle sue statistiche vitali, come ad esempio i punti ferita o le resistenze a danni specifici. Uno sbaglio classico dei neofiti dei MMOG è scegliere un personaggio tank come il classico guerriero credendo che si ricoprirà il ruolo dello sterminatore inarrestabile: per esigenze di bilanciamento, di solito una classe tank non infligge molti danni (altrimenti sarebbe invincibile!) e può diventare un ruolo frustrante per i personaggi che amano l’azione veloce.

ScreenShot00004

Nella categoria degli healer rientrano tutti quei personaggi che forniscono supporto al gruppo, non solo dal punto di vista curativo come il nome farebbe credere. Molti giochi, infatti, hanno esteso il ruolo dell’healer a classi che forniscono esclusivamente protezioni o bonus alle caratteristiche dei personaggi (in gergo buff, “aiutini”). Il ruolo dell’healer in un gruppo è vitale e richiede moltissimo sacrificio: l’azione di gioco non è la più varia (di solito si deve “semplicemente” stare nelle retrovie e supportare i tank con cure e buff mentre tengono a bada i nemici), giocare in solitario è quasi impossibile, ma il tutto viene controbilanciato dall’importanza del ruolo, che garantisce una estrema facilità nel trovare gruppo. Solitamente un healer ha la possibilità di indossare armature di media robustezza in quanto è di solito il bersaglio preferenziale dei nemici e deve comunque rimanere in prossimità della prima linea di battaglia. Non troppo raramente i migliori giocatori in gruppo si scoprono proprio tra gli healer: una discreta propensione a socializzare e a cooperare sacrificandosi per il gruppo sono indispensabili per portare avanti con successo questo archetipo e l’impiego abbastanza passivo permette di avere tempo per pianificare strategie, tenere d’occhio la zona e consigliare una linea d’azione ai propri colleghi impegnati battaglia.

ScreenShot00002

Nella categoria dei nuker, invece, rientrano tutti i personaggi che infliggono moltissimi danni su un bersagli singoli o che riescono ad agire su più bersagli alla volta (ovvero ad area of effect, area d’effetto, altrimenti detta AOE). Un nuker solitamente fa della velocità la sua difesa e si focalizza sull’efficacia di uccidere un nemico in un tempo molto breve, minimizzando i danni ricevuti. Sempre per bilanciare le dinamiche di gioco, un nuker è quasi del tutto indifeso agli attacchi altrui e necessita della protezione di almeno un tank per le battaglie più dure. In un gruppo i nuker sono l’unica classe che infligge danni degni di nota e sono un elemento fondamentale per il bilanciamento offensivo del party. Sono una delle clasi con il più alto livello di diffcoltà quando giocate in gruppo: è richiesta una buona conoscenza delle reazioni dei nemici e delle proprie abilità per evitare di “rubare l’aggro ai tank”, evento che di solito si risolve in una disastrosa morte per il nuker ed in una diminuizione del potenziale offensivo del party (che in alcuni casi potrebbe determinare una ritirata o una disfatta). I nuker possono essere anche ottime classi per chi ama giocare per lo più in autonomia ma anche qui è necessario ricercare bene: alcune classi sono in grado di sopravvivere da sole, altre sono del tutto dipendenti da una classe di supporto.

mesmers Da quando esiste EverQuest, la “sacra trinità” di D&Diana memoria ha subito molte contaminazioni ed innovazioni. Il ruolo di nuker ed healer sono stati sicuramente quelli più ritoccati: esistono varianti che operano ad ad area, altre che si focalizzano sui bersagli singoli, altri che in realtà non fanno danni diretti ma limitano le azioni dei nemici stordendoli oppure scagliandoli l’uno contro l’altro (i cosidetti crowd controller, gestori delle masse, o mezzer, da mesmerizer). Il ruolo del tank, invece, è rimasto più o meno inalterato in qualsiasi gioco, con una recente propensione a creare il ruolo del tank DPS (da Damage Per Second, l’unità con cui solitamente si misurano i danni), un quasi-nuker in grado di gestire l’aggro ma che necessita quasi sempre di supporto continuo per rimanere in piedi se lo scontro è prolungato.

LOTRO ha tre classi che mappano direttamente i tre archietipi principali, il Guardian, il Ministrel e l’Hunter più altri archetipi che si collocano a metà strada come il Captain (un tank/buffer), il Burglar (un nuker/stealth), il Champion (un tank/nuker) ed il Lore-Master (che fa un po’ di tutto tranne il tank).

Quello che non bisogna mai dimenticare quando si sceglie una classe in un MMOG è che non esistono classi del tutto vincenti ma neanche sistemi di gioco completamente bilanciati. Ogni MMOG presuppone che molti dei suoi contenuti siano fruibili solo giocando in gruppo e quindi introduce dei limiti (a volte anche un po’ artefatti) per evitare che gli archetipi si rubino il ruolo a vicenda. Questi limiti, ovviamente, inficiano su ciò che un giocatore può fare giocando solo o con un gruppo ristretto o molto diverso da quello considerato di riferimento dai quest designer. Nonostante ciò, per limitare i tempi d’attesa ed impedire di frustrare i giocatori nel caso non si trovino subito dei partner, quasi tutti i giochi moderni permettono a quasi tutte le classi un minimo d’autonomia, introducendo qualche abilità in grado di supplire in maniera limitata ed inefficiente alle attività tipiche degli altri ruoli. Un buon esempio sono le tradeskill First Aid e Cooking di WOW che permettono a tutte le classi di curare i propri punti ferita, limitando il downtime dovuto all’aspettare il recupero naturale delle proprie forze, nel caso non ci sia un healer nei paraggi.

E’ importante ribadire quanto sia vitale documentarsi bene prima di scegliere la propria classe in un MMOG. La scelta migliore è iniziare sin da subito a raccogliere informazioni sulle razze e le classi presenti nel gioco, i relativi stili di gameplay e anche le ambientazioni in cui si andranno a collocare (ad esempio, se non vi piaccono decine di chilometri quadri di lande desertificate e sterili, evitate di scegliere l’Orda come fazione in WOW), aiutandovi tramite i forum ufficiali e gli immancabili wiki gestiti dalle comunità di gaming. Senza arrivare all’utilizzo degli spoiler, molti di questi siti hanno informazioni e guide strategiche a volte vitali per capire la chiave di lettura del vostro personaggio e, cosa molto più importante, quello che gli altri giocatori umani si aspettaranno da voi se impersonerete quella classe!

La Lingua del Ludo

Talune volte frequento il newsgroup it.comp.giochi.sviluppo e spesso leggo l’annosa domanda: “Che linguaggio si usa per fare videogiochi?”

Un tempo la risposta sarebbe stata semplice: “Il C++, mio buon amico”. Anni ancora prima, la riposta sarebbe stata ancora più sgraziata “Il C, per l’amore diddio”.

Se andiamo ancora nel passato, allora sarebbe stata “L’assembly, you fuckin’ noob”.

E oggi? Finalmente possiamo dire “dipende”. Aaah la libertà! Tanto bella quanto pericolosa.

E da cosa dipende? Dipende da cosa dobbiamo fare. Non parlo della “complessità”, ma della “mansione”.

Dobbiamo fare Tool, l’Engine o il Gioco?

Nei tre casi le nostre competenze richieste saranno diverse. Se facciamo l’Engine, ad esempio, non si può scappare: tutti gli SDK di tutte le console sono in C o C++.

Ma se facciamo il gioco? Beh, in quel caso, immaginiamo di utilizzare “Virtools”: questo strumento si programma con degli script.

Oppure, ancora, Macromedia Director o il sistema “Vicious Engine“: tutti questi sistemi si programmano con degli script.

Oppure supponiamo che l’engine sia stato fatto in modo che tutte le chiamate si possa usare, chessò, in Phyton: così facendo il programmatore del gioco deve conoscere Phyton e non il C++.

Se devo fare i Tools, ho varie scelte: potrei dover conoscere il linguaggio che usa l’engine (il C++, o il binding il Phyton), oppure, se devo fare roba per 3d Studio Max, dovrei conoscere MaxScript.

Ed ecco fatto! Abbiamo un bel po’ di figure professionali che non devono sapere il C++, ma lavorano nei videogiochi.

Se poi aggiungiamo che magari le pagine di menù vengono fatte in Flash, opplà! Abbiamo miliardi di papabili Falshisti che potremmo usare per programmare le nostre pagine.

Porto qualche esempio, in modo da capirci: Valve software ha l’engine in C++, ma i tools in C#. In questo modo ha i tools fatti in un linguaggio che toglie moltissimi problemi di gestione della memoria, è molto produttivo e consente di fare interfacce grafiche in pochissimo tempo.

Battlefield è fatto in larga parte in Phyton, mentre l’AI e tutti gli eventi scriptati di Crysis e Far Cry sono fatti in LUA, un altro linguaggio di scripting molto in voga.

Tutte le avventure grafiche Lucas sono state fatte con lo storico SCUMM, un sistema a script.

Dopo tutto questo discorso, capiamo che, ad oggi, la risposta “Il C++ o Morte!” E’ obsoleta. Obsoletissima!

E l’ottimizzazione storica che fa il C++? Eeeh, ci ricolleghiamo al precedente articolo, ma temo che ci sarà ancora da parlare parecchio su questo argomento.

Demenziale, delirante, giapponese: Gekibo/Gekisha Boy

Prodotto da Irem | Sviluppato da Tomcat System | Piattaforma PC Engine | Rilasciato nel 1992

David Goldman è il nome del bamboccione col sorriso idiota stampato sulla faccia (invariabilmente allargato per mostrare bene tutti e cinquantadue i dentini a disposizione) chiamato ad attraversare orizzontalmente città, mari e monti per superare gli ardui test imposti dall’LA Photography School. L’anziano e scorbutico selezionatore tenuto a valutare i suoi sforzi appare solo durante le brevi e drammatiche fasi d’intermezzo, emanando severità.

Gekisha Boy, conosciuto come Photo Boy, è stato uno dei giochi Irem di maggior successo, ma pare non abbia mai abbandonato (almeno ufficialmente) il suolo natio, benché sia ora possibile trovarne in giro un hack con le frasi giapponesi tradotte in un ben più accessibile inglese, e giocarselo in santa pace tramite l’apposito emulatore, illecitamente. Si tratta di una sorta di Operation Wolf pacifista con la macchina fotografica al posto di fucili e bombe a mano, di una specie di precursore spiritual-anale di titoli quali Beyond Good & Evil e Pokèmon Snap.

Photo Boy

Non è difficile capire perché non sia stato ritenuto idoneo per l’avventura oltreoceano. Gekisha Boy trasuda giapponesità e demenzialità da tutti i pori, e prende gioiosamente per il culo l’America e l’insano stile di vita dei suoi abitanti, la sua cultura pop anni 80 e la sua moralità, i suoi divi e i suoi (super)eroi. Ma anche i suoi comuni e indaffaratissimi cittadini, che qui deambulano per le strade goffi, fessi e stereotipati.

Le musichette sono sgraziate, a tratti quasi cacofoniche e sembrano non adattarsi per nulla a quello che succede sullo schermo, i passanti hanno la preoccupante tendenza a denudarsi improvvisamente in preda a strane urgenze e il nostro eroe non perde occasione per immortalare i loro gingilli. David fotografa palle lampeggianti e altri oggetti imprecisati, poco plausibili e di dubbia provenienza; mentre gli aerei precipitano insistentemente nei giardini (non a caso i genitori del nostro eroe sono periti proprio a causa di un incidente di volo) e mostri ben poco depilati fanno scempio di città e monumenti nell’indifferenza di viandanti, vigili urbani e alieni di passaggio.

Non c’è quasi nulla di normale in Gekisha Boy, ed è proprio questo che lo rende così speciale.
Una boccata d’aria fresca in un mare di titoli seriosi e tutti uguali. Un titolo imperdibile, irresistibile.




NB Gekisha Boy ha avuto un seguito per PlayStation 2 nel 2001 intitolato semplicemente Gekisha Boy 2 (ed è conosciuto anche come Gekibo 2 e Polaroid Pete, ma l’uscita della versione europea a opera della JVC dovrebbe essere saltata all’ultimo momento). Sequel che, nonostante il passaggio a uno stile grafico alla PaRappa, ha mantenuto intatto l’umorismo e lo spirito della versione originale, aggiungendo nuove peculiarità al gameplay. Il titolo per PC Engine è stato invece ripubblicato per PlayStation con un livello extra e il nome di The Cameraman nel 2002 nell’ambito della collana Simple 1500 Series.