“Everything is open source now”: anatomia del nuovo modding con l’IA

Minecraft dentro Elden Ring, uno skateboard nelle mappe di Modern Warfare 2, un’elytra sopra Los Santos. Su X la nuova ondata di modding e mashup ha trovato una formula: “Everything is open source now”. La frase comprime una tesi radicale: il possesso del codice sorgente originale potrebbe smettere di essere il requisito per analizzare o modificare un videogioco.

Il cambiamento riguarda quanto costa ricostruire il funzionamento di un programma a partire dal software compilato, dalle sue risorse e dal suo comportamento osservabile. Gli agenti possono utilizzare decompilatori, produrre implementazioni candidate, compilarle e confrontare i risultati. Nei mashup, quella conoscenza serve a trasferire una simulazione in un altro runtime oppure a far comunicare processi che continuano a eseguire i giochi originali.

Ambito dell’analisi e criteri di verifica

La seguente analisi del modding assistito dall’IA confronta post degli autori, repository e documentazione pubblica disponibili all’8 ottobre 2026. Non comprende prove di gameplay. Per ogni caso interessa identificare quale codice viene eseguito, quale componente mantiene lo stato della simulazione e come sono trasferiti rendering, collisioni ed eventi. Ogni dichiarazione sull’impiego dell’IA viene attribuita al suo autore.

Tre proprietà vanno valutate separatamente: fedeltà del codice ricostruito, equivalenza del comportamento e qualità dell’implementazione. Un confronto binario può verificare la prima su un perimetro definito. Test ripetibili possono misurare aspetti della seconda. La terza richiede di esaminare anche sincronizzazione, conversioni dei dati e gestione dei casi limite. La riuscita di una demo documenta le condizioni che la fanno funzionare, senza estendere automaticamente il risultato all’intero gioco.

Dal canale YouTube di GameSource

Xbox nel caos: chiusure di studi e Game Pass a rischio [Sourcecast s26: e13]

Iscriviti al canale →

Modding e open source: accessibilità tecnica e apertura

Un riferimento centrale usato per l’analisi è All games are open source now, l’articolo pubblicato da Rehan Sheikh su X il 4 ottobre 2026. L’autore collega le proprie sperimentazioni con Terraria e GTA V ai crossover di Tobyn Jacobs e Chasm, e al toolkit Universal Modder. Interpreta la convergenza tra agenti di programmazione, generazione di risorse e distribuzione nel browser come l’inizio di un mercato dei giochi facilmente remixabili.

È una tesi ambiziosa, scritta da un autore direttamente coinvolto nei progetti. Va letta però come interpretazione e previsione, l’esistenza di una demo non dimostra che ogni gioco sia ricostruibile in un weekend, né che sviluppo, verifica e distribuzione abbiano azzerato il loro costo.

Le origini di questo nuovo trend sono riconducibili al post di Chasm del 19 settembre, dedicato alla riscrittura di Skate 3 in Rust: “Every game is open source now”. Chasm descriveva uno sviluppo umano assistito dall’IA, citava Codex e dichiarava l’obiettivo di riprodurre il comportamento del gioco originale.

È importante ricordare però che la definizione di open source rimane più precisa: richiede condizioni di licenza che consentano accesso al sorgente, modifiche e redistribuzione. Rendere un binario più comprensibile non assegna automaticamente quelle condizioni al gioco commerciale. Open Source Definition.

La distinzione conta anche per capire cosa desideriamo da questa tecnologia. Possibilità di intervenire, disponibilità del codice e libertà di condividere il risultato sono tre questioni che possono avere risposte differenti.

Codice, risorse e distribuzione: perché la tesi va oltre le mod

Rehan scompone il videogioco in tre parti: codice, risorse e distribuzione. Nel modding, creare una modifica riguarda tutte e tre. Una nuova arma richiede un comportamento, una rappresentazione visiva e un pacchetto che qualcuno possa usare. Un crossover deve anche trasportare e adattare dati tra sistemi differenti.

