Tower Survivors — recréation open source

Recréation, en Rust/Bevy, d'un tower defense multijoueur en ligne inspiré de TowerSurvivorsv1_90.w3x : chaque joueur défend une tour unique avec des armes achetées, en coop contre des vagues d'ennemis, avec économie, score, défis à contrainte et skins cosmétiques.

Commencez ici :

1. tower_survivors_analysis.md — ce qui a été extrait/compris de la map source (systèmes, contenu, mécaniques).
2. ROADMAP.md — le plan de recréation complet, en phases.

Structure du workspace

.
├── Cargo.toml          # workspace, versions centralisées
├── shared/               # components/messages réseau — la source de
│                           vérité du protocole, utilisée par client ET serveur
├── server/               # binaire headless, autoritaire, déployable en VPS
├── client/                # binaire avec rendu, se connecte au serveur
└── data/                    # catalogue de contenu RON (Phase 3+), partagé
                               client+serveur via l'asset source `data://`
    ├── weapons/              # *.weapon.ron — voir shared::content::WeaponDef
    ├── enemies/              # *.enemy.ron — voir shared::content::EnemyDef
    ├── challenges/           # *.challenge.ron — voir shared::challenges::ChallengeDef
    └── skins/                # *.skin.ron — voir shared::challenges::SkinDef

Statut actuel

