Se avete seguito le notizie delle ultime settimane sul mondo dei videogiochi, di sicuro avrete letto tra le più curiose quella dedicata al modo in cui è stato realizzato il treno in cui il giocatore viaggiava nel DLC Broken Steel di Fallout 3. Un vero e proprio trucco di programmazione, sul quale andremo nel dettaglio tra poco, che ha lasciato alcuni giocatori sorpresi di fronte alla sua natura, al punto da prendersela con le diverse entità coinvolte: c'è per esempio chi ha accusato il team di sviluppo di essere svogliato, così come è stato preso di mira il motore grafico del gioco, "reo" di non aver reso possibile la realizzazione di un treno in modo adeguato. Al di là delle reazioni spropositate, meravigliarsi per una cosa del genere può apparire più che normale se non si è nel giro degli addetti ai lavori, non solo del mondo dei videogiochi ma della programmazione e dell'informatica in generale, alle quali si riconduce ovviamente anche il lavoro di chi crea il nostro tipo d'intrattenimento preferito. Proviamo dunque a curiosare dentro Fallout 3 e altri titoli per scoprire alcune delle curiosità più interessanti che si celano dietro al lavoro svolto per dar loro vita.
I videogiochi non sono Matrix e non simulano al 100% la realtà: ecco alcuni trucchi di chi li sviluppa
Un treno in testa
Partiamo dunque dall'esempio citato poco sopra, quello del treno di Fallout 3. A dare il via a tutto è stato uno screenshot pubblicato online, dedicato a uno degli strumenti usati per lo sviluppo di Broken Steel: al suo interno compariva il modello di un personaggio non giocante, per il quale al posto della testa appariva però l'intero vagone. Una cosa alquanto buffa, messa realmente in piedi dal team di Bethesda per uno scopo validissimo: far comparire un veicolo in movimento in un gioco dove il motore grafico usato, nel caso specifico Gamebryo, non era stato progettato con la gestione dei veicoli in mente.
Realizzare un treno "normale" non sarebbe di certo stato impossibile per il team di sviluppo, che tra le alternative avrà di sicuro considerato la possibilità di realizzare una componente a parte in grado di mettere in scena un treno che somigliasse al modo in cui lo intendiamo nella realtà. Bisogna però considerare se in termini di tempo e denaro ne sarebbe valsa la pena, o se l'escamotage in questione offrisse invece il miglior rapporto tra semplicità di realizzazione e qualità finale, intesa oltre che come resa agli occhi del giocatore anche come parte esente da bug che possano rovinare l'esperienza di gioco. Le valutazioni fatte hanno portato Bethesda a optare per la soluzione più fantasiosa: mettere in testa al personaggio non giocante un elmetto a forma di treno, piantando poi nel terreno del livello tutta la parte di corpo che non fosse la testa. Ma c'è di più, perché il fatto che Gamebryo non fosse stato concepito per far muovere un treno ha messo gli sviluppatori davanti a un altro problema: quello di far sì che il giocatore credesse di essere davvero in una carrozza in movimento. Per risolverlo, inutile a dirlo, è stato messo in atto un altro trucco: una volta entrato nel treno, il personaggio controllato si ritrovava automaticamente in testa un altro elmetto in grado di coprire l'intero campo visivo riproducendo così gli interni di un treno, facendo poi partire un'animazione per dare l'impressione che il mezzo fosse in movimento. Se avete giocato a Broken Steel, a questo punto fermatevi a pensare a quel treno e diteci se vi siete accorti di nulla. Al 99,9% (vi concediamo il beneficio del dubbio) la risposta è no, motivo per il quale non c'è niente per cui ci si debba sentire traditi, o ancora peggio per cui si debba accusare di pigrizia i membri del team Bethesda al lavoro sul gioco: semplicemente, hanno fatto quanto di meglio era possibile fare coi mezzi a loro disposizione, per riuscire a raggiungere un obiettivo all'interno di Fallout 3 che con la tecnologia in uso sarebbe stato molto più complicato da raggiungere.
Giocare per programmare
Se siete incuriositi dal lavoro che si trova alle spalle di ciò che vedete sul vostro monitor, vi segnaliamo l'esistenza di un videogioco che unisce la componente ludica a quella di programmazione. Si tratta di Hack 'n' Slash di Double Fine Productions, concepito dal suo creatore proprio per insegnare i rudimenti della programmazione videoludica a chi è a digiuno di nozioni d'informatica: al suo interno il giocatore può modificare vari parametri legati agli elementi che popolano il mondo, fino a usare uno strumento di debug come parte integrante dell'esperienza di gioco.
Non solo Fallout
Se credete che quello di Fallout 3 sia un caso isolato vi sbagliate di grosso, anche se il secondo esempio legato a un titolo di una certa importanza arriva in realtà sempre da Bethesda. Se avete giocato a Skyrim, avrete visto tavolini come quello qui di fianco: date un'occhiata anche alla seconda immagine e sappiate che per gran parte del tempo il gioco vi ha mentito, visto che non si trattava affatto di tavolini ma di scaffali, disposti dagli sviluppatori in modo che scomparissero nel terreno al punto giusto (in modo molto simile a quanto fatto con il personaggio-treno di Fallout 3), sembrando così un componente d'arredo diverso. Pigrizia? Magia? No, semplice senso pratico per ovviare alla necessità di creare un oggetto che rispondesse alle stesse caratteristiche.
Sempre in Skyrim, vi sconvolgerà sapere che ogni negoziante ha una cassa nascosta sotto la mappa con all'interno il materiale venduto: con questo stratagemma, uccidendolo non si ottiene tutto quanto il malloppo, ma solo ciò che è parte del suo inventario. Di esempi in cui le cose non sono come sembrano, nei videogiochi, ce ne sarebbero a decine: in Half-Life, gli ascensori non avevano possibilità di riprodurre suoni, così gli sviluppatori pensarono di far provenire il rumore dei bottoni dal personaggio che li premeva. In Call of Cthulhu: Dark Corners of the Earth appariva invece uno specchio che specchio non era: si trattava della stessa stanza dove si trovava il giocatore, ribaltata a 180 gradi dando l'impressione di essere un riflesso. In realtà la guardavamo da un buco nel muro. E ci risulta che sia esistito almeno uno shooter in cui il motore grafico non consentisse un'efficace gestione delle collisioni e non fosse in grado di evitare che il fucile passasse attraverso le mura di una casa, permettendo di sparare oltre di esse. Perché allora non far partire il proiettile dagli occhi del personaggio che spara, invece che dall'arma stessa, riuscendo così a risolvere in modo rapido il problema? Per non parlare dei giochi in cui crediamo che sia l'ascensore che ci contiene a muoversi, ma in realtà è il mondo che si muove intorno a noi. A volte dimentichiamo che le cose nei videogiochi non esistono nel senso reale del termine, ma sono il risultato dell'applicazione di linee di codice e immagini, legate insieme dalla matematica per offrirci il risultato che vediamo: a volte rispecchia la realtà, altre volte è frutto di un'illusione maturata dalla difficoltà di far funzionare un engine che spesso deve tenere conto di un quantitativo sterminato di elementi grafici e fisici. Concludiamo con la bugia più grande che un videogioco ci abbia mai raccontato, o almeno con quella più vecchia: risale addirittura al 1979 e riguarda Space Invaders. In molti ricorderanno che abbattendo le forze aliene, la loro discesa verso terra aumentava di velocità, rendendo così la vita più difficile al giocatore. In realtà il gioco fu inizialmente concepito per mantenere sempre la stessa velocità, ma l'hardware disponibile all'epoca era messo sotto stress in fase di rendering al punto da rallentare all'inizio del livello: eliminando gli alieni, il giocatore alleggeriva il carico sull'architettura, dandole così la possibilità di muovere gli elementi presenti sullo schermo con velocità crescente. Visto che la cosa funzionava, fu lasciata all'interno del gioco e "venduta" come parte di esso.