Nella sua interpretazione, gli agenti riducono il lavoro sul codice, la generazione di texture e mesh accelera la produzione delle risorse, il browser semplifica l’accesso al risultato. Qui la tesi diventa una previsione: Rehan immagina una piattaforma per scoprire remix e accreditare i creatori dei mondi originali. Le implementazioni pubbliche permettono di studiare alcuni passaggi di questo processo, mentre la sostenibilità di quel mercato resta aperta.

Chasm e Tobyn nella nuova ondata di modding

Il 27 settembre Chasm mostra lo skateboard dentro Modern Warfare 2. Il 29 settembre Tobyn Jacobs pubblica Minecraft dentro Elden Ring, dichiarando anche il funzionamento su Mac tramite Crossover. Nello stesso periodo arriva Minecraft in Skyrim. Il 30 settembre Rehan mostra il volo con l’elytra in GTA V.

Chasm precede Tobyn nei post individuati. Tobyn ha però un’influenza documentata sui progetti successivi, il repository Minecraft/GTA V lo cita tra le ispirazioni, e l’autore di Minecraft Ring su Reddit riconosce sia il suo video sia SkyCraft. La ricostruzione ha quindi almeno due figure centrali e non consente di assegnare a un solo utente l’invenzione dell’intero fenomeno.

La viralità delle clip è facile da comprendere, un personaggio e un mondo familiari messi insieme in modo assurdo rendono il risultato leggibile in pochi secondi. Il formato premia una combinazione riconoscibile prima ancora che il pubblico conosca il procedimento tecnico.

Oltre a loro, un altro utente merita di essere menzionato per il lavoro svolto. Il motore Skate 3 in Rust riconosce a dumbad oltre due anni di ricerca su formati, animazioni e comportamento del gioco originale. La nuova implementazione si appoggia a quel lavoro di ricerca e modding. Il contributo degli agenti va valutato insieme alle conoscenze e agli strumenti che hanno reso possibile usarli.

Decompilazione, ricompilazione e compatibilità

Il reverse engineering studia il funzionamento di un sistema. La decompilazione produce una rappresentazione di livello più alto del codice compilato, ma non garantisce il recupero di nomi, struttura o commenti del progetto originale. La static recompilation parte dal codice macchina già compilato e lo traduce prima dell’esecuzione, anche attraverso una rappresentazione intermedia, per renderlo eseguibile in un altro ambiente. Non richiede di recuperare il sorgente originale. Una reimplementation implementa nuovamente i comportamenti. Un compatibility layer permette al programma originale di utilizzare servizi diversi da quelli per cui era stato costruito.

I mashup aggiungono un’altra possibilità: far comunicare simulazioni separate oppure integrarne parti in un nuovo runtime. Avere una di queste soluzioni non significa aver realizzato anche tutte le altre.

Gli agenti nel modding: leggere, compilare, confrontare

Rehan insiste su un punto che aiuta a capire perché queste sperimentazioni stanno arrivando insieme: un agente può eseguire una sequenza di operazioni, osservare gli errori e riprovare. La pipeline diventa un ciclo di ricerca con strumenti esterni, risultati osservabili e una memoria delle decisioni già verificate.

Prima si riconosce il gioco, poi si sceglie come intervenire

Universal Modder organizza questo lavoro in procedure e note condivise. La ricognizione iniziale identifica game engine, versione e strumenti di modding disponibili. Il risultato orienta la scelta: usare un loader della community, cambiare dati oppure analizzare codice compilato. La promessa di modificare quasi qualsiasi gioco va valutata su ciascuna implementazione.

La documentazione di reverse engineering distingue, per esempio, gli assembly .NET analizzabili con ILSpy dal codice nativo studiato con Ghidra o IDA. Nel caso di Unity IL2CPP, ricostruire nomi, tipi e firme dei metodi non equivale a recuperarne i corpi, quelli richiedono l’analisi del codice nativo. La struttura del programma determina quante informazioni sono già disponibili e quanto lavoro rimane.

Un bridge come Ghidra MCP rende interrogabili funzioni, stringhe e riferimenti. L’MCP è il protocollo attraverso cui l’agente richiama questi strumenti. Il decompilatore produce la rappresentazione del binario, il modello la esamina e decide quali operazioni richiedere. Può seguire chi chiama una funzione, proporre nomi più comprensibili e annotare un’ipotesi da verificare.

