Browser-native games worden serieus: wat open-source gevechtsprojecten laten zien

Ik begon dit onderzoek in de verwachting dat ik een handvol interessante experimenten met gevechten in de browser zou vinden. In plaats daarvan vond ik een veel breder ecosysteem: echte derdepersoons-actieprototypes met lock-on-doelkeuze, vertakkende combobomen, perfecte parries, onkwetsbaarheid tijdens ontwijken, houdingssystemen, luchtaanvallen, aanvalssignalen van bazen, motion warping, hit-stop, fysieke botsingen tussen wapens, gamepadondersteuning, aanraakbediening en deterministische simulatie.

Dat is de belangrijkste uitkomst. Dit zijn niet langer alleen kleine games die toevallig in een webpagina worden gerenderd. Sommige lossen dezelfde technische problemen op als conventionele actiegames, maar worden via een URL verspreid en zijn meteen speelbaar.

Voor mij als webontwikkelaar is juist dat het fascinerende deel. Het oude beeld van games werd gedomineerd door installatieprogramma's, grote downloads, patchers, launchers en de vertraging tussen het ontdekken van een game en die daadwerkelijk kunnen spelen. De browser verkort dat traject drastisch: open een link, laad de assets en begin te spelen.

Dit onderzoek richtte zich op projecten met een speelbare browserversie en openbare broncode. Unity WebGL-exports zijn bewust uitgesloten, omdat ik games wilde bestuderen die rond webtechnologieën zijn gebouwd, niet games die alleen naar het web zijn geëxporteerd.

De sterkste projecten die ik vond

De nuttigste vondsten waren niet allemaal om dezelfde reden sterk. Sommige hadden de diepste combosystemen. Andere boden een betere derdepersoonsarchitectuur, een schonere gevechtssimulatie of overtuigender fysieke treffers.

Waarom de resultaten me verrasten

Het verrassende was niet simpelweg dat de graphics er goed uitzagen. Een verzorgde scène renderen is maar één onderdeel van gameontwikkeling. De projecten die eruit sprongen, implementeerden systemen die moeilijk overtuigend zijn na te bootsen: invoerbuffering, overgangen tussen gevechtstoestanden, doelkeuze, beweging tijdens aanvallen, animatietiming, trefferdetectie, reacties van vijanden, verdedigingsvensters, cameragedrag en impactfeedback.

Dat levert een nuttig onderscheid op:

• animatietiming is niet hetzelfde als gevechtstiming;
• de renderframerate is niet hetzelfde als de simulatiesnelheid;
• een botsing is niet automatisch een geldige treffer;
• de animatie hoeft de beweging niet per se te bepalen;
• visueel contact is niet hetzelfde als ervaren impact.

Die verschillen kwamen bij de sterkste projecten steeds opnieuw terug en zijn belangrijker dan het logo van de renderer in de README.

Voxel Musou: browsergevechten kunnen een echte move-grammatica hebben

Voxel Musou was een van de duidelijkste voorbeelden dat gevechten in de browser niet meer hoeven neer te komen op één aanvalsanimatie die aan één knop is gekoppeld. De broncode staat op mike007jd/voxel-musou.

Het project gebruikt lange ketens van normale aanvallen en vertakkingen voor opgeladen aanvallen in plaats van een puur lineaire combo. Architectonisch is dat belangrijk, omdat het systeem als volgt kan worden gemodelleerd:

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

Dit is voor een character-actiongame een veel betere basis dan een steeds groter wordende verzameling uitzonderingsvoorwaarden. Het demonstreert ook luchtaanvallen, speciale reeksen, meerdere personagekits, baasgedrag, hit-stop en gevechten tegen grote groepen vijanden.

De bredere technische les is dat moves data moeten worden en overgangen expliciet moeten zijn. Zodra dat zo is, hoeft voor een extra personage niet meer de volledige gevechtscontroller te worden herschreven.

Long Wind: het dichtst bij een moderne browser-actiegame

Long Wind was een van de sterkste alles-in-één-referenties, omdat het derdepersoonsbeweging combineert met lichte en zware aanvallen, lock-on, blokkeren, perfecte parry, onkwetsbaarheid tijdens ontwijken, houdingsdruk, executies, reacties op lanceren en neerslaan, projectielen, bazen en meerdere typen vijanden. De broncode staat op jbang2004/long-wind.

Het is niet waardevol omdat elke afzonderlijke functie ongekend is, maar omdat de functies samenkomen in één actieprototype dat native in de browser draait. Daardoor is het een nuttige referentie om het hele traject te volgen van invoer naar doelkeuze, aanvalstoestand, animatie, contact, reactie, hit-stop en camerafeedback.

Motion warping lost een probleem op dat webdemo's vaak negeren

