Come ho costruito un gioco multiplayer in un pomeriggio con Claude

L'AI non ti ruberà il lavoro di game designer. Ma qualcuno che sa usare Claude per prototipare un'idea in poche ore, sì. La domanda vera è: fino a quando saremo noi a decidere cosa costruire?

Qualche giorno fa mi sono ritrovato a sperimentare con Claude Code e Opus, spinto dalla curiosità di vedere fino a dove potevo arrivare nella costruzione di un videogioco senza scrivere una riga di codice manualmente. Non sono un game developer professionista, ma volevo testare se l'approccio iterativo che uso nei workflow di automazione potesse funzionare anche per progetti creativi complessi.

Quanto costa davvero costruire un gioco con l'AI

Partiamo da un aspetto pratico che nessuno racconta: costruire con l'AI non è gratis. Ho testato tre versioni di Claude per capire il rapporto qualità-prezzo: Haiku 3.5, Sonnet 3.5 e Opus 3.5.

Con Haiku 3.5 ho speso circa 5 euro per un prototipo funzionante ma basico: grafica semplice, meccaniche essenziali, nulla di sorprendente. Con Sonnet e Opus, entrambi attorno ai 24-25 euro, la qualità è schizzata verso l'alto: animazioni fluide, fisica credibile, dettagli che fanno la differenza tra un esperimento e qualcosa che vale la pena condividere.

Il punto non è risparmiare a tutti i costi, ma sapere che con meno di 30 euro puoi mettere in piedi un prototipo giocabile che un anno fa avrebbe richiesto settimane di lavoro e un team dedicato.

Come usare Claude Code per iterare rapidamente

Il mio setup: Claude Code con Opus 3.5 in un terminale dentro Orca, un'app che ti permette di gestire thread paralleli con agenti AI diversi. Non è l'unico modo, puoi usare tranquillamente l'app desktop di Claude o Cursor, ma il punto è lavorare per iterazioni veloci.

Invece di scrivere specifiche dettagliate, uso la trascrizione vocale per buttare giù pensieri in tempo reale. Parlo a circa 200 parole al minuto contro le 40-80 che battiamo alla tastiera. Questo mi permette di catturare idee mentre gioco, testando meccaniche direttamente nel browser e segnalando a Claude cosa funziona e cosa no.

• Primo passaggio: dump vocale di tutte le feature che voglio (personaggi, meccaniche di movimento, sistema di combattimento)
• Secondo passaggio: playtest immediato per identificare cosa rompe l'esperienza
• Terzo passaggio: feedback iterativo a Claude mentre registro nuovi dettagli

Il segreto non è scrivere il prompt perfetto al primo colpo, ma giocare il prima possibile e lasciare che l'esperienza guidi le correzioni. È lo stesso principio che applico quando costruisco automazioni con Make o n8n: prototipare veloce, rompere tutto, aggiustare.

Dal single player al multiplayer: il salto di complessità

Avere un gioco funzionante è un conto. Renderlo multiplayer è tutta un'altra storia. Ho chiesto a Claude di trasformare il prototipo single player in un'esperienza condivisa, introducendo scelta tra fazioni, meccaniche di respawn competitive (stile League of Legends: più il match va avanti, più è frustrante morire), e bilanciamento tra giocatori umani e bot NPC.

Il primo ostacolo? La fisica del movimento. Quando ti agganci a una superficie e vieni proiettato a velocità folle, l'impatto dovrebbe farti male. Non ha senso che un personaggio umano possa schiantarsi contro un muro a 100 km/h senza conseguenze. Ho introdotto un sistema di frenata (tasto G per attivare razzi di rallentamento) che consuma gas ma ti permette di atterrare con grazia.

Secondo problema: la netcode. Per connettere giocatori su reti diverse ho usato un relay Twilio, che permette connessioni peer-to-peer anche quando il NAT sarebbe un incubo. Non è la soluzione più economica su larga scala, ma per un prototipo giocato da 5-10 persone funziona benissimo.

Cosa ho imparato testando il gioco con persone reali

Ho invitato alcuni collaboratori a provare il gioco, uno addirittura collegato da un aereo sopra l'Atlantico. Risultato? Venti minuti di risate, trash talk e scoperta di bug che non avrei mai trovato da solo.

Il feedback più prezioso non viene dalle metriche, ma dall'osservare come giocatori veri reagiscono alle tue meccaniche. Ho scoperto che la sensibilità del mouse doveva essere personalizzabile (chi gioca su trackpad ha un'esperienza completamente diversa), che serviva una kill/death board visibile con Tab, e che le animazioni di attacco dovevano essere più evidenti in prima persona rispetto alla terza.

Dettagli che non avresti mai specificato in un prompt iniziale, ma che emergono solo quando provi il prodotto finito.

Il costo totale dell'esperimento

Alla fine, l'intero progetto (dalla prima versione single player al multiplayer funzionante online) mi è costato 31,44 euro in token Opus 3.5. La maggior parte della spesa (circa 17 euro) è arrivata dalle sessioni iterative rapide, dove correggevo bug e aggiungevo feature in tempo reale.

Un dettaglio interessante: se usi Claude in sessioni concentrate (entro un'ora), benefici di sconti automatici sui token rispetto a sessioni distribuite su giorni diversi. È il tipo di ottimizzazione che impari solo sperimentando.

Trenta euro per passare da zero a un gioco multiplayer giocabile, hostato online, in meno di un giorno. Non è perfetto, non è AAA, ma è funzionante e divertente. E questo è il punto.

Stiamo entrando in un'era in cui il gap tra idea ed esecuzione si sta assottigliando a una velocità spaventosa. Se stai costruendo qualcosa che richiede prototipazione rapida (tool interni, MVP di prodotto, esperienze interattive per clienti), l'approccio iterativo con AI agent come Claude può darti un vantaggio competitivo reale. La differenza la fa sapere quando delegare all'AI e quando sporcarsi le mani per capire cosa funziona davvero.