Un jeu de tank multijoueur 3D gratuit dans le navigateur – sur un ordinateur de bureau, un téléphone ou un casque VR – qui joue avec les clients et les serveurs BZFlag. Rien à installer.
Jouez maintenant : · Serveurs · Aide : contrôles et drapeaux · BZFlag Discord

/list répertorie les serveurs bzo publics et les serveurs BZFlag, tous proxy. Cliquez sur une ligne pour accéder à ce jeu.
Le serveur est Node.js ; le client est Three.js, via WebSockets, WebTransport et WebRTC.
Chaque version taguée publie :
- une version GitHub avec des notes générées à partir de CHANGELOG.md
- une archive source
- une image Ubuntu 26.04 versionnée sur
ghcr.io/timriker/bzo:-ubuntu26.04 - un déménagement
ubuntu26.04étiqueter ghcr.io/timriker/bzo:etghcr.io/timriker/bzo:latesttous deux utilisant Ubuntu 26.04
Chaque image publiée contient linux/amd64 et linux/arm64 variantes. Les balises de version utilisent stable vX.Y.Z SemVer uniquement ; Les balises prerelease et build-metadata ne sont pas publiées.
Les images Docker sont construites sur Ubuntu 26.04 avec celles d’Ubuntu nodejs package (Node.js 22) et CI s’exécute sur le même nœud dans un conteneur Ubuntu 26.04.
Une image Docker de GitHub Container Registry, ou une archive tar source ou une extraction git. Docker est le meilleur chemin d’installation et de mise à jour pour la plupart des gens.
docs/installation.md couvre les deux, ainsi que la configuration, l’exécution derrière un proxy inverse, la liste de votre serveur, le proxy des serveurs BZFlag et la mise à jour.
Un site qui interroge les serveurs (statistiques, navigateur de serveur) trouve ce qu’il peut demander dans docs/api.md.
/listc’est Lancement les liens ouvrent un serveur BZFlag dans un client BZFlag installé ; docs/bzflag-links.md configure bzflag:// sous Linux, Windows et macOS.
bzo porte tous les drapeaux de BZFlag. WA Le grand angle apparaît, se colle et se secoue comme n’importe quel mauvais drapeau, mais ne fait rien : il élargit le champ de vision, et en VR, le casque possède la projection.
docs/flags.md a le reste, y compris pourquoi.
Journal des modifications et notes de version
- L’historique lisible par l’homme est conservé dans CHANGELOG.md
- Les versions balisées de GitHub utilisent la section correspondante du journal des modifications comme notes de version
docs/controls.md possède tous les contrôles : le clavier et la souris, les commandes tactiles à l’écran, les manettes de jeu et les contrôleurs XR. Dans le jeu, / ou ? montre celui du clavier.
Le mode VR utilise WebXR natif et nécessite un navigateur et un casque prenant en charge
immersive-vr. Pour une validation locale, ouvrez le jeu à http://localhost:5154. Pour un accès à distance, servez le jeu terminé https:// — avec celui du serveur
https certificat, ou via un proxy inverse ; le client utilise automatiquement
wss:// pour sa connexion WebSocket lorsque la page est servie via HTTPS.
Un navigateur de casque lançant l’application installée tente d’accéder à la réalité virtuelle sans page de destination 2D. xr-launch.js demande la session avant le chargement du reste du client et continue de demander chaque signal susceptible de transporter l’activation de l’utilisateur dont une session immersive a besoin – chargement de la fenêtre, focus, affichage de la page, changement de visibilité et gestionnaire de lancement – le moteur de rendu récupérant les résultats de la session. Là où aucun d’entre eux n’atteint, et partout ailleurs, le mode VR démarre à partir du bouton.
Un nom enregistré rejoint immédiatement, et sans celui-ci, le menu XR s’ouvre sur un écran Rejoindre portant le même nom, les mêmes choix d’équipe et de char que la boîte de dialogue d’entrée 2D, donc rien n’attend sur un écran que le joueur ne peut pas voir.
La saisie en XR utilise le propre clavier système du casque, activé lorsque la ligne Nom ou MOTD prend le focus. Quest Browser 26.1 et versions ultérieures en fournissent un ; un casque qui ne marque pas ces lignes uniquement sur le bureau, et le joueur peut toujours rejoindre sous le nom attribué par le serveur. Chaque fois que le clavier s’ouvre, il lance une nouvelle modification, de sorte que la première touche remplace tout le champ plutôt que de s’y ajouter.
Le bouton VR en un clic à côté de l’engrenage des paramètres s’affiche uniquement sur un appareil équipé d’un casque, car Chrome sur Android signale immersive-vr assistance sur n’importe quel téléphone via Cardboard ; Le mode VR reste dans le menu Paramètres.
Si le déploiement définit une restriction Permissions-Policy en-tête, autoriser
xr-spatial-tracking=(self). TLS est soit celui du serveur (httpsvoir docs/installation.md) ou un proxy inverse (docs/installation.md).
Utilisez la liste de contrôle de validation WebXR lors de la vérification d’un nouveau navigateur, casque ou déploiement. Le rendu WebGPU sort du cadre de cette liste de contrôle.
Cela exécute les vérifications de syntaxe et de charpie, une vérification de démarrage du serveur et les suites de tests.
CI exécute également ces vérifications sur les demandes push et pull.
Validez tout d’abord et ne laissez rien derrière : une balise nomme un arbre, donc une modification toujours présente dans le répertoire de travail lorsque la balise disparaît n’est pas dans la version – la version dit une chose et la boîte en dit une autre, et personne ne peut la reproduire à partir de la balise. Cela inclut le travail que quelqu’un d’autre n’a pas engagé : examinez-le, dites de quoi il s’agit et validez-le, plutôt que de le contourner. git status est propre avant de préparer une version et propre à nouveau une fois le tag poussé ; tout ce qui est encore en attente à la fin signifie que la version est sortie sans cela.
Les balises de version sont stables vX.Y.Z SemVer uniquement : les versions préliminaires et les métadonnées de build ne sont pas publiées.
Préparez une version localement :
npm run release:prepare -- 1.0.1
Cela met à jour :
package.jsonpackage-lock.jsonpublic/version.mjsCHANGELOG.md
Tous les quatre vont dans le commit de publication. public/version.mjs est celui qui est facile à laisser derrière lui, et une balise sans elle envoie un client signalant la version qui la précède.
Modifiez ensuite la nouvelle section du journal des modifications afin qu’elle contienne les véritables modifications visibles par l’utilisateur.
Validez localement :
npm run check
npm run release:check -- v1.0.1
npm run release:check:increment -- v1.0.1
Ensuite, validez, taguez et poussez :
git add package.json package-lock.json public/version.mjs CHANGELOG.md
git commit -m "Release v1.0.1 - short description. Closes #1"
git tag v1.0.1
git push
git push origin v1.0.1
Le sujet décrit la version plutôt que de l’étiqueter : la version est déjà dans le tag, package.json et CHANGELOG.mdet git log --oneline
est la seule vue où le sujet est tout ce qui existe. Nommez le changement en quelques mots et référencez le problème avec un véritable mot-clé de clôture là où la version le termine, car un simple (#NN) seulement des liens.
Le flux de travail de publication :
- vérifiez que la balise stable est plus récente que la version précédente et pointe vers
main - installer les dépendances et exécuter des vérifications Lint, validation, audit et CodeQL
- échouer si
package.jsonne correspond pas à la balise poussée - échouer si CHANGELOG.md ne contient pas de section correspondante sans espace réservé
- créer et tester des images Ubuntu 26.04 avec Node.js 22 d’Ubuntu pour
linux/amd64etlinux/arm64 - promouvoir les balises Docker versionnées et déplacées vérifiées vers GHCR
- publier une version GitHub et joindre une archive tar source
Une version qui échoue dans son flux de travail est laissée seule. bzo est en développement et toutes les balises ne produisent pas d’artefacts. Corrigez la cause et passez à la version suivante : ne supprimez ni ne déplacez une balise publiée, et ne remplissez pas une version de GitHub pour une version qui n’a jamais été construite. CHANGELOG.md est l’enregistrement dans tous les cas, et il contient déjà la section de la version qui a échoué.
public/version.mjs est écrit par scripts/prepare-release.mjs et vérifié par rapport à l’étiquette par scripts/check-release.mjs. Ne le modifiez pas à la main et ne réintroduisez pas ailleurs une chaîne de version client codée en dur.
Actifs groupés et licences
Le code est AGPLv3. Les actifs ne sont pas tous la même histoire.
bzo expédie des modèles, des textures, des sons et des cartes depuis plusieurs endroits : certains appartiennent au projet BZFlag, utilisé sous sa licence ; certains étaient faits pour le bzo ; certains sont arrivés avec une contribution. Un fichier n’hérite pas de la licence du référentiel en s’y trouvant, et un actif dont personne n’a enregistré l’origine est une question laissée à celui qui la posera ensuite.
Qu’est-ce qu’on attend de tout ce qui est ajouté ici :
- dire d’où il vient et dans quelles conditions, dans la pull request
- privilégier les termes compatibles avec la distribution AGPLv3
- un en-tête indiquant qu’un fichier a été exporté par un outil ne garantit rien, pas plus qu’une note indiquant que l’auteur ne l’a pas examiné
Tous les actifs déjà présents dans l’arborescence ne répondent pas à cette barre. Certains sont antérieurs aux attentes et d’autres sont arrivés avec une contribution qui valait la peine d’être acceptée en soi, et l’intention est d’obtenir une licence claire et enregistrée pour chacun d’entre eux plutôt que de prétendre que c’est déjà fait. Si vous connaissez la provenance de quelque chose ici, ou si vous en êtes l’auteur, veuillez le dire dans un numéro – c’est la manière la moins chère de terminer cela.
Les cartes posent la même question sous une forme différente : une carte téléchargée depuis un serveur ou enregistrée par un client ne comporte aucune subvention. Voir docs/bzw.md pour le format de carte lui-même.
Ce projet est sous licence GNU Affero General Public License v3.0.
Les utilisateurs du réseau peuvent accéder au code source depuis l’application en cours d’exécution via /sourceou directement à :