Overview
Prologue features an accessible yet surprisingly complex liquid system. This was not always the case. Early versions of the game only contained a simple water value on food items and a few water containers, such as bottles.
Once we added the ability to refill water bottles from rivers and muddy areas, players immediately started asking for more ways to interact with water. How can I collect rainwater? Can I refill my cooking pot? Can I move water between containers? What started as a simple survival mechanic became a recurring topic within the community.
This article describes the challenges behind the liquid system and how I designed it by leveraging systems that already existed in the game.
We did it, you can refill your cooking pot in the rain!
The problem
In an immersive game such as Prologue, players naturally expect water to behave according to their mental model of water. Water can be collected, stored, transferred, poured, spilled, and mixed. Once players believe a liquid exists in the world, they start expecting all of the logical consequences that come with it.
This meant we needed a liquid system with enough granularity to fulfill those expectations while remaining consistent with the rest of the game. At the same time, Prologue already had established systems for inventory management, containers, wetness, and cooking. Rather than introducing a completely separate framework, I decided to extend the existing systems to support transferable liquids.
In the Movie, the main characters must precisely obtain 4 gallons of water by using a 3-gallon jug and a 5-gallon jug. Thanks to a succession of imprecise transfers, they finally obtain 4 liters of water. The concept for constrained transfer led me to the idea of using our inventory system to manipulate liquids.
Making “cell water” feel like water
The inventory in Prologue is cell-based. Liquids therefore had to integrate with this system while still behaving somewhat like liquids.
One of the inspirations came from classic liquid-transfer puzzles such as the water jug puzzle featured in Die Hard with a Vengeance (see the picture above). The interesting part of these puzzles is that players can control liquids, but not with arbitrary precision. They must work within the constraints imposed by the available containers. I wanted Prologue’s liquid system to create a similar balance between control and constraint.
I decided that each inventory cell would represent a fixed volume of liquid. Players could transfer liquids one cell at a time for precision, continuously pour between containers, or transfer all available liquid at once.
Players can decide to move liquids, but the density property determines which liquid moves first (the one at the top). This constraint creates interesting inventory problems that players can solve in various ways.
Liquids were also given a few simple properties that players would intuitively understand. Liquids have density, meaning they stack on top of one another according to their weight. They also have gravity, naturally settling toward the bottom of a container.
Unlike regular items, liquids cannot be moved freely within the inventory. Players cannot pick up individual liquid cells and place them wherever they want. The only way to manipulate liquids is through pouring, forcing players to interact with them differently than traditional inventory items. These constraints kept the system relatively simple while still allowing for surprisingly complex interactions.
Because the liquid system was built directly on top of the inventory, very little additional explanation was required. Players already understood how containers worked. The only new concept they needed to learn was how liquids behaved inside those containers. Combined with visual feedback and audio feedback, pouring liquids felt like a physical action rather than a menu interaction.
The liquid system required us to adapt the inventory to host two container slots. This allowed players to transfer liquids between containers directly.
From Inexistance to Core System
The original goal was simply to give players more control over water. However, once the system existed, it naturally started connecting to other systems. Players’ questions such as: “How can I refill my cooking pot with rainwater?” led us to investigate how we could provide new gameplay opportunities.
The liquid system deepened the cooking system by allowing players to control the water content of their meals. This added another layer of resource management and created new decisions around food preparation.
It also deepened the wetness system: Once liquids could exist inside containers, they could also interact with other items. Water could spread to items stored in the same container, and it could leak beyond the container itself if that container was not waterproof.
Players no longer had to think only about inventory space. They also had to pay attention to:
- Which container they were using.
- Whether that container was waterproof.
- What other items were stored alongside the liquid.
- Where they were pouring the liquid.
As the liquid system provided new ways to interact with other systems, it gradually became a fully integrated system that influenced inventory management, cooking, resource management, and wetness.
Reflecting back
Delaying the liquid system turned out to have significant benefits. By the time we started building it, we already understood what players expected from water and had several established systems that could support it. Rather than designing a liquid system in isolation, we could build it around existing constraints and player needs. This drastically reduced both design and implementation time.
Desire paths emerge when people reveal the routes they actually want to take. Observing them before building often leads to better solutions.
Building the system earlier might have resulted in deeper integration with some features, but it would also have required solving many problems before we fully understood which problems players actually wanted solved.
Another benefit came from leveraging the inventory system itself. Because players already understood the inventory, containers, and item interactions, the liquid system required very little onboarding. Rather than learning an entirely new interface, players simply applied existing knowledge in a slightly different way.
One of the most surprising outcomes was how physical the system felt despite existing entirely inside the inventory. With the right interaction model, visual feedback, and audio feedback, players quickly stopped thinking about moving values in a menu and started feeling like they were manipulating liquids.
Looking back, one of the most interesting consequences of a simple interaction was the expectations it created. Once players could refill containers, they immediately started asking for the logical next steps. Can I collect rainwater? Can I refill my cooking pot? Can I transfer liquids between containers? Whenever you introduce an interaction that has a strong real-world counterpart, players naturally start applying their own understanding of that system. The more believable the interaction, the more expectations it creates.
Designing the liquid system became an exercise in identifying those expectations and finding creative ways to satisfy them using the systems already present in Prologue.