Perché il matching è un obiettivo adatto all’automazione

Nella matching decompilation, si scrive una funzione in un linguaggio e la si ricompila cercando di riprodurre il codice macchina originale. Due sorgenti dal comportamento equivalente possono generare istruzioni diverse. Contano compilatore, opzioni di ottimizzazione e forma del codice. È un problema più preciso del semplice far funzionare qualcosa di simile.

Il ciclo può essere ripetuto: leggere l’assembly, proporre il sorgente, compilare e confrontare le istruzioni prodotte con quelle attese. Strumenti come objdiff ricompilano gli oggetti modificati e visualizzano le differenze rispetto al risultato previsto. L’agente può quindi modificare una scelta, per esempio un tipo o l’organizzazione di un ciclo, e misurare di nuovo. Il compilatore e il differ costituiscono il feedback al core del ciclo di ricerca.

Un agente può tentare molte correzioni quando esiste un criterio misurabile, e gli strumenti di confronto rendono visibili i progressi. La percentuale di matching va comunque letta insieme alla base di riferimento su cui è misurata. Funzioni, dimensione del codice e componenti ricostruiti descrivono aspetti diversi. Per ottenere un port servono inoltre le risorse e un ambiente capace di sostituire i servizi della piattaforma originale.

Le infrastrutture per questo lavoro esistevano già, come decomp.me, dedicato alla decompilazione collaborativa. Anche N64Recomp e ReXGlue hanno percorsi specifici per N64 e Xbox 360. L’agente si inserisce quindi in un ecosistema di strumenti e ricerca già esistente, senza rendere equivalenti decompilation e static recompilation, che restano tecniche distinte.

Compilare è solo una parte: il gioco deve essere osservato

La procedura di automazione prevede avvio, preparazione della scena, input e lettura di screenshot e log. Un’altra possibilità è un bridge interno alla mod che invia all’agente lo stato del gioco e riceve istruzioni. In questo modo si possono osservare dati espliciti, anziché dedurre tutto dall’immagine.

Nel modding, una scena ripetibile permette di controllare una modifica nelle stesse condizioni. Un agente può verificare se un oggetto compare, se un attacco produce danno o se il programma registra un errore. Valutare il bilanciamento, la leggibilità e il piacere di giocare richiede criteri ulteriori. Aver superato una prova automatica dice qualcosa di utile, ma circoscritto.

Nel toolkit le note conservano versioni, problemi e soluzioni per il tentativo successivo. Questo passaggio è meno vistoso della clip, ma evita di ripetere la ricerca già svolta. Esiste anche Universal Game Modder, un progetto distinto per analizzare e modificare binari attraverso MCP.

Modding e mashup: runtime comuni e giochi collegati

Modern Warfare 2, Skate 3 e Minecraft: un runtime comune

2010 Rust Rewrite Mashup combina i tre giochi su IW4L, il runtime Rust realizzato da vladtrc e collaboratori. Il mondo Minecraft è gestito dal motore Rust MinecraftOSS, in questo caso non si tiene aperto il normale client Java accanto a Call of Duty.

IW4L legge risorse originali di MW2 e le utilizza in una nuova implementazione basata su Bevy e wgpu. È un progetto sperimentale con parti incomplete, il recupero delle risorse e la somiglianza visiva non dimostrano una riproduzione perfetta di ogni comportamento.

Per lo skateboard, la documentazione tecnica descrive il trasferimento delle collisioni delle mappe alla simulazione, l’individuazione dei bordi utilizzabili per i grind e il retargeting delle animazioni sullo scheletro del soldato. Un bordo deve diventare una superficie su cui lo skateboard sa scorrere. La posa del personaggio deve seguire quel movimento. La difficoltà è rendere compatibili sistemi che non erano stati progettati insieme.

SkyCraft e GTA V: collegare giochi ancora in esecuzione

SkyCraft mantiene Minecraft e Skyrim attivi. Un plugin SKSE e una mod Fabric scambiano informazioni attraverso memoria condivisa, un’area accessibile ai due processi. Minecraft mantiene la propria logica, Skyrim il mondo, gli NPC e le missioni.

