u/wizzard_rick

I'm a solo developer making Salt and Soil, a strategy game about one family on a map of North America from 1607 to 1900. This is the next entry in my terrain diary (1, 2, 3). It started with one railroad for my Sacramento scenario and ended with 175 major lines and 578 sections, each appearing on the date it actually opened. This week a timelapse of this network was the top post of the day on r/dataisbeautiful (thread). This is the other half of the story: how the track is drawn.

The embarrassing first version (left half of the first image). I began with pixel-art rail tiles. On the new heightfield terrain they floated over the hills and trees like stickers, zigzagged wherever a line ran north–south, and ignored the lighting. Roads already had a better answer: the terrain shader draws them as a ribbon of ground through smoothed per-cell waypoints.

What I did instead. The railroad is a second copy of that ribbon with different contents: a gravel bed, sleepers and two rails, all taken from the terrain palette. Because it's ground, the track follows the relief, gets the same lighting bands and grain, disappears behind hills in front of it, and trees standing on the line are cleared in the year the railhead reaches them. The parts that took the longest:

• Sleepers keep an even spacing across cell edges. Each cell stores its sleeper phase, so they line up at every seam and don't slide while a line grows.
• The whole network is built once when the map loads. Every edge stores when the railhead reached it, so changing the year only changes one number in the shader, and the track visibly extends along its curve.
• Railways don't wander like roads: no meander, and only light smoothing, because heavier smoothing pulled the line into kinks at cell edges.

The data. US routes follow Jeremy Atack's historical GIS of American railroads. He's an economic historian at Vanderbilt who mapped every US railroad from 1826 to 1911. Before putting it into a commercial game I emailed him; he said yes, asked for a copy when it's finished, and he's in the credits. Canada and Mexico follow the US DOT's North American Rail Network. Opening dates come from railroad chronologies.

Two things I didn't expect to learn while laying all this: in the winter of 1866–67 the Central Pacific hauled three locomotives over the snowbound Sierra on log sleds, and before its bridge opened in 1882, the Northern Pacific crossed the Missouri at Bismarck each winter on track laid on the ice.

Where I'm stuck: tunnels. The track is ground, so the Central Pacific simply climbs over Donner Summit instead of going through the Summit Tunnel. At about 20 miles per cell a real tunnel is smaller than a pixel, but the ridge it passes under isn't. Options I'm weighing:

1. Compute a smoothed grade line along the route, fade the ribbon wherever the terrain rises above it, and draw a portal at each end.
2. Draw a dashed cartographic line across the ridge.
3. Carve a shallow notch in the heightfield along the route.

How would you handle tunnels on a heightfield shader like this?

Try to name a tabletop RPG designed in Russian. Most people here can't — not because there aren't any, but because almost none of it has ever been readable in English.

The scene itself is busy: original systems, zines, homebrew, festivals, small publishers, a large OSR wing. It just happens behind a language wall.

There's been a news digest covering it since 2009 — weekly for most of that run, daily now. It was built the other way round from what you'd assume: made for Russian-speaking players who wanted to follow the world hobby, so it has always carried international news alongside local. Every item is now translated into English, which means the same window works in both directions.

https://gazette.rpg-news.org/

Disclosure: I used to be editor-in-chief of the outlet that publishes it, and now write for it and build the daily paper. My project, not a neutral recommendation.

So half of any issue is news you already have — Paizo, Kickstarters, the ENnies. The other half looks like this:

• Megakhrushch — a megadungeon whose entire setting is an infinite Soviet prefab apartment block. Endless identical corridors, hostile stairwells, and a booklet that generates the contents of each flat as you go. The author calls it "khrushch-crawling."
• Selo Borg — a MÖRK BORG hack set in a dying Russian village. The doom-metal apocalypse framing fits rural decay disturbingly well. A good example of what the scene does with imported systems: not translating them, but rebuilding them around local material.
• Post-Soviet Mysticism: Upyri — folk horror in ordinary courtyards and apartment blocks, built on Slavic folklore rather than the Anglo vampire canon, so the monsters don't behave the way you expect. You die, come back with real power and a real curse, and the actual question of play is why you'd keep existing at all.
• Mir Fantastiki, a long-running Russian SF magazine, just put out a 176-page print special entirely about tabletop RPGs — 150+ systems surveyed, assembled with dozens of authors and publishers from the scene. A glossy newsstand magazine covering our hobby at that depth, on paper, in 2026.

To be clear about what this is: we don't translate the games or the source articles. Each item is a short annotation in English plus a link to the original, which will be in Russian. It's a map of what's happening, not a library. The annotations themselves are machine translation with human review — good enough to follow, not literary, and game titles and personal names are the roughest part. The daily artwork isn't generated; it's historical illustration with a source note.