Phases 0 et 1 complètes, Phase 2 quasi complète, Phases 3-7 complètes, Phase 8 en cours (voir ROADMAP.md) : connexion client/serveur réelle (bevy_replicon 0.40.4 + bevy_replicon_renet2 0.17.0), tour fixe par joueur pouvant posséder plusieurs armes simultanées (achetées depuis un catalogue data-driven en RON, aucune arme offerte au départ) et des bonus génériques cumulés (PV max, régénération, réduction de dégâts, revenu passif, bonus de dégâts par type), tous achetés via la même offre de boutique que les armes, vagues d'ennemis isolées par joueur (types d'ennemis data-driven, santé/vitesse croissantes dans le temps, nouveaux types débloqués progressivement), économie, défaite, compteur de vagues affiché, tableau de bord (DPS/ revenu/puissance de feu/score par joueur) avec espionnage (Tab), défis à contrainte de type de dégâts récompensés par un skin de tour cosmétique, compte joueur persistant (token anonyme, score cumulé/skins en base SQLite) avec reconnexion en cours de partie après coupure réseau, HUD localisé en français (bevy_fluent), lobby (prêt/démarrage synchronisé), caméra déplaçable. Boutique refaite (2026-08-30) : l'ancien catalogue fixe à achat libre (confirmé non fidèle à la map source par ré-extraction directe) est remplacé par une offre à 4 emplacements d'armes + 4 d'améliorations génériques, tirées par palier de rareté (Commun/Peu commun/Rare/Épique, coûts et probabilités extraits de la map source), renouvelable par reroll à coût croissant — voir ROADMAP.md ("Système de shop réel"). HUD refait en vrais panneaux (fond contrasté, deux colonnes) avec la caméra dézoomée pour garder la carte visible derrière. Testé jusqu'à 8 clients simultanés sans erreur. Reste : souris/minimap (Phase 2, confort d'UX), icônes/tooltips pour la boutique (pas d'assets graphiques pour l'instant), contenu à étoffer et passes d'équilibrage (Phase 8, en cours), thèmes cosmétiques et comptes pseudo/mot de passe (reportés, voir ROADMAP.md).

Prérequis Linux (compilation du client)

Bevy compile le support des DEUX serveurs d'affichage (X11 et Wayland) dans le même binaire par défaut — le bon backend est choisi tout seul au lancement selon l'environnement (WAYLAND_DISPLAY/DISPLAY), donc un seul binaire tourne partout. Ça veut dire que la compilation a besoin des en-têtes de développement des DEUX, même sur une machine qui n'utilise que l'un des deux au quotidien (signalé en jeu 2026-08-31 : échec de compilation sur une machine X11 sans paquets Wayland installés — voir le commentaire dans client/Cargo.toml pour le détail de pourquoi ce n'est pas contournable côté Cargo.toml).

# Debian/Ubuntu
sudo apt install g++ pkg-config libx11-dev libxkbcommon-dev libwayland-dev libasound2-dev libudev-dev

# Fedora
sudo dnf install gcc-c++ libX11-devel libxkbcommon-devel wayland-devel alsa-lib-devel systemd-devel

# Arch
sudo pacman -S base-devel libx11 libxkbcommon wayland alsa-lib systemd-libs

Le serveur (cargo run -p server) n'a besoin d'aucun de ces paquets — il tourne headless, sans fenêtre ni rendu.

Binaires client précompilés (Linux + Windows)

À chaque tag vX.Y.Z poussé sur le dépôt, .forgejo/workflows/ release-client.yml compile le client pour Linux (natif) et Windows (cross-compilation via mingw-w64) et publie les deux archives sur la release Forgejo correspondante — voir l'onglet "Releases" du dépôt. Toutes les releases sont publiées en pre-release (prerelease: true, projet en développement actif, aucune version stable pour l'instant) — à ne retirer que le jour où une version est jugée réellement stable.

Un binaire précompilé n'a besoin d'AUCUN outil Rust/Cargo pour tourner (les paquets système ci-dessus ne servent qu'à COMPILER). Après extraction de l'archive, garder la disposition des dossiers telle quelle (data/ à côté de client/, jamais l'inverse — voir la doc de shared::register_data_source si besoin de comprendre pourquoi) :

tower-survivors-client-vX.Y.Z-linux-x86_64/
├── data/
└── client/
    ├── client          (ou client.exe sous Windows)
    ├── config.ron.example  (copier en config.ron pour se connecter à un
    │                        serveur distant — voir section suivante)
    └── assets/

Puis lancer l'exécutable directement depuis ce dossier client/ (double- clic sous Windows, ./client sous Linux).

Se connecter à un serveur distant

Le serveur écoute sur 127.0.0.1 (loopback uniquement, comportement historique inchangé) tant qu'aucune config n'est donnée — pour héberger une vraie partie accessible à des amis sur d'autres machines, exposez-le sur toutes les interfaces :

# Argument CLI (le plus explicite) :
cargo run -p server -- --bind 0.0.0.0:5000

# ...ou juste un port (IP 0.0.0.0 implicite) :
cargo run -p server -- --bind 5000

# ...ou variable d'environnement (pratique pour un systemd/conteneur) :
TOWER_SURVIVORS_BIND_ADDR=0.0.0.0:5000 cargo run -p server

Le port UDP correspondant doit être ouvert sur le pare-feu/la box de la machine hôte.

Pour héberger pour de bon — matchmaking à plusieurs salles, matrice de flux, exemple nftables complet, redirection de port et unité systemd : voir DEPLOYMENT.md. À retenir d'emblée : grâce au relais UDP, un seul port suffit (UDP 5000) pour tous les clients natifs, quel que soit le nombre de salles.

Côté client, l'adresse par défaut (tde.k-yu.fr:5000, le serveur public — un nom de domaine ou une IP, au choix) se configure par ordre de priorité croissante : un fichier config.ron posé À CÔTÉ du binaire/dossier client/ (voir la disposition ci-dessus), puis les arguments --server/--name (pratiques en dev pour basculer vite entre plusieurs serveurs de test) :

// config.ron
(
    server_addr: "203.0.113.42:5000",
    display_name: "Xel",
)

cargo run -p client -- --server 203.0.113.42:5000 --name Xel

display_name est un pseudo purement cosmétique (affiché dans le HUD/ tableau de bord de tous les joueurs) — PAS un système de compte avec mot de passe, voir shared::PlayerName.

Lancer

# Terminal 1
cargo run -p server

# Terminal 2 (répéter pour tester plusieurs joueurs)
cargo run -p client

Sans argument, le client démarre sur un écran d'Accueil puis Rejoindre (adresse serveur + pseudo, favoris sauvegardables) — voir "Se connecter à un serveur distant" plus haut. Passer --server saute directement à la connexion (pratique en dev pour un test rapide sans repasser par le menu).

Touches 1-4 : acheter l'emplacement d'ARME correspondant de l'offre de boutique (voir le HUD — 4 emplacements tirés par rareté, aucune arme au départ, la tour ne tire sur rien tant que rien n'a été acheté). Touches 5-8 : acheter l'emplacement d'AMÉLIORATION correspondant (même offre, groupe différent — revenu passif, PV max/régénération/ réduction de dégâts, ou bonus de dégâts par type). Y : reroll complet de l'offre — gratuit tant qu'il reste des rerolls gratuits (6 de départ + un pool "bonus" dont le plafond grandit avec le temps de jeu, confirmés extraits de la map source), coût croissant ensuite. Tab : espionner un autre joueur (affiche son détail d'armes/bonus en lecture seule). F1-F4 : lancer un défi à contrainte du catalogue. [/] : changer de skin de tour parmi ceux débloqués. R bascule prêt/pas prêt en salon d'attente. Flèches/WASD déplacent la caméra.

Réglages de partie configurables (variables d'environnement du serveur) :

# Nombre de joueurs max (2-8, défaut 8)
TOWER_SURVIVORS_MAX_PLAYERS=4 cargo run -p server

# Vitesse de jeu et coefficient de difficulté (0.25-4.0, défaut 1.0)
TOWER_SURVIVORS_GAME_SPEED=1.5 TOWER_SURVIVORS_DIFFICULTY=2 cargo run -p server

# Persistance (Phase 7) : chemin de la base SQLite serveur, et durée de
# grâce de reconnexion (secondes, 30-1800, défaut 180)
TOWER_SURVIVORS_DB_PATH=tower_survivors.db TOWER_SURVIVORS_RECONNECT_GRACE_SECS=180 cargo run -p server

Le client génère et conserve un token de compte anonyme localement (fichier .tower_survivors_token par défaut, chemin personnalisable via TOWER_SURVIVORS_TOKEN_PATH) :

TOWER_SURVIVORS_TOKEN_PATH=/chemin/vers/token cargo run -p client

Avant de coder la suite

Les versions de bevy_replicon / bevy_replicon_renet2 sont verrouillées et vérifiées (voir CLAUDE.md), mais cet écosystème réseau évolue vite — revalidez contre docs.rs/bevy_replicon avant toute montée de version.