Scacchi D'Arme

Il campo di battaglia non finisce sulle 64 caselle

Negli ultimi giorni mi sono accorto che una delle parti più difficili del progetto non era più la partita. La partita funzionava. I pezzi funzionavano. Le battaglie funzionavano. L'IA funzionava. Anche la possibilità di cambiare la scacchiera era ormai presente. Il problema era tutto ciò che stava intorno.

Quando si lavora su una scena 3D è facile concentrarsi sugli elementi più evidenti: scacchiera, pezzi, movimenti. Appena però si costruisce un'ambientazione vera, anche il cielo, il terreno, la luce, gli elementi sullo sfondo e le transizioni diventano parte integrante dell'esperienza.

Ho iniziato quindi a lavorare sulla possibilità di cambiare l'ambiente circostante con diversi scenari: mare, erba, deserto e ghiaccio. L'idea era che la personalizzazione del terreno dovesse essere indipendente dal materiale della scacchiera.

Il problema è diventato evidente proprio nelle transizioni. La dissolvenza sembrava funzionare, ma alcuni elementi continuavano a rimanere attivi. Uno sfondo poteva spegnersi correttamente mentre un altro elemento continuava la propria animazione per diversi secondi. In particolare, cielo e componenti luminose potevano restare visibili quando la scena precedente avrebbe dovuto essere già scomparsa.

La cosa interessante è che il problema visibile non si trovava necessariamente nel punto in cui lo guardavo. Non bastava modificare l'effetto grafico: bisognava intervenire sulla gestione dello stato della scena e sul modo in cui i diversi livelli venivano attivati e disattivati.

È un esempio perfetto del motivo per cui sto costruendo il progetto per iterazioni. Una richiesta porta a un risultato, il risultato fa emergere un problema, il problema richiede una soluzione più strutturale e quella soluzione apre una nuova possibilità.

Ci lavoro soprattutto la sera, dopo la giornata di lavoro. A volte penso di sistemare una piccola cosa e mi ritrovo a passare molto più tempo del previsto a capire perché un determinato elemento non voglia comportarsi come dovrebbe. Ma proprio queste serate stanno facendo diventare il progetto più solido.

Cielo, luce e luna

Il cielo è uno degli elementi che all'inizio avevo considerato quasi soltanto decorativo. Con la crescita della scena 3D mi sono invece reso conto che è uno dei componenti che determinano maggiormente la sensazione di trovarsi in un mondo coerente.

La difficoltà è arrivata quando ho iniziato a introdurre ambientazioni diverse e a ragionare anche sulla dimensione temporale della scena. Se cambia l'atmosfera, non deve cambiare soltanto il colore del terreno. Anche il cielo deve seguire il nuovo stato e gli elementi luminosi devono essere coerenti.

E poi c'è la luna. Volevo che la luna fosse un elemento reale della scena notturna, non semplicemente un'immagine appoggiata dietro alla scacchiera. Allo stesso tempo non doveva interferire con gli altri elementi e soprattutto doveva scomparire quando l'ambiente precedente veniva sostituito.

Una prima versione funzionava isolatamente ma mostrava problemi quando veniva combinata con altre parti della scena. In un'altra, la luna rimaneva visibile durante alcune transizioni, mentre il cielo sottostante era già cambiato. In un altro caso il problema sembrava essere la luna ma dipendeva in realtà dal modo in cui veniva gestito lo stato dello sfondo.

È stata una di quelle serate in cui ho imparato che in un ambiente 3D un elemento apparentemente semplice può avere molte dipendenze. La soluzione è arrivata trattando cielo, luna e terreno non più come decorazioni indipendenti ma come parti di un unico stato ambientale.

Ancora una volta il lavoro con Claude è diventato soprattutto un dialogo tecnico: descrivere ciò che vedo, spiegare quando avviene, indicare cosa dovrebbe succedere e chiedere di modificare la logica senza rompere ciò che già funziona.

Il risultato magari non è il tipo di modifica che un visitatore nota immediatamente. Ma è una di quelle che rendono il progetto più credibile quando lo si guarda per diversi minuti.

Tutto si ferma insieme

Il problema delle transizioni viene affrontato in maniera definitiva. Ogni voce e ogni strato dell'ambiente precedente deve ricevere l'ordine di fermarsi esattamente nello stesso istante in cui parte la dissolvenza. La durata scelta è di 0,35 secondi.

