Une ville, un personnage, des rencontres. Le projet transpose Montpellier en terrain d’exploration et prépare une place au récit autobiographique de Mehdi.
La conception part d’un déplacement agréable, d’une caméra stable et de lieux reconnaissables.
Saint-Éloi est proposé comme quartier pilote. Bâtiments, rues et limites de secteur doivent former un parcours lisible, avec des collisions et des repères cohérents.
Les pistes de conception associent personnages, circulation et transports. Leur état doit rester cohérent lorsque le joueur s’éloigne puis revient dans un quartier.
Le récit autobiographique est prévu après validation du monde. La Mort est envisagée comme une frontière narrative du périmètre d’exploration.
Les documents décrivent une expérimentation et les étapes suivantes. Ils rapportent des tests historiques ; ils ne constituent pas une version du jeu à télécharger depuis cette page.
Le prochain jalon décrit est un parcours complet : marcher dans le quartier, prendre un tram, descendre et vérifier l’exécutable exporté.
Voir les critères de validation ↓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.
« 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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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 ↗Une autre forme de création portée par la même direction humaine.
Explorer la bande dessinée →