Prototype multijoueur compétitif en vue subjective pour 2 à 12 joueurs. Le premier objectif est de prouver qu'un duel autour d'un pivot de labyrinthe est amusant, lisible et réactif en réseau avant de produire le contenu final.
La cible joueur initiale est Windows x86_64 IL2CPP. Le développement se fait sur deux Mac Apple Silicon et un PC Windows ; le build Mac reste un outil de test interne. FishNet/Tugboat fournit aujourd'hui un listen-server de prototype, Tailscale relie uniquement les postes de l'équipe, et Steam/serveur dédié attendent leur gate.
Le dépôt est au jalon M0 — fondations.
- gouvernance GitHub à fermer : dépôt actuellement public, sans licence ni protection de
main; - projet Unity URP et conventions de travail préparés ;
- versions Unity/FishNet figées et scène de connexion à trois générable ;
- scripts d'installation, diagnostic, assets et tests local/distant Mac/Windows ;
- séparation Git / Git LFS / masters DVC / caches locaux documentée ;
- fournisseur DVC choisi et scripts R2 préparés ;
- premier master à pousser/restaurer et deux masters absents à récupérer ou requalifier ;
- premier import Unity Mac et
packages-lock.jsonmergé ; - ouverture propre sur le second Mac et build Windows IL2CPP ;
- Zak, Sean et Nils visibles dans la même session depuis leurs trois réseaux ;
- HT-00 : première observation humaine locale exécutée sans crash ; interaction labyrinthe encore non prouvée ;
- gate Wwise à ouvrir après la première preuve distante autoritaire — ne bloque pas le setup.
La machine pilote peut construire le labyrinthe et lancer un smoke test où le joueur et les pivots sont visibles en réseau. Ce code est volontairement étiqueté prototype : déplacement client-authoritative, transition des colliders par image et collisions issues du FBX ne valident pas M1. Les prochaines actions sont le clone propre sur le second Mac et Windows, le test distant à trois, l'ouverture du coffre DVC, puis la migration décrite dans l'ADR 0004.
Pour exécuter l'installation dans le bon ordre — d'abord sur le Mac pilote, ensuite sur l'autre Mac et Windows — suivre ONBOARDING.md.
Le studio Blender compact est intégré dans tools/blender-agent-studio/. Il est versionné dans ce
repo sans son historique Git et sans les 7,82 Go d'assets sources : catalog/assets.json en conserve
l'inventaire vérifiable. Claude découvre automatiquement
.claude/skills/blender-production-studio/ et Codex
.agents/skills/blender-production-studio/ depuis la racine de GAME.
Avec Claude Code, lancer claude depuis la racine puis écrire initialise l'environnement. Le skill projet setup-game détecte Mac ou Windows, installe aussi le client Tailscale de test distant, exécute le bon setup et rend le verdict du doctor. La connexion Tailscale reste un écran interactif individuel ; aucune clé n'est partagée avec Claude.
Pour intégrer Zak et Sean : Nils envoie en privé des invitations Tailscale individuelles, jamais une clé d'authentification. Le tailnet actuel est personnel et distinct de l'organisation GitHub ; comme le jeu vise un usage commercial, son propriétaire doit confirmer ou adopter un plan compatible avant le prochain playtest structuré (conditions des offres Tailscale). Après acceptation, chacun clone le repo et demande à Claude initialise l'environnement pour jouer à distance. L'absence d'un lot DVC réellement poussé et restaurable ne bloque pas ce setup, mais bloque désormais toute modification ou transmission des masters des FBX actuels.
main refuse les pushes directs sur chaque clone initialisé grâce au hook partagé, et Claude a la même interdiction. Les branches suivent feat/..., fix/..., art/..., audio/..., data/..., docs/... ou chore/... ; le script publish-task pousse ensuite la branche et ouvre sa PR. Zak et Sean n'ont pas à administrer ou merger les PR : ils livrent une branche testée et Nils gère l'intégration actuelle. Le dépôt étant public, une protection serveur et des rôles moins permissifs font désormais partie de la gate G0 du plan maître.
Ne clonez pas le projet dans iCloud, OneDrive, Dropbox ou un dossier réseau.
Après installation de Homebrew :
brew install git git-lfs gh
gh auth login --web
gh auth setup-git
gh repo clone NOT-THAT-WAY/GAME
cd GAME
./scripts/setup-macos.sh --all --remote-playLe script installe Git/LFS, GitHub CLI, Unity Hub, Visual Studio Code, son extension Unity/C# et Tailscale, prépare Smart Merge et ouvre les installations interactives. DVC reste hors du setup initial. Une fois Unity et la connexion Tailscale terminés, relancer :
./scripts/setup-macos.sh --remote-playSur une machine vierge, installer les outils nécessaires au clone puis rouvrir PowerShell :
winget install --id Git.Git --exact
winget install --id GitHub.GitLFS --exact
winget install --id GitHub.cli --exactEnsuite :
gh auth login --web
gh auth setup-git
gh repo clone NOT-THAT-WAY/GAME
Set-Location GAME
powershell -ExecutionPolicy Bypass -File .\scripts\setup-windows.ps1 -All -RemotePlayAprès l'installation de Unity et la connexion Tailscale, relancer setup-windows.ps1 -RemotePlay.
Les scripts sont idempotents. L'éditeur Unity reste une étape interactive parce que Hub doit confirmer l'architecture et les modules de build.
État mesuré le 9 août 2026 : trois objets LFS — le labyrinthe, le personnage de base et son clone riggé — et zéro pointeur DVC. Le budget interne du prototype reste limité à 2 Gio d'exports actifs. Les clones et builds restent possibles, mais deux masters sont absents et le troisième n'est pas encore restaurable depuis R2 : la première sauvegarde DVC reste prioritaire avant leur prochaine modification ; voir la stratégie d'assets.
Les masters lourds ne sont pas envoyés dans GitHub. Une fois l'URL privée communiquée par l'administrateur du stockage :
./scripts/setup-macos.sh --install-tools --with-assets
./scripts/assets-macos.sh configure "s3://ntw-assets/game" \
--endpoint "https://<ID_DE_COMPTE>.r2.cloudflarestorage.com" \
--region "auto" \
--profile "game-assets"
./scripts/assets-macos.sh pullpowershell -ExecutionPolicy Bypass -File .\scripts\setup-windows.ps1 -InstallTools -WithAssets
.\scripts\assets-windows.ps1 -Action Configure -RemoteUrl "s3://ntw-assets/game" `
-EndpointUrl "https://<ID_DE_COMPTE>.r2.cloudflarestorage.com" `
-Region "auto" `
-Profile "game-assets"
.\scripts\assets-windows.ps1 -Action PullGitHub garde seulement les pointeurs DVC, les exports nécessaires au jeu et les métadonnées. Les credentials restent propres à chaque membre et ne sont jamais commités.
| Donnée | Emplacement |
|---|---|
| code, scènes, réglages, documentation | GitHub public actuellement ; décision G0 en attente |
| PNG/FBX/WAV nécessaires au build | Git LFS, avec budget |
| Blender/PSD/sessions DAW/sources brutes | remote DVC privé |
| secrets et preuves nominatives | gestionnaire dédié |
Library, caches, logs et builds |
local, ignoré |
Sur le même réseau local, après le premier import et le merge du lockfile :
# Mac hôte
./scripts/first-test-macos.sh host --name "TON_NOM"
# Second Mac
./scripts/first-test-macos.sh client --address "192.168.1.42" --name "NOM_MAC_2"# Windows
.\scripts\first-test-windows.ps1 Client -Address "192.168.1.42" -Name "NOM_WINDOWS"Le succès est simple : les trois noms apparaissent dans les trois fenêtres. Voir le protocole complet.
Si chacun est chez soi, ne pas utiliser l'IP 192.168.x.x. Le Mac mini de Zak peut héberger et jouer :
# Hôte distant
./scripts/remote-test-macos.sh host --name "Zak"
# Client Mac avec l'IP Tailscale 100.x.y.z affichée par l'hôte
./scripts/remote-test-macos.sh client --address "100.x.y.z" --name "Nils"# Client Windows
.\scripts\remote-test-windows.ps1 Client -Address "100.x.y.z" -Name "Sean"Voir le protocole distant. Aucun serveur dédié ni port de box n'est nécessaire ; la machine hôte doit simplement garder le jeu ouvert.
| Couche | Choix actuel | État |
|---|---|---|
| Moteur | Unity 6000.3.20f1 LTS |
dans le projet |
| Rendu | URP 17.3.0, Forward+ |
dans le projet |
| Input | Unity Input System 1.20.0 |
dans le projet |
| Réseau local | FishNet 4.7.2 + Tugboat |
dans le projet |
| Tests multi-instance | Multiplayer Play Mode 2.0.2 |
dans le projet |
| Réseau de développement distant | Tailscale, hors du build | setup Mac/Windows |
| Masters lourds | DVC 3.x + Cloudflare R2 privé | remote choisi, premier push/restore en attente |
| Assets de build | Git LFS + UnityYAMLMerge | configuré |
| Audio | Wwise 2025.1.4 |
après gate Mac/Windows |
| Steam | Steamworks.NET 2025.164.1 + FishySteamworks 4.1.1 |
après validation distante |
FishyFacepunch n'est pas repris car son dépôt est archivé. Tugboat reste le profil quotidien ; Steam viendra en profil additionnel.
Tout le monde touche au gameplay, au contenu et aux tests. Les profils indiquent le meilleur point de départ, pas une propriété permanente.
| Profil | Affinités | Prochain point d'appui naturel |
|---|---|---|
| Zak | technique, réseau, logique, juridique | test FishNet/Windows, règles réseau, licences |
| Sean | création, visuel, narration, illustration, design, Unity | blockout, lisibilité du pivot, pipeline art |
| Nils | technique + artistique, son, vision globale, IA | DVC, Wwise, cohérence d'intégration |
Le membre qui possède le PC prend la validation Windows. Les rôles pilote/binôme/testeur tournent à chaque lot afin qu'au moins deux personnes comprennent chaque système.
- Plan maître, gates, charge et ordre d’exécution
- Backlog détaillé prêt à distribuer en issues/PR
- Workpacks prémâchés par pôle et ownership des fichiers
- Matrice de tests, rotations et preuves attendues
- Plan de fermeture de l’audit jusqu’au premier duel M1
- Smoke test humain minimum HT-00
- Lancement et collecte locale de HT-00
- Contrat du jeu, permissions et interdictions
- CI et builds Mac/Windows
- Roadmap et priorités
- Ordre d'installation des trois postes
- Installation Mac/Windows
- Studio Blender intégré et skills
- Premier test de connexion
- Test depuis des réseaux différents
- Test jouable du labyrinthe
- Blocage Windows IL2CPP et build Mono de secours
- Travail à trois
- Assets hors GitHub
- Gestion des données
- Rapports DVC et Blender→Unity validables
- Options DEC-01 à DEC-04 avant M1/M2
- Stack et versions
- Architecture autoritaire : topologie, ticks, murs et joueur
- Audit du document maître du 5 août 2026
- Règles de contribution
- Conception du jeu
HT-00 reste consigné INCOMPLETE et ne bloque pas M1. Deux pistes avancent désormais ensemble :
baseline propre, machines et masters récupérables, puis preuve distante ; et provenance des
builds → topologie typée → scène grise à un mur → murs et joueur par tick → réseau dégradé → premier
duel humain. La map 16×16 revient ensuite comme test d’intégration, pas comme banc de diagnostic.