Prima alcuni elementi continuavano il proprio ciclo naturale dopo che la scena aveva già iniziato a scomparire. Un elemento poteva restare attivo per diversi secondi perché la sua animazione non aveva ancora raggiunto il termine naturale. Visivamente questo produceva un risultato incoerente: il giocatore percepiva che qualcosa della scena precedente non era stato davvero sostituito.

La soluzione non è stata semplicemente accelerare le singole animazioni. È stato necessario cambiare la logica delle transizioni. Quando parte la dissolvenza, tutto ciò che appartiene all'ambiente precedente riceve lo stesso ordine di arresto.

Nessun layer decide più autonomamente di continuare. Nessun effetto rimane attivo perché il suo timer interno non è ancora terminato.

È una correzione quasi invisibile per chi gioca, ma estremamente importante per la qualità della scena. Un sistema ben funzionante non deve soltanto avere molte funzioni: deve avere un comportamento coerente quando queste funzioni vengono usate insieme.

Dopo la modifica rifaccio i collaudi generali. Cambio ambiente, torno indietro, provo più combinazioni e verifico che la correzione non introduca regressioni. Il risultato è quello cercato: il cambio diventa netto e prevedibile.

È anche un ottimo esempio di come le serate di sviluppo non siano sempre dedicate a “creare qualcosa di nuovo”. Alcune sono dedicate semplicemente a fare in modo che ciò che esiste già si comporti bene.

Mare, erba, deserto e ghiaccio

Una volta stabilizzata la personalizzazione della scacchiera, è naturale spostare l'attenzione sul terreno che la circonda.

La richiesta è quella di poter scegliere ambientazioni differenti: mare, erba, deserto e ghiaccio. Non voglio però che siano semplici texture alternative. L'idea è che ogni ambiente abbia una propria atmosfera.

Il mare dovrebbe dare un senso di apertura e movimento. L'erba richiama un campo di battaglia medievale. Il deserto porta verso un'atmosfera più arida e ostile. Il ghiaccio introduce invece una scena fredda e quasi irreale.

La parte interessante è la separazione fra i due livelli di personalizzazione. La scacchiera può essere di pietra, marmo, legno, onice e oro oppure cristallo. Il terreno è un livello separato.

Questo significa che non devo scegliere fra “scacchiera di marmo” o “mondo ghiacciato” come due preset chiusi. Posso costruire una combinazione.

Questa distinzione diventa importante anche dal punto di vista tecnico. Il motore di scacchi non deve sapere dove si trova. I pezzi devono continuare a funzionare allo stesso modo. L'ambiente è un livello di rappresentazione e non deve influenzare la logica della partita.

Ancora una volta la sera diventa il momento in cui provo, guardo il risultato, noto che un elemento non si integra bene con gli altri e torno da Claude con una nuova richiesta.

Ogni nuova possibilità porta quindi anche una nuova complessità. Ma il progetto è arrivato a un punto in cui vale la pena affrontarla.

Dal prototipo al gioco completo

Dopo molte iterazioni arriva una delle serate più soddisfacenti dell'intero progetto. La versione 3D non è più soltanto una dimostrazione di pezzi animati. È diventata una partita di scacchi completa.

Con il re ormai integrato, posso verificare in simulazione una serie di condizioni che devono funzionare insieme: scacco, scacco matto, stallo, arrocco corto e lungo, presa en passant, promozione e il duello del re.

Non mi limito inoltre a testare singole situazioni. Lascio giocare partite intere all'IA e controllo che il sistema riesca a rimanere coerente durante sequenze più lunghe.

Questa differenza è importante. Una cosa è verificare che una singola regola sia corretta. Un'altra è vedere quella regola interagire con tutte le altre durante una partita.

In questa fase i test risultano positivi e non vengono rilevati errori nelle casistiche che ho provato.

Rimane una distinzione che voglio mantenere chiara: i test del motore e delle regole possono essere simulati in modo sistematico, mentre il rendering finale deve essere giudicato in un browser reale. In altre parole, una verifica tecnica non sostituisce una verifica estetica e di usabilità.

È una distinzione che considero importante anche per il modo in cui racconto questo progetto. Non voglio presentare un risultato come perfetto soltanto perché un simulatore non ha evidenziato errori.

La serata termina con una sensazione particolare: Scacchi D'Arme ormai è davvero giocabile.

Suoni, animazioni e controllo dell'esperienza

