DeepSeek V4: ottimizzare la generazione di giochi IA con un budget contenuto

I modelli economici possono creare giochi browser a cui le persone abbiano davvero voglia di giocare? Nell'ultima settimana abbiamo provato a rispondere con test in OpenGame Studio. L'aggiunta più recente è DeepSeek-V4.1-Flash-1017, uscito il 17 ottobre e appartenente alla famiglia DeepSeek V4.

Abbiamo testato anche Grok 4.6, Xiaomi MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash e Claude Haiku 5.5. Volevamo trovare un equilibrio migliore tra costo di generazione, attesa, comportamento giocabile e qualità visiva. Un gioco che si apre correttamente può comunque muoversi a destra quando il giocatore preme sinistra, assegnare monete troppo presto oppure continuare a cadere durante la pausa.

L'ultimo runner generato da DeepSeek ha superato i controlli principali di gioco che abbiamo eseguito. La grafica era modesta. Gli esperimenti precedenti hanno messo in luce problemi diversi, compreso un difetto nel nostro sistema di convalida della consegna. Questi dettagli sono più utili a chi crea giochi di una classifica dei modelli senza spiegazioni.

Il runner originale realizzato con DeepSeek-V4.1-Flash-1017. Personaggio, corsie e monete si distinguono; l'ambiente resta quello essenziale di un prototipo.

Ottimizzare la generazione di giochi a basso costo

Per chi crea giochi in piccolo, contano gli esperimenti ripetuti. Una prima versione può richiedere un altro tentativo per la telecamera, i comandi, le collisioni o lo stile grafico. La domanda pratica è quanto gioco utile e verificabile otteniamo da questo processo.

Un modello di punta potente come Claude Opus 5.5 è un'alternativa ovvia per lavori di programmazione impegnativi. Anche la descrizione ufficiale parla dell'uso di sub-agenti. Prima di scegliere un flusso di lavoro più ampio, volevamo esplorare una selezione più economica. Il nome di un modello non garantisce un buon gioco e l'uso di più agenti è una scelta di flusso di lavoro che può comportare più attività e consumi.

La nostra selezione comprendeva diverse opzioni:

• Grok 4.6 ci ha fornito un riferimento generalista. Per noi era un'opzione meno orientata al risparmio, resa interessante anche dall'accesso tramite abbonamento. La pagina ufficiale del rilascio descrive l'accesso alla programmazione tramite Grok Build e altri strumenti.
• Xiaomi MiMo V2.6 Flash e Pro ci hanno permesso di confrontare due opzioni della stessa famiglia. Xiaomi presenta Flash come efficiente e adatto a un uso frequente, e Pro come adatto a ragionamenti e progetti più impegnativi. Pro è un modello di punta nella sua famiglia, ma rientrava comunque nella nostra esplorazione di opzioni economiche.
• GLM 5.3 Flash era un'altra opzione orientata all'efficienza. La presentazione ufficiale ne spiega il posizionamento. Volevamo vedere come avrebbe gestito la richiesta completa di un gioco.
• Claude Haiku 5.5 aggiungeva un'opzione internazionale sensibile ai costi. Anthropic descrive Haiku come modello adatto a lavori rapidi e ad alto volume. L'abbiamo provato per creare un gioco, con una revisione limitata descritta più avanti.
• DeepSeek-V4.1-Flash-1017 era l'esperimento più recente. L'annuncio del rilascio include dimostrazioni di progetti. Abbiamo usato una nostra richiesta per un runner per vedere cosa si sarebbe trasferito a OpenGame Studio.

Nella selezione sono presenti più famiglie di modelli cinesi perché i costi contenuti le avevano rese interessanti. È un riflesso del nostro processo di scelta, non una conclusione sulla qualità dei modelli in base al Paese.

Un runner, sei esperimenti con modelli diversi

Il gioco condiviso era Colossal Runner, un endless runner originale in terza persona con tre corsie. Il personaggio corre in avanti automaticamente. Il giocatore cambia corsia, salta le barriere, scivola sotto gli ostacoli sopraelevati, raccoglie monete e ricomincia dopo una collisione. Tastiera e comandi touch dovrebbero produrre lo stesso risultato visibile.

