Steam Game
Open-world exploration adventure
Adventure, Indie | Developer: Giant Cube Games | Publisher: Giant Cube Games
Coming soon
desol is an open-world style exploration game where you play as a lone traveler navigating an ominous desert shaped by colossal Cube Monoliths.
Cross the desert in search of a mythical Sea seen only in dreams. Gather water, follow fragmented clues, learn the patterns of moving monoliths, and let curiosity guide the journey without quest markers or checklists.
Available link: https://store.steampowered.com/app/4666960/desol/
Engineering Blog
Part 1: Cube Flatten System
During the development of desol, one of the core interaction problems came from the Cube Monolith itself. The project needs a massive cube that can move through the desert scene, respond to the player, and maintain believable contact with an uneven sand terrain. A simple rigid-body collision setup was not enough: because the cube is oversized and the terrain height varies continuously, even small discontinuities can quickly become visible as jitter, clipping, floating edges, or sudden snapping.
The Cube Flatten System was created to make that interaction feel continuous. Instead of letting the cube collide with the raw terrain only after it arrives, the system predicts the area where the cube is going to land during its interpolation movement. It then samples the height field under that future footprint and uses the average height of the target region as a reference for terrain adjustment.
In the earliest version, shown below, the flattening behavior was driven by interpolation time. For each interpolation step, I calculated the cube’s expected landing position, collected the terrain heights inside that footprint, and applied a decreasing height adjustment toward the sampled average. The result was still rough, but it demonstrated the first version of the idea: terrain deformation guided by predicted cube motion, rather than relying only on reactive collision after contact.
The first version of the Cube Flatten System only averaged the sand height under the cube and pushed the contact area toward a flatter surface. It made the cube landing easier to read, but it did not yet calculate a real sense of sand redistribution. It also could not rebuild the terrain after the cube moved away, which meant the player did not have a reliable regenerated surface to keep walking on.
My first attempt was to raise the flattened area directly after the cube left the footprint. This was still too close to a simple mean-height adjustment, so the result looked rough in the wrong way. Instead of feeling like sand had been displaced and settled, the terrain became pitted and uneven.
For the second attempt, I generated a mound-like terrain shape around the cube’s landing area. The implementation uses a quadratic function as the profile, then rotates that profile in place to create a radial sand pile around the footprint. In this demo, I pushed the parameters further than they would be in the final game, so the sand pile behavior is easier to see.
After this test, I realized that most deterministic connection methods for the terrain still looked weak. They could produce a clean mathematical shape, but the transition always felt too obvious: the regenerated area read as a patch placed on top of the sand, rather than a part of the same terrain. At the same time, using ordinary noise was not a good answer either. A simple noise layer did not adapt well to the complicated terrain shapes I was testing in the actual game scene, especially around steep slopes and already-deformed surfaces.
The idea that finally made the system feel more usable came from terrain painting tools. A terrain brush is a good balance between averaging and natural variation: it can smooth a local area without forcing everything into a single artificial height, and it gives me a controllable way to blend the border of the regenerated footprint back into the surrounding sand.
The final implementation plan is to rebuild the terrain in stages. While the cube is flattening the sand, the system stores the cells it leaves behind. When the cube moves away, those cells are lifted back toward an averaged height first. Then, around the connection border, the system places many small randomized terrain brushes using nearby mean values, so the regenerated footprint can connect more naturally to the existing terrain instead of forming a hard seam. Because the terrain generation also depends heavily on texture detail, I add another pass of noise-driven texture lines on top, so the rebuilt area inherits the visual grain of the surrounding sand.
The final in-game version connects the flattening system back into the chasing cube. At this stage, the cube is no longer only a test object moving across a debug terrain patch; it is part of the actual desert encounter, moving at player scale and deforming the sand as it advances. The system continuously updates the terrain under the cube footprint so the monolith reads as heavy, grounded, and physically present, while the surrounding sand remains smooth enough for gameplay.
This pass shows the intended production behavior: the cube can pursue the player across uneven dunes, push the terrain toward a stable contact surface, and leave behind a readable flattened trail without breaking the desert silhouette. Compared with the earlier interpolation prototype, the important shift is that the flattening logic is now working inside the real scene with the gameplay cube controller, so the visual effect, collision requirement, and player interaction all meet in one system.
Special Desert Terrain Generation
Reference / Credit: This terrain prototype credits two references: Ken Perlin’s SIGGRAPH 2002 / ACM TOG paper Improving noise, together with Perlin’s Improved Noise reference implementation, for the layered procedural-noise foundation; and Procedural Sand Dune Terrain (Zara, 2007) for sand-dune-oriented terrain shaping.
The desert terrain generation became a separate technical problem from the cube flattening system. The world needed to read as a wide, wind-shaped desert, but it also had to remain controllable enough for gameplay, camera framing, collision testing, and later terrain deformation. I used a GPT-assisted prototyping workflow to split the generator into two passes: first a base sand surface with directional texture, then an independent hill overlay that could be regenerated without permanently stacking on top of the previous result.
Base Desert Texture Pass
The base pass starts by projecting each terrain sample into a wind-aligned coordinate system. Instead of sampling noise directly in world XZ, the terrain uses one axis along the wind and one axis across the wind, which lets the ridges stretch like sand shaped by a dominant wind direction.
On top of that rotated domain, I used layered Perlin noise and folded it into a ridged profile. The fold turns smooth noise into sharper crest lines, while the octave sum keeps the surface from looking like a single repeated wave.
The final base surface is lightly blurred along the wind direction. This is not a full erosion simulation; it is a cheap directional smoothing pass that helps the generated sand feel like it has been pushed in one consistent direction.
Hill Overlay Pass
The second pass treats large dunes and hills as a separate overlay on top of the base heightmap. Each hill samples a random center inside a normalized spawn rectangle, then adds a soft Gaussian height contribution around that center. Keeping this as an overlay made the workflow much easier: I could regenerate hills repeatedly from the same stored baseline instead of accidentally adding new hills onto old hills every time the button was pressed.
In the later version of the tool, the generator also tracks every hill center as a transform list. That made the hills more than just baked height values: other debugging tools and gameplay systems could query where the generated forms were, while the terrain artist could still regenerate the whole arrangement from a clean baseline.
Dynamic Mesh Ocean Simulation
The ocean prototype was built around a moving dynamic mesh instead of a single large static water plane. The game only needed detailed wave geometry around the active play area, so I used a grid that follows an active simulation origin across the world. As the grid moves, its vertices are regenerated in local space and displaced every frame by wave functions, while a water material handles the surface color, highlights, transparency, and depth response.
This separated the simulation into two practical layers: the mesh provides real animated geometry for wave silhouettes and collision-aware sampling, and the material provides the visual water behavior. Keeping the mesh local also makes the ocean cheaper to update, because vertex density stays near the visible and interactive area.