Workshop notebook · Thomas Cohu

Monster stories

Published on 1 October 2026

At first, I just wanted to learn how to make a small game with Godot. Monstres Papillons became an experimentation ground for design, coding agents… and even music.

A memory of Windows 3.1

I started thinking about this game a little over a year ago. I wanted to learn how to make a game with Godot, an open source 2D and 3D game engine. I was looking for a simple enough idea to get started and discover the mechanics, the scripting language, sprites, sound work…

I began with the excellent Godot tutorials, all by hand, to get an overview. And in the meantime, an idea kept turning in my head:

I need a simple little game, for mobile. Hey, what if I remade a version of that old Windows 3.1 game I played with my brother-in-law when I was a kid?

I couldn’t remember its name at all: it was JezzBall. But I remembered its mechanic well. Balls move around a grid; you fire vertical or horizontal cuts to shrink the playfield, without letting a ball hit a cut while it is still being built. A game of patience, and we had a lot of fun setting each other challenges.

A simple mechanic, fairly basic movements: it seemed perfect for experimenting with Godot. Making the balls move smoothly as the engine gets updated, computing bounce angles inside a rectangular area, then finding the zones to remove after each cut… I had plenty to learn.

February 2026: first attempts

While gently training myself on Godot, in the evenings or at weekends when I had time, I started talking with Le Chat de Mistral to explore the approach, especially the visual one. My first attempts were honestly not very pretty. :D

Four pixel art attempts of pink balls, with different shadows and highlights. — First visual attempts: balls, still far from the monsters and the butterflies.

I also explored the algorithms to handle the cuts and compute the zones. The AI helped me write small pieces of script and test approaches, like the flood fill: a traversal of neighbouring cells that lets you identify a zone after a cut.

The idea kept growing. On mobile, I wanted a fun game, with a bit more character than plain balls.

But I didn’t go any further at that point. I left the subject on hold for several months.

Late August: picking it back up with Codex

I spent a good part of the summer playing with Codex. Starting from a few open source proposals, I built myself skills: sets of instructions to work with the agent on design as a pair, idea exploration, specifications or user experience.

A small toolbox to move forward in concrete steps, while following a precise thread. By repeating the approach over and over, I found a method that works well for me:

Start from a general idea and ask for mock-ups.
Iterate on the visuals to sharpen the direction.
Define the scope of a small prototype.
Write specifications limited to that first attempt.
Have the prototype implemented, then test it.

Three visual explorations: an arena of translucent candies, a cartoon blue board and a garden populated with fluffy monsters. — Three tracks to search for the game’s character. These are exploration mock-ups, not screenshots of the final game.

On this project, Codex turned out to be very much at ease with Godot and its constraints. It also let me produce small visuals that I could adapt and use as sprites. My job was to choose the art direction, work on the game mechanics and steer the development.

A workshop within the workshop

To make a good game, you need steady progression, achievable objectives that still require a challenge, fun… In short, quite a few ingredients that are hard to bring together. You can’t get there on the first try. An idea that looks good on paper can very well turn out to be a dead end once you implement it and try to play.

To build the levels and test all my (far too many!) ideas, I built a level design workshop inside Godot. It lets me test the mechanics, compose levels and check whether they are playable and fun.

The level workshop inside Godot: two monsters on a blue board, a choice of orthogonal, diagonal or curved terrains, and a button to test the configuration. — The workshop inside Godot: compose a level, pick a terrain variant, then move on to the playable test.

In practice, it is always the same cycle: idea => a prototype => tests => evaluation => fixes… then abandoning the track, integrating it into the game, or a new idea (ideas come from doing, from confronting intuition with something concrete). And you start again. The playability and fun tests end up deciding.

I had thought of many little things: a monster that breaks walls, bonuses to collect, terrains with relief… Some ideas are simply postponed; others are dropped entirely.

I also explored narrative ideas, notably a whole adventure around a lonely robot that has to terraform a planet… Well, I may come back to that later. :)

Delegating the code, keeping the direction

At first, I honestly had the ambition to code in Godot myself. But in practice, I quickly left that part to coding agents so I could focus on my strengths: design choices, planning and priorities.

I carry the intention. The AI can propose tracks and implement them; it is up to me to decide where I want to go, then to check what the result feels like by playing.

Today, I work with Codex as much as with Mistral Vibe. Codex mostly accompanies me on design, brainstorming and planning. For implementation and bug fixing, I rather work with Mistral Vibe.

I notably had a very good session reworking the game engine with Mistral Vibe and GLM 5.3, to optimise performance. On that kind of work, this combination proved remarkably effective: code analysis, performance measurements (benchmarks), audit and optimisation. It is a concrete example of those moments when I go back over technical choices to make the game evolve.

On Monstres Papillons, I ended up delegating all of the code writing. This experience convinced me it was possible for this project, provided a few guardrails are kept:

Design and validate the architecture. Keep an overview, even when you do not write every line.
Require tests. Check behaviours as they are implemented.
Document continuously. Before and after implementation, to keep a trace of intentions and decisions.
Stay on short loops. Limit each step so I can test myself everything that has just been added.
Come back regularly to architecture and performance. As the game grows, the code can degrade and some choices need to be revisited.

After three weeks in a row of daily work, I was very happy with the result.

And what about the music?

I am ready to use AI for pretty much everything. But sound and music, I really enjoy making them myself.

I wanted an old-school arcade atmosphere, a slightly « Nintendo » sound. I started by noodling on a keyboard to find a motif that works well, then I wrote the score in Noteflight to convert it to MIDI and get that slightly robotic steadiness that I am unable to hold when playing myself.

I still wanted to try an experiment with AI. I am very slow at writing a score. Since the theme was already composed, could ChatGPT help me write the various bass, drum and brass parts from a MIDI export of my first version?

Excerpt from the conversation with ChatGPT: a MIDI orchestration proposal, then instructions for drums, brass and a piano variation. — The theme is already composed; the experiment is about its arrangement. An excerpt of my instructions and of ChatGPT’s answer.

Well, it works rather well! I saved some time and, above all, tested a process I will probably reuse: give precise enough instructions to get a MIDI file close to what I have in mind, then listen to it and rework it.

In practice, I changed quite a lot of things afterwards, and I could have done without it. But it remains an interesting experiment!