How Order of the Sinking Star Was Designed

Order of the Sinking Star was in development for the better part of a decade. That length of time is not incidental to how the game turned out; it is the reason for how it turned out. As the project's director puts it, a game of this size has a very narrow window in which outside ideas can still get in. Whatever influenced it had to be there before the work started, or close to the beginning, because once you are in the middle of a production this large you are not going to change what you are doing. There is simply too much already built.

The influences that did make it in are worth naming, because they explain the shape of the final game. One was a small, punishing puzzle game that arrived shortly after his previous title: Stephen's Sausage Roll, by Stephen Lavelle. Blow calls it one of the greatest puzzle games ever made, and is quick to add that it is not for everyone. The others were a set of simple, free puzzle games that ran in a browser — modest things, made by a few different designers, with almost nothing spent on presentation.

Those free browser games are the real seed of Order of the Sinking Star. The thought that started the project was not 'let us make a bigger version of this.' It was: what if several of these tiny games, each with its own rules and its own little universe, could be played side by side — and then what if those universes came together, and the characters from one met the characters from another, and the mechanics from each started to interact with the mechanics from the rest?

That single idea is the game. It is also, as Blow notes, what consumed the entire development schedule. The goal was never merely to let one world meet another in the fiction. It was to have the objects of one world physically interact with the objects of another and produce something that neither world could have produced alone. 'When you do that, it opens up a lot of possibility.' The work that follows from that idea — searching out every interaction, finding the interesting ones, and then building levels that show them to a player — is not the kind of work that can be rushed.

Asked how a puzzle in this game actually gets made, Blow answers by describing the basic concept rather than a design method. One world has magic mirrors that teleport things around. Another has skipping stones that you push, and that skip across water until they hit land. Put those two things in the same world and you do not have to invent a puzzle; you have to ask what naturally happens. A skipping stone travels in a direction, so teleporting it means teleporting its momentum as well as its position. What does that mean? The question answers itself, and the answer is a puzzle.

This is the dividing line he draws most sharply. A puzzle is good when it comes out of what the objects are and how they behave — when solving it shows you something real about this particular game world. A puzzle is much worse when it is really just a room full of objects jammed into a position that is hard to sort out. 'That has nothing to do with what the objects are or how they behave.' It is worse for a second reason as well: a crammed-in puzzle is one that could have appeared in any other puzzle game. It is not unique to this one.

So the standing question at the desk is not 'is this hard?' It is 'what can other games not do?' Once a level exists, the team looks at it again and asks how hard they are making the player work to reach the interesting thing, and whether that work is aimed at the right thing. If a level is supposed to be about a wizard and a mirror and the way a teleport changes when those two elements meet, then making the player spend a long time shoving unrelated blocks around has broken the level. The player is no longer thinking about the wizard and the mirror. The level has stopped being about what it was about.

Not every idea is a good idea, and the game's size is partly a consequence of taking that seriously. Blow is candid that some concepts are the best in the game, some are merely good, and some are not good at all. A large number of finished puzzles were cut once it became clear they belonged in the third category. The result is a game that is enormous, but enormous because the team kept the good ideas and discarded the rest — not because everything they built got shipped.

One of the earliest design goals was to avoid the standard structure of a puzzle game: a menu of stages, played in order. The question that drove the overworld design was blunt — how do we make this not just be a glorified level select screen?

The answer took years to work out. Different regions of the overworld had to feel genuinely different from one another, which sounds obvious until you try to do it while keeping everything on topic and relevant to everything else. What works for another game is not necessarily appropriate here; the team had to find what worked for this one. Blow's own assessment is that the overworld is among the coolest parts of the finished game, and that the time spent on it was worth it.

What makes it cohere is a rule the team settled on: wherever you are, and whatever puzzles you are working through, the way you make progress on the overworld is to use what you just learned there. Work through the first levels of the region built around magic mirrors and you are rewarded with a magic mirror of your own on the overworld — one that lets you teleport to places you could not previously reach. The mechanic does not stay inside the level. It comes out into the world with you.

The freedom that follows is deliberate. There is a short, entirely linear opening, and then the player is let out into the world to go wherever they like. The game will suggest a direction, and it will warn you away from one path unless you are looking for a challenge, but it does not tell you about every route that exists. You can take the advice or ignore it, and you can change your mind at any point. Blow is explicit that this is a design temperament rather than a rule: he is not interested in controlling the experience at every moment, and he likes games that hand the player a large space of decisions to make on their own.

One of the four worlds is stocked with figures out of fantasy role-playing: a warrior, a thief, a wizard, a druid, a bard, and a priestess. The important thing about them is what they are not. They are not combat heroes. Their abilities are entirely puzzle-related.

