Narrative games traditionally ask players to shape their own stories. Tides of Tomorrow takes that idea one step further by allowing another player's decisions to become part of yours. Through its Story-Link system, every playthrough follows another player's journey, with their choices affecting dialogue, world states, encounters, and even how characters perceive the events unfolding around you. Rather than using multiplayer for direct cooperation or competition, the game turns asynchronous interaction into the foundation of its storytelling.

Making that concept work required far more than branching dialogue. Developer DigixArt had to design an entirely new narrative framework capable of connecting players without breaking pacing, consistency, or player agency. Behind the scenes, Story-Link combines state-machine logic, replay systems inspired by multiplayer networking, layered post-processing effects, and carefully structured level permutations to create the illusion that another player has genuinely lived through the world before you.

We spoke with Game Director Adrien Poncet, Programmer Jerome Aspe, and Technical Artist Raphael Garcia about the origins of Story-Link, building asynchronous narrative systems in Unreal Engine 5.4, designing the game's vibrant "plasticpunk" aesthetic, and creating one of the most technically ambitious storytelling systems we've seen in recent years.

Tides of Tomorrow introduces the “Story-Link” system, where another player’s decisions directly shape your experience. What was the original inspiration behind this mechanic? 

Adrien Poncet, Game Director: The inspiration actually came from our previous game, Road 96. We always look for new ways to tell stories in games, and after exploring procedural elements in Road 96, we thought it could be interesting to explore multiplayer elements for our next game. 

In Road 96, you play several runs of the game (in a sort of roguelite fashion), and at some point, you’re able to leave something behind for your next character, like hiding some money that can be found during your next run. This made us think: what if each of these characters were actually a different player? 

We also looked at games using asynchronous multiplayer mechanics for inspiration. Dark Souls inspired us with the idea of seeing player ghosts, while Death Stranding was more about how other players can influence your game world. We also looked at indie games like Phantom Abyss and Mirror Layers. 

But we had this unique idea of letting players directly influence each other’s stories, and we had no real blueprint for that exact mechanic, so we had to conceptualize it from scratch. The closest reference we found was a very niche, small game called Moirai. 

We introduced a lot of unique twists such as NPCs directly talking about the previous player in their dialogue, to simulate the idea that this previous player is an actual character in that world. 

From a systems design perspective, how is Story-Link structured under the hood to allow player actions to meaningfully alter world states, dialogue, encounters, and level layouts? 

Adrien Poncet: Finding the right formula was very challenging. We wanted each player to always follow someone else, while also being followable by other players, so there couldn’t be a clearly defined “beginning” or “end” to the timeline of events. It’s technically an infinite chain of players following each other, but narratively we only account for the immediate previous player and the potential future players (N+1 and N-1). 

So, we approached it with a “state machine” logic: each level has several states, which can be altered by each player’s actions so that the next player is confronted with a different state. 

At first, we designed it so that the whole level would have three states, but it quickly became too ambitious to change an entire level every time. So, we shifted to an approach where individual elements within a level (like a specific NPC or gameplay element) could have their own variety of states. In the final game, each level is a mix of both ideas (a global state changing for each player, and individual elements within that state being altered too).

We kept this approach on a per-level basis to make it more manageable. It gave us more flexibility and ensured the branching possibilities wouldn’t explode exponentially. 

This also allowed us to let you switch the player you’re following between levels, allowing you to keep playing even if you “catch up” with someone. 

Finally, other players can heavily modify your journey and your perspective on levels, events, and characters, but in the end, you’re still in control of your destination. This strikes a nice balance between letting the Story-Link system shine and preserving what makes traditional story games fun—making your own choices and having an impact on your own story. 

The game allows players to follow friends, streamers, strangers, or pre-made saves through shareable Story-Link Seeds. How did you approach designing this system to feel both social and narratively cohesive? 

