← Retour aux projets 
Code En cours
MinecraftClaude — Claude joue à Minecraft
Expérience multi-agents : Claude Code construit de zéro son propre framework, puis joue en autonomie à Minecraft survival en mode multi-agents.
Expérience multi-agents : Claude Code construit de zéro son propre framework, puis joue en autonomie à Minecraft survival en mode multi-agents.
MinecraftClaude est une expérience multi-agents avec un objectif simple mais ambitieux : laisser Claude construire de A à Z le framework nécessaire pour jouer à Minecraft, puis jouer en autonomie.
Aucun code de jeu n’est écrit à la main. L’orchestrateur lance des agents Claude Code qui conçoivent, implémentent et testent le système — puis un agent de jeu prend le relai et joue en survival.
Il n’y a pas d’appel direct à l’API Anthropic : tout passe par le CLI claude -p, en utilisant la session Claude Code de l’utilisateur.
Le système repose sur quatre agents distincts, coordonnés par un orchestrateur Python :
Lit l’état du projet (roadmap.json, inventaire de code) et décide de la prochaine tâche à confier au Dev. Évalue aussi les demandes de nouvelles fonctionnalités pendant la phase de jeu — en rejetant tout ce qui ressemble à de la triche (commandes /give, mode créatif, etc.).
Reçoit une spécification de tâche et l’implémente en utilisant les outils Claude Code (Bash, Read, Write, Edit, Glob, Grep). Teste son travail avant de rendre compte. Peut relancer jusqu’à 3 fois si l’implémentation échoue.
Tourne en boucle continue pendant le jeu. À chaque itération, il reçoit l’état du jeu (position, santé, inventaire, blocs et entités proches), appelle claude -p pour décider de l’action suivante, et envoie la commande au bot. Maintient une mémoire persistante (objectifs, plan, acquis, tentatives échouées) qui survit aux redémarrages.
Un bot Mineflayer qui reçoit des commandes JSON via stdin et renvoie l’état du jeu via stdout. Gère le déplacement (A* pathfinding), le minage, le chat, et expose une vue spectateur navigateur via prismarine-viewer.
Les agents ne communiquent jamais directement entre eux — tout passe par des fichiers JSON dans project-state/ :
roadmap.json → avancement des jalons
code-inventory.json → fonctionnalités implémentées (anti-doublons)
pm-decision.json → décision courante du PM
tasks/<id>.json → spécification d'une tâche
current-report.json → rapport du Dev
bot-memory.json → mémoire persistante de l'agent de jeu
bot-capabilities.json → liste des commandes disponibles (mise à jour dynamiquement)
bot-requests/<id>.json→ demandes de nouvelles fonctionnalitésCela rend le système transparent, reprise-après-panne, et facile à auditer.
L’orchestrateur pilote une boucle PM → Dev sur 5 jalons :
| Jalon | Description |
|---|---|
| M1 | Infrastructure Docker, connexion bot au serveur |
| M2 | Actions Mineflayer (déplacement, minage, chat), scan de blocs |
| M3 | Boucle de jeu agent ↔ bot, mémoire persistante |
| M4 | Vue spectateur navigateur, relay chat SSE |
| M5 | Comportements survival (sécurité, ressources, outils, abri) |
Une fois tous les jalons validés, la phase de construction s’arrête et le jeu commence.
L’agent de jeu tourne en boucle : il reçoit l’état, appelle Claude, exécute l’action, recommence. En parallèle, si Claude constate qu’il lui manque une capacité (ex : poser un bloc), il soumet une demande de fonctionnalité. Le PM l’évalue, le Dev l’implémente, et la nouvelle commande est disponible à l’itération suivante — sans redémarrage.
Le bot joue en mode survival légitime : il doit collecter du bois, fabriquer des outils, construire un abri, survivre la nuit.
L’orchestrateur démarre le serveur Minecraft (Docker), exécute la phase de construction si nécessaire, puis lance la boucle de jeu. La vue spectateur est accessible sur http://localhost:3007.