Built on hybrid 2D and 3D water simulation models, here's how these mechanics informed the gameplay of this unique city builder.
Game Developer Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.
Earlier installments cover topics such as the memory-altering mechanics of adventure game RE:CALL, the appeal of distorting the nostalgic and familiar for the sake of terrifying your audience with Choo Choo Charles developer Gavin Eisenbeisz, and teaching the player to find the beat through environmental cues in Melatonin.
In this edition, the developers behind busy beaver city builder Timberborn tell us about how the game's unique irrigation systems were designed using hybrid 2D and 3D simulation to inform how water interacts with land.
Hello, we are Kamil Dawidow, game co-director, and Michal Amielanczyk, comms manager, from Mechanistry. Our studio is based in Poland, and in 2021, we launched the early access version of our first game, the post-apocalyptic city builder Timberborn.
In Timberborn, the player begins with a small beaver village…
…and then turns it into a sprawling city in the desert.
In our game, the player picks between two factions of bipedal, futuristic beavers. But we didn’t choose these rodents just because they’re cute chonkers. The species' signature abilities and affinity for water are the cornerstones of Timberborn’s gameplay. When you think of beavers, you probably see cut trees and a landscape changed by dams. That’s what our game is about.
Aww. No wonder carrots are one of the basic foods consumed by Timberborn beavers.
If you didn’t play our game, that’s a shame, but for now, here’s a recap of how we’ve realized its “beaverness” so far. Timberborn is a city builder, as the main goal is to create a thriving beaver colony in the post-human wasteland. All the city-building efforts are centered around water, though. Beavers drink it, use it in the production chains and as an energy source (thanks to water wheels), and, probably most importantly, as a way to irrigate the wasteland, turn it green, and sustain plant life. There are even purely aquatic crops. Since it’s a beaver game, your colonists can also traverse water areas just fine, and even do some work underwater.
Each Timberborn map is made of layers of cuboid tiles, with multiple water sources scattered around. Thanks to the water physics we’re about to cover in this article, the water spills over, creating waterfalls and basins where the elevation is lower. It also evaporates, which becomes more visible during recurring, increasingly harsher droughts that turn off the water sources.
Here’s what happens in Timberborn when you let the water flow through the wasteland.
The dry/wet season dynamic is crucial for Timberborn’s gameplay, and the player is given lots of tools to handle the water's storage, retention, and direction. In the game, we've got dams, pumps, terraforming machines, and much more. Constant water-related logistical challenges add both to the city-building mechanics and Timberborn’s beaver vs. environment theme.
Our main idea for Timberborn has always been “build a beaver city in the post-apo world," and we knew we wanted droughts in the game. That’s what pushed us toward implementing water physics and irrigation mechanics. Originally, water wasn’t simulated—it simply covered select areas on the map, powering-up water wheels, and during droughts, its level would need to simply drop. However, we realized having it properly simulated would be a game changer, which would also enable tools such as dams—a concept criminally underused in games.
Before Kamil started his work on in-game water physics, he researched scientific publications on the subject, including Fast Hydraulic Erosion Simulation and Visualization on GPU by Xing Mei, Philippe Decaudin, and Bao-Gang Hu. In short, available water simulation models vary depending on the intended use. There are 2D models, where the water surface is treated as a single layer, and 3D models where water is multi-layered (useful for modeling deep oceanic waters, for example). Even though our game is 3D, we adapted the 2D variant seen below.
This is how our water simulation model works on a flat 2D surface. Adapted from Fast Hydraulic Erosion Simulation and Visualization on GPU by Xing Mei, Philippe Decaudin, and Bao-Gang Hu.
Each tile connects to its four neighbors via virtual pipes and has a value representing the depth of water covering it. The game tries to level out these levels. There’s also the water momentum (current), calculated between simulation ticks (every couple hundred ms), based on how much water moved between tiles in a tick, compared to previous ticks. A shallow river that encounters a dam spills slowly, whereas emptying a massive reservoir onto a plain below results in flooding.
The latter scenario comes up often, as verticality is also a big factor in Timberborn. Maps have dramatically different topography, and players can create their maps in the editor. Many in-game buildings are stackable on top of each other, there are platforms, bridges, etc.
The 2D and 3D hybrid nature of our water physics system can be easily seen on an unlocked camera. Under the hood, water is this massive sheet thrown over the map, raised to match the ground’s height and water depth. The water’s momentum is visualized by its texture.
The system adapts to the map’s topography, as well as to the player’s decisions. To redirect rivers, the player can reshape the land (removing and adding land blocks), or use tools such as beaver-built levees, dams, and floodgates. Levees simply block all water. Dams, on the other hand, dynamically regulate how much water passes between tiles. We can’t use hard values here as that would result in water oscillations and waves. Finally, we have player-regulated floodgates that can be turned from solid water blockers to partially open dams.
Our water physics system needed a lot of fine-tuning. For example, we needed to make the transition at the beginning of a drought smooth despite the water "remembering" its momentum even after water sources turn off. From the player’s perspective, a drought starts at a very specific time (with water sources hitting zero strength), but to make the transition smooth, sources’ strength starts dropping much sooner. Similarly, even though water simulation and moisture calculation are updated in ticks, the visuals need to be rendered continuously.
In early Timberborn builds, all land was green, but soon after we implemented water simulation, we turned the world into a wasteland that’s only green in the vicinity of water bodies. Beavers can only grow crops and forests in such areas. If the soil goes dry, plants begin to wither, some sooner than others. Irrigation was the perfect encouragement for water physics play; it fits the post-apo theme and adds another unique gameplay twist. Splitting the in-game world into water, green, and dry areas helps us differentiate the visuals (before any buildings come in). It also gives the player a natural, ecologically-inclined goal of turning the entire map green.
The moisture system is of our own making although it shares basic principles with the water system. Moisture “spills over” from water tiles onto adjacent ground tiles, with subsequent ground tiles receiving lower and lower moisture levels, until reaching the threshold that results in a dry tile. Even though this system is 2D-based, we also account for differences in elevation. If the adjacent tile the moisture spilled over is at a higher elevation, the value drop is significantly sharper. Hence, it’s difficult to irrigate a high hill by building a canal at its foot.
Each model we considered had its advantages and disadvantages. The model we picked is very fun to play with and easy to understand, but as with all alternatives, it has its quirks. Take the "water dump exploit," for example. Instead of irrigating an area as intended (with large rivers, canals, or lakes), you could blow up a single tile with dynamite. You then put a water dump (a building that drops water beneath) over it, and boom, a large area turns green. This even outclasses the Irrigation Tower—a building one of our factions got for exactly that purpose.
The regular irrigation tower on the left versus the water dump “exploit” on the right.
We tried to fix that by calculating how many tiles can each water tile moisturize, giving an edge to larger bodies of water. We also considered increasing the evaporation rates for such small water areas. In the end, we needed to leave that as it was for the time being. Creating and testing new models was very time-consuming, and we weren’t fully satisfied with our results—which means, reworking the entire irrigation system is probably not a way to solve this issue.
It may look cool, but gameplay-wise, a perpetuum mobile was not a desired feature.
Another pet peeve of ours was ensuring that the crafty Timberborn players wouldn’t be able to build a Perpetuum Mobile. This issue arose when we added mechanical water pumps to the game. These unmanned, high-end buildings use power to transfer water to upper areas, making them a great tool for creating reservoirs at higher elevations. The problem is the water you pump up flows down afterward, which means it can power up water wheels… and those can be hooked up to the very same pump that made this setup possible. In the end, we needed to add some innate water resistance to the water wheels, to make this idea almost impossible.
Water simulation, shortly followed by irrigation mechanics, came together in the game, quickly becoming a core for Timberborn’s gameplay we kept in mind while designing other features.
In-game beavers can swim, but at one point, that obvious feature wasn’t there, so water acted as a natural obstacle. As soon as we added simulated water, it needed to be done, though. Route calculations are quite taxing on Timberborn’s performance. When water spilled all over the map, cutting off the routes for non-swimming beavers, it resulted in lag spikes. We implemented a hybrid model where the beavers simply continue following their paths. If a path ends up underwater, they’ll just swim or dive into the deeper waters. Plus, we could make beavers move faster in water, create a win-win situation that makes perfect sense lore-wise.
A beaver casually swimming in front of a dam.
Another good example came about a year into the game’s early access when Timberborn finally received fully realized terraforming. Thanks to the addition of dirt excavators, the player can remove ground blocks and create fresh ones to freely reshape the terrain and create new water routes. The dynamic water and moisture simulations work perfectly with that.
Beaver dirt excavators in action. The dirt can then be used to lay new terrain blocks.
Our players love the water-related features. Right now, one of the most common requests is the addition of bleed valves—objects that allow the water to spill from the bottom rather than just from the top. We’re looking into that as this would allow the player to empty reservoirs no matter how deep, complementing the existing floodgates of regulated height already in the game.
We hope you now have a picture of the intertwined gameplay systems in Timberborn. The organic addition of water simulation led to the addition of the irrigation system. They pair well with other systems such as terraforming, our post-apocalyptic setting, and its rodent dwellers. And that’s probably the key takeaway we would like to share—do not design your in-game systems in a vacuum, but try to make them interact and work together. There lies the beauty of the emergent gameplay that the player loves to discover just as much as we do.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
