The Montpellier ECU workshop · production journal

Stories, a game,
one shared ecosystem.

The comic, game, MTP Token and our production tools share an approach: start with human intent, make, verify and preserve the record of the work.

Documentation status as of 22 September 2026. The projects continue to evolve.

The common thread

Create, share,
connect.

Montpellier ECU extends beyond a single piece of software or token. The story gives the project a voice; the game explores a territory; digital tools serve creation and exchange. This connection expresses our approach without implying that all applications are already technically interconnected.

01 / TELL STORIES

The graphic novel.

A personal story, authorial choices and editorial work built page by page.

How we make it ↓
02 / EXPLORE

The Montpellier game.

A playable prototype turning the city into a space for experimentation and creation.

From map to game ↓
03 / CONNECT

MTP and its tools.

A token on Base, a website and applications whose actual functions we document.

From contract to uses ↓
De l’écran à l’abandon · graphic novel

From story to layout.

  1. Preserving the author's voice. The manuscript, memories and editorial decisions guide production. A model's suggestion remains a proposal, never a memory added as fact.
  2. Break down scenes and find references. We connect scenes, pages, comic panels and their versions. A produced page is not automatically an approved page.
  3. Assemble and review. The tablet layout serves as a working reference. Checks include pagination, integrity, framing, text and accessibility.
  4. Correct without erasing history. We locate defects, compare before and after and preserve originals. The final deluxe file awaits explicit approval.

The lesson: an attractive image is not enough. Continuity, readability and the author's choices must remain open to review.

Montpellier · Godot prototype

Making a city work.

We preserved the 2D and then 3D stages and identified a single current version. As of 22 September 2026, the reference is a playable V2 in development, not a V3 announced in advance.

  1. Structure the terrain. Geographic data and building footprints provide the foundation; sectors load and unload as needed to limit resource use.
  2. Build interaction. Movement, controls, trams, characters and interiors are developed in the Godot engine, then tested in the game.
  3. Export and test. We distinguish the source project from the Windows executable and test user journeys. Earlier deliveries are retained for rollback.
  4. Document limitations. A playable environment is not an exact reproduction of Montpellier: terrain, details and some scenes remain simplified.

The lesson: the version that matters is the one you can launch, test and find again, with its known defects.

Montpellier ECU · MTP Token

From contract to evidence.

To describe the token's creation, we separate historical contract versions from the official contract. The official contract is an ERC-20 on Base: its constructor created 21 million MTP, with 18 decimals. The examined sources define no public function for additional minting after deployment.

  1. Identify the right contract. Find the official address and creation transaction without mixing in properties from an older version.
  2. Find sources and parameters. Gather the contract, dependencies, compiler and optimisation settings.
  3. Reproduce compilation. The check dated 22 September 2026 reproduced the creation bytecode and deployed runtime exactly. This establishes that match; it is not an exhaustive security audit.
  4. Describe the tools precisely. Wallet reads balances; listing drafts remain local; market data comes with availability limitations. An imagined feature is not presented as delivered.
Read the evidence and limitations →

The token is neither a promise of returns nor evidence of automatic funding for the comic or game. Belonging to the same ecosystem creates no additional financial rights.

The tools behind the projects

A model, but also
an entire workshop.

We built two complementary Windows assistants: AWS Workshop for larger remote tasks, and Local Workshop for smaller tasks and images on our own machine. They share project folders, renders and a local action history.

They operate through a concrete loop: request, tool call, execution, reading results, verification and a resumption point. Files, shell, backups, logs and tests matter as much as the model. These applications remain workshop tools with documented limitations; we do not present them as a complete replacement for Codex.

We also selected suitable open-source components: Ollama, stable-diffusion.cpp, TAESD, PDF libraries and display tools. Each component retains its licence and role.

What we learned

Verify before announcing.

Keep the evidence.

An enthusiastic message does not replace a file, a test result or a version actually launched.

Preserve versions.

Identifiable backups and shared memory help avoid restarting work or overwriting what worked.

Keep it lightweight.

Match models to hardware, measure timings and finish useful functions before adding options.

Acknowledgements

Create with tools and judgement.

Thank you to the OpenAI teams and model family, and to ChatGPT and Codex, for helping with thinking, writing, coding, analysis and corrections throughout this process. Thank you also to the communities developing the open-source components used in our workshop.

Creative direction, editorial choices, approvals and responsibility for publication remain human. Montpellier ECU is an independent project; these acknowledgements imply no official OpenAI partnership or endorsement.

Public ecosystem documentation ↗