Il protocollo attuale contiene stato del giocatore, collisioni, attori ed eventi. Gli NPC possono essere rappresentati da entità invisibili attaccabili in Minecraft, associate all’identificativo originale di Skyrim. Il bridge traduce un attacco in una conseguenza nell’altro gioco. Sono previsti anche trasferimenti di mesh e texture affinché Skyrim disegni elementi Minecraft nel proprio fotogramma.

Nel protocollo SkyCraft la scala è fissata a 70 unità Skyrim per blocco, con coordinate nello spazio Minecraft. Lo stato esporta tick fisici a 20 Hz, posizioni precedenti e correnti e timestamp affinché Skyrim possa interpolare sul proprio clock di rendering. Lo scambio usa contatori di sequenza per evitare di leggere uno stato mentre viene aggiornato. Scala spaziale, fase temporale e consistenza dello stato sono parte dell’interfaccia tra le simulazioni.

Il progetto Minecraft × GTA V di Rehan usa invece anche una composizione delle immagini basata sulla profondità. Confrontare la distanza degli elementi dalla camera permette di stabilire cosa debba apparire davanti. Un blocco oltre un muro non deve coprirlo soltanto perché viene disegnato per ultimo.

Le note di sviluppo esplicitano la conversione: un metro GTA corrisponde a un blocco, mentre la posizione GTA (x, y, z) diventa Minecraft (x, z + yOffset, −y). Colore e depth buffer passano in memoria condivisa, mano e HUD su un overlay separato. Il compositor converte la profondità Minecraft sull’asse della vista GTA prima del depth test.

La camera introduce anche un problema di sincronizzazione. Quando un frame di Minecraft viene mostrato, la posizione della camera è già cambiata. Per ridurre questo ritardo, il progetto corregge prima la rotazione dell’immagine e poi anche il movimento nello spazio, usando la profondità della scena per compensare gli spostamenti. In un test con una parete di Minecraft davanti allo skyline di GTA, gli autori hanno misurato un ritardo di circa un frame. L’integrazione dipende quindi non solo dal corretto allineamento delle coordinate, ma anche dalla sincronizzazione temporale delle immagini.

Per le collisioni, il terreno di GTA viene rappresentato in Minecraft con barriere invisibili. I blocchi piazzati diventano oggetti invisibili di GTA. Il progetto ne limita il numero a 400. È un esempio concreto del divario tra una scena convincente e un’integrazione capace di sostenere qualunque situazione di gioco.

Dall’immagine generata all’asset che il motore accetta

Il caso San Franciscans per Age of Empires II: Definitive Edition mostra un’altra parte del processo raccontato da Rehan. La civiltà introduce Robotaxi e droni, ma aggiungerli richiede una pipeline precisa. Il progetto parte da concept generati con fal, li trasforma in modelli 3D e li renderizza con Blender per ottenere gli sprite.

La camera è ortografica e inclinata di 30 gradi. Ogni animazione viene renderizzata nelle 16 direzioni previste dal gioco. I fotogrammi vengono poi convertiti in file SLD, separando immagine, ombra e colore del giocatore. La mod aggiorna infine anche i dati relativi a unità, tecnologie e testi. Il progetto riutilizza lo spazio assegnato ai Borgognoni, mostrando come l’aggiunta di nuovi contenuti richieda di adattarsi alla struttura dati già prevista dal gioco.

In Fal Arsenal per Terraria il percorso è differente. I disegni generati vengono ritagliati, ridimensionati e organizzati nei fotogrammi che la mod carica attraverso tModLoader. Questa parte del modding richiede di rispettare orientamento degli sprite, trasparenza e disposizione delle animazioni. Il codice che disegna il proiettile deve interpretarne correttamente la direzione.

Il repository documenta anche un problema legato al comportamento dell’IA: il sistema usato inizialmente come base per un nemico smetteva di inseguire il giocatore durante il giorno. Per il Mech Walker è stata quindi sviluppata una logica specifica. È un esempio di come, anche quando la parte grafica è già pronta, sia ancora necessario studiare il comportamento del gioco e verificarlo con test diretti.

Non solo decompilazione: altri percorsi tecnici