Adrien Poncet: One important aspect for us was to let players express their personality through experience. This is why we introduced traits that reflect how different players approach the game and make decisions. 

We also built the system around the idea of sharing resources, which works well with the post-apocalyptic setting and the themes of the story. It allowed us to materialize exchanges between players in a concrete and tangible way inside the game world, giving more weight to the idea of “leaving things behind”. 

From the start, we paid extra attention to consistency between players. We always had this idea in mind: if you watch a streamer play and then decide to follow them, everything needs to make sense. This meant we couldn’t “cheat” the system and had to ensure that every variation remained narratively coherent. 

One of the most interesting aspects is the “Tides of Time” vision mode, which lets players literally see what another player previously did. How was that feature implemented technically and visually? 

Jerome Aspe, Programmer: On the technical side, it works a bit like multiplayer replication. The system stores all actions performed during a configurable time window, including their type (interaction, emote, movement), the player's state (skin, posture, vehicle use, velocity), and metadata such as timestamp and position. 

The system records every action performed during the last X seconds and keeps saving the next ones for Y seconds. Once a checkpoint is reached or the level ends, we upload the player save to the servers. 

If I decide to follow this player, I will receive their save data. And the system will use all the data previously saved to simply replicate the movements, animations, and actions!  

Raphael Garcia, Technical Artist: The visual effects are composed of two main elements: a layered post‑process effect and the player “ghosts”, supported by a small Niagara system. 

First, the post‑process effect. It consists of several post‑process layers stacked together within a post-process volume. Working in layers rather than using a single large post‑process pass gives us more flexibility, since we can sometimes activate only certain passes and not others, which makes it easy to create different intensity levels and serve the staging. 

Splitting the post‑process into multiple layers also lets us control the Blendable Location of each pass independently, which helps us fine‑tune the inputs and optimize performance. 

Raphael Garcia: Another interesting point: the material parameters of the post process are animated independently through a system developed in-house. It uses a curve-based system that allows us to precisely animate the parameters of each material layer, so we can fine-tune the effect with a lot of precision depending on different states in the game.

The ghosts are skeletal meshes with translucent material using a custom stencil to stand out against the post process. For optimization reasons, the skeletal meshes used as ghosts are special versions of the game's characters. To reduce the workload for the character artists, I built a small tool that repacks the albedos of each character to fit the ghost texture into a single lower-quality texture compared to the base characters. 

Narrative games are usually heavily authored, while systemic games often prioritize simulation. How did your team balance authored storytelling with dynamic, player-driven variation? 

Adrien Poncet: A big part of this comes from the combinatorial aspect of the system. By having multiple states for different elements within each level, we can create a wide range of situations from a limited set of authorized content. 

On top of that, we added additional storytelling layers through some features that are more systemic like merchants, donation boxes... but also emotes, which allows players to express intent and meaning in a more emergent way. 

From a technical standpoint, what engine and core technologies are powering Tides of Tomorrow, and what made them the right fit for a system-heavy narrative experience?  

Jerome Aspe: Tides of Tomorrow is powered by Unreal Engine 5.4. We also use Fluid Flux to handle the ocean. 

I think it’s a good fit for this game because we are still a relatively small team (30 people), so we needed an engine that was ready to use and one that the team was already comfortable with. 

Moreover, Unreal Engine 5 has a nodal coding system (Blueprints) that allows designers to prototype and make small game systems quickly! 

Raphael Garcia: We made the choice to fully embrace UE5's modern rendering pipeline: Nanite, Lumen and Virtual Shadow Maps enabled on almost every platform, from PC down to Steam Deck (Steam Deck just doesn't get VSM). 

Tides of Tomorrow is a very asset-dense game, and Nanite lets us reach the visual quality we were aiming for. It also works particularly well with our material approach, which relies heavily on vertex colors: as a result, aside from certain props and the characters, the majority of the environment uses the same textures. The benefit behind this is that it lets the artists iterate quickly throughout production. 