Fino a questo momento gran parte dell'attenzione è stata concentrata sulla parte visiva. A un certo punto però diventa evidente che un gioco di battaglie non può vivere soltanto di immagini.

Vengono quindi integrati musica ed effetti sonori. I suoni sono sintetizzati e volutamente semplici, ma hanno uno scopo preciso: fornire feedback.

Una cattura deve avere una componente sonora. Una battaglia deve poter essere percepita. Un effetto magico deve avere un suono. Il duello del re deve sembrare diverso dalla cattura del soldato.

La funzione viene inserita nelle Opzioni, ma con una scelta precisa: i suoni sono spenti di default. Chi desidera un'esperienza più immersiva può attivarli.

La stessa logica viene applicata alle animazioni. È possibile disattivarle completamente oppure saltare una singola battaglia toccando la scacchiera.

Questa possibilità nasce dalle prove reali. Una prima volta voglio vedere il combattimento. Dopo molte partite, invece, posso preferire un'esperienza più rapida.

È un passaggio importante perché il progetto smette di imporre una sola modalità di utilizzo. Inizia a offrire al giocatore un certo livello di controllo.

La musica e i suoni non sono quindi un'aggiunta puramente estetica. Sono parte dell'interfaccia. Servono a comunicare ciò che sta succedendo e a rendere più naturale il passaggio fra una mossa e l'altra.

Ancora una volta, il lavoro della sera consiste soprattutto nel trovare il punto giusto fra spettacolo e ritmo. Le battaglie devono essere presenti, ma non devono prendere il controllo della partita.

Recluta, Cavaliere e Maestro

L'avversario artificiale viene raffinato e portato dentro la versione più completa del progetto. Il motore già sperimentato nella precedente versione 2D diventa il cuore della modalità contro il computer.

Vengono mantenuti tre livelli: Recluta, Cavaliere e Maestro.

Il livello avanzato utilizza più tempo per elaborare la mossa e in questa fase impiega circa un secondo e mezzo. Non è ancora il limite definitivo che immagino per il progetto, ma è sufficiente per dare al livello Maestro un carattere diverso.

Il motore deve inoltre evitare di entrare inutilmente in ripetizioni quando è in vantaggio. Il rischio sarebbe quello di avere una posizione favorevole che finisce in una patta semplicemente perché il computer continua a ripetere la stessa sequenza.

Le prove non vengono più fatte soltanto sulle singole funzioni. Inizio a lasciare giocare partite intere all'IA.

Questo cambia molto il tipo di test. In una partita completa una regola può interagire con un'altra dopo decine di mosse. L'IA può arrivare a una promozione, effettuare una cattura, entrare in una posizione di scacco o gestire un arrocco.

Quando qualcosa non mi convince, torno da Claude con una descrizione precisa. Cerco di spiegare la situazione, la sequenza che l'ha preceduta e il comportamento atteso.

Il VibeCoding diventa così un ciclo continuo di idea, implementazione, partita, osservazione, correzione e nuova partita.

È una delle fasi in cui capisco meglio che usare un modello per costruire un progetto non significa semplicemente chiedere codice. Significa soprattutto saper descrivere un problema e guidare iterazioni successive.

Gli scacchi prima dello spettacolo

Arriva il momento di eliminare definitivamente alcune semplificazioni delle prime versioni. Scacchi D'Arme sta diventando un gioco abbastanza complesso da non poter più usare condizioni provvisorie per la vittoria.

Non si vince più perché un pedone arriva in fondo alla scacchiera e non si vince semplicemente eliminando tutti i pezzi. La partita deve terminare con lo scacco matto.

Vengono consolidate le principali regole: scacco, scacco matto, stallo, arrocco corto, arrocco lungo, presa en passant, promozione, ripetizione della posizione, regola delle 50 mosse e materiale insufficiente.

Il re sotto scacco riceve una rappresentazione visiva dedicata: un anello rosso lampeggiante sulla casa.

La promozione viene resa esplicita attraverso un selettore che permette di scegliere regina, torre, alfiere o cavaliere. Il pedone si trasforma attraverso una nuvola dorata; quando gioca l'IA, la scelta viene effettuata automaticamente.

È un passaggio decisivo perché il progetto cambia natura. Prima stavamo costruendo un gioco fantasy che utilizzava gli scacchi come base. Da questo momento in poi stiamo costruendo una vera partita di scacchi alla quale ho aggiunto una rappresentazione scenografica delle catture.