Un caso diverso è Pebble di Brian Gao, un gioco ispirato a Minecraft sviluppato in Swift con renderer Metal. L’autore descriveva lo sviluppo assistito da Claude già a giugno su Reddit. Il repository specifica di non utilizzare codice decompilato di Minecraft, si tratta quindi di una reimplementation, precedente all’ondata di progetti emersa a settembre.

Esiste anche MetalMod, che interviene invece sul backend grafico attraverso Fabric. È un caso particolarmente interessante perché interviene sul rendering senza ricreare il gioco. L’entità degli eventuali miglioramenti di prestazioni va però misurata con benchmark comparabili. È quindi importante distinguere questo tipo di intervento da una reimplementation completa. Nel caso di Pebble, Swift è il linguaggio con cui viene costruito il programma e Metal l’API utilizzata per rendering e calcolo sulla GPU. MetalMod, invece, lavora sull’infrastruttura grafica di un gioco già esistente.

Per Bloodborne, bbport documenta un approccio ancora diverso: esegue su Linux il codice x86-64 originale, sostituendo i servizi e le librerie della PS4 e traducendo la parte grafica verso Vulkan tramite un renderer derivato da shadPS4. L’autore paragona l’approccio a Wine e DXVK e descrive il progetto come ancora sperimentale. Non si tratta quindi di una decompilazione completa in codice sorgente.

Il caso di GTA V nel browser è più recente e molto meno documentato. Il 6 ottobre Alex St. Louis ha dichiarato su X di aver portato GTA V in WebAssembly con l’aiuto dell’IA, collegando il sito PlayGTA5. Tra le fonti consultate non abbiamo però individuato un repository primario che permetta di ricostruire nel dettaglio l’architettura del progetto o di verificare l’eventuale utilizzo dei sorgenti trapelati.

WebAssembly offre un formato compilato che il browser può eseguire. WebGPU espone invece funzionalità della GPU per grafica e calcolo. In un port che li utilizza, il primo può eseguire la logica e il secondo gestire il rendering sul dispositivo del giocatore. È un percorso diverso dallo streaming, dove il gioco gira su un server che invia immagini.

Questo spiega perché il browser interessi agli autori di remix. Un link può diventare il punto di accesso all’esperienza. Il port deve però adattare anche grafica, input e caricamento dei dati all’ambiente web.

Quando il confine si sposta: giochi Windows su iPhone e PS5 su PC

Un altro percorso è quello di Madeira, un progetto di ricerca che esegue giochi Windows su iPhone senza jailbreak. FEX-Emu traduce durante l’esecuzione le istruzioni x86 e x86-64 in ARM64, Wine fornisce le API Windows e, compilato per ARM64EC, gira nativamente, mentre viene tradotto il codice del gioco. DXMT adatta Direct3D 9, 10 e 11 a Metal. Per Direct3D 12, Madeira include un’implementazione propria che converte gli shader DXIL attraverso il Metal Shader Converter di Apple.

Anche il modello di esecuzione va adattato: iOS impedisce all’app di avviare altri programmi, quindi i componenti convivono in un solo processo e il server di Wine diventa un thread. Senza jailbreak non significa però senza vincoli: la traduzione richiede il JIT, abilitato tramite debugger, e l’app viene installata tramite sideloading. Compatibilità e prestazioni variano tra i giochi.

Il repository dichiara una quantità significativa di lavoro assistito dall’IA nei propri fork. Avverte inoltre di non proporre quelle modifiche a FEX-Emu, che non accetta codice generato dall’IA. L’accelerazione si appoggia dunque a infrastrutture preesistenti, le cui politiche di contribuzione restano distinte.

Sul fronte PS5, AnyPS5 affronta un problema diverso. La documentazione dell’architettura descrive un relinker che trasforma gli eseguibili della console nel formato nativo di Linux o Windows e li collega a implementazioni sostitutive delle librerie di sistema. Il programma risultante viene caricato dal sistema operativo come un normale processo. Gli import vengono risolti attraverso i NID, gli identificatori usati per riconoscere le funzioni richieste dai moduli originali.

