I giochi nativi del browser fanno sul serio: cosa rivelano i progetti di combattimento open source

Ho iniziato questa ricerca aspettandomi di trovare una manciata di interessanti esperimenti di combattimento nel browser. Invece ho trovato un ecosistema molto più ampio: veri prototipi d’azione in terza persona con lock-on, alberi di combo ramificati, parate perfette, invulnerabilità durante la schivata, sistemi di postura, attacchi aerei, segnali anticipatori degli attacchi dei boss, motion warping, hit-stop, scontri fisici tra armi, supporto ai gamepad, controlli touch e simulazione deterministica.

Questo è il risultato importante. Non si tratta più soltanto di piccoli giochi che per caso vengono renderizzati dentro una pagina web. Alcuni affrontano gli stessi problemi di ingegneria dei giochi d’azione tradizionali, ma vengono distribuiti tramite un URL e possono essere giocati immediatamente.

Per me, come sviluppatore web, è questa la parte affascinante. Il vecchio modo di concepire i giochi era dominato da installer, download pesanti, patcher, launcher e dal ritardo tra la scoperta di un gioco e il momento in cui si poteva davvero provarlo. Il browser comprime drasticamente questo percorso: apri un link, carichi gli asset e inizi a giocare.

Questa ricerca si è concentrata su progetti con una build giocabile nel browser e codice sorgente pubblico. Ho escluso intenzionalmente gli export Unity WebGL perché volevo studiare giochi costruiti attorno alle tecnologie web, non giochi semplicemente esportati sul web.

I progetti più solidi che ho trovato

Le scoperte più utili non erano tutte valide per lo stesso motivo. Alcune avevano i sistemi di combo più profondi. Altre offrivano una migliore architettura in terza persona, una simulazione del combattimento più pulita o colpi fisici più convincenti.

Perché i risultati mi hanno sorpreso

La cosa sorprendente non era semplicemente che la grafica fosse bella. Renderizzare una scena rifinita è solo una parte dello sviluppo di un gioco. I progetti che spiccavano implementavano sistemi difficili da simulare in modo convincente: buffering degli input, transizioni di stato del combattimento, selezione del bersaglio, movimento durante gli attacchi, timing delle animazioni, rilevamento dei colpi, reazioni dei nemici, finestre difensive, comportamento della telecamera e feedback dell’impatto.

Da qui emerge una distinzione utile:

• il timing dell’animazione non è il timing del combattimento;
• il frame rate di rendering non è la frequenza di simulazione;
• una collisione non è automaticamente un colpo valido;
• l’animazione non ha necessariamente l’autorità sul movimento;
• il contatto visivo non equivale all’impatto percepito.

Queste distinzioni ricorrevano continuamente nei progetti più solidi e sono più importanti del logo del motore di rendering nel README.

Voxel Musou: il combattimento nel browser può avere una vera grammatica delle mosse

Voxel Musou è stato uno degli esempi più chiari del fatto che il combattimento nel browser non debba più significare una sola animazione d’attacco associata a un solo pulsante. Il codice sorgente è disponibile su mike007jd/voxel-musou.

Il progetto usa lunghe catene di attacchi normali e diramazioni con attacchi caricati invece di una combo puramente lineare. Questo è importante a livello architetturale, perché il sistema può essere modellato così:

current move + buffered input + combat state -> next move

È una base molto migliore per un gioco d’azione incentrato sul personaggio rispetto a una raccolta sempre più ampia di condizioni per casi speciali. Mostra inoltre attacchi aerei, sequenze speciali, diversi kit di personaggi, comportamenti dei boss, hit-stop e combattimenti contro grandi gruppi di nemici.

La lezione ingegneristica più generale è che le mosse dovrebbero diventare dati e le transizioni dovrebbero diventare esplicite. Quando questo avviene, aggiungere un altro personaggio non richiede più di riscrivere l’intero controller del combattimento.

Long Wind: il riferimento più vicino a un moderno gioco d’azione nel browser

Long Wind è stato uno dei riferimenti più completi perché combina movimento in terza persona con attacchi leggeri e pesanti, lock-on, guardia, parata perfetta, invulnerabilità durante la schivata, pressione sulla postura, esecuzioni, reazioni di lancio e atterramento, proiettili, boss e diversi archetipi di nemici. Il codice sorgente è disponibile su jbang2004/long-wind.

È prezioso non perché ogni singola funzionalità sia senza precedenti, ma perché tutte convivono in un unico prototipo d’azione nativo del browser. Questo lo rende un riferimento utile per seguire l’intero percorso dall’input alla selezione del bersaglio, allo stato d’attacco, all’animazione, al contatto, alla reazione, all’hit-stop e al feedback della telecamera.

Il motion warping risolve un problema che le demo web spesso ignorano