Per me questa distinzione è fondamentale. Le animazioni possono cambiare. I personaggi possono essere ridisegnati. L'ambiente può essere sostituito. Ma la partita deve restare coerente.

La regola che accompagna tutto il progetto diventa quindi molto semplice: prima il gioco, poi lo spettacolo.

È soprattutto nelle ore serali che questa parte viene verificata. Una nuova funzione viene provata, poi provo a romperla attraverso altre situazioni e infine verifico che le correzioni non abbiano introdotto regressioni.

Dalla partita alla scena

Dopo aver costruito la base 2D, chiedo di portare il progetto nella terza dimensione. La richiesta è volutamente semplice: la scacchiera deve diventare un luogo.

La prima versione utilizza la pietra. Compare una cornice, compare un bordo, agli angoli vengono inseriti i bracieri e i pezzi acquistano profondità.

La differenza è immediata. La scacchiera non è più soltanto lo spazio logico nel quale avvengono le mosse. È diventata una scena.

Entrano quindi in gioco telecamera, illuminazione, ombre, materiali e prospettiva.

Una luce troppo forte appiattisce i modelli. Una troppo debole nasconde i dettagli. Una telecamera troppo vicina rende i pezzi enormi; una troppo lontana toglie impatto alle battaglie.

La versione 3D diventa quindi più di un semplice cambio estetico. Diventa una nuova fase dello sviluppo.

Per continuare a lavorare rapidamente, mantengo la separazione tra motore e rendering. Il motore continua a ragionare in termini di caselle, pezzi, mosse e stato. La scena 3D legge quello stato e lo rappresenta.

È una decisione che si rivelerà fondamentale più avanti, quando nascerà la possibilità di tornare alla visualizzazione 2D senza perdere la partita.

Queste sono serate molto visive. C'è meno lavoro astratto e molto più tempo passato a guardare ciò che succede sullo schermo, provando ad avvicinarmi all'immagine che avevo in mente.

Scacchi D'Arme comincia in questo momento a sembrare davvero un mondo.

Una sola pagina, una vera partita

Il primo obiettivo concreto è creare una app HTML singola che possa essere aperta direttamente nel browser e nella quale due giocatori possano affrontarsi in una vera partita di scacchi.

La prima versione viene costruita prima di tutto attorno alla logica: movimento dei pezzi, turni, catture e gestione dello stato.

Poi arrivano le regole speciali: arrocco, en passant, promozione, scacco matto e stallo.

Viene aggiunta la patta e successivamente la possibilità di annullare la mossa. In parallelo viene costruita la modalità a due giocatori.

Il motore viene sottoposto anche a test standard di scacchi e a simulazioni specifiche. È il fondamento sul quale tutto il resto dovrà poggiare.

Questa impostazione è importante perché non voglio costruire prima una grafica spettacolare e poi provare a farci entrare dentro una partita. Preferisco l'ordine inverso.

La logica deve sapere cosa succede. Solo dopo potremo decidere come rappresentarlo.

È anche il momento in cui viene definita la direzione dell'IA: un avversario con diversi livelli di difficoltà basato su una ricerca delle mosse, in modo da poter giocare sia in solitaria sia in modalità a due giocatori.

La prima versione è ancora lontanissima dall'immagine finale, ma ha una caratteristica fondamentale: si può giocare.

È una delle serate in cui mi rendo conto che un progetto che all'inizio sembrava enorme può essere spezzato in problemi piccoli. Una sera le regole. Poi una funzione. Poi un test. Poi un'altra funzione.

È così che il progetto comincia realmente a crescere.

Una cattura diventa un evento

Una volta costruita una partita funzionante, arriva la domanda che rappresenta il cuore del progetto: cosa succede quando un pezzo prende un altro pezzo?

La risposta è l'idea alla base di Scacchi D'Arme. Il pezzo attaccante raggiunge la casa del difensore, parte una breve scena di combattimento e soltanto al termine il pezzo catturato viene eliminato.

L'ispirazione concettuale è chiaramente Battle Chess, ma la scelta è fin dall'inizio quella di non riprodurre le animazioni originali del 1988. Voglio personaggi e sequenze nuovi.

La prima serie viene progettata in SVG, mantenendo personaggi stilizzati ma riconoscibili. Il soldato usa la lancia. Il cavaliere carica. Il mago utilizza un attacco a distanza. La torre colpisce fisicamente. La regina utilizza la magia. Il re combatte con la spada.

