Diciassette anni fa Brandon Sheffield mise insieme su Gamasutra la classica raccolta "Dirty Coding Tricks" (http://www.gamasutra.com/view/feature/132500/dirty_coding_tricks.php), la traduzione su Habr è qui, e "Developers share their most memorable dirty coding tricks" (https://www.gamedeveloper.com/programming/developers-share-their-most-memorable-dirty-coding-tricks) dove c'erano una telecamera ruotata di 90 gradi invece di sistemare il rendering, uno spazio aggiunto al codice solo per far quadrare il checksum, e due megabyte di memoria nascosti "per i giorni difficili", per poi tirarli fuori solennemente una settimana prima della consegna.
Da allora le raccolte sono state fatte a pezzi e trasformate in citazioni, io stesso ne ho ritrovate alcune persino nel codice di certi progetti, e il genere ha attecchito non solo tra gli sviluppatori di videogiochi. Credo che la gente della programmazione si sia affezionata a queste storie perché spesso vi si riconosceva: le proprie scadenze e i propri hack vergognosi che magari girano ancora da qualche parte in produzione.
Questo articolo è una prosecuzione scherzosa di quella raccolta, con storie dello stesso genere sotto forma di leggende degli studi americani, di classici degli anni Ottanta, del gamedev russo e sovietico con il suo umore tutto particolare. Una parte di queste storielle non è verificata e non ho trovato le fonti, una parte si è rivelata effettivamente una leggenda, ma talmente convincente che alla fine la leggenda ha battuto la realtà nel senso letterale del termine, finendo nel codice di uno dei giochi.
Cercherò di indicare il narratore, se si tratta di ricordi altrui, e se una storia esiste solo sotto forma di folklore ci metterò una nota per segnalare che è folklore. Come vedrete, la differenza a volte è importante. Bene, partiamo, spero venga una lettura interessante...
Della batteria...
Il gioco "Super Time Force" di Capybara Games era interamente costruito attorno alla meccanica del riavvolgimento del tempo: se il giocatore moriva, riavvolgendo il tempo correva accanto alla propria copia passata, e queste copie potevano essere parecchie. Dal punto di vista del motore questo significava che lo stato di ogni oggetto andava conservato per ogni istante di tempo, e siccome la quantità di memoria era un'eterna emicrania su Xbox 360, mettere insieme un hack per questa meccanica non fu difficile.
Durante la certificazione del gioco il QA inviò un bug: se per due minuti martelli tutti i pulsanti alla massima velocità, poi riavvolgi il tempo, poi ripeti... e ripeti ancora, il gioco crasha. È normale che i tester mandino bug del genere... l'anormale comincia quando ti siedi a sistemarli.
I crash in certificazione non li ammorbidisci con nessuna preghiera, tanto più un crash trovato dai tester interni del vendor, e così la certificazione risulta bocciata. Benvenuti alla ripetizione dell'esame fra due settimane. E se al rilascio manca un mese, sistemare "come si deve" la meccanica di gioco principale significa mandare a monte con certezza proprio quel rilascio, per cui il team si mise a rilevare la velocità disumana di pressione dei tasti: se il giocatore premeva i pulsanti più in fretta di quanto sia fisicamente capace un essere umano normale — i tester sono comunque una sottospecie cattiva a sé stante della gente dei videogiochi — allora o era un tester, o una scimmia che sbatte il controller contro la gabbia, e in entrambi i casi si poteva fingere che il giocatore avesse sbagliato per caso e fosse morto. Il giocatore muore, una parte del buffer della timeline collassa, la memoria si libera, tutti contenti.
Ma neanche i tester di Microsoft sono nati ieri, e visto un affronto così sfacciato verso gli sforzi spesi per trovare quel bug tanto insidioso, trovarono un altro bug, stavolta sovraccaricando la timeline con un gran numero di esplosioni, che ovviamente vivevano anch'esse secondo le leggi di gioco del riavvolgimento del tempo. Il rilascio si avvicina, qualcosa bisogna fare, e così, all'avvicinarsi al limite di memoria, a schermo compariva il dialogo della batteria scarica del controller, e il giocatore veniva gentilmente sbattuto fuori nel menu di selezione livello, anche se in quel momento il controller era carico al cento per cento.
Il QA, vedendo il familiare dialogo di sistema, chiuse il bug, accettò la fix e il gioco superò la certificazione. La storia l'ha raccontata il direttore tecnico dello studio, Kenneth Yong.
Dell'importanza dei contatori di fps...
Gli sviluppatori di un gioco di corse (probabilmente era Burnout 3: Takedown, a giudicare dall'epoca, dallo studio e dall'autore della storiella) si scontrarono con una lamentela dei tester: la guida dell'auto si sentiva diversa a seconda che sul cruscotto virtuale fosse disegnata o meno l'icona con il contatore degli FPS. Sull'icona non sono sicuro... La causa di questo comportamento non la si trovava, e nella build master, dove il contatore non c'era, le auto venivano descritte come "a scatti", cioè il contatore di fps in qualche modo influenzava la fisica dell'auto.
Due settimane di lavoro ingegneristico, scavi nella fisica, ricerca delle variabili dipendenti dallo stato dello stack dopo il rendering del font, verifica dei timing e dell'ordine di aggiornamento dei sottosistemi... non diedero nulla. La causa non fu mai trovata e alla fine il gioco venne spedito con il contatore di fotogrammi acceso per sempre, che veniva stampato oltre il bordo destro dello schermo. Milioni di giocatori giocavano a una corsa nel cui angolo un widget invisibile mostrava diligentemente due cifrette e, con il solo fatto della sua esistenza, sistemava la fisica e i comandi.
Martin Turton, che all'epoca lavorava allo studio Criterion Games, raccontava di questo problema proprio nel contesto dello sviluppo delle versioni per PlayStation 2 e Xbox. Secondo Martin, la differenza nel comportamento del motore fisico stava nel fatto che, durante il rendering del testo (il contatore FPS), cambiava lo stato della memoria o della cache, il che in qualche modo "allineava" i timing nel lavoro con il VSync, a cui erano legati i calcoli fisici del gioco. Un esempio lampante del genere degli heisenbug: se non capisci la causa, allora fissa l'effetto che la sistema.
Degli scoiattoli invisibili...
Il gioco Titan Quest non aveva un sistema di timer per le quest, e qualunque trigger scattava all'istante, al fotogramma successivo dopo l'attivazione, per cui la possibilità di "aspettare tre secondi e poi aprire la porta" semplicemente non esisteva. La feature fu richiesta verso la fine dello sviluppo del gioco, cosa quasi irrealizzabile, perché si portava dietro la riscrittura del sistema delle quest.
Un tester che aiutava con gli script scoprì che il ritardo si poteva ottenere tramite la durata dell'animazione allo spawn delle creature di gioco, sulle quali si potevano appendere i trigger degli script. Aspetti la fine dell'animazione, ottieni il trigger. Come timer venne scelto uno scoiattolo, una fauna decorativa che nel gioco correva semplicemente per bellezza, e ora la sua versione invisibile cominciò a lavorare nei livelli come timer, misurando i ritardi necessari attraverso le animazioni.
Innocui roditori diventarono il meccanismo standard di conteggio del tempo in un RPG commerciale, e ancora oggi da qualche parte nei boschi greci di Titan Quest vivono orde di scoiattoli invisibili che coscienziosamente... ticchettano. Per la sua inventiva al ragazzo consegnarono un tamburello personalizzato e la carica di sommo-designer, mentre lo sporco hack divenne un meccanismo standard nel gioco. L'ha raccontato il proprietario di Crate Entertainment, Arthur Bruno.
Del secondo di silenzio...
Lavorando a Mega Man Legacy Collection per 3DS gli sviluppatori beccarono un bug nel sistema audio che non riuscirono mai a rintracciare. Il primissimo suono del gioco, alla comparsa del logo dello studio, gracchiava o non veniva riprodotto affatto, mentre dopo tutto funzionava alla perfezione: si rompeva solo il primo suono.
Il debug mostrò che il flag "il canale sta suonando" nell'audio-API di Nintendo considerava il canale occupato per il primo suono avviato nel gioco, anche se fisicamente non suonava nulla. Lì poteva esserci di tutto, da una race di inizializzazione a una particolarità del firmware in base alla fase lunare, e per questo, prima del primo suono vero, il gioco riproduceva un secondo di silenzio.
Il silenzio gracchiava e coraggiosamente non veniva riprodotto, mentre il suono del logo passava per secondo e suonava ormai normalmente: con questa fix lo spedirono. L'ha raccontato Keith Kaizershot, e sono quasi certo che questo espediente sia stato inventato in modo indipendente da decine di programmatori audio in tutto il mondo, e più di una volta. In uno dei nostri progetti avevamo anch'noi un suono "silent alert" che i mob sentivano e il giocatore no: così un mob comunicava a tutti intorno di essere stato colpito. I suoni silenziosi sono in generale uno dei pattern più antichi nello sviluppo di giochi, che permettono di avvertire i nemici circostanti, aprire porte, lanciare script e persino chiudere quest, ma questa è ormai... tutta un'altra storia.
Del livello 256...
Il contatore dei livelli in Pac-Man era di un solo byte, per cui il 256° livello veniva conservato come 255 (0xFF). Il disegno della frutta in basso sullo schermo prendeva il numero del livello e aggiungeva uno, ma al 256° livello 255+1 va in overflow a 0, e il gioco comincia a disegnare spazzatura presa da porzioni altrui di memoria nella metà destra dello schermo; superare questo livello era impossibile, perché non si vedevano i puntini necessari da raccogliere.
Gli sviluppatori di Namco ritenevano che la difficoltà crescente non avrebbe fatto arrivare nessuno al livello 250, e la gestione dell'overflow semplicemente non la scrissero. Il primo "gioco perfetto" con l'arrivo al 256° livello (3.333.360 punti) venne ufficialmente riconosciuto a Billy Mitchell nel 1999.
Dei 4 secondi...
Il tempo per completare un livello in Donkey Kong si calcola come 10×(livello+4), ma al 22° livello questo limite viene 10×26 = 260, che con un contatore a 8 bit dà 4, cioè al giocatore restano appena ~4 secondi, che fisicamente non bastano per arrivare in cima, e Mario muore.
Per 44 anni questo livello è stato considerato insuperabile, finché nel febbraio del 2025 lo speedrunner Kosmic non lo superò per la prima volta, tramite un glitch di arrampicata su una scala "rotta" più un tempismo fortunato con i barili. Cioè la leggenda dell'insuperabilità si è rivelata non del tutto vera, e il gioco si può finire senza "modifiche". Un buon esempio di quando persino un bug "a prova di bomba", decenni dopo, finisce comunque per cedere.
Delle API altrui...
Allo studio Backbone si presero l'incarico di portare in poche settimane sei arcade di Midway sulla prima PlayStation 3, ma il problema era che il codice di questi giochi, usciti prima su Xbox Live Arcade, non era affatto multipiattaforma e stava immerso fino al collo in DirectX.
Alcune settimane di sofferenze e riscrittura dello strato di rendering di ogni gioco per la nuova API grafica della PS3 sfociarono nel fatto che il team implementò in parte la stessa API DirectX sopra il sistema video della PS3. Dal punto di vista ingegneristico, nello sviluppo di giochi, uno strato che imita un'API altrui è un classico legale del porting degli anni Ottanta, ma dal punto di vista legale e della certificazione di queste cose non si parla agli incontri con chi detiene la piattaforma.
L'autore della storia, Ian Sherman, ricordava che l'ultima settimana del progetto il team la passò a coprire le tracce, cambiando i nomi delle funzioni e ripulendo dalla build ogni riferimento da cui si potessero riconoscere le chiamate all'API altrui. I giochi uscirono, e la PS3 per quasi un anno finse di essere un pochino Windows, finché il rendering non fu rifatto completamente sull'API della piattaforma.
Dei giochi sepolti...
Atari acquistò i diritti di "E.T." da Spielberg per circa 25 milioni di dollari a fine luglio 1982, e al programmatore Howard Scott Warshaw diedero appena cinque settimane e mezza per lo sviluppo, invece dei soliti sei mesi-un anno, per fare in tempo per Natale.
Il gioco uscì nel dicembre 1982, fu un fiasco e divenne uno dei simboli del crollo dell'industria videoludica del 1983. La leggenda voleva che le cartucce invendute Atari le avesse seppellite in una discarica ad Alamogordo (Nuovo Messico) e per decenni non ci si credette, e persino lo stesso Warshaw riteneva questa storia una diceria, finché il 26 aprile 2014 degli scavi pubblici non confermarono la faccenda. Più tardi uno dei manager Atari, James Heller, precisò la portata della tragedia: le cartucce non erano "milioni" ma circa 728.000 unità (il numero totale; le E.T. occupavano presumibilmente il 10% del volume), ma restò non confermato il fatto di altri due luoghi di sepoltura accertati, perché il numero totale di cartucce E.T. prodotte era intorno ai 5 milioni, di cui se ne vendettero circa 1,5 milioni, mentre ~3,5 milioni sparirono nel nulla.
Un altro luogo si ritiene fosse lo stabilimento di El Paso, dove le cartucce dei giochi venivano triturate come rifiuti per un successivo riciclaggio. La dirigenza Atari, vedendo come i locali saccheggiavano la discarica, ordinò di ricoprire tutto con cemento dall'alto, ma nel 1983 gli adolescenti del posto si intrufolavano comunque oltre i sorveglianti e portavano via decine di cartucce schiacciate, ma ancora funzionanti.
Del bug più ostinato...
Dave Baggett (Naughty Dog), uno dei due programmatori del primo Crash Bandicoot, scriveva il codice dei salvataggi. La storiella a volte viene attribuita ad Andy Gavin, il secondo programmatore e cofondatore dello studio.
Ogni tanto la scrittura sulla memory card andava in timeout, e siccome la scrittura non era transazionale, un tentativo fallito cancellava per intero la card del giocatore. Cioè il bug non solo impediva di salvare, distruggeva fisicamente i salvataggi di altri giochi.
Baggett tagliava metodicamente pezzi di codice, finché rimasero quasi solo la nuda inizializzazione del motore e la chiamata di scrittura, ma il bug continuava comunque a riprodursi ogni tanto. Cioè di codice ormai non ce n'era quasi più, e il bug c'era ancora. La causa si rivelò essere nell'hardware: quando i ragazzi, per una simulazione della fisica il più possibile precisa, impostarono il timer programmabile della PS1 a un kilohertz, cioè mille interrupt al secondo, mentre di default quello lavorava a un centinaio di hertz.
Questo timer eccessivo entrava in conflitto con lo scambio dati sulle porte del controller con la memory card, il che ogni tanto portava alla perdita di dati, e l'operazione di scrittura si rompeva. Un caso classico in cui il perfezionismo in un sistema rompe tutt'altro sistema, per nulla collegato al primo. Così anche qui il tuning della fisica dei salti del bandicoot uccideva la memory card, e provate a trovare un nesso del genere guardando il codice dei salvataggi.
Del papà di Doom...
Dal libro "Masters of Doom" di David Kushner.
Il giovane John Carmack a quattordici anni decise che gli serviva un computer Apple II della sua scuola. L'intrusione fu organizzata con la caratteristica meticolosità di Carmack, e la finestra dell'aula la forzarono con una miscela di termite, ma l'"operazione" fallì.
Carmack finì sotto perizia psichiatrica e passò un anno in un istituto per adolescenti difficili, mentre il gamedev mondiale ottenne il suo ingegnere principale con una reputazione già consolidata di adolescente problematico, per il quale gli ostacoli hanno carattere puramente tecnico.
Del DOOM che venne bannato...
Quando questa coppia di geni collegò a DOOM il gioco in rete, fecero la prima versione del codice di rete su IPX, che semplicemente spediva pacchetti broadcast con i dati, cioè ogni aggiornamento dello stato di gioco lo riceveva ogni macchina della rete locale, comprese quelle che non giocavano a nessun DOOM ed erano magari il server della contabilità.
Un deathmatch a quattro metteva a nanna la rete locale di un intero campus con una tempesta di pacchetti broadcast, e gli amministratori di sistema in tutta l'America, già una settimana dopo il rilascio, impararono a filtrare il traffico di DOOM e a bannare le macchine con il gioco. Nelle università il gioco veniva vietato per ordinanza, e l'attesissima feature di rete, che ha generato il termine stesso deathmatch, all'inizio funzionava come un attacco ddos. Pochi giochi possono vantarsi che le loro patch note fossero scritte sotto la pressione dei sysadmin della contabilità, e non dei giocatori.
Del Gandhi nucleare...
La leggenda probabilmente la conoscete... Si ritiene che nel primo Civilization al pacifico Gandhi fosse stata assegnata un'aggressività minima pari a uno, e che al passaggio dell'India alla democrazia l'aggressività del leader calasse di due andando in negativo, il byte senza segno andava in overflow, l'uno si trasformava in 255, e il più grande pacifista nella storia dell'umanità cominciava a bombardare i vicini con regalini nucleari. La storia si è diffusa così ampiamente che ancora oggi la si porta come esempio da manuale di overflow di interi; io stesso, quanto meno, ho sentito proprio questa versione.
Ma Sid nelle sue memorie ha scritto chiaro e tondo che nessun bug del genere nell'originale Civilization c'era, né poteva esserci, e le variabili intere erano con segno, per cui un overflow senza segno da uno-meno-due semplicemente non sarebbe potuto accadere. E anche se il valore fosse per miracolo diventato 255, l'aggressività nel gioco veniva usata come livelli 0-1-2, per cui 255 sarebbe stato semplicemente un due nel significato, e Gandhi si sarebbe comportato come al solito. Non esiste una sola testimonianza confermata del "Gandhi cattivo" nel gioco originale del novantuno, mentre il meme stesso ha preso forma su forum e wiki già negli anni Duemiladieci, a posteriori.
Ma la leggenda si è rivelata così convincente che in Civilization V Gandhi è stato ormai reso di proposito il candidato più probabile all'uso dei mezzi di lancio, e gli sviluppatori, conoscendo questo meme, decisero di stare al gioco. Così un bug inventato è diventato una feature vera, seppure a posteriori.
Dei poliziotti psicopatici...
Il progetto dello studio DMA Design con il titolo di lavorazione Race'n'Chase era su inseguimenti con la polizia in una città aperta vista dall'alto, ma gli inseguimenti venivano piuttosto insipidi, e l'editore valutava se chiudere tutta la faccenda, ma qui intervenne sua maestà il "Caso". Si ruppe la ricerca del percorso delle auto della polizia e durante l'inseguimento queste cominciarono a cercare di speronare il giocatore da parte a parte, tagliando attraverso i marciapiedi e la corsia opposta, causando un caos peggiore del giocatore stesso.
Bastava imbattersi in poliziotti simili e il noioso inseguimento si trasformava rapidamente in follia, pedoni schiacciati e città in rovina, mentre i tester, che ancora il giorno prima sbadigliavano durante le sessioni, cominciarono a litigare per il posto alla macchina di test. I poliziotti impazziti piacquero talmente a tutti che il bug non lo sistemarono, anzi, al contrario, ci costruirono sopra una meccanica di inseguimenti a sé stante e spostarono l'accento del gioco dalle corse alla libertà criminale, regalando al mondo Grand Theft Auto.
Così un bug nell'IA ha di fatto dettato il DNA della serie commercialmente più di successo nella storia dei videogiochi. Ora, ogni volta che in GTA vi vola dietro una volante impazzita, ricordatevi del bug stagionato trent'anni.
Dei fagioli e del simulatore di dio...
Prima dei giochi Peter Molyneux con l'amico Les Edgar gestiva una ditta di consegna merci e, tra le altre cose, portava fagioli in scatola in Medio Oriente. La ditta si chiamava Taurus, e con il gamedev aveva più o meno lo stesso rapporto che hanno i fagioli con un compilatore.
Commodore confuse la loro Taurus con la software house di rete Torus e, sull'onda di questa confusione, propose ai futuri padri del genere god game una decina di Amiga gratuite. Molyneux, per sua stessa ammissione, non si affrettò a dissipare l'equivoco e firmò i documenti prima che cambiassero idea sul regalare computer gratis.
Va precisato che quasi tutta questa storia è nota dalle parole dello stesso Molyneux, famoso per il suo amore per un bel racconto, per cui sulla precisione documentaria dei fagioli informatici non ci metto la mano sul fuoco. Quando alla neonata studio servì un nome, lo scelsero dalla statuetta di una rana che stava in ufficio, sul cui basamento faceva bella mostra la scritta "Bull Frog by Leonardo". Così il leggendario studio ottenne il suo nome.
E Populous, che ha generato un intero genere di god game, lo assemblarono con i Lego, quando Molyneux e compagni disponevano il rilievo con i cubetti e muovevano gli omini di plastica. In verità lui stesso ammise poi che ai fini del bilanciamento del gioco questo non diede nulla e funzionò soprattutto come ottimo pretesto mediatico e pubblicità. Ciò tuttavia non riduce affatto il peso del caso, quando uno studio che ha dato al mondo tutta una gamma di nuovi generi come Syndicate, Theme Park e Dungeon Keeper è cresciuto da un errore d'ufficio altrui, da un gioco di costruzioni per bambini e da una rana di plastica.
Della lettera di troppo...
Nel gioco Aliens: Colonial Marines c'era un refuso nel file PecanEngine.ini: nella riga di rimappatura delle classi per i bot la parola Tether (l'aggancio del comportamento per l'IA) era scritta come Teather, con una "a" di troppo. Il motore cercava la classe di comportamento corretta del bot per Tether, non la trovava, e i parametri di "aggancio della caccia" degli xenomorfi si resettavano al comportamento di default, per cui gli alieni vagavano come ubriachi, si incastravano nei muri o restavano impalati sotto i colpi.
Il refuso lo trovò un modder (jamesdickinson963), e "PC Gamer" e "Kotaku" riprodussero la fix rimuovendo una lettera, dopodiché l'IA si ravvivava sensibilmente, cominciava a camminare normalmente, ad aggirare sui fianchi, a schivare i colpi e persino a saltare sui muri, cosa che ovviamente non è affatto propria degli Alien.
Va notato che l'effetto di questo in certi punti era al limite del placebo, perché il gioco era comunque brutto per un mucchio di altre ragioni, a partire dalle meccaniche core confuse fino a un'IA francamente debole e a un design dei livelli poco ispirato. Quindi presentarla come "un refuso ha ucciso tutto il gioco" non conviene, e sarà più corretto dire che "un refuso ha disattivato uno strato consistente del comportamento dell'IA". L'editore ufficialmente il gioco non lo ha mai patchato.
Dei caricamenti da sei minuti...
Nel febbraio 2021 un programmatore con il nick t0st (su GitHub tostercx), stufo marcio dei caricamenti da sei minuti di GTA Online su pc, scavò con un disassemblatore nella logica di connessione allo shop e trovò due colli di bottiglia. Nel primo il gioco parsava un JSON di quasi dieci megabyte ogni volta all'aggiornamento della pagina (il catalogo dello shop, ~63 mila voci) tramite sscanf, che al suo interno chiamava strlen su ogni elemento, trasformando il parsing in O(n²). Il secondo punto era lì stesso, nel controllo dei duplicati degli oggetti, che girava con una semplice ricerca per ciascuno dei 63 mila elementi, il che portava di nuovo a una ricerca N².
t0st scrisse una propria DLL che si iniettava nel processo e reindirizzava entrambi i punti a varianti ottimizzate, tagliando il caricamento di circa il 70% (da ~6 minuti a ~2), e pubblicò un'analisi dettagliata sul proprio sito. Più tardi Rockstar confermò il problema, integrò la fix nell'aggiornamento 1.37 (16 marzo 2021) e ringraziò t0st nelle patch note, versandogli 10k$ di bug bounty in via eccezionale.
Dei bug e dello champagne...
Jet Set Willy di Matthew Smith uscì su ZX Spectrum nel 1984 e divenne rapidamente un successo, con un piccolo problema: finire il gioco era fisicamente impossibile. La colpa era di alcuni bug non collegati tra loro, uno dei quali sovrascriveva dati di gioco importanti, portando alla scomparsa di uno degli oggetti necessari. Lo sviluppatore semplicemente non verificò il playthrough completo prima della consegna e non notò il problema, l'editore approvò tutto, convinto che "beh, il percorso principale funziona".
Al gioco era abbinato un concorso e al primo che avesse finito il gioco si prometteva di consegnare una cassa di Dom Pérignon, un volo in elicottero e un incontro con lo stesso Matthew Smith. Ricordo che finire il gioco non si poteva. L'editore Software Projects, quando fioccarono le lamentele, all'inizio provò a spacciare il bug per una feature voluta, ma quando il numero di lamentele sull'impossibilità di finire il gioco superò le diverse centinaia, il bug alla fine lo riconobbero.
Vincitori del concorso risultarono due giocatori, Ross Holman e Cameron Else, che, disperando di finire il gioco e ottenere l'agognata cassa di spumantino, si infilarono nel codice, dimostrarono che il playthrough era impossibile e scrissero da soli le correzioni. E poi finirono pure il gioco riparato con le proprie mani e telefonarono all'editore con le prove; in seguito le loro modifiche stettero alla base della patch ufficiale.
I loro premi comunque li ottennero, e questo, a quanto pare, è il primo caso documentato di patch della community pagata con champagne ed elicottero.
Della perestrojka...
"Perestroika" del 1990, scritta da Nikita Skripkin, divenne il prodotto perfetto del suo tempo. La compagnia "Nikita" sarà chiamata così in onore dell'autore e verrà creata solo un anno più tardi, nel 1991, per cui la consueta dicitura "gioco dello studio Nikita" in realtà anticipava un po' gli eventi.
Nell'estate del 1989 all'autore fu suggerita l'idea di fare qualcosa nello spirito dei game show giapponesi, dove i partecipanti fanno a gara a saltare su tronchi e piattaforme sull'acqua; il momento politico nel Paese si rifletté nel documento di design e ne venne fuori una satira politica, dove una rana-"democratica" salta sopra una palude sulle ninfee, che raffigurano leggi e decreti, raccoglie beni di consumo e valuta, evitando l'imposta progressiva e schivando i "burocrati" e singoli personaggi cattivi che cercano di catturarla. Nella schermata iniziale, per completare il quadro dell'epoca e pubblicizzare le principali meccaniche di gioco, disegnarono Gorbaciov sullo sfondo di un muro del Cremlino sfondato, sulle note della "Dubinuška".
La meccanica del gioco era semplice e "acchiappante", la parola "gameplay additivo" allora non era ancora stata inventata, e tutto il contenuto stava in superficie: bastava guardare fuori dalla finestra. Pochi giochi sono riusciti a ottenere così a buon mercato una risposta tanto potente in un'Unione Sovietica che scoppiava dalle cuciture.
Del lupo e dei cartoni animati...
"Elektronika 24-01/Nu, pogodi!", nota anche come "Il lupo prende le uova", fu la prima console tascabile sovietica di massa con schermo LCD a segmenti, prodotta a partire dal 1984, e costava circa 25 rubli. Era un clone non ufficiale del Nintendo EG-26 "Egg" della serie Game & Watch, sia per l'hardware sia per la meccanica.
Tra i bambini degli anni '80, e anche dei '90, girava una leggenda tenace: che a 1000 punti il gioco avrebbe mostrato il cartone animato «Nu, pogodi!» — «Beh, aspetta!», anche se ciò era in linea di principio impossibile su un display a segmenti, dove ogni sezione dell'immagine è rigidamente "cablata" nello schermo. Il vero "bonus" per i 1000 punti era molto più modesto e consisteva nell'azzeramento del punteggio e in un'accelerazione del gioco di circa un terzo.
Dello spazio e dei ranger...
Una delle mie storie preferite del gamedev post-sovietico. Dmitry Gusarov insegnava programmazione a Vladivostok e da solo realizzò la strategia "General", uscita nel 1999. Il gioco venne davvero di ottima fattura e dopo il rilascio la sua casella di posta traboccava di lettere di appassionati che desideravano fare giochi, e nello stesso anno mise insieme lo studio NewGame Software., dove per giunta gli sviluppatori sedevano in città diverse del Paese e assemblavano il gioco per corrispondenza, attraverso l'internet lento e costoso dell'inizio del millennio.
Scelsero il tema spaziale banalmente perché lo spazio era più facile da disegnare. Sfondo nero, puntini delle stelle, sprite di navi e nessuna animazione di corsa, di volti o di draghi con lo skinning corretto.
Le caratteristiche quest testuali, l'anima della serie, comparvero quasi per caso, quando uno dei partecipanti volle programmare qualcosa, visto che studiava per fare il programmatore, e Gusarov inventò per lui un mini-gioco con lo sbarco su un pianeta nello spirito delle vecchie avventure testuali a risposta multipla. La prima di queste quest la fece lui stesso, poi al motore delle quest si collegò tutta una comunità di autori e l'esperimento collaterale crebbe fino a diventare una meccanica core, che i fan della serie ricordano per prima cosa.
Si ritiene che la musica venisse scritta da remoto e alla cieca, perché il compositore non aveva accesso alla build e l'internet non permetteva di spedire le build. Per questo le melodie bisognava comporle sugli screenshot inviati. Anche la trama la inventarono all'ultimo momento, perché per Gusarov contava soprattutto un mondo vivo, che giocasse da sé senza il giocatore, e non una storia; e quando fu chiaro che una trama serviva comunque, si scoprì che in squadra nessuno sapeva inventarle. Toccò chiamare una persona apposita, che tirò fuori una concezione ben strutturata sui klissan.
Dei giochi su carta...
Negli anni Ottanta il dispositivo di gioco di massa in URSS non erano i computer, ma le calcolatrici programmabili, tipo le Elektronika B3-34, MK-54, MK-61 (che aveva anch'io, o meglio mio padre). Sulla rivista «Tekhnika Molodyozhi» (Tecnica per i giovani) usciva la rubrica "Club dei giochi elettronici", dove ogni mese stampavano... ehm... giochi nuovi, e la parola "stampavano" qui è del tutto letterale. Il gioco veniva distribuito sotto forma di listato su una pagina della rivista, e siccome la calcolatrice non aveva un supporto dati, il gioco andava reinserito in memoria a ogni accensione, digitando le istruzioni sulla tastiera. Questa schermata di caricamento durava una ventina di minuti e richiedeva attenzione, perché un refuso al quarantasettesimo passo si scopriva nella migliore delle ipotesi con un crash del programma, e nella peggiore mai.
Tutta la ricchezza della piattaforma si limitava a circa un centinaio di passi di programma e a una quindicina di registri di memoria, se la memoria non m'inganna; per confronto, persino l'Atari 2600 con i suoi 128 byte aveva ordini di grandezza di spazio di manovra in più.
Il successo della rubrica era il "Lunolët", un clone di Lunar Lander, e prima lessi il racconto di fantascienza di Michail Puchov senza listato, che spiegava proprio cosa e perché andava fatto, e poi vidi sulla rivista il listato e in testa qualcosa scattò. Bisognava pilotare l'apparecchio con una riserva limitata di carburante, immettendo la spinta e il tempo di funzionamento del motore, e bisognava farlo atterrare sulla Luna a una velocità non superiore ai cinque metri al secondo, altrimenti sovraccarico e morte dell'equipaggio. Sul display della calcolatrice, intanto, c'erano solo cifre: quota, velocità, carburante residuo, mentre tutta la grafica, tutto il paesaggio e tutto il dramma dell'atterraggio avvenivano nell'immaginazione.
Attorno a questo gioco crebbe una grande comunità nell'ambito del ciclo di Puchov "La via verso la Terra", dove persino il messaggio di errore sul display, il famoso EGGOG, entrò a far parte del folklore e ottenne una spiegazione interna al mondo narrativo. In sostanza era gamedev in cui da motore grafico serviva la propria testa, mentre la distribuzione funzionava attraverso la tipografia e la carta fisica.
Perciò la prossima volta che mi diranno che oggi un gioco non lo si può fare senza Unreal, un budget e un editore, io mostrerò loro semplicemente un listato di «Tekhnika Molodyozhi» e una foto del me stesso decenne con una calcolatrice.
Non mi discosterò dalle tradizioni di questo genere: se avete storielle simili, raccontatele nei commenti, e se saranno con l'indicazione della fonte, è addirittura magnifico.
I link, se per caso qualcuno volesse cercare bug, sviste e discrepanze:
https://www.gamedeveloper.com/programming/developers-share-their-most-memorable-dirty-coding-tricks
https://en.wikipedia.org/wiki/Burnout_3:_Takedown
https://www.gamedeveloper.com/programming/my-hardest-bug-ever
https://beza1e1.tuxen.de/lore/crash_bandicoot.html
https://davidkushner.substack.com/p/prepare-to-meet-thy-doom
https://doomwiki.org/wiki/Broadcast_packet_meltdown
https://en.wikipedia.org/wiki/Nuclear_Gandhi
https://www.gamespot.com/articles/sid-meier-confirms-nuclear-gandhi-is-sadly-just-a-/1100-6481941/
https://www.grandtheftwiki.com/Race’n’Chase
https://www.destructoid.com/grand-theft-auto-only-exists-because-of-a-glitch/
https://www.filfre.net/2016/06/peter-molyneuxs-kingdom-in-a-box/
https://handwiki.org/wiki/Company:Bullfrog_Productions
https://www.techinsider.ru/technologies/1738689-pochemu-amerika-soshla-s-uma-po-igre-perestroika-sdelannoi-v-sssr/
https://hypestorm.ru/perestroika/
https://dtf.ru/avi/1057195-kosmicheskie-reindzhery-istoriya-serii
https://habr.com/ru/post/176485/
https://pacman.fandom.com/wiki/Map_256_Glitch
https://en.wikipedia.org/wiki/Billy_Mitchell_(gamer)
https://errors.fandom.com/wiki/DK_kill_screen
https://www.gamesradar.com/games/donkey-kong/after-44-years-donkey-kong-player-discovers-that-the-legendary-kill-screen-isnt-really-the-end/
https://www.pcgamer.com/all-this-time-aliens-colonial-marines-stupid-ai-may-have-been-caused-by-a-single-typo/
https://techraptor.net/gaming/news/coding-typo-ruined-xenomorph-ai-in-aliens-colonial-marines
https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/
https://www.techdirt.com/2021/03/18/modder-solves-gta-online-loading-time-problem-gets-paid-rockstar-it/
https://dubikvit.livejournal.com/23894.html
https://droider.ru/post/volk-lovit-yajcza-sovetskoe-nintendo-razbor-05-09-2022/
https://edition.cnn.com/2014/04/27/tech/gaming-gadgets/atari-et-video-game