Samurai Third-Person Template ThreeJS è particolarmente interessante perché affronta un classico problema del combattimento corpo a corpo in terza persona. Il codice sorgente è disponibile su achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Un’animazione d’attacco creata in anticipo presuppone che il bersaglio si trovi a una determinata distanza quando il colpo raggiunge il frame di contatto. In un gioco reale, il bersaglio non è quasi mai posizionato perfettamente. Se il personaggio riproduce semplicemente l’animazione sul posto, la spada può mancare visibilmente il bersaglio anche se il gioco applica il danno. Se invece il personaggio si teletrasporta nella posizione corretta, l’attacco appare artificiale.

Il motion warping offre una risposta migliore: regolare rotazione e traslazione durante l’attacco in modo che il personaggio raggiunga la posizione di contatto prevista nel momento giusto.

La distinzione importante è:

animation intent != movement authority

Un personaggio può preservare l’intento visivo di un’animazione creata in anticipo mentre il controller di gameplay mantiene l’autorità su dove il personaggio si sposta realmente.

Il rilevamento delle collisioni e la validazione dei colpi sono problemi diversi

Stick & Steel esplora un modello di combattimento molto diverso. Il codice sorgente è disponibile su Rabneba/stick-steel.

Invece di trattare la spada principalmente come un’animazione con un volume di danno, il progetto conferisce alle armi una presenza fisica. Contano la velocità al contatto, l’orientamento dell’arma, la zona del corpo, le guardie, gli scontri, gli atterramenti e i disarmi.

La lezione più trasferibile non è che ogni gioco d’azione dovrebbe usare armi completamente fisiche. È questa:

Una collisione ti dice che due cose si sono toccate. Non ti dice se si è verificato un colpo significativo.

Un sistema di combattimento convincente spesso ha bisogno di un secondo livello che decida se il contatto aveva velocità sufficiente, la direzione corretta, la regione corretta dell’arma, il timing giusto e uno stato valido del bersaglio per poter contare come danno.

Una risoluzione centralizzata del combattimento rende più comprensibile una difesa complessa

Hollowmere, con codice sorgente su euuuuuuan/hollowmere-public, si è distinto meno per lo spettacolo visivo e più per l’architettura software.

La simulazione del combattimento è separata dal rendering e la risoluzione difensiva è centralizzata. Questo evita un problema comune nei giochi d’azione, in cui il sistema di schivata, quello di parata, quello di reazione ai colpi e il livello di animazione possono essere in disaccordo indipendentemente sul fatto che lo stesso attacco abbia colpito o meno.

Un modello mentale più pulito è:

incoming attack -> evade | parry | hit

Il renderer dovrebbe mostrare il risultato, non inventare una seconda versione della verità del combattimento.

Questa distinzione diventa sempre più importante con l’aumentare della complessità del combattimento. La simulazione deterministica e le transizioni di stato esplicite non sono funzionalità appariscenti, ma rendono più facile testare, fare debug ed estendere un sistema di combattimento complesso.

Il game feel è un sistema ingegneristico, non una decorazione

Fabled Revolutions, con codice sorgente su ericrius1/FabledRevolutions, è utile proprio perché isola gli effetti che fanno percepire i colpi come sostanziosi.

Un sistema di combattimento logicamente corretto può comunque risultare debole. La collisione può essere precisa, il danno può essere applicato nel frame corretto e il risultato può ancora sembrare quello di due modelli che si attraversano.

L’impatto percepito deriva spesso da una combinazione di effetti di breve durata:

• hit-stop;
• scuotimento o contraccolpo della telecamera;
• scie delle armi;
• particelle d’impatto;
• lampeggio di danno;
• knockback;
• reazione dell’animazione;
• suono ben sincronizzato.

Questo suggerisce un’altra distinzione utile: la correttezza del combattimento non è il suo game feel. Un gioco nel browser ha bisogno di entrambi.

Il motore di rendering non era il principale indicatore della qualità del combattimento

Uno degli schemi più interessanti emersi dalla ricerca è che la qualità del combattimento migliore non dipendeva dal fatto che un progetto usasse o meno l’API di rendering più recente.

Three.js ricorreva spesso. Alcuni progetti usavano tecnologie di rendering legate a WebGPU, altri stack convenzionali basati su WebGL. Motori fisici, TypeScript, JavaScript, Vite, WebAssembly e diversi approcci al rendering comparivano tutti nella ricerca.

Il combattimento sofisticato dipendeva invece più costantemente dall’architettura: simulazione a passo fisso, stati espliciti, targeting affidabile, gestione sensata dell’autorità delle animazioni, mosse guidate dai dati, risoluzione centralizzata dei danni e buon feedback dell’impatto.

È un dato incoraggiante per gli sviluppatori web. Non serve aspettare che ogni utente disponga dello stack grafico più recente prima di sperimentare seriamente con il design del combattimento.

Perché la distribuzione tramite browser cambia l’equazione

Il browser ha un vantaggio che ha poco a che fare con la grafica: un attrito di distribuzione estremamente basso.