La richiesta originale comprendeva anche pausa, rianimazioni con monete guadagnate e un ostacolo gigantesco che blocca due corsie lasciandone una sicura. Queste regole interagiscono tra loro e rendono la prova più significativa di una scena in movimento con un contatore del punteggio.

Tra l'11 e il 17 ottobre 2026 abbiamo riutilizzato la stessa richiesta originale nei seguenti esperimenti:

Sono esperimenti individuali condotti da chi sviluppa. Offrono un banco di prova pratico, ma con limiti chiari: ogni modello ha prodotto un proprio brief e una propria implementazione, con scelte visive diverse. I test si sono svolti in date diverse e l'ambiente del sito non era congelato. MiMo Flash ha richiesto un'ulteriore discussione prima della creazione. I tempi escludono discussione, definizione delle specifiche e test di gioco; il valore di GLM termina al rifiuto.

Per il runner di DeepSeek abbiamo mantenuto i vincoli di generazione esistenti e le stesse istruzioni per il builder 3D usate negli esperimenti MiMo. Prima dei controlli di accettazione non abbiamo corretto manualmente il codice sorgente. Questa serie non stabilisce una classifica statisticamente affidabile di velocità o qualità.

Cosa hanno aggiunto MiMo, GLM e Haiku al confronto

MiMo Flash ha prodotto un gioco ispezionabile con comandi utili, compresi controlli limitati di tastiera, touch e pausa. Il problema era la regola delle monete: le ricompense potevano arrivare prima che il runner raggiungesse una moneta. Durante il controllo della raccolta, il codice sorgente leggeva il campo di posizione sbagliato. Una scena convincente e un contatore in aumento avevano nascosto un'interazione difettosa.

Risultato originale di MiMo Flash, prima delle successive correzioni selettive. Il difetto del tempismo della raccolta è stato individuato nei controlli del gameplay e del codice sorgente; questa immagine da sola non può dimostrarlo.

Anche MiMo Pro ha prodotto un prototipo giocabile e i controlli su direzione e contatto con le monete erano incoraggianti. Una pausa a mezz'aria ha rivelato un altro difetto. Distanza e monete si fermavano, ma il personaggio continuava a cadere. Una pausa completa deve bloccare la simulazione pertinente, compreso il movimento verticale.

Scena urbana originale di MiMo Pro. Per individuare il difetto della pausa serviva un test a metà salto, che un'immagine statica attraente non avrebbe rivelato.

GLM ha prodotto due risultati distinti. La sessione in Studio non ha consegnato il gioco perché il nostro validatore ha interpretato erroneamente il codice di gioco in linea come markup di risorse vietato. Si è trattato di un errore della piattaforma. Sarebbe fuorviante considerarlo una prova dell'incapacità di GLM di generare il gioco.

Abbiamo recuperato l'originale invariato e lo abbiamo esaminato separatamente. I controlli limitati su direzione, touch e pausa funzionavano; dopo il riavvio, invece, la visualizzazione delle monete poteva restare invariata. Questa ispezione ci dice qualcosa sul comportamento dell'artefatto, ma non trasforma il flusso di Studio fallito in una consegna riuscita.

Originale di GLM recuperato e ispezionato separatamente. Questa immagine non dimostra che la consegna tramite Studio sia riuscita.

Haiku 5.5 ha prodotto l'anteprima relativamente in fretta in questo campione. La schermata iniziale era visibile; dopo una prima ispezione visiva abbiamo interrotto il test. Non abbiamo completato i controlli di accettazione per tastiera, touch, collisioni, rianimazione o riavvio. La prima impressione non ha cambiato la nostra preferenza per gli esperimenti MiMo, ma non disponiamo di prove di gioco sufficienti per esprimere un giudizio definitivo sulla qualità di Haiku.

Questa distinzione conta quando si tiene un diario dei test: consegna, revisione visiva e verifica del comportamento sono traguardi diversi.

Perché sinistra può diventare destra?