Samurai Third-Person Template ThreeJS is vooral interessant omdat het een klassiek probleem bij derdepersoonsgevechten van dichtbij aanpakt. De broncode staat op achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Een vooraf gemaakte aanvalsanimatie gaat ervan uit dat het doelwit zich op een bepaalde afstand bevindt wanneer de slag het contactframe bereikt. In een echte game staat het doelwit bijna nooit perfect. Als het personage de animatie simpelweg op zijn plaats afspeelt, kan het zwaard zichtbaar missen terwijl de game toch schade toepast. Als het personage naar de juiste positie teleporteert, oogt de aanval kunstmatig.

Motion warping biedt een beter antwoord: pas de rotatie en translatie tijdens de aanval zo aan dat het personage op het juiste moment de verwachte contactpositie bereikt.

Het belangrijke onderscheid is:

animation intent != movement authority

Een personage kan de visuele bedoeling van een vooraf gemaakte animatie behouden, terwijl de gameplaycontroller de uiteindelijke zeggenschap houdt over waar het personage daadwerkelijk naartoe gaat.

Botsingsdetectie en treffervalidatie zijn verschillende problemen

Stick & Steel verkent een heel ander gevechtsmodel. De broncode staat op Rabneba/stick-steel.

In plaats van het zwaard vooral te behandelen als een animatie met een schadevolume, geeft het project wapens een fysieke aanwezigheid. Contactsnelheid, wapenoriëntatie, lichaamszone, blokkeringen, clashes, knockdowns en ontwapenen spelen allemaal een rol.

De meest overdraagbare les is niet dat elke actiegame volledig fysieke wapens zou moeten gebruiken. Het is deze:

Een botsing vertelt je dat twee dingen elkaar hebben geraakt. Het vertelt je niet of er een betekenisvolle treffer plaatsvond.

Een overtuigend gevechtssysteem heeft vaak een tweede laag nodig die bepaalt of het contact genoeg snelheid had, uit de juiste richting kwam, het juiste deel van het wapen betrof, op het juiste moment plaatsvond en een geldige toestand van het doelwit trof om als schade te tellen.

Centrale gevechtsafhandeling maakt complexe verdediging makkelijker te doorgronden

Hollowmere, met broncode op euuuuuuan/hollowmere-public, viel minder op door visueel spektakel en meer door de softwarearchitectuur.

De gevechtssimulatie staat los van de rendering en de afhandeling van verdediging is gecentraliseerd. Dat voorkomt een veelvoorkomend probleem in actiegames waarbij het ontwijksysteem, parrysysteem, trefferreactiesysteem en de animatielaag onafhankelijk van elkaar van mening kunnen verschillen over de vraag of dezelfde aanval raak was.

Een helderder mentaal model is:

incoming attack -> evade | parry | hit

De renderer hoort het resultaat weer te geven, niet een tweede versie van de gevechtswerkelijkheid te verzinnen.

Dit onderscheid wordt steeds belangrijker naarmate gevechten complexer worden. Deterministische simulatie en expliciete toestandsovergangen zijn geen spectaculaire functies, maar ze maken complexe gevechten makkelijker te testen, debuggen en uitbreiden.

Game feel is een technisch systeem, geen versiering

Fabled Revolutions, met broncode op ericrius1/FabledRevolutions, is juist nuttig omdat het de effecten isoleert die treffers gewicht geven.

Een logisch correct gevechtssysteem kan nog steeds zwak aanvoelen. De botsing kan nauwkeurig zijn, schade kan op het juiste frame worden toegepast en toch kan het resultaat voelen alsof twee modellen gewoon door elkaar heen bewegen.

De ervaren impact komt vaak voort uit een stapeling van kortdurende effecten:

• hit-stop;
• cameratrilling of -schok;
• wapensporen;
• impactdeeltjes;
• trefferflits;
• knockback;
• animatiereactie;
• goed getimed geluid.

Dat wijst op nog een nuttig onderscheid: een correct gevechtssysteem is niet hetzelfde als goed gevechtsgevoel. Een browsergame heeft beide nodig.

De renderer was niet de belangrijkste voorspeller van gevechtskwaliteit

Een van de interessantere patronen uit het onderzoek was dat de beste gevechten niet werden bepaald door de vraag of een project de nieuwste rendering-API gebruikte.

Three.js kwam herhaaldelijk terug. Sommige projecten gebruikten renderingtechnologie rond WebGPU, andere conventionele op WebGL gebaseerde stacks. Physics-engines, TypeScript, JavaScript, Vite, WebAssembly en verschillende renderingbenaderingen kwamen allemaal in het onderzoek voor.

Geavanceerde gevechtssystemen hingen veel consequenter af van de architectuur: simulatie met een vaste tijdstap, expliciete toestanden, betrouwbare doelkeuze, duidelijke verantwoordelijkheid voor animatie, datagedreven moves, gecentraliseerde schadeafhandeling en goede impactfeedback.

Dat is bemoedigend voor webontwikkelaars. Je hoeft niet te wachten tot elke gebruiker de nieuwste grafische stack heeft voordat je met serieus gevechtsontwerp experimenteert.

Waarom distributie via de browser de uitgangspositie verandert

De browser heeft een voordeel dat weinig met graphics te maken heeft: extreem weinig frictie bij distributie.