Questa prima impostazione è già sufficiente per cambiare la percezione del progetto. Una cattura non è più semplicemente un aggiornamento della scacchiera. È un piccolo evento.

La necessità di costruire ogni pezzo con una propria identità porta però a una scelta metodologica importante: non chiedere tutto contemporaneamente.

Meglio costruire un pezzo, provarlo, correggerlo, definire la sua battaglia e poi passare al successivo.

Ogni nuovo combattente diventa così anche un test della meccanica generale di cattura.

È in questa fase che Scacchi D'Arme smette definitivamente di essere una semplice implementazione di scacchi e comincia ad avere un linguaggio proprio.

Un pezzo alla volta

La costruzione vera e propria dei personaggi parte dal pedone. È il pezzo più semplice e proprio per questo è il candidato ideale per costruire il primo sistema di battaglia.

Nasce come un soldato fantasy medievale con lancia e scudo. La richiesta non è soltanto estetica: il personaggio deve poter stare sulla casella, muoversi, catturare e partecipare a una sequenza coerente.

Il soldato affonda la lancia due volte. È una scena breve e leggibile, pensata per stabilire anche i tempi generali delle battaglie.

Quando il primo combattimento funziona, la percezione del progetto cambia. Non sto più guardando una pedina che si sposta. Sto guardando un personaggio.

Da questo momento in poi ogni pezzo viene costruito con lo stesso approccio: identità visiva, movimento, battaglia, integrazione e test.

Questa metodologia si adatta perfettamente al tempo che posso dedicare al progetto. Non ho bisogno di risolvere tutto in una volta. Posso lavorare su una singola cosa nelle ore serali e verificare il risultato prima di passare alla successiva.

È anche il motivo per cui il progetto viene raccontato come un diario. La crescita non è avvenuta per blocchi giganteschi già pianificati. È avvenuta per piccoli passi.

Una sera il soldato.

Un'altra la torre.

Poi il cavaliere, l'alfiere, la regina e infine il re.

Scacchi D'Arme cresce letteralmente pezzo dopo pezzo.

Il pedone è quindi più importante di quanto possa sembrare. Non è soltanto il primo personaggio. È la prima dimostrazione che le idee visive possono essere trasformate in comportamenti interattivi attraverso il processo di VibeCoding.

Si può reinterpretare oggi quell'idea?

Scacchi D'Arme nasce da un ricordo molto preciso. Battle Chess è uno di quei giochi che rimangono impressi perché prendono qualcosa di astratto e lo trasformano in spettacolo.

Negli scacchi una cattura normalmente è soltanto un cambio di posizione. In Battle Chess diventa un combattimento. È proprio questa idea che voglio esplorare.

La domanda però non è come copiare quel gioco. È se sia possibile reinterpretare oggi quella sensazione, con strumenti moderni e con una propria identità.

Le animazioni originali del 1988 sono materiale proprietario e non devono essere riprodotte. La direzione diventa quindi quella di creare personaggi fantasy medievali originali e battaglie nuove.

La prima ipotesi è una piccola applicazione HTML singola, apribile nel browser.

Il piano iniziale è molto più semplice di quello che finirò per costruire: prima la scacchiera e le regole, poi l'IA, poi le animazioni di cattura.

Non immagino ancora che nelle settimane successive arriveranno una versione 3D completa, una vista 2D, cinque materiali per la scacchiera, quattro ambientazioni, cielo, luna, musica, effetti sonori, IA multilivello e un sistema di transizioni.

Il progetto nasce attraverso VibeCoding con Claude. Io porto l'idea, definisco ciò che voglio ottenere, descrivo il comportamento, provo il risultato, osservo ciò che non mi convince e torno con una nuova richiesta.

Non c'è una singola richiesta iniziale capace di prevedere tutto quello che verrà dopo.

C'è un ciclo continuo: idea, implementazione, prova, correzione, nuova idea.

Ed è proprio questo che oggi considero la parte più interessante del progetto. Non il fatto che esista un gioco di scacchi con battaglie, ma il fatto che sia cresciuto una funzione alla volta, un pezzo alla volta, una prova alla volta.

Inizio a lavorarci nelle ore serali, dopo il lavoro, senza sapere esattamente dove porterà la prima versione.

La sera del 10 luglio non esiste ancora Scacchi D'Arme. Esiste soltanto l'idea di provare a costruirlo.