TIMESYNCERS DEV BLOG: DESIGNING CONSEQUENCES THAT MATTER

I spent most of last week deleting a feature I had been building for three months. It was a dialogue branching system for TimeSyncers, my time travel game where the whole pitch is that your decisions in one era ripple forward into the next. The system worked. The branches forked. The variables tracked. And when I sat down and actually played through a few of the routes I had built, I realized I had accidentally built Telltale. Choices that felt important in the moment and resolved into the same scene four hours later. The exact thing the game is supposed to be a counterargument to.

So I deleted it. Three months of work, into the void. Then I sat in my office chair and stared at the wall for about an hour, which is the most productive thing a solo developer can do after making a hard call. After that I started over, and what I started building is the system I want to talk about today, because the lessons from the wreckage are the kind of thing I would have killed to read three months ago.

This is a post about why most games fake consequences, what real consequence design actually requires, and the specific tools and trade-offs I am wrestling with right now on TimeSyncers. If you are building anything with branching narrative, or even just thinking about it, I hope this saves you some of the time I just lost. If you want the bigger picture on this stuff first, I wrote about the butterfly effect in games a couple of months ago and it is the philosophical underpinning of everything I am doing here.

Why most games fake it

Consequences are expensive. That is the thing nobody puts on the marketing materials. When a publisher trailer talks about how your choices will shape the world, what they actually mean is that your choices will shape one or two end-of-game cinematics and maybe a paragraph of text in the credits. The rest of the game is a corridor with the lights set to slightly different colors based on what you picked.

This is not because writers are lazy. It is because the math of branching content is brutal. Every binary choice doubles your downstream content. Two choices means four possible states. Ten choices means a thousand and twenty four. The number of branches grows so fast that even AAA studios with hundred-million-dollar budgets can only afford to truly branch in a handful of places. Everywhere else, they fake it. They use the illusion of choice, which Telltale perfected, and which a generation of players ate up because the feeling of agency is almost as good as actual agency, until you replay the game and notice the seams.

There is also the play tracking problem. If you build a branch that fifty percent of players will see, you have justified the budget. If you build a branch that two percent of players will see, your producer is going to ask you why you spent six weeks on content that almost nobody will encounter. The answer that "those two percent will love it" is true and also unconvincing in a budget meeting. So the branch gets cut, the path gets converged, and the game ships with the appearance of depth and the reality of a flowchart that mostly looks like a single line with some decorative squiggles.

I am a solo developer. I do not have producers. I do not have budget meetings. What I have instead is the equally brutal constraint of being one person, which means every branch I build is something I am personally going to write, script, voice direct, and debug. The math gets even worse when you are the entire studio.

The Telltale cautionary tale

I want to be careful here because I love the Telltale Walking Dead games. They made me cry. They taught me that games could do drama. The original season one is a masterpiece in a lot of ways. But it also kicked off a decade of design rot where "X will remember that" became the dominant model for choice in narrative games, and that model is fundamentally a lie.

The pop-up was theater. Clementine remembered, in the sense that one or two lines of dialogue might shift slightly in episode three. The major beats were locked. The deaths were locked. The plot was a corridor and your job was to pick the wallpaper. This was a brilliant illusion and it absolutely worked on first playthrough. The problem is what it taught the rest of the industry. After Telltale, every narrative game adopted the "your choices matter" marketing without adopting the structural commitments that would actually make that statement true. We got a decade of games where you picked a tone for a conversation and then watched the same cutscene play out.

The cautionary part is not that Telltale did this. They were broke and they were pioneering. The cautionary part is that the rest of the industry copied the surface and skipped the substance. Real consequence design is not a UI element. It is a structural commitment to building content that some players will never see.

What real consequences require

I have been writing a list, taped above my monitor, of what I think real consequence design actually requires. It started as three items. It is now twelve, and I keep adding to it. Here are the four that I think are non-negotiable.

The first is multiple endings that are actually different. Not "the same ending with a different color filter." Not "the same ending with one extra line of voiceover." Different in the sense that a player describing the ending to a friend would describe a different ending. Different characters alive. Different power structures. Different worlds. If the endings can be summarized in the same sentence, they are not really different.

The second is NPCs reacting to past choices in ways that are specific. Generic reactions like "I heard about what you did" do not count. The NPC needs to reference the specific thing, by name, with detail. If you saved their cousin in chapter two, the NPC mentions the cousin in chapter five. Not "thanks for your help with my family." The cousin's name. The location. The detail that proves the game was paying attention. This is enormously more expensive than generic reactivity but it is the difference between feeling tracked and feeling seen.

The third is world state persistence. The world has to be different because of what you did, not just the dialogue. If you blew up a bridge in act one, the bridge is still blown up in act three, and traveling between those areas is slower or impossible because of it. The state has to live in the world, not in a tracker variable that occasionally triggers a line of dialogue.

The fourth is that some content has to be unrecoverable. If you can save-scum your way to seeing every branch, the consequences are not real. They are puzzles. Real consequence requires that some doors close forever, that some characters die and stay dead, that some quest lines vanish without warning. This is the part that scares developers because it scares players too. Players hate missing content. But missing content is the price of meaningful choice, and you cannot have one without the other.