Traditionele games zetten vaak meerdere stappen tussen ontdekking en interactie: de winkelpagina vinden, een groot pakket downloaden, het installeren, starten, op updates wachten en soms een account aanmaken voordat je bij betekenisvolle gameplay komt.

Een browsergame kan dat traject terugbrengen tot één link.

Dat verandert de manier waarop prototypes kunnen worden gedeeld en getest. Een ontwikkelaar kan een build publiceren, een URL sturen, iemand anders meteen in exact dezelfde versie krijgen, feedback verzamelen en een volgende iteratie uitrollen zonder de tester te vragen handmatig een nieuw pakket te installeren.

Dit voordeel is vooral belangrijk voor experimentele games en onafhankelijke ontwikkeling. De browser is niet alleen een runtime, maar ook een distributiesysteem.

Waar de browser nog verliest

Het onderzoek heeft me er niet van overtuigd dat browsers native gameplatforms hebben vervangen. Dat hebben ze niet.

Verschillende beperkingen blijven belangrijk:

• Grote hoeveelheden assets. Directe toegang voelt niet meer direct wanneer een game een zeer grote eerste download nodig heeft.
• Geheugendruk. Browsers moeten naast andere tabbladen en het besturingssysteem bestaan, en geheugengedrag is minder voorspelbaar dan in een speciaal native proces.
• Thermische grenzen op mobiel. Een technisch functionerende 3D-game kan tijdens een langere sessie nog steeds sterk terugklokken.
• Verschillen tussen browsers. Graphics, audio, pointer lock, fullscreen-gedrag, controllers en prestatiekenmerken zijn niet volledig uniform.
• Voorbereiding van shaders en assets. Compilatie- of uploadwerk kan nog steeds zichtbare haperingen veroorzaken als de pipeline niet zorgvuldig is ontworpen.
• Beperkingen rond offlinegebruik en lokale persistentie. Native applicaties houden meer directe controle over grote lokale installaties en bestanden.
• Beveiliging in competitieve games. Serieuze anti-cheat en aannames over een vijandige client worden veel lastiger wanneer de client een webapplicatie is.

Deze beperkingen zijn belangrijk omdat ze bepalen waar browsergames vandaag het sterkst zijn: games die profiteren van directe toegang, snelle iteratie, platformonafhankelijke distributie en beheersbare budgetten voor assets en runtime.

AI maakt de lus van prototype naar URL veel korter

AI is hier relevant, maar niet omdat het op magische wijze één zin omzet in een afgewerkte game van hoge kwaliteit. Het realistischere voordeel is de snelheid van iteratie.

Moderne gameontwikkeling bevat veel kleine taken die samen kostbaar zijn: state machines opzetten, debugweergaven bouwen, tests schrijven, experimenteren met vijandgedrag, dataformaten voor moves maken, invoercode refactoren, shaders prototypen, physics-bugs onderzoeken en tijdelijke content aan elkaar koppelen.

AI kan veel van die lussen verkorten. Gecombineerd met distributie via het web wordt de workflow ongewoon direct:

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

De browser maakt deployment al snel. AI kan ook de implementatiekant van dezelfde lus versnellen.

De belangrijke kanttekening is dat snelle generatie geen smaak of validatie vervangt. Een gegenereerde gevechtscontroller kan structureel verkeerd zijn. Animatietiming vereist nog steeds menselijk oordeel. Physics moet nog steeds worden gedebugd. Prestaties moeten nog steeds worden gemeten. AI verlaagt de kosten van het uitproberen van ideeën; het neemt niet weg dat je moet bepalen welke ideeën goed zijn.

Wat dit betekent voor webontwikkelaars

De grens tussen webontwikkeling en gameontwikkeling wordt minder scherp.

Een serieuze browsergame kan tegenwoordig vertrouwde webtools gebruiken en tegelijk klassieke concepten uit game-engineering vereisen:

• vaste simulatiestappen;
• toestandsmachines;
• invoerbuffering;
• animatiegrafen;
• ruimtelijke queries;
• physics;
• framebudgetten;
• beheer van GPU-resources;
• audiotiming;
• deterministische systemen.

Tegelijk krijgen gameontwikkelaars die op de browser mikken dingen waarin het web al uitzonderlijk goed is: URL's, directe deployment, CDN-distributie, snelle updates, telemetrie, accountsystemen, responsieve interfaces en delen zonder frictie.

Het onderzoek heeft mijn eigen beeld veranderd. Ik zie browsergames niet langer vooral als vereenvoudigde versies van native games. Ik zie de browser als een steeds capabeler gameplatform met een andere reeks sterke punten: directe distributie, snelle iteratie, steeds serieuzere 3D-mogelijkheden en een enorm bestaand ontwikkel-ecosysteem.

Het web wordt niet alleen beter in het weergeven van games die elders zijn gebouwd. Het wordt steeds meer een plek waar serieuze gamesystemen rechtstreeks kunnen worden ontworpen, geïmplementeerd, getest, verspreid en gespeeld.