I giochi tradizionali spesso inseriscono diversi passaggi tra la scoperta e l’interazione: trovare la pagina sullo store, scaricare un pacchetto di grandi dimensioni, installarlo, avviarlo, attendere gli aggiornamenti e talvolta creare un account prima di arrivare a una parte significativa del gameplay.

Un gioco nel browser può ridurre questo percorso a un link.

Questo cambia il modo in cui i prototipi possono essere condivisi e testati. Uno sviluppatore può pubblicare una build, inviare un URL, far provare immediatamente a un’altra persona la stessa versione, raccogliere feedback e distribuire un’altra iterazione senza chiedere al tester di installare manualmente un nuovo pacchetto.

Questo vantaggio diventa particolarmente importante per i giochi sperimentali e lo sviluppo indipendente. Il browser non è soltanto un runtime; è anche un sistema di distribuzione.

Dove il browser è ancora svantaggiato

La ricerca non mi ha convinto che i browser abbiano sostituito le piattaforme di gioco native. Non è così.

Restano importanti diversi vincoli:

• Asset di grandi dimensioni. L’accesso istantaneo smette di sembrare istantaneo quando un gioco richiede un download iniziale molto pesante.
• Pressione sulla memoria. I browser devono convivere con altre schede e con il sistema operativo, e il comportamento della memoria è meno prevedibile rispetto a un processo nativo dedicato.
• Limiti termici sui dispositivi mobili. Un gioco 3D tecnicamente funzionante può comunque subire un forte throttling durante una sessione più lunga.
• Differenze tra browser. Grafica, audio, pointer lock, comportamento a schermo intero, controller e caratteristiche prestazionali non sono perfettamente uniformi.
• Preparazione di shader e asset. La compilazione o il caricamento possono ancora provocare stalli visibili se la pipeline non è progettata con attenzione.
• Vincoli offline e di persistenza locale. Le applicazioni native mantengono un controllo più diretto su installazioni locali di grandi dimensioni e file.
• Sicurezza competitiva. Un anti-cheat serio e la necessità di assumere che il client sia ostile diventano molto più difficili quando il client è un’applicazione web.

Questi limiti contano perché definiscono dove oggi i giochi nel browser sono più forti: nei giochi che traggono vantaggio dall’accesso immediato, dall’iterazione rapida, dalla distribuzione multipiattaforma e da budget gestibili per asset e runtime.

L’IA accorcia molto il ciclo dal prototipo all’URL

L’IA è rilevante qui, ma non perché trasformi magicamente una frase in un gioco finito di alta qualità. Il vantaggio più realistico è la velocità di iterazione.

Lo sviluppo moderno di giochi comprende molte piccole attività che nel complesso sono costose: impostare macchine a stati, costruire viste di debug, scrivere test, sperimentare con i comportamenti dei nemici, creare formati dati per le mosse, rifattorizzare il codice di input, prototipare shader, esaminare bug di fisica e integrare contenuti provvisori.

L’IA può accorciare molti di questi cicli. Insieme alla distribuzione web, il flusso di lavoro diventa insolitamente diretto:

idea -> prototype -> deploy -> open URL -> test -> iterate

Il browser rende già rapido il deployment. L’IA può rendere più veloce anche il lato implementativo dello stesso ciclo.

L’avvertenza importante è che la generazione rapida non sostituisce il giudizio né la validazione. Un controller di combattimento generato può essere strutturalmente sbagliato. Il timing delle animazioni richiede ancora giudizio umano. La fisica deve ancora essere sottoposta a debug. Le prestazioni devono ancora essere misurate. L’IA riduce il costo di provare idee; non elimina la necessità di decidere quali siano valide.

Cosa significa per gli sviluppatori web

Il confine tra sviluppo web e sviluppo di giochi sta diventando meno rigido.

Un gioco serio nel browser può oggi usare strumenti web familiari pur richiedendo concetti classici di ingegneria dei videogiochi:

• passi di simulazione fissi;
• macchine a stati;
• buffering degli input;
• grafi di animazione;
• query spaziali;
• fisica;
• budget per frame;
• gestione delle risorse GPU;
• timing audio;
• sistemi deterministici.

Allo stesso tempo, gli sviluppatori di giochi che puntano al browser ottengono aspetti in cui il web è già eccezionalmente efficace: URL, deployment immediato, distribuzione tramite CDN, aggiornamenti rapidi, telemetria, sistemi di account, interfacce responsive e condivisione senza attriti.

La ricerca ha cambiato il mio modo di vedere la questione. Non considero più i giochi nel browser principalmente come versioni semplificate dei giochi nativi. Vedo il browser come una piattaforma di gioco sempre più capace, con un diverso insieme di punti di forza: distribuzione immediata, iterazione rapida, capacità 3D sempre più avanzate e un enorme ecosistema di sviluppo già esistente.

Il web non sta semplicemente diventando più bravo a mostrare giochi costruiti altrove. Sta diventando sempre più un luogo in cui sistemi di gioco seri possono essere progettati, implementati, testati, distribuiti e giocati direttamente.