The tools that help

I have been prototyping in two tools and I want to talk about both because the choice has shaped how I think about the design.

The first is Twine. Twine is a free, web-based tool for writing branching narratives. It is the most important tool in my pipeline right now and it is not even part of the actual game. I use Twine to prototype every major narrative branch before I write a single line of game code. I sketch the choice. I sketch the consequences. I sketch the cascade. Then I play through it as a player would, and most of the time I realize the choice is not as interesting as I thought it was, and I throw the Twine file away.

This is the workflow that saved me from shipping a much worse game. Twine is so cheap to write in, compared to actual game scripting, that I can iterate on a narrative branch fifty times before committing to building it. The cost of throwing away a Twine prototype is an afternoon. The cost of throwing away a fully implemented dialogue system, as I learned last week, is three months.

The second tool is Ink. Ink is the scripting language Inkle developed for their games, which include 80 Days and Heaven's Vault, both of which are masterclasses in branching narrative on a budget. Ink is the implementation language. Once a Twine prototype survives playtesting, I port it to Ink, which compiles into a structure my game engine can consume at runtime. Ink handles the variable tracking, the conditional logic, the weaving together of branches. It is the most powerful tool I have found for actually shipping branching narrative without losing your mind.

The combination is Twine for thinking and Ink for shipping. If you take one practical thing away from this post, take that.

The branching depth versus content cost trade-off

Here is the design decision I am wrestling with right now. How deep should any given branch go before it converges back to a shared state?

Shallow branching is cheap. You let the player make a choice, you play out the immediate consequence over the next few minutes, and then you converge back to a shared next scene. The cost is low and the player gets the satisfaction of having made a choice. The downside is that on replay, the player notices the convergence, and the choice retroactively feels less meaningful.

Deep branching is expensive but transformative. You let the player make a choice, and the next twenty hours of game are different because of it. Different scenes, different characters, different mechanics. The cost is enormous because you are essentially building two games. The upside is that the choice feels real because it is real.

For TimeSyncers I am settling on a middle path that I am calling "tributary branching." Every major choice opens a branch that runs for a meaningful chunk of game, maybe two to three hours, before reconverging with the main flow. The reconvergence is not a reset. The world state changes carry forward. The NPCs you met on the branch may still be present. The relationships persist. But the game's main spine pulls everyone back to a shared sequence of beats.

This is a compromise. I know it is a compromise. The game I really want to make is one where the branches never reconverge and the world simulates forward from your choices for hundreds of hours. That game cannot be made by one person in a reasonable timeframe, and probably cannot be made at all with current technology. So I am picking the deepest version of branching that I can actually ship, and accepting that some players will notice the reconvergence and feel a little cheated. I would rather ship a compromise than not ship the game.

The Disco Elysium gold standard

If you want to know what real consequence design looks like at the absolute peak, play Disco Elysium. I bring it up not because I think anyone can match it, because I do not, but because it is the only game I have played that delivers on every single item on my non-negotiable list and then some.

Disco Elysium tracks your choices at a granularity that I find honestly intimidating. Skill checks fail in ways that propagate forward. Dialogue options vanish based on past statements. Characters remember specific things you said hours ago and reference them in conversations you do not see coming. Your political alignment, your fashion choices, your drug habits, your relationship with your partner, all of it stacks into a composite portrait of the detective you have become, and the world reacts to that portrait constantly.

The endings are different in the way that endings should be different. The character you are at the end of the game is different. The world you have moved through is different. Replays are not just about seeing missed content. They are about being a different person and experiencing the same nightmare from a different angle.

What ZA/UM did is something I do not believe could have been done by a normal studio. It required a specific combination of literary ambition, design discipline, and willingness to write enormous amounts of text that many players would never read. I am not going to match it. Nobody is. But it sets the bar for what is possible, and aiming at the bar is better than aiming at the floor.

Where TimeSyncers is now

I am six months into the consequence system rebuild. The Twine prototypes for the first three major choice points are done. The Ink scripts for the first one are about seventy percent implemented. I have a working prototype where you can make a decision in 1985, jump forward to 2025, and see a town that looks different because of what you did. The differences are still mostly cosmetic. The simulation is not yet doing what I want. But the bones are there.

The hardest part is not the technology. The hardest part is the writing. Every branch requires me to imagine, in detail, what a different version of the world would look like. Every NPC requires alternate dialogue trees. Every scene requires alternate framings. The content cost is exactly as bad as I was warned it would be, and I am only getting through it because I have been ruthless about scope. The game is small. Three time periods. About fifteen named NPCs. A handful of major choice points. Anything bigger than that and I would still be writing it in 2030.

If you are building something with consequence at the center, my honest advice is to start small and stay small. Do not try to be Disco Elysium on the first try. Pick three choices that genuinely matter and build them right, all the way through. One real branch is worth twenty fake ones. Players will feel the difference even if they cannot articulate why.

That is what I am working on this week. Next week I will probably delete half of it again. Such is the gig.