Il runner di Grok ha rivelato il problema dei comandi più evidente. Partendo dalla corsia centrale, Freccia sinistra spostava il personaggio sul lato destro dello schermo. Anche le scivolate verso sinistra producevano lo stesso risultato.

Prima: il runner è al centro.

Dopo Freccia sinistra: il runner è visibilmente a destra. Entrambe le catture mostrano la versione generata senza modifiche.

Il codice sorgente ha spiegato il problema: il gestore spostava il personaggio verso la coordinata X negativa del mondo per «sinistra», mentre la direzione della telecamera faceva apparire quel movimento come uno spostamento a destra sullo schermo. Tastiera e touch condividevano lo stesso controller di corsia e quindi ereditavano l'errore.

Il punto di riferimento del giocatore è la pista visibile. Una coordinata in diminuzione non dimostra uno spostamento corretto verso sinistra. Anche con una telecamera che segue il personaggio occorre controllare la posizione del personaggio rispetto alle corsie, perché può restare al centro dello schermo mentre si muove la pista.

Un altro esperimento di corsa ha messo in luce una debolezza anche nella nostra valutazione. Un controller automatico poteva compensare la sterzata invertita e completare un giro. Ora verifichiamo ogni direzione separatamente, partendo da una nuova gara. Terminare il percorso non aveva verificato l'etichetta dei comandi.

Come si è comportato DeepSeek V4 nel test del runner

Dopo una breve conferma, l'ultimo runner è stato creato in circa sette minuti. Abbiamo provato il risultato originale nell'anteprima del sito:

• Direzioni: Freccia sinistra, Freccia destra, A e D portavano alla corsia visibile corretta. Gli input ripetuti si fermavano alla corsia più esterna.
• Touch: le scivolate a sinistra e a destra funzionavano nelle emulazioni verticale e orizzontale. Verso l'alto si saltava; verso il basso il personaggio si abbassava in una scivolata.
• Ostacoli: con la tastiera abbiamo superato una barriera a terra, scivolato sotto una sbarra sopraelevata e preso la corsia sicura accanto al blocco gigante.
• Monete e rianimazioni: la raccolta iniziava al raggiungimento delle monete. Una rianimazione consumava le monete guadagnate e riprendeva la partita in sicurezza; se le monete non bastavano, non venivano consumate né l'uso veniva sprecato.
• Pausa e riavvio: mettendo in pausa a metà salto, altezza e distanza restavano ferme e gli input sulla pista venivano bloccati. Il riavvio azzerava la corsia centrale, la distanza e le monete visibili.

Una corsa tra gli ostacoli è continuata oltre i 216 metri con 51 monete raccolte. L'automazione del browser ha inviato normali comandi di gioco. Non abbiamo modificato coordinate, punteggi o stato delle collisioni per ottenere il risultato.

Una scivolata a sinistra raggiunge la corsia sinistra visibile nell'emulazione browser verticale. La compatibilità con un telefono fisico non è stata testata.

Non abbiamo provato tutte le sequenze casuali di ostacoli, il percorso sul tetto del treno, il limite delle rianimazioni né gli stati avanzati di gioco. Nell'ambito dei test svolti, il prototipo funzionava e gestiva le regole in modo promettente.

Logica, grafica e leggibilità vanno valutate separatamente

Il runner di DeepSeek distingueva gli oggetti importanti: personaggio verde acqua, bordi brillanti delle corsie, monete d'oro e ostacoli a contrasto. L'ambiente scuro e spoglio e gli edifici semplici lasciavano ampio margine di miglioramento visivo. Questo singolo risultato non dimostra in generale che DeepSeek sia più bravo nella logica che nella grafica.

Il nostro esperimento separato Neon Harbor Sprint aveva uno stile neon deciso, ma la sagoma dell'auto e la strada erano meno leggibili. Una revisione delle prestazioni ha ridotto la risoluzione di rendering: la risposta è migliorata, ma si sono persi dettagli.

Prototipo di corsa DeepSeek distinto, basato su una richiesta diversa e fuori dal confronto tra i runner.