Raphael Garcia: On the lighting and shadow side, Lumen and VSM fit within the budget; the visual quality they brought made them an obvious choice for the team. 

In addition, we set up a Houdini PDG pipeline, which takes care of every export, through a custom Blender plugin, by automatically processing the assets: it generates the vertex colors, acts as a validator to make sure every asset coming into Unreal meets a specific technical quality bar, and also prepares the LODs of each mesh in the background. The idea is to serve as a backup in case, during production, we decide to switch to LODs on a specific platform.  

Raphael Garcia: A quick word on the vertex colors: R is AO, G is curvature with noise, A is a random per-element attribute, and B is left open for the artists to paint into. 

The game’s “plasticpunk” aesthetic is visually distinct, mixing post-apocalyptic themes with vibrant color and plastic pollution imagery. How did you develop that art direction? 

Adrien Poncet: We wanted something that felt different from the usual dusty, rusty grey/brown post-apocalyptic settings. Also, we like colors! And we felt like the contrast between the blue of the ocean, and the other colors coming from plastic waste could make for a striking and memorable art direction. 

This is one of the very first concept that was made for the game. It was made by comic artist Thomas von Kummant. 

Adrien Poncet: In general, we start with key concept arts like this, but then we don’t produce that much concept art, we like to test things and iterate in engine directly. Everyone is very versatile in our team, so our 3D artists usually produce their own concept arts when they feel the need for it, to solve any questions they have before producing 3D assets.  

Our main characters are usually an exception to this; we produce them in a more traditional way by refining the concept art before going 3D.  

Can you walk us through your workflow for building a level that must support multiple narrative permutations and player outcomes simultaneously? 

Adrien Poncet: There isn’t a single template for building levels, because each one comes with its own constraints and challenges depending on the initial pitch. 

In some cases, we would design the level extensively on paper before moving to prototyping. In others, we would first create a rough “A” version of the level, then build an alternative “B” version, and progressively add interconnections between the different states through iteration. 

What remains constant is that it requires thinking in a sort of “four-dimensional” way: what could another player have done in a different version of the level that might impact this one, and vice versa? 

We also designed choices so that they always have a dual purpose: they should have a meaningful immediate impact on the current player, while also leaving a trace for future players. Finding the right balance between these two was key, so that players never feel penalized in the present for the sake of a hypothetical future outcome. 

Looking back, what were the biggest technical or creative challenges in building a game where another player effectively becomes part of your narrative experience? 

Adrien Poncet: Creatively speaking, I think my answers to previous questions already give a good sense of how challenging it was to conceptualize the Story-Link! But even when we had something working on paper, there were still many challenges in exposing it to the player, making it engaging, and improving the UX before reaching the final quality. It was a long-term process that lasted throughout the entire production. 

Jerome Aspe: On a technical level, personally, the biggest challenge of this project was the Story-Link record system. 

We cannot control the player's actions, and we also had technical limitations. For example, a player might stand still for ten minutes while the system is recording them. But watching someone do nothing for 10 minutes is not interesting, and we cannot send 1GB of data to the server.

So, we had to build our system accordingly: trim unnecessary recordings, restrict the number of emotes per area, and optimize the size of the data sent to the servers. This system also needed to handle many technical tasks while remaining easy for designers to use. 

Finally, are there any behind-the-scenes materials—such as narrative flowcharts, system visualizations, or debug tools—you can share to help developers better understand how Tides of Tomorrow was built? Or WIP assets? 

Adrien Poncet: We sometimes used this kind of flowchart to design the different Story-Link states and outcomes in each situation. We called it the ABC system because we found that having three different states was necessary to avoid repetitiveness from one player to another. 

Usually, once we had a design that worked on paper, we would quickly discover a whole new set of problems once we started prototyping it. Then, we iterate directly in the engine to find the correct narrative balance between the different states. 

DigixArt, Game Development Studio for Tides of Tomorrow