La CPU resta nel mondo x86-64, ma questo non rende automaticamente compatibili servizi di sistema e grafica. AnyPS5 decodifica gli shader RDNA, li traduce in una rappresentazione intermedia e produce SPIR-V per pipeline Vulkan. Il lavoro riguarda quindi anche le interfacce che il codice si aspetta di trovare, oltre al formato dell’eseguibile.

La lista di compatibilità consultata documenta Dreaming Sarah come giocabile su Windows, mentre lascia il risultato Linux non determinato. È un riscontro limitato, che non dimostra la compatibilità con l’intera libreria PS5. La definizione “senza emulazione” usata dal progetto descrive il suo approccio all’esecuzione, ma non elimina il lavoro necessario per riprodurre i servizi della piattaforma originale.

Madeira e AnyPS5 rendono concreta una possibilità già incontrata con bbport: conservare il codice del gioco e intervenire sull’ambiente che lo circonda. Nel primo caso occorre tradurre anche le istruzioni della CPU; nel secondo il centro del lavoro è adattare eseguibili, librerie e grafica. Nel discorso sul modding, questa distinzione conta più dell’etichetta scelta per la clip: aiuta a capire che cosa è stato costruito e quali ostacoli restano.

Perché fa paura, e cosa vale la pena difendere

Lo slogan colpisce perché riguarda il controllo. Se analizzare e adattare un programma diventa più accessibile, più persone possono intervenire su esperienze che fino a ieri sembravano dipendere soltanto dal produttore. Il modding offre quindi una prospettiva interessante per accessibilità, sperimentazione e conservazione. Anche il nostro dibattito sull’IA nei videogiochi può partire da casi concreti come questi.

La conservazione diventa concreta quando il gioco resta disponibile, ma l’hardware o le API da cui dipende non sono più accessibili: adattarne il codice o ricostruire quei servizi può permettergli di continuare a funzionare su un sistema diverso. Questo non risolve automaticamente la perdita di un server online, che può richiedere dati e comportamenti non ricavabili dal solo client.

La stessa possibilità apre domande scomode. Chi riconosce il lavoro di chi ha studiato un engine per anni? Chi corregge il progetto dopo la clip? Come distinguiamo una prova limitata da una riproduzione fedele? Quanto dell’entusiasmo viene dalla novità del risultato e quanto dalla sua effettiva utilità?

Scegliere uno strumento e valutare ciò che produce sono decisioni separate. Un crossover può dimostrare un’integrazione tecnicamente interessante senza proporre un’esperienza che vorremmo giocare a lungo. La curiosità iniziale merita spazio, e secondo me è anche una parte importante di questa fase, ma non può essere l’unico criterio di giudizio.

Personalmente, trovo questa fase del modding affascinante e sono piuttosto favorevole alla direzione che sta prendendo. Una combinazione assurda può essere un ottimo punto di partenza. Un agente capace di aiutare a superare un ostacolo tecnico può permettere a qualcuno di realizzare un’idea che altrimenti avrebbe abbandonato, ed è forse questo l’aspetto che mi entusiasma di più: abbassare alcune barriere senza eliminare la necessità di capire ciò che si sta costruendo.

Preferisco però giudicare il risultato attraverso codice comprensibile, verifiche, manutenzione e crediti, senza prendere una dichiarazione di velocità come misura del valore. Fare qualcosa in pochi giorni può essere impressionante, ma conta molto di più capire se quel lavoro può essere studiato, corretto e portato avanti.

L’open source comprende anche il lavoro collettivo che rende un progetto studiabile e manutenibile. Sarebbe un esito povero usare quella parola soltanto per celebrare la capacità di riprodurre il lavoro altrui, dimenticando chi costruisce e mantiene gli strumenti, la documentazione e le conoscenze che rendono possibili questi esperimenti.

La domanda che mi lascia questa ondata è quanto spazio sapremo dare a progetti che durano. Le dimostrazioni spettacolari possono essere un inizio, non necessariamente un punto di arrivo. I risultati più promettenti saranno quelli che permetteranno ad altri di sperimentare, capire, correggere e costruire qualcosa di nuovo: da un ponte fra due giochi fino a un nuovo renderer, un port o un’esperienza originale.