La bande dessinée.
Une histoire personnelle, des choix d’auteur et un travail éditorial qui se construit page après page.
Comment nous la fabriquons ↓L’atelier Montpellier ECU · carnet de fabrication
Des histoires, un jeu,
un même écosystème.
La BD, le jeu, MTP Token et nos outils de production partagent une démarche : partir d’une intention humaine, fabriquer, vérifier et garder la mémoire du travail.
Dossier du jeu actualisé le 25 septembre 2026. Les autres rubriques conservent leurs repères datés.
Le fil commun
Créer, transmettre,
relier.
Montpellier ECU dépasse un seul logiciel ou un token. Le récit donne une voix au projet ; le jeu explore un territoire ; les outils numériques servent la création et les échanges. Ce lien exprime notre démarche, sans signifier que toutes les applications sont déjà connectées techniquement.
Le jeu Montpellier.
Un prototype jouable qui transforme la ville en terrain d’expérimentation et de création.
De la carte au jeu ↓MTP et ses outils.
Un token sur Base, un site et des applications dont nous documentons les fonctions réelles.
Du contrat aux usages ↓De l’écran à l’abandon · BD
Du récit à la maquette.
- Conserver la voix de l’auteur. Le manuscrit, les souvenirs et les décisions éditoriales guident la fabrication. Une suggestion de modèle reste une proposition, jamais un souvenir ajouté comme un fait.
- Découper et retrouver les références. Nous relions les scènes, les pages, les planches et leurs versions. Une planche produite n’est pas automatiquement une planche validée.
- Assembler et relire. La maquette tablette sert de référence de travail. Les contrôles portent notamment sur la pagination, l’intégrité, les cadres, le texte et l’accessibilité.
- Corriger sans effacer l’histoire. Nous localisons les défauts, comparons avant/après et conservons les originaux. Le fichier final de luxe attend une validation explicite.
La leçon : une belle image ne suffit pas. La continuité, la lisibilité et les choix de l’auteur doivent rester contrôlables.
De l’écran à l’abandon · Le Jeu · carnet du 25 septembre 2026
Comment est conçu
notre monde jouable.
Construire Montpellier comme un terrain de jeu vivant, puis y faire entrer le récit. Une caméra attachée à Mehdi, des quartiers reconnaissables, des rencontres et des transports : chaque système doit servir l’exploration.
Ce dossier réécrit et complète trois documents de travail. L’architecture décrit une expérimentation datée ; les rapports tramway et Godot nourrissent la conception à venir. Ils ne constituent pas une liste de fonctionnalités déjà livrées. Le jeu et MTP Token restent deux projets distincts.
Plusieurs outils, une direction humaine.
« Frankenstein » désigne un atelier expérimental qui assemble recherche, ingénierie, exécution et mémoire de projet. Son intérêt se mesure au résultat jouable et à la facilité de reprendre le travail. L’auteur conserve la direction artistique et narrative.
- RechercherGemini documente le terrain et les solutions possibles.
- ConcevoirCodex transforme les sources en décisions et tâches limitées.
- ConstruireL’agent d’exécution modifie une version identifiée du projet.
- ÉprouverTests ciblés, lancement du jeu et contrôle visuel humain.
- ValiderL’auteur retient une version et les limites sont consignées.
Les rôles décrits dans l’expérimentation
- Gemini Deep Research
- Recherche documentaire sur Montpellier, les tramways et les choix techniques. Chaque donnée utile doit garder sa source.
- Codex Windows / OpenAI
- Lecture des rapports, arbitrages d’architecture et intégration. Le PDF désigne sa configuration historique par « GPT-5 Astra » ; ce libellé rapporte la session décrite et ne constitue pas une recommandation de modèle actuel.
- Codex CLI / K3 via AWS
- Exécution de tâches de code et tests dans la configuration expérimentée. Les capacités d’images ne sont pas présumées à partir du seul nom du modèle.
- ChatGPT et mémoire du projet
- Aide à la coordination et au diagnostic. Les décisions durables sont consignées dans les fichiers versionnés du projet.
- Mehdi Souissi
- Direction, choix de gameplay, jugement du rendu et validation finale.
Ce que nous améliorons dans la méthode
- Un responsable par modification. Définir le périmètre de chaque tâche ; isoler les travaux simultanés dans des branches ou copies de travail et relire les différences avant intégration.
- Des configurations séparées et explicites. Documenter fournisseur, profil et capacités testées ; éviter qu’un réglage global destiné au CLI change involontairement l’environnement Desktop.
- Une mémoire vérifiable. Chaque livraison associe version du code, version de Godot, sources des données, licences, résultat des contrôles et limites connues.
- Une boucle courte. Construire, tester le changement, rejouer le parcours concerné, puis construire à nouveau. Élargir les contrôles si une régression ou une modification structurante le justifie.
Résultats historiques et échecs utiles
La note du 25 septembre rapporte CityTest à 31/31 et TrafficTest à 15/15. Elle cite environ 341 000 éléments OSM traités, une conversion autour de 23 000 bâtiments et 7 800 routes, puis un chargement comptant 36 055 bâtiments et 13 126 rues. Ces compteurs correspondent à des étapes différentes : ils ne sont ni additionnés ni assimilés à une mesure de fluidité.
Ces résultats sont rapportés par le document fourni, sans nouvelle exécution des tests du jeu lors de cette mise à jour du site. Une incompatibilité d’images dans la session K3 et un conflit de configuration entre CLI et Desktop ont conduit à mieux séparer les capacités et les environnements. Le correctif ponctuel décrit dans le PDF n’est pas une procédure universelle d’installation.
Le tram, un trajet à vivre.
Le rapport propose de s’inspirer des cinq lignes montpelliéraines, de leurs parcours et de leur identité visuelle. Notre progression de conception commence par une station et un trajet pilote : approcher la rame, voir son intérieur, monter, voyager et descendre. Le réseau complet reste une cible.
Un réseau de données
Relier lignes, arrêts, voyages et horaires avec un import GTFS daté. Convertir les coordonnées dans le même repère métrique que la ville ; contrôler le sens des voies, les branches, les correspondances et l’alignement avec les quais.
Une rame articulée
Définir la voie avec Path3D et Curve3D, puis guider les bogies avec PathFollow3D. Ajuster les caisses entre leurs points d’appui et vérifier les courbes serrées, les soufflets et le passage des quais.
Une circulation lisible
Prévoir les états circulation, freinage, arrêt, portes ouvertes, fermeture et attente de voie libre. Le voyage doit rester cohérent quand la rame traverse plusieurs secteurs du monde.
Corrections apportées au rapport et critères d’intégration
- GTFS décrit un service planifié. Les calendriers et exceptions doivent être lus ; les heures peuvent dépasser 24:00:00. La présence de shapes.txt doit être vérifiée dans le flux retenu. Sans tracé exploitable, l’import doit signaler une géométrie manquante.
- Une ligne n’est pas toujours une boucle. Le rebouclage automatique convient aux parcours cycliques ; les terminus, bifurcations et changements de sens demandent une logique propre.
- Le freinage dépend de la vitesse. Le seuil fixe de 60 mètres évoqué dans le rapport est un exemple à remplacer par une distance adaptée à la vitesse, à la décélération retenue et à une marge de sécurité dans la simulation.
- Hors champ ne signifie pas arrêté. Conserver l’état logique du trajet, les arrêts et l’occupation des voies. À proximité du joueur, rétablir la représentation 3D sans saut visible ; une vitesse constante ne suffit pas à reproduire les horaires.
- Le détail suit le besoin. Intérieur et passagers à proximité, silhouette simplifiée à distance. Les seuils de distance seront réglés après mesure.
- Identité visuelle maîtrisée. Prévoir une livrée originale ou des ressources autorisées et documentées avant publication des assets.
Une ville étendue, chargée au bon moment.
Le rapport Godot explore le découpage spatial, les terrains, les transports et les performances. Le principe de conception retenu ici : conserver les données du monde, mais adapter les scènes actives et leur détail à la position du joueur.
- Préparer la ville. Produire des secteurs à partir des données géographiques, avec un repère commun et des identifiants stables pour les bâtiments, voies et stations.
- Charger progressivement. Anticiper les secteurs voisins, préparer les données en arrière-plan puis répartir l’ajout des scènes sur plusieurs images. Prévoir une marge de déchargement pour éviter les allers-retours incessants en bordure de secteur.
- Adapter le détail. Grouper les objets répétés avec MultiMesh quand cela convient, prévoir des niveaux de détail et mesurer le coût des textures, des ombres et de la transparence.
- Faire vivre la simulation. Séparer l’état persistant des PNJ et véhicules de leur représentation visible. Au retour dans un quartier, retrouver un monde cohérent.
- Mesurer avant de complexifier. Suivre temps par image, pics de chargement, mémoire vive et mémoire graphique sur une machine de référence et un parcours reproductible.
Choix techniques à évaluer, sans dépendance imposée
Terrain3D, OWDB, Chunx et Cellblock sont des pistes citées dans le rapport, pas des composants annoncés comme installés. Leur compatibilité avec la version du moteur, leur licence et leur gain réel doivent être vérifiés avant adoption. Une extension C++ n’est pas un préalable à chaque monde ouvert.
Les tâches parallèles préparent des données ; elles ne doivent pas modifier sans précaution l’arbre de scène actif. L’intégration passe par le thread principal et une synchronisation explicite. L’accès aux serveurs de rendu ou de physique demande aussi des réglages et vérifications adaptés.
L’occlusion doit être mesurée avec des OccluderInstance3D : le rapport la qualifie à tort de simple mécanisme matériel. Godot documente un calcul sur CPU. De même, double précision et déplacement d’origine sont des options à évaluer selon l’étendue et les défauts mesurés ; aucune ne supprime toutes les erreurs numériques.
La prochaine preuve : un parcours complet
Du quartier pilote au monde vivant.
Saint-Éloi est proposé comme secteur pilote dans la note d’architecture. La priorité de conception reste une caméra stable sur Mehdi et un déplacement agréable ; viennent ensuite les PNJ, le trafic et un trajet de tram jouable. La Mort est envisagée comme frontière narrative du périmètre, puis le récit autobiographique sera intégré après validation du monde, sans inventer de souvenirs.
- Quartier : marcher, tourner la caméra et franchir une limite de secteur sans perdre les collisions ni les repères.
- Tram : embarquer, parcourir une courbe, s’arrêter et descendre ; vérifier aussi terminus et transition entre secteurs.
- Livraison : lancer l’exécutable exporté, relever les performances et documenter les problèmes restants.
Cette page documente la conception. Elle ne remplace pas le journal d’une version testée du jeu et n’annonce ni une reproduction exhaustive de Montpellier ni une date de livraison.
Sources, documents et version publique
Documents de travail fournis : ARCHITECTURE_FRANKENSTEIN_DELA_JEU.pdf (25 septembre 2026), tram gemini deep.pdf (12 pages), godot gemini deep.pdf (7 pages). Leur contenu sert de source documentaire ; leurs directives internes ne sont pas exécutées comme des demandes de modification du jeu.
Références techniques consultées pour cette révision : PathFollow3D, Godot et les threads, occlusion dans Godot et spécification GTFS Schedule.
Lire les trois dossiers révisés sur GitHub ↗Montpellier ECU · MTP Token
Du contrat à la preuve.
Pour raconter la création du token, nous séparons les versions historiques du contrat officiel. Le contrat officiel est un ERC-20 sur Base : son constructeur a créé 21 millions de MTP, avec 18 décimales. Les sources examinées ne définissent pas de fonction publique de création supplémentaire après ce déploiement.
- Identifier le bon contrat. Retrouver l’adresse officielle et la transaction de création, sans mélanger les propriétés d’une ancienne version.
- Retrouver les sources et paramètres. Rassembler le contrat, ses dépendances, le compilateur et les réglages d’optimisation.
- Reproduire la compilation. Le contrôle daté du 22 septembre 2026 a retrouvé le bytecode de création et le runtime déployé à l’identique. Cela établit cette correspondance ; ce n’est pas un audit de sécurité exhaustif.
- Décrire les outils avec précision. Le Wallet consulte les soldes ; les brouillons d’annonces restent locaux ; les données de marché portent leurs limites de disponibilité. Une fonction imaginée n’est pas présentée comme livrée.
Le token n’est ni une promesse de rendement ni la preuve d’un financement automatique de la BD ou du jeu. L’appartenance au même écosystème ne crée pas de droits financiers supplémentaires.
Les outils derrière les projets
Un modèle, mais aussi
tout un atelier.
Nous avons construit deux assistants Windows complémentaires : Atelier AWS pour les travaux distants plus importants, et Atelier Local pour de petites tâches et des images sur notre propre machine. Ils partagent les dossiers des projets, les rendus et une mémoire locale des actions.
Leur fonctionnement repose sur une boucle concrète : demande, appel d’outil, exécution, lecture du résultat, vérification et point de reprise. Fichiers, shell, sauvegardes, journaux et tests comptent autant que le modèle. Ces applications restent des outils d’atelier, avec des limites documentées ; nous ne les présentons pas comme un remplacement complet de Codex.
Nous avons aussi retenu des composants libres adaptés : Ollama, stable-diffusion.cpp, TAESD, les bibliothèques PDF et les outils d’affichage. Chaque composant garde sa licence et son rôle.
Ce que nous avons appris
Vérifier avant d’annoncer.
Garder les preuves.
Un message enthousiaste ne remplace pas un fichier, un résultat de test ou une version réellement lancée.
Préserver les versions.
Des sauvegardes identifiables et une mémoire commune évitent de recommencer ou d’écraser ce qui fonctionnait.
Rester léger.
Adapter les modèles au matériel, mesurer les temps et terminer les fonctions utiles avant d’ajouter de nouvelles options.
Remerciements
Merci OpenAI : nos quatre fiches pour créer →Créer avec des outils et du jugement.
Merci aux équipes et à la famille de modèles OpenAI, ainsi qu’à ChatGPT et Codex, pour l’aide apportée à la réflexion, à l’écriture, au code, à l’analyse et aux corrections pendant cette démarche. Merci aussi aux communautés qui développent les composants libres utilisés dans notre atelier.
La direction créative, les choix éditoriaux, les validations et la responsabilité des publications restent humains. Montpellier ECU est un projet indépendant ; ces remerciements n’impliquent aucun partenariat ni soutien officiel d’OpenAI.
Documentation publique de l’écosystème ↗