Siamo tornati al runner perché un gioco diverso avrebbe reso il confronto meno chiaro. Il racer ci ha comunque dato una lezione utile: valuta personaggio, ostacoli e bordi delle corsie alle dimensioni effettive di gioco e in movimento. Effetti e decorazioni dell'interfaccia possono coesistere con una scarsa leggibilità.

Le richieste e le competenze sono troppo vincolanti?

La nostra richiesta per il runner era deliberatamente dettagliata, per poterla riutilizzare. Un normale creatore dovrebbe poter partire da un'idea molto più breve. Aiutare a trasformarla in un brief utile fa parte del compito del prodotto.

Non abbiamo svolto un confronto controllato tra una richiesta breve e una dettagliata. La lunghezza del prompt quindi non spiega da sola i comandi invertiti. Il codice che non funzionava offre una spiegazione diretta legata alla telecamera e all'input, mentre altri risultati ottenuti con la stessa richiesta indicavano correttamente le direzioni.

Alcuni vincoli proteggono l'esperienza: comandi coerenti, raccolta delle monete al contatto, pausa completa e riavvio pulito. Altre scelte possono restare libere, tra cui tema, palette, resa della telecamera e modo in cui il modello costruisce la scena. Anche un processo di sviluppo troppo rigido può lasciare poco spazio per ispezionare e migliorare la prima implementazione. Vale la pena provare più opportunità di revisione, ma qui i benefici restano un'ipotesi.

I tentativi precedenti hanno dimostrato perché occorre prestare attenzione al flusso di lavoro. Un tentativo con MiMo ha esaurito il limite di risposte prima di consegnare il gioco. Un altro ha scritto il codice ma ha perso la consegna finale dopo un errore del flusso di dati del provider. Le cause erano diverse e andrebbero annotate separatamente dai difetti di gameplay. Impediscono anche di considerare ogni tentativo storico come un test A/B basato soltanto sul modello.

Un creatore potrebbe iniziare così:

Crea un rapido runner 3D con tre corsie. Fammi schivare a destra e a sinistra, saltare le barriere e scivolare sotto i pannelli, usando tastiera o touch. Voglio un personaggio riconoscibile, raccolte di monete appaganti e un riavvio rapido dopo una collisione. Scegli ambientazione e stile visivo.

È un punto di partenza suggerito, non la richiesta originale usata nel confronto. Studio può chiarire le regole mancanti, confermare il brief e lasciare spazio alla creatività. Poi un breve test di gioco può indicare la revisione successiva più utile.

Cosa cambiano questi test nel nostro prossimo esperimento

Per noi ottimizzare significa ora includere affidabilità della consegna, tempo di ispezione e quantità di riparazioni necessarie a un risultato giocabile. La generazione economica è utile se il risultato regge ai normali comandi e può migliorare con un ciclo di revisione gestibile.

Conserveremo i risultati originali, annoteremo la fase raggiunta da ogni tentativo e confronteremo tastiera e touch con il comportamento visibile. Un confronto futuro potrà mantenere invariato il gioco e modificare una sola variabile del flusso, come la lunghezza del brief o il numero di revisioni possibili. Queste osservazioni da sole non ci dicono quale modello vincerà quell'esperimento.

Per un esempio giocabile, visita Colossal Runner. Le sue versioni pubbliche curate includono correzioni successive e sono distinte dagli esperimenti originali mostrati qui. Puoi anche esplorare altri giochi browser per trovare idee sull'esperienza che vorresti creare.

Hai in mente un gioco semplice? Inizia un brief in OpenGame Studio, definisci il ciclo centrale e prova la prima versione con comandi reali.

Nota sulle fonti

Le fonti ufficiali documentano nomi dei modelli, contesto dei rilasci e posizionamento dei fornitori: rilascio DeepSeek del 17 ottobre, Grok 4.6, MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5 e il riferimento di punta non testato Claude Opus 5.5.

Le osservazioni sul gameplay e i tempi di creazione provengono dai nostri esperimenti OpenGame Studio e dai relativi originali conservati. Le otto immagini sono catture invariate delle ispezioni, con grafica procedurale originale o risorse dei personaggi OpenGame M0 con licenza CC0-1.0. Nessuna immagine è una dimostrazione di un provider o una ricostruzione migliorata.