If any of this sends readers toward a designer, so much the better. A bit of interest from outside might be exactly what nudges some of these games into English editions, and I'm glad to help any author who wants to try.

Happy to answer questions about the scene itself — what's popular there, what's worth your time, how it differs from the English-speaking hobby.

I’m the solo developer behind Salt & Soil, and I’ve been rebuilding its map renderer so mountain ranges can continue across tile boundaries instead of looking like rows of separate sprites.

The old version treated every mountain cell as an isolated piece. The new renderer builds one continuous elevation surface first, then translates it back into the game’s isometric palette. The map cells, city positions, and simulation haven’t changed—only the way the terrain is presented.

These are the same three regions before and after: Sacramento and the Sierra Nevada, Chesapeake Bay, and the Great Lakes.

I’m a solo developer working on Salt & Soil, a generational strategy game with a world map that changes across almost 300 years. I’m preparing a new public playtest for September, so if the setting or map interests you, you can follow the game on Steam there.

These screenshots show three regions at the same scale:

• Sacramento and the Sierra Nevada
• Chesapeake Bay
• The Great Lakes

The upper panel is an aligned real-world terrain reference, the middle panel is my previous tile-based map, and the lower panel is the current renderer.

In the old system, every mountain cell received a separate sprite. That made the map deterministic and easy to work with, but every peak had to return to ground level at the edge of its tile. Large mountain regions therefore looked like collections of similar objects rather than connected landforms.

The new version builds one continuous elevation surface, derives slopes and lighting from it, and then translates the result into the game’s limited grass, soil, rock, and snow palettes. Trees, settlements, roads, and labels remain separate layers.

The underlying simulation has not changed. Gameplay still uses the same cells, settlement locations, roads, rivers, and historical data. I am only changing how that information becomes an image.

I’m not aiming for a one-to-one geographical renderer. Real elevation contains too much detail for this camera scale, so smaller features are simplified and some valleys or coastlines are exaggerated to preserve strategic readability.

The new terrain feels much more coherent to me, but I’m still tuning how much texture and contrast it should have. I’d be especially interested in whether the quieter surface has lost too much of the old tile map’s character while becoming easier to read.

I’m building Salt & Soil, a generational strategy game set between 1609 and 1900. After the feedback on my previous terrain posts, I rebuilt the map again—this time using the real geography as a reference.

This is the third entry in an accidental terrain-generation diary.

In the first post, I generated every terrain tile and mountain sprite procedurally. One version had the atmosphere I wanted, but roads, settlements, and strategic geography disappeared into the detail.

Several comments pointed out a deeper problem: the mountains could never become convincing ranges while every tile had to return to ground level at its border.

That led to the second post. I stopped asking each mountain cell to produce an isolated peak and began building one continuous elevation surface across connected terrain.

The new images show the latest result in three regions:

• Sacramento and the Sierra Nevada
• Chesapeake Bay
• The Great Lakes

The upper panel is an aligned real-world terrain reference. The middle panel is the previous tile-based map. The lower panel is the current terrain renderer. Each comparison uses the same region and scale.

The broad geography is now guided by elevation data, but the rendering itself is generated. The pipeline turns that data into a continuous surface, combines large landforms with smaller ridge-and-valley structures, calculates the surface direction, and applies consistent lighting across the terrain.

The result is then reduced into the game’s limited grass, soil, rock, and snow palettes. Trees, settlements, roads, and other objects remain separate layers, so the landscape can gain depth without swallowing everything the player needs to read.

The logical map has not changed. Rivers, settlements, roads, historical borders, and gameplay still use the same cells. The elevation surface is a visual interpretation of that data rather than a replacement for the grid underneath it.

The biggest lesson was that flat-looking mountains are not necessarily lacking height. My old mountains had plenty of vertical contrast, but their shapes and lighting restarted in every cell. Making the peaks taller or adding more noise only made the repetition louder. A continuous surface and one lighting model did far more to make the terrain read as a landform.

I am still deliberately cheating. Real elevation contains much more information than is useful at this zoom. Some valleys are widened, minor features disappear, coastlines receive cleaner silhouettes, and the palette is compressed so roads and settlements remain visible. The goal is recognizable strategic geography, not a geographical renderer.

And yes—the beaches are back. They are no longer entire beach tiles, though. The coastline is generated across cell boundaries, allowing narrow beaches, rocky sections, and direct grass-to-water transitions without turning 25 miles of coastline into one enormous strip of sand.

This is the latest checkpoint rather than the final version. I still want to recover some of the rocky character of the earlier mountain sprites without bringing back their visual noise.