The warrior is very good at pushing things. The thief pulls things — and, in Blow's phrasing, she pulls them pathologically. Everyone in that world is a little bit crazy, and the thief is the clearest expression of it: move away from a movable object and she will always drag it along. She will even pull another character, which produces what he cheerfully describes as a comedy of errors, everybody hauling everybody else around the map. Levels introduce these characters one at a time, show you how their abilities behave, and then start combining them so that several heroes have to solve a problem together.

Getting the heroes out of their own levels and into the overworld created a genuine design problem. The player explores the overworld with a single character, and the heroes' abilities are not available there — and if they were, it would be a mess to have a wizard zipping around the whole world at will. The solution is a system of wardrobes. Walk through one, put on an outfit, and you carry that character's abilities while you are wearing it. It is one of the more elegant pieces of design in the game, and it exists because the team refused to accept the obvious structural compromise.

Storytelling was, by the director's own account, one of the hardest problems in the project, and the difficulty came from the genre rather than from the writing. In a puzzle game, characters who talk a great deal create a mechanical conflict: the player is either cutting them off to keep solving, or standing still waiting for them to finish. Neither feels good. What the game settled on instead is deliberately clipped — you enter a hero's level, they exchange a few sentences, and that is the whole scene.

The brevity is not a shortcut; it is a harder discipline. It is far easier to explain a world's lore in depth than to refer to it obliquely and still have players understand what is being said. The short form also had to be reconciled with the game's other governing rule, that a level's idea should shine through and not be crowded out. A long scene of two soldiers reminiscing about an old battle adds backstory and world-building, but it also has nothing to do with what the player is doing, and it buries the puzzle's idea under noise. Longer pieces of story were moved into audio logs scattered across the overworld, which change in character as the game goes on.

None of it is presented as a cutscene that locks the player in place. When a level opens, the characters talk to each other while you walk around and work on the puzzle, and the audio logs on the overworld play while you move. Blow accepts the tradeoff this creates: he cannot control where the player is standing when a particular paragraph lands. He prefers the freedom to the control. The result is a story delivered a few sentences at a time, which asks the player to hold the last few levels in mind and add the new piece to them — and, in his view, leaves them more curious about what the next fragment will be.

Order of the Sinking Star runs on an engine written in a programming language the studio built itself. The reasoning behind both decisions is unusually direct. The previous two games were written in C++, which Blow describes without hedging as a miserable language to program in. Looking at the other languages then under development, he found that what their designers were trying to solve had nothing to do with the problems he actually had when making a game. So he began building a language aimed at those problems, and kept it largely private on purpose.

The privacy is the interesting part of the decision. A programming language that people start using locks its features down, because changing them afterwards breaks everybody's programs. By holding the language back, the team kept the freedom to keep improving it — the opposite of the usual instinct to give a new technical thing a catchy name and push it on the world. As Blow puts it, the point was not to be seduced into building a thing everybody would use, but simply to build the best thing.

The engine followed from the language. He wanted to use the new language for something significant, and he did not want to write another game in C++. There is also a continuity argument: both earlier games shipped on their own technology, and in the eras when they were made there was no reasonable off-the-shelf alternative. By the time this project began, capable third-party engines did exist and could have been used. The team chose not to, because making their own technology is work they enjoy and because it buys a degree of control — and a visual identity — that borrowing someone else's engine does not.

The cost is real and he does not pretend otherwise. When the game was brought to the Nintendo Switch 2, the engine did not simply run there; the whole engine had to be made to work on that platform, which is a substantial amount of labour for a very small team. The trend across the industry runs the other way, toward off-the-shelf engines, precisely because this work is hard. What the studio gets in return is the ability to drill into any line of code that is not behaving as well as it should — to refine it and optimise it — rather than accepting the limits of a system someone else owns.

Asked what he wishes he had known when he started, Blow points back at the design criterion that took the longest to articulate: whether a puzzle is good enough, and how hard the player is being made to work for what the game gives them. He went into the project confident in his puzzle design — he had made Braid, he had made The Witness, people liked those games — and the experience still taught him something he did not know. The difference between how the game played before the team arrived at this philosophy and how it played afterwards is, in his words, stark.

The clearest illustration is a specific failure mode, one that appears in a puzzle or two of Braid. A level has an idea, and if you see it, the level is good. If you do not see it, the attempt to solve it turns messy and clumsy. At the time, he treated that as simply how things were — players would recognise a good puzzle once they found the answer. He now ranks that as a lesser kind of puzzle than one that expresses its idea and also stays clean, never encouraging the player to do unfun, scrappy things while experimenting. It is a very specific standard, and the team took it seriously in this game. Asked whether he would design the earlier games differently now, he says they would probably come out pretty different, and that this is simply what it is always like to look back at your own work.

The game that resulted from all of this is large in a way that is meant to be felt rather than catalogued: four worlds, each with its own rules and cast, built so that they can be crashed together, and a mechanic set that only produces its best material once those worlds have been merged. Blow's summary of the project is not about size. It is about the reason for the time spent: the team could have released something years earlier, but chose to keep going until it was the best version of what it could be.