Il progetto parte da un desiderio semplice: fare un FPS da giocare con gli amici. L'autore, /u/zRevengee, non ha usato un motore commerciale in cloud o un assistente basato su API a consumo. Ha eseguito Qwen 3.8 Flash Next in locale, con quantization Q4_K_XL e finestra di contesto da 256k token, affidando a opencode il ruolo di harness per generare e modificare il codice. Il risultato è un gioco multiplayer con una lista di funzioni sorprendentemente ampia: shader retro in stile PSX attivabile, ambienti completamente distruttibili, corsa tattica, inclinazione con Q ed E per sbirciare dagli angoli, modalità free for all, SnD, solo spade, solo RPG, deathmatch a squadre, killfeed, mappa con puntini rossi quando un giocatore spara, bunny hop, ciclo giorno-notte con pioggia o neve, slider per FOV e intensità dello shader e una modalità nascondino.

Il dato tecnico più interessante non è la singola feature, ma il ritmo di lavoro. La demo giocabile è nata in circa due ore; il lavoro di rifinitura ha richiesto tre giorni, spesso con la macchina che lavorava mentre l'autore era al lavoro o dormiva, controllata da telefono tramite KVM remoto. Questo sposta il baricentro: il collo di bottiglia non è il costo per token o la latenza di una API, ma il tempo macchina disponibile. Su una configurazione con AMD Ryzen 9 5900X, 128 GB di DDR4 a 3200 MHz e due GPU NVIDIA — una RTX 5090 e una RTX 4000 PRO, con 32 + 24 GB di VRAM — il modello ha prodotto in media 20 token al secondo con MTP. È un ritmo lento rispetto ai servizi hosted, ma sufficiente per un flusso asincrono: si imposta il task, si lascia il modello a iterare e si controlla più tardi.

L'aspetto strutturale è che questa esperienza non è un outlier isolato. I modelli aperti, quando girano su hardware locale con quantization aggressiva, permettono a singoli sviluppatori di affrontare progetti creativi complessi senza inviare codice o asset fuori dalla propria rete. Per chi valuta deployment on-premise, i trade-off sono chiari: da un lato non ci sono costi per token e i dati restano sul ferro; dall'altro servono GPU con VRAM adeguata e un raffreddamento capace di reggere sessioni lunghe. Qui la VRAM complessiva dichiarata è di 56 GB, un requisito non banale per un hobbista, ma nemmeno irraggiungibile per team piccoli che vogliono affiancare al cloud una capacità locale.

Ma il punto non è consigliare a tutti di comprare due GPU. È che il confine tra consumatore e creatore si sta spostando. Un modello quantizzato in Q4_K_XL, con una finestra di 256k token, può tenere in memoria un intero progetto di gioco e produrre modifiche coerenti. La degradation rispetto alla precisione piena c'è, ma in un contesto di coding iterativo il vantaggio di avere un assistente sempre disponibile, senza filtri di utilizzo e senza fatturazione mensile, compensa ampiamente la qualità leggermente inferiore di qualche suggerimento.

Resta una domanda aperta su chi ci perde in questo scenario. I servizi cloud di coding assistito offrono modelli più grandi e risposte più rapide, ma costringono a condividere il codice e a dipendere da una connessione. L'hardware locale richiede investimento iniziale e competenze di gestione. La storia di questo FPS dimostra che il mercato si sta segmentando: non c'è un unico deployment giusto, ma percorsi diversi a seconda della sensibilità ai costi, alla privacy e alla pazienza. Il fatto che un singolo utente abbia ottenuto un demo giocabile in due ore, con un modello locale e un harness self-hosted, segnala che l'ecosistema degli strumenti on-premise sta raggiungendo una maturità sufficiente per progetti reali, non solo per esperimenti.