I’ve spent the last few weeks rebuilding the world map for Salt & Soil, my generational strategy game. The goal wasn’t simply to make it prettier: mountain ranges, rivers, settlements, roads, and labels all needed to remain readable because geography directly shapes the player’s long-term decisions.

I previously shared parts of the procedural terrain pipeline on r/proceduralgeneration. After a lot of experimentation, I’m finally happy enough with the result to show the full comparison.

Each slide uses the same region and scale in the old and new styles. For the Sacramento area, I’ve also included the corresponding real-world terrain, rotated and scaled to match the in-game view as closely as possible. The game map isn’t meant to reproduce every detail, but major valleys, mountain ranges, coastlines, and settlement locations should feel recognizable.

The next public playtest is planned for September, and it will feature a completely different scenario from the previous one. There may be a few clues hidden in these maps—any guesses about when and where it takes place?

I’d also love to hear which version communicates the important strategic geography more clearly, especially at a glance.

I bought no hobby supplies specifically for this build. Everything came from the rubbish bin or from things already hiding in my workshop.

The walls are individual bricks cut from insulation foam, with builder’s filler pushed into the gaps. I painted them using some half-dried children’s acrylics that were apparently still alive enough for one last job. The reliefs around the entrance are pieces of the guard from a broken plastic sword, the plants came from some aquarium-themed toy, and the ground-floor door was a leftover part from a CastleCraft kit. The barrels are the only pieces I actually 3D printed.

The most expensive component is the sphere on the roof: it came from inside a can of Guinness.The tower demanded it.

I made the tower for Wizzard Tower, a narrative solo wargame I’m developing, in which a rather unimpressive mage gathers a retinue, learns spells, and slowly turns a miserable little tower into a proper seat of magical power.

It was also my entry for a terrain challenge that I organized myself—and somehow I still ran out of time. The final stage became a desperate race against my own deadline, so a few planned details never made it onto the model.

I’m Roman, the solo developer behind Salt and Soil, a historical family strategy game set on the American frontier. Researching it keeps turning up stories that sound like someone smuggled a meme into the archives, so I’ve started recreating my favorites as short visualizations with the game’s map renderer—specifically for r/HistoryMemes.

Today’s rabbit hole begins at Rouses Point, New York. In 1816, the United States started building a fort there to defend the northern end of Lake Champlain. The border was supposed to follow the 45th parallel, and according to the line being used at the time, the fort was safely inside the US.

Then an 1819 survey measured the parallel more accurately.

The border was roughly three-quarters of a mile farther south. The brand-new American fort was in British territory.

Construction stopped after about $113,000 had already been spent—at the time, not adjusted for inflation. The abandoned ruins acquired the wonderfully blunt nickname “Fort Blunder,” while locals gradually carried away much of the reusable stone, brick, and iron.

Then diplomacy rescued the mistake. In 1842, the Webster–Ashburton Treaty accepted the old surveyed line as the official border, placing the site back inside the United States. The government began building a new Fort Montgomery there in 1844. It eventually cost about $2 million, mounted 60 guns…and apparently never received a permanent garrison.

The animation is a historical visualization made with my game’s map renderer and settlement art, not footage of a scripted in-game event.

Sources: Clinton County Historical Association, Library and Archives Canada, and the US government records covering the fort’s cost and armament and its later status.

I'm building Salt and Soil, a family strategy game that runs from 1609 to 1900. Its public playtest recently ended, and one pleasant surprise was how often players said they liked the map.

But the comments under my previous post kept bothering me. Several people said the mountains were too confined to individual cells, too noisy when repeated, and should be generated with some knowledge of the surrounding mountain tiles. You also kept telling me to bring the beaches back. So instead of leaving the renderer alone after the playtest, I started a work-on-my-mistakes pass.

The image shows the same seed, the same logical map and the same scale. Only the terrain rendering changes.

01 — The previous 128 px tile map

This is the old baseline. Every logical mountain cell receives its own mountain tile. It is deterministic and easy to author, and any cell can hold a settlement, road or river.

The drawback is visible repetition: a large mountain region becomes a field of separate peaks, and every peak has to return to ground level at its tile boundary.

02 — Raised terrain with procedural 2D mountains

For this version, my script generates small 3D heightfields from ridge, saddle and massif profiles, calculates slope and lighting, reduces the result to the game's pixel-art palette, and bakes the result into 2D sprites. Some sprites cover several logical mountain cells, while the ground beneath them is raised.

This gives me much larger silhouettes and fewer identical peaks. It also keeps the convenience of sprites.

But the range is still assembled from separate objects. Their joins can become visible, dense groups still create visual noise, and settlements or rivers need special rules whenever they intersect a large sprite.

03 — One continuous 3D terrain mesh

In the third version I stopped placing mountains on top of tiles. The script takes the whole connected mountain biome, builds one shared heightfield, lays out ridges, branches, peaks and saddles, and then carves valleys through the same surface.

The result is projected onto the game's staggered isometric grid and shaded with the same small rock, grass and snow colour ramps as the rest of the map.

Rivers now follow the drainage valleys instead of being painted over the finished mountains. Mountain streams stay narrow, then widen in the lowlands. Roads follow the surface as well.

Trees remain upright 2D sprites, but their height and density come from the terrain: no trees above the tree line, more growth in lower valleys and near water, and foreground slopes can occlude them correctly.

I also finally brought the beaches back.

They are no longer full beach tiles: the coastline is generated across tile boundaries, with wider sand in sheltered sections, direct grass-to-water transitions on exposed sections, and small sandy or rocky far-bank faces to give the water a little depth. Bridges are now placed on the actual river centreline rather than the centre of a logical tile.

The logical map has not changed. Every cell under the mountain mesh is still a mountain in the game data, and settlements, roads and rivers still use the same cells. This is only a different way of turning that data into an image.

I plan to continue with version 03. It is less finished as pixel art than version 02, but it solves the structural problem that bothered me most: a mountain range can finally be one landform instead of a collection of objects pretending to touch.

Does 03 read as a coherent mountain range at gameplay scale, or has it become too smooth? And would you bring more of 02's rocky texture into it, or keep the surface quieter so settlements and roads remain readable?

Strategy games often turn skilled workers into settlement modifiers. While researching colonial Virginia, I learned that many young Virginians were apprenticed to blacksmiths for 3–13 years, usually until age 21.

The skill was not an abstract settlement upgrade. It belonged to the person who had spent years learning it.

That is what I wanted the mechanic in this clip to preserve. Nathan leaves the household at 17 in 1780. Three yearly turns pass without his labor or combat ability. When he returns at 20, the blacksmith specialty belongs to him: he can operate a smithy and produces tools 50% faster.

I am the solo developer of Salt and Soil, a strategy game about one frontier family from 1609 to 1900. The family tree is the campaign, and the free Steam Playtest is open through August 19.

I like maps because they turn lists of dates into spatial relationships. Timelapses take that one step further: compress three centuries into seconds, and a seemingly static map begins to feel alive.

I made this from historical data compiled for the map of my solo-developed game. It shows 147 conventional city-founding dates and ten historic route corridors. Political borders are omitted because no single boundary layer would be accurate across the entire period. The dates do not represent first human settlement, and the routes are not a complete history of colonization and migration.

The map belongs to Salt and Soil, a colony sim about one family living through a changing American frontier. Its public Steam Playtest is open through August 19.

Made a little grappling hook + rope marker for custom scenarios, and also just because I thought it would look cool hanging off the terrain.

The idea is that it represents a rope long enough to climb roughly to a second-storey window or battlement, so I can use it as an actual objective/interaction marker during games.

Very simple build: ordinary hemp twine soaked in superglue so it keeps its shape, with the grappling hook bent from a couple of paperclips.

The paintjob is pretty rough — I wanted to build and test the whole thing in about half an hour. I think it works surprisingly well on the table, though, so I’ll probably make a few more.

These are direct exports from the same renderer I wrote, with the camera, projection, crop and terrain layer locked between all three dates. The political layer uses dated source snapshots and holds each state until the next documented boundary change; it does not smoothly invent borders between dates.

Main geographic sources: Natural Earth, CEC Level III ecoregions, and the Newberry Atlas of Historical County Boundaries.

This is the economic trap I want Salt and Soil to create: in this 1613 household, three tobacco bales will gross 21 money in Jamestown, but the labour that produced the export crop did not grow food. The next-year food projection is already −10, while market food costs 5.

Tobacco is profitable and dangerous for the same reason: it lets the household specialise, then makes survival dependent on buyers, food prices and continued access to the market. The decision is no longer “can I make money?” It is “how much of the family's food supply am I willing to outsource?”

This is a deterministic economy, not an outcome written by the narrative AI. Tobacco bales, stored food and town prices are separate game-state values. The video reconstructs the numbers from this recorded run over the live map; it does not stage buildings or settlement growth.

Historically, the National Park Service notes that Thomas Dale initially limited tobacco cultivation because settlers might neglect basic survival needs. Its account of Jamestown in 1617 describes damaged infrastructure while colonists were dispersed planting tobacco. Source: National Park Service

Would you keep selling tobacco and buy food, or treat the negative food projection as a hard stop?

AI disclosure: generative AI is used at runtime for some family-specific Council prose and choices, and assisted parts of programming