Developer Diary – Fragments
The project that starts where it ends
No other project has ever required me to work in such a backwards way. Both in terms of its components and its mechanics, Fragments is a game in which each stage is intertwined with the previous one, whilst depending on the next. You have to validate the end to validate the beginning, but how can you validate the beginning when it depends on the end being validated?
FEASIBILITY AS A STARTING POINT
The essence of Fragments lies in its components. You simply cannot go wrong with them. All these pieces, despite their distinctive appearance, must fit together just like those of a traditional jigsaw puzzle. Yet their manufacturing processes have very little in common.
Take a classic jigsaw puzzle: to obtain the product you’re all familiar with, the factory prints the final image onto paper and then sticks it onto cardboard. A press cuts out all the pieces in a single step. The jigsaw puzzle is then whole and fully assembled. The pieces are subsequently separated and packed into bags. This process ensures that each piece fits together with its neighbours, and with no others.
Now consider Fragments: one piece must be able to connect to a second piece, detach from it to connect to a third piece along the same edge—or even to a fourth piece—which must itself be able to connect to another piece. The classic puzzle approach is therefore impossible to apply here.
With such unique components, it all starts with this question: Will the factory be able to produce a game that works this way, with the same quality as a traditional puzzle?
It’s actually almost a metaphysical question: Do two blades with the same cutting path produce the same result as a single blade that cuts the same path twice?
I’m giving you five years to find the solution.
Five years – that’s how long it took from the first time I saw the “Puzzle Stories” prototype to the release of Fragments – Solara.
DECONSTRUCT TO RECONSTRUCT
Assessing feasibility with the factory is perhaps the most black-and-white stage of development. We outline our (numerous) requirements to the factory, and they outline their (also numerous) constraints. We discuss, test, make changes, and retest—month after month. But in the end, the answer is either yes or no. Simple. In our case, it’s a yes (what a relief!). Now the real work can begin. And the to-do list is a long one.
Writing a scenario
It’s crucial that, right from the start of the story, the player wants to find out what happens next and see it through to the end. And we quickly saw this during our test runs: fiddling with these pieces without really understanding why simply leads to confusion. Confusion leads to getting stuck, getting stuck leads to frustration (and frustration leads to the dark side of the force).
Writing a beginning, a middle, and an end helps to provide context, goals, rewards, and the desire to go further. I invite you to read the designer’s diary if you haven’t already. (available HERE) With each iteration, with every change to the material or illustrations, you must ensure that the story and its writing remain consistent. Significant changes may therefore still occur right up until the very last test.

Illustrate each jigsaw piece
In a narrative game where players must carefully observe the illustrations, even the slightest imbalance in an element can make a section either too easy or too difficult. The aim is to control the pace so that it serves the story: a tense scene should convey a sense of urgency, with events unfolding in rapid succession; a quiet moment may require more observation and reflection. Each element must therefore appear in the right place, with just the right balance of prominence or subtlety. I’m not even talking about the atmosphere or the world-building. I’m talking about the level of detail, the points of focus… So I’m talking about iterations and refinements.
Whenever the designer comes up with a puzzle for me, we consider whether it comes at the right moment, whether it fits with the jigsaw pieces involved, and whether it adds something interesting. If all the boxes are ticked, then I put together a briefing for the illustrator. We then discuss what the player might be thinking at that moment, where they’ve come from, and where they want to go. This allows us to reveal or hide elements to suit our needs and the pacing requirements of the scenario. Once the sketch is complete, we run a test, then adjust the illustration, test it again, and repeat the process. If a message is difficult to convey through the illustration, we rely on the text. On the other hand, if the text starts to feel too heavy-handed, we rely on the illustration. All these elements are therefore complicated to implement, but when used correctly, they act as tools we can utilise to vary the difficulty or the pace.
It is thus impossible to finalise every illustration on the first attempt. This stage takes an enormous amount of time. And redrawing an illustration from scratch takes far longer than rewriting a piece of text (provided that the new text does not alter the structure of the storyline or its stakes). We refine the work as we go along: we carry out initial tests using rough sketches. We adapt them if necessary, then test the sketches in colour. We make further adjustments when needed, then finalise the textures and lighting. At this stage, the tests should primarily serve as a final check. Normally, only very minor adjustments remain at this point. Some test runs therefore combine finished illustrations and simple sketches, as not all of them have progressed at the same pace. Right up until the very last test run, significant changes may still be made. (does that sound familiar?)



Envisioning the components
The components must allow for a simple, effective set-up, without any spoilers. We’re looking for a quick set-up to allow players to dive straight into the story, and components that are easy to collect and then put away: the components must take a step back and let the experience take centre stage. This is the usual part of our work, even for a card game or a tile-laying game: ensuring that all the elements highlight the game’s strengths whilst minimising its flaws.
With Fragments, the real challenge lies in the countless possible connections. You need Excel spreadsheets in every direction, with clearly defined nomenclatures and codes, to check that each edge connects only to the intended edges. These edges, in fact, are at the heart of the mechanics: they allow or prevent connections, control the player’s actions, the order in which elements are unlocked, and the pace of the story. These checks are complex, and we try different ways of identifying dead ends. When we spot one, we’re glad to have avoided a problem, but we’re disappointed at the prospect of possibly having to rewrite a significant portion of the story.
Right up until the very last test, significant changes may still be made (no, you’re not mad).


Faster and more reliable, but sometimes too detached from the components.
Improving ergonomics
The player must concentrate on the story and the puzzles, whilst taking care not to make any ruling-related mistakes. Turning over a tile when they are not allowed to do so could block them permanently. Separating two tiles that should have remained joined could give them the answer to a puzzle.
We therefore need clear iconography and solid rules that cover all eventualities while leaving room for surprises in future boxes. But we also need to limit the number of pictograms so that they are easy to distinguish and remember. Even if it means abandoning some great puzzle ideas if their pictogram is used too rarely: we don’t want players to have to remember something that’s almost useless. We therefore refine the iconography throughout the testing process to achieve a coherent and flexible, yet limited, system. Significant changes may still be made right up until the very last test (you get the idea?).


Testing
Testing narrative games is the worst. I wouldn’t wish it to anyone… Each tester can only play once: you can’t forget either the ending of the story or the solution to a puzzle. If something is hidden in the illustration, only someone who has never seen it before can tell us how difficult it is to spot. So we always have to find new testers.
And yet, if you get several people to play the same version, you’ll get different results. If you read, ‘As soon as I got out of bed, I nearly stepped on a dead mouse – a gift left behind by my cat’, what catches your attention most of all?
– ‘Ah, I was asleep!’
– ‘Ah, I’ve got a cat!’
– ‘Ah, I’ve got mice in my house!’?
And thirty minutes into the game, with loads of extra information, which one will stick in your mind? Every player remembers different things. And I’m only talking about text here. Imagine all that with detailed illustrations… To achieve the desired pace and emotions, there’s no secret: you have to test, retest, change, retest, change again and retest over and over. Just like a jigsaw puzzle, everything is interlinked; each step depends on the others. And just like a jigsaw puzzle, it is only at the end – when the final piece is in place and all the steps have been validated together – that we can finally see the whole picture. You have to constantly take things apart to put them back together. It takes a long time. And it’s difficult to standardize as well: yet every problem has its own unique solution. We repeat things a lot, but always in a different way. Ultimately, it is all these unique features that make Fragments a one-of-a-kind game, from the idea in the designer’s mind right through to your gaming table.

