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.

Hi everyone! Here’s another update on my procedural plate tectonics simulation.

The top is the previous version, and the bottom is the new one, both running along the same timeline.

In the new version, island arcs can now mature and accrete into continental crust, a few cleanup rules help reduce tiny isolated crustal fragments, and there’s now a basic craton mechanic as well.

Which version looks better to you?

[TLDR]: I released a free C++ library and free GUI application (Studio) for procedurally generating animated pixel-art spaceships, with a wide range of configurable parameters!

Hello everyone!

While working on my video game, Rogues in Space, I, a kind of pretty bad pixel artist, started developing a procedural spaceship generator, the purpose of which was to just generate a very basic ship that I could manually "clean up" and animate.

Aaand well, I just kept adding generators for more and more things - hulls, engines, wings, weapons... In the end I even added animations and spritesheets!

At some point, when it was clear that this (now) library and GUI application were getting larger than the video game itself, it made more sense to cut it off as its own project instead of having it permanently embedded in the game codebase.

So, after doing all the new work that I've never originally intended, today I've released SpectralShipGen and SpectralShipGen Studio as open-source projects!

SpectralShipGen is the C++17 generation library itself, while SpectralShipGen Studio is a standalone GUI application for visually playing around with the generator and exporting ship images and animation spritesheets without needing to integrate the library into anything.

On the technical side, ships are generated deterministically from seeds, and how they look (and from which components/color palettes and what intensity), can be controlled through structural profiles, faction profiles, mentioned color palettes and plenty of other generation settings. Majority of the aspects of an existing ship (so engines, details, accessories, weapons, etc.) can be rerolled individually instead of regenerating everything, keeping the general construction of the ship mostly the same, except for the specific parts that you wish to change.

Saving and loading the recipes for said construction is also supported, as well as adding the ships to favorites/bookmarks, and browsing them later.

All ships are also generated with Idle animation and with (currently experimental) left/right/up/down movement and firing animations.

I've tried to keep the different visual identities fairly broad rather than making them into simple predefined ships. So, the same structural style or faction can still produce quite different results based on the seed and configuration.

The library itself is independent, while the Studio application does rely on SFML (and the library, of course) for the graphical rendering, button interactions, and everything else GUI related.

Interestingly, an unexpected amount of work towards this release ended up being in the boring-but-important category - regression/performance/robustness testing, establishing CI, writing (everyone's favorite) documentation, thinking about how licensing works, etc., so that these two can actually function as an independent library and a standalone application.

I've attached several examples of generated animations that I thought were interesting to show what the output can be, although they only cover just a tiny amount of what can be generated. I've also attached a couple of screenshots from the Studio application as well.

In case anyone likes what they're seeing and is wondering about using the generated output - anything you generate with it is yours to use however you want, including commercially. There's no attribution requirement and the source code licenses don't apply to the generated images or spritesheets.

Lastly, I'd also like to mention a couple of important topics.

I definitely don't see this ever replacing actual pixel artists - someone who's at least decent with pixel art can likely make a much better spaceship by hand. Something like this is, I think, much more useful if you're on a very tight art budget, if you need/want a bunch of ships generated during runtime (as you don't really need to save the generated spritesheet to disk in order to use it), if you're at a game jam and just need urgent assets.. Or if you just wanna generate a few hundred ships to see what odd things appear, because that can also be pretty entertaining (I may or may not have spent too much time doing just that).

Something that I also want to be fully transparent about, because I do think it will definitely be asked - the development/code writing on this project has been AI-assisted. However, that is the extent of it. There is no generative AI image creation anywhere in SpectralShipGen, reference images are NOT used, and there aren't any premade spritesheets or images "hidden" behind the library being chopped up and re-combined.

The ships are generated by the C++ code itself through procedural geometry, pixel masks, components (hull, engines, details, weapons, etc.) placing rules, seeded random decisions, and so on.

The nice thing about doing it with deterministic seeding way is that the same seed and the same configuration always give the same ship.

The amount of AI assistance during development was also one of the reasons I personally felt more comfortable making the project open source instead of keeping it completely proprietary. That's also not supposed to be some statement about how AI-assisted software should be licensed or what anyone else should do with their own work (that's a completely separate discussion) - it just felt like the right choice for me and this particular project.

As mentioned, the generated output is deliberately unrestricted as well - if you generate a ship image or spritesheet with SpectralShipGen (or Studio), you can do whatever you want with it. Use it in a commercial video game, redistribute it, paint over it, use it as a placeholder - attribution isn't required.

Links:

Library: https://github.com/SpectralHorse/SpectralShipGen
Studio: https://github.com/SpectralHorse/SpectralShipGen-Studio
Studio Download (from GitHub): https://github.com/SpectralHorse/SpectralShipGen-Studio/releases/tag/v1.0.0

I'd be very interested to hear about your thoughts - both about the generator itself and if the different ships actually feel like they have enough variety while still looking like they are thematically and systematically similar.

And, of course, if you end up generating something ridiculous with it - I'd love to see it! :)

Essentially i have many maps like the one you see above where there are color bands representing ranges of elevation as well as notable rivers and other bodies of water. I would like to create a program that can use the information presented into these maps as constraints that then erosion would be applied to to convert it into an highly detailed, grayscale, realistic, elevation map. My thought is to draw "ridge line" divides across the map that divides which way water would flow, and have it naturally flow away from those ridge lines and towards the pre drawn bodies of water, eroding and depositing soil at rates determined by the slope of each band. i also thought of including a geology map layer that could further effect rates of erosion and deposition, as well as uplift to counteract erosion in some places.

Is this the best way to simulate natural terrain formation to turn a hand drawn map like this into a realistic, high detail height map or is there a better way?