Battlezone Online (bzo) is een gratis 3D multiplayer tankspel dat direct in de browser speelbaar is op desktops, telefoons en VR-headsets, zonder dat installatie vereist is. Het spel is compatibel met BZFlag-clients en -servers.
Technische specificaties en installatie De server draait op Node.js en de client maakt gebruik van Three.js via WebSockets, WebTransport en WebRTC. Gebruikers kunnen een eigen server installeren via Docker-images (gebaseerd op Ubuntu 26.04), broncode-tarballs of een git-checkout.
VR en Besturing Via WebXR biedt het spel een native VR-modus voor ondersteunde headsets. De besturing is breed inzetbaar en ondersteunt toetsenbord, muis, touch-interfaces, gamepads en XR-controllers.
Ontwikkeling en Licenties Het project hanteert een strikt releaseproces via GitHub met SemVer-versionering. De broncode is gelicentieerd onder AGPLv3, terwijl de assets (modellen, texturen en geluiden) verschillende licentiestatussen hebben, waarbij het streven is naar volledige transparantie en compatibiliteit met de AGPLv3.
Battlezone Online
Speel nu: https://bz.rikers.org Servers: https://bz.rikers.org/list Hulp: besturing en flags BZFlag Discord
Uitproberen
Op https://bz.rikers.org/list vind je een overzicht van de publieke bzo-servers en de BZFlag-servers die zij proxyen. Klik op een rij om het spel te betreden.
De server is gebouwd met Node.js; de client maakt gebruik van Three.js via WebSockets, WebTransport en WebRTC.
Inhoud van releases
Elke getagde release publiceert:
- Een GitHub-release met aantekeningen gegenereerd vanuit
CHANGELOG.md.
- Een broncode-tarball.
- Een versiebeheerde Ubuntu 26.04-image op
ghcr.io/timriker/bzo:<version>-ubuntu26.04.
- Een bewegende
ubuntu26.04 tag.
ghcr.io/timriker/bzo:<version> en ghcr.io/timriker/bzo:latest, beide gebruikmakend van Ubuntu 26.04.
Elke gepubliceerde image bevat varianten voor linux/amd64 en linux/arm64. Releasetags gebruiken uitsluitend stabiele vX.Y.Z SemVer; prerelease- en build-metadata-tags worden niet gepubliceerd.
Docker-images worden gebouwd op Ubuntu 26.04 met het eigen nodejs-pakket van Ubuntu (Node.js 22), en CI draait op dezelfde Node in een Ubuntu 26.04-container.
Een server installeren en draaien
Installatie kan via een Docker-image vanuit de GitHub Container Registry, een broncode-tarball of een git-checkout. Voor de meeste gebruikers is Docker de betere methode voor installatie en updates.
docs/installation.md bevat informatie over beide methoden, alsofdat configuratie, draaien achter een reverse proxy, het aanmelden van je server, het proxyen van BZFlag-servers en het uitvoeren van updates.
Een site die servers pollt — voor statistieken of een serverbrowser — kan informatie vinden in docs/api.md.
De 'Launch'-links op /list openen een BZFlag-server in een geïnstalleerde BZFlag-client; docs/bzflag-links.md legt uit hoe je bzflag:// instelt op Linux, Windows en macOS.
Flags
bzo ondersteunt elke flag die BZFlag heeft. De WA (Wide Angle) spawn verschijnt, plakt en schudt af zoals elke andere slechte flag, maar doet niets: het zou het gezichtsveld moeten verbreden, maar in VR wordt de projectie beheerd door de headset.
De rest van de flags, inclusief de redenen hiervoor, staan in docs/flags.md.
Changelog en releasenotes
De leesbare geschiedenis wordt bijgehouden in CHANGELOG.md. Getagde GitHub-releases gebruiken de overeenkomstige sectie uit de changelog als releasenotes.
Besturing
In docs/controls.md staan alle besturingsopties: toetsenbord en muis, touch-besturingen op het scherm, gamepads en XR-controllers. In het spel tonen / of ? de toetsenbordbesturing.
WebXR
De VR-modus maakt gebruik van native WebXR en vereist een browser en headset die immersive-vr ondersteunen.
- Lokale validatie: Open het spel via
http://localhost:5154.
- Externe toegang: Serveer het spel via
https:// — met het eigen https-certificaat van de server of via een reverse proxy. De client gebruikt automatisch wss:// voor de WebSocket-verbinding wanneer de pagina via HTTPS wordt geserveerd.
Een browser op een headset die de geïnstalleerde app start, probeert VR te betreden zonder 2D-landingspagina. xr-launch.js vraagt om de sessie voordat de rest van de client laadt, en blijft vragen bij elk signaal dat een gebruikersactivatie zou kunnen bevatten (window load, focus, page show, visibility change en de Launch Handler). De renderer neemt de sessie over die resulteert. In alle andere gevallen start de VR-modus via de knop.
Een opgeslagen naam meldt direct aan. Zonder naam opent het XR-menu op een Join-scherm met dezelfde keuzes voor naam, team en tank als de 2D-dialoog, zodat de speler niet hoeft te wachten op een scherm dat niet zichtbaar is in VR.
Typen in XR gebeurt via het systeemtoetsenbord van de headset, dat verschijnt wanneer de rij voor Naam of MOTD focus krijgt. Quest Browser 26.1 en later bieden dit; headsets die dit niet ondersteunen, markeren deze rijen als 'Desktop only'. De speler kan dan nog steeds deelnemen onder de naam die de server toewijst. Elke keer dat het toetsenbord opent, start er een nieuwe bewerking, waardoor de eerste toets het hele veld vervangt in plaats van erop aan te vullen.
De VR-knop naast het instellingen-tandwiel wordt alleen getoond op apparaten met een headset. Dit is omdat Chrome op Android immersive-vr ondersteuning rapporteert op elke telefoon via Cardboard; daar blijft de VR-modus in het instellingenmenu staan.
Als de deployment een restrictieve Permissions-Policy header gebruikt, sta dan xr-spatial-tracking=(self) toe. TLS wordt verzorgd door de server zelf (https, zie docs/installation.md) of een reverse proxy.
Gebruik de WebXR-validatielijst bij het controleren van een nieuwe browser, headset of deployment. WebGPU-rendering valt buiten de scope van deze lijst.
Ontwikkelingscontroles
npm run check Dit voert de syntaxis- en lint-controles uit, een server-boot-check en de testsuites. CI voert deze controles ook uit bij pushes en pull requests.
Releaseproces
Commit eerst alles: een tag benoemt een tree, dus een wijziging die nog in de working directory staat op het moment van taggen, zit niet in de release. Dit betekent dat de versie iets anders zegt dan de inhoud, en dat het niet gereproduceerd kan worden vanaf de tag. Dit geldt ook voor niet-gecommitteerd werk van anderen: review dit, benoem het en commit het voordat er getagd wordt. git status moet schoon zijn vóór de voorbereiding van een release en schoon na het pushen van de tag.
Releasetags zijn uitsluitend stabiele vX.Y.Z SemVer — prereleases en build-metadata worden niet gepubliceerd.
Een release lokaal voorbereiden: npm run release:prepare -- 1.0.1
Dit werkt het volgende bij:
package.jsonpackage-lock.jsonpublic/version.mjsCHANGELOG.md
Deze vier bestanden gaan in de release-commit. public/version.mjs wordt vaak vergeten; een tag zonder dit bestand levert een client op die de vorige versie rapporteert.
Bewerk daarna de nieuwe sectie in de changelog zodat deze de werkelijke, voor de gebruiker zichtbare wijzigingen bevat.
Lokaal valideren: npm run check npm run release:check -- v1.0.1 npm run release:check:increment -- v1.0.1
Commiten, taggen en pushen: git add package.json package.lock.json public/version.mjs CHANGELOG.md git commit -m "Release v1.0.1 - korte beschrijving. Closes #1" git tag v1.0.1 git push git push origin v1.0.1
De onderwerpregel beschrijft de release in plaats van deze alleen te labelen. De versie staat immers al in de tag, package.json en CHANGELOG.md. Benoem de wijziging in een paar woorden en gebruik een echt closing-keyword voor het issue, aangezien een kale (#NN) alleen een link is.
De release-workflow zal:
- Verifiëren dat de stabiele tag nieuwer is dan de vorige release en naar
main wijst.
- Afhankelijkheden installeren en lint-, validatie-, audit- en CodeQL-controles uitvoeren.
- Falen als
package.json niet overeenkomt met de gepushte tag.
- Falen als
CHANGELOG.md geen overeenkomstige sectie (geen placeholder) bevat.
- Ubuntu 26.04-images bouwen en smoke-testen met Ubuntu's Node.js 22 voor
linux/amd64 en linux/arm64.
- De geverifieerde versiebeheerde en bewegende Docker-tags promoveren naar GHCR.
- Een GitHub-release publiceren en een broncode-tarball toevoegen.
Een release die faalt in de workflow wordt ongemoeid gelaten. bzo is in ontwikkeling en niet elke tag produceert artifacts. Los de oorzaak op en ga naar de volgende versie — verwijder of verplaats geen gepubliceerde tag, en vul geen GitHub-release aan voor een versie die nooit gebouwd is. CHANGELOG.md blijft in alle gevallen het verslag.
public/version.mjs wordt geschreven door scripts/prepare-release.mjs en geverifieerd tegen de tag door scripts/check-release.mjs. Bewerk dit bestand niet handmatig en introduceer geen hardcoded client-versie-strings op andere plekken.
Gebundelde assets en licenties
De code is gelicentieerd onder AGPLv3. De assets hebben een verschillende status.
bzo bevat modellen, texturen, geluiden en maps van diverse bronnen:
- Sommige zijn van het BZFlag-project en worden gebruikt onder diens licentie.
- Sommige zijn specifiek voor bzo gemaakt.
- Sommige zijn via contributies binnengekomen.
Een bestand erft niet automatisch de licentie van de repository door erin te staan. Voor nieuwe toevoegingen wordt het volgende verwacht:
- Vermeld in de pull request waar het vandaan komt en onder welke voorwaarden.
- Geef de voorkeur aan voorwaarden die compatibel zijn met AGPLv3-distributie.
- Een header die aangeeft dat een bestand is geëxporteerd door een tool is geen licentieverlening, en een opmerking dat de auteur het niet heeft uitgezocht ook niet.
Niet elk asset in de huidige tree voldoet hier al aan. Het doel is om voor elk bestand een duidelijke, geregistreerde licentie te krijgen. Als je de herkomst van iets weet of de auteur bent, meld dit dan in een issue.
Maps vormen een soortgelijk vraagstuk: een map die is gedownload van een server of is opgeslagen door een client, brengt geen licentieverlening met zich mee. Zie docs/bzw.md voor het map-formaat zelf.
AGPL broncode beschikbaarheid
Dit project is gelicentieerd onder de GNU Affero General Public License v3.0. Netwerkgebruikers kunnen de broncode via de draaiende app benaderen via /source, of direct via: https://github.com/timriker/bzo
Battlezone Online
Speel nu: https://bz.rikers.org Servers: https://bz.rikers.org/list Hulp: besturing en flags BZFlag Discord
Uitproberen
Op https://bz.rikers.org/list vind je een overzicht van de publieke bzo-servers en de BZFlag-servers die zij proxyen. Klik op een rij om het spel te betreden.
De server is gebouwd met Node.js; de client maakt gebruik van Three.js via WebSockets, WebTransport en WebRTC.
Inhoud van releases
Elke getagde release publiceert:
- Een GitHub-release met aantekeningen gegenereerd vanuit
CHANGELOG.md.
- Een broncode-tarball.
- Een versiebeheerde Ubuntu 26.04-image op
ghcr.io/timriker/bzo:<version>-ubuntu26.04.
- Een bewegende
ubuntu26.04 tag.
ghcr.io/timriker/bzo:<version> en ghcr.io/timriker/bzo:latest, beide gebruikmakend van Ubuntu 26.04.
Elke gepubliceerde image bevat varianten voor linux/amd64 en linux/arm64. Releasetags gebruiken uitsluitend stabiele vX.Y.Z SemVer; prerelease- en build-metadata-tags worden niet gepubliceerd.
Docker-images worden gebouwd op Ubuntu 26.04 met het eigen nodejs-pakket van Ubuntu (Node.js 22), en CI draait op dezelfde Node in een Ubuntu 26.04-container.
Een server installeren en draaien
Installatie kan via een Docker-image vanuit de GitHub Container Registry, een broncode-tarball of een git-checkout. Voor de meeste gebruikers is Docker de betere methode voor installatie en updates.
docs/installation.md bevat informatie over beide methoden, alsofdat configuratie, draaien achter een reverse proxy, het aanmelden van je server, het proxyen van BZFlag-servers en het uitvoeren van updates.
Een site die servers pollt — voor statistieken of een serverbrowser — kan informatie vinden in docs/api.md.
De 'Launch'-links op /list openen een BZFlag-server in een geïnstalleerde BZFlag-client; docs/bzflag-links.md legt uit hoe je bzflag:// instelt op Linux, Windows en macOS.
Flags
bzo ondersteunt elke flag die BZFlag heeft. De WA (Wide Angle) spawn verschijnt, plakt en schudt af zoals elke andere slechte flag, maar doet niets: het zou het gezichtsveld moeten verbreden, maar in VR wordt de projectie beheerd door de headset.
De rest van de flags, inclusief de redenen hiervoor, staan in docs/flags.md.
Changelog en releasenotes
De leesbare geschiedenis wordt bijgehouden in CHANGELOG.md. Getagde GitHub-releases gebruiken de overeenkomstige sectie uit de changelog als releasenotes.
Besturing
In docs/controls.md staan alle besturingsopties: toetsenbord en muis, touch-besturingen op het scherm, gamepads en XR-controllers. In het spel tonen / of ? de toetsenbordbesturing.
WebXR
De VR-modus maakt gebruik van native WebXR en vereist een browser en headset die immersive-vr ondersteunen.
- Lokale validatie: Open het spel via
http://localhost:5154.
- Externe toegang: Serveer het spel via
https:// — met het eigen https-certificaat van de server of via een reverse proxy. De client gebruikt automatisch wss:// voor de WebSocket-verbinding wanneer de pagina via HTTPS wordt geserveerd.
Een browser op een headset die de geïnstalleerde app start, probeert VR te betreden zonder 2D-landingspagina. xr-launch.js vraagt om de sessie voordat de rest van de client laadt, en blijft vragen bij elk signaal dat een gebruikersactivatie zou kunnen bevatten (window load, focus, page show, visibility change en de Launch Handler). De renderer neemt de sessie over die resulteert. In alle andere gevallen start de VR-modus via de knop.
Een opgeslagen naam meldt direct aan. Zonder naam opent het XR-menu op een Join-scherm met dezelfde keuzes voor naam, team en tank als de 2D-dialoog, zodat de speler niet hoeft te wachten op een scherm dat niet zichtbaar is in VR.
Typen in XR gebeurt via het systeemtoetsenbord van de headset, dat verschijnt wanneer de rij voor Naam of MOTD focus krijgt. Quest Browser 26.1 en later bieden dit; headsets die dit niet ondersteunen, markeren deze rijen als 'Desktop only'. De speler kan dan nog steeds deelnemen onder de naam die de server toewijst. Elke keer dat het toetsenbord opent, start er een nieuwe bewerking, waardoor de eerste toets het hele veld vervangt in plaats van erop aan te vullen.
De VR-knop naast het instellingen-tandwiel wordt alleen getoond op apparaten met een headset. Dit is omdat Chrome op Android immersive-vr ondersteuning rapporteert op elke telefoon via Cardboard; daar blijft de VR-modus in het instellingenmenu staan.
Als de deployment een restrictieve Permissions-Policy header gebruikt, sta dan xr-spatial-tracking=(self) toe. TLS wordt verzorgd door de server zelf (https, zie docs/installation.md) of een reverse proxy.
Gebruik de WebXR-validatielijst bij het controleren van een nieuwe browser, headset of deployment. WebGPU-rendering valt buiten de scope van deze lijst.
Ontwikkelingscontroles
npm run check Dit voert de syntaxis- en lint-controles uit, een server-boot-check en de testsuites. CI voert deze controles ook uit bij pushes en pull requests.
Releaseproces
Commit eerst alles: een tag benoemt een tree, dus een wijziging die nog in de working directory staat op het moment van taggen, zit niet in de release. Dit betekent dat de versie iets anders zegt dan de inhoud, en dat het niet gereproduceerd kan worden vanaf de tag. Dit geldt ook voor niet-gecommitteerd werk van anderen: review dit, benoem het en commit het voordat er getagd wordt. git status moet schoon zijn vóór de voorbereiding van een release en schoon na het pushen van de tag.
Releasetags zijn uitsluitend stabiele vX.Y.Z SemVer — prereleases en build-metadata worden niet gepubliceerd.
Een release lokaal voorbereiden: npm run release:prepare -- 1.0.1
Dit werkt het volgende bij:
package.jsonpackage-lock.jsonpublic/version.mjsCHANGELOG.md
Deze vier bestanden gaan in de release-commit. public/version.mjs wordt vaak vergeten; een tag zonder dit bestand levert een client op die de vorige versie rapporteert.
Bewerk daarna de nieuwe sectie in de changelog zodat deze de werkelijke, voor de gebruiker zichtbare wijzigingen bevat.
Lokaal valideren: npm run check npm run release:check -- v1.0.1 npm run release:check:increment -- v1.0.1
Commiten, taggen en pushen: git add package.json package.lock.json public/version.mjs CHANGELOG.md git commit -m "Release v1.0.1 - korte beschrijving. Closes #1" git tag v1.0.1 git push git push origin v1.0.1
De onderwerpregel beschrijft de release in plaats van deze alleen te labelen. De versie staat immers al in de tag, package.json en CHANGELOG.md. Benoem de wijziging in een paar woorden en gebruik een echt closing-keyword voor het issue, aangezien een kale (#NN) alleen een link is.
De release-workflow zal:
- Verifiëren dat de stabiele tag nieuwer is dan de vorige release en naar
main wijst.
- Afhankelijkheden installeren en lint-, validatie-, audit- en CodeQL-controles uitvoeren.
- Falen als
package.json niet overeenkomt met de gepushte tag.
- Falen als
CHANGELOG.md geen overeenkomstige sectie (geen placeholder) bevat.
- Ubuntu 26.04-images bouwen en smoke-testen met Ubuntu's Node.js 22 voor
linux/amd64 en linux/arm64.
- De geverifieerde versiebeheerde en bewegende Docker-tags promoveren naar GHCR.
- Een GitHub-release publiceren en een broncode-tarball toevoegen.
Een release die faalt in de workflow wordt ongemoeid gelaten. bzo is in ontwikkeling en niet elke tag produceert artifacts. Los de oorzaak op en ga naar de volgende versie — verwijder of verplaats geen gepubliceerde tag, en vul geen GitHub-release aan voor een versie die nooit gebouwd is. CHANGELOG.md blijft in alle gevallen het verslag.
public/version.mjs wordt geschreven door scripts/prepare-release.mjs en geverifieerd tegen de tag door scripts/check-release.mjs. Bewerk dit bestand niet handmatig en introduceer geen hardcoded client-versie-strings op andere plekken.
Gebundelde assets en licenties
De code is gelicentieerd onder AGPLv3. De assets hebben een verschillende status.
bzo bevat modellen, texturen, geluiden en maps van diverse bronnen:
- Sommige zijn van het BZFlag-project en worden gebruikt onder diens licentie.
- Sommige zijn specifiek voor bzo gemaakt.
- Sommige zijn via contributies binnengekomen.
Een bestand erft niet automatisch de licentie van de repository door erin te staan. Voor nieuwe toevoegingen wordt het volgende verwacht:
- Vermeld in de pull request waar het vandaan komt en onder welke voorwaarden.
- Geef de voorkeur aan voorwaarden die compatibel zijn met AGPLv3-distributie.
- Een header die aangeeft dat een bestand is geëxporteerd door een tool is geen licentieverlening, en een opmerking dat de auteur het niet heeft uitgezocht ook niet.
Niet elk asset in de huidige tree voldoet hier al aan. Het doel is om voor elk bestand een duidelijke, geregistreerde licentie te krijgen. Als je de herkomst van iets weet of de auteur bent, meld dit dan in een issue.
Maps vormen een soortgelijk vraagstuk: een map die is gedownload van een server of is opgeslagen door een client, brengt geen licentieverlening met zich mee. Zie docs/bzw.md voor het map-formaat zelf.
AGPL broncode beschikbaarheid
Dit project is gelicentieerd onder de GNU Affero General Public License v3.0. Netwerkgebruikers kunnen de broncode via de draaiende app benaderen via /source, of direct via: https://github.com/timriker/bzo
Groetjes,