Generated on the Website: Merak Map Maker

This is a "wind-blown" version of an earlier project of mine (see the original in comments).

The L-system rule is the same, but each segment follows a curved path rather than a straight one.

I think this one has a much more natural flow, without losing its mathematical roots.

Which version do you prefer?

Coded in Processing.

Plotted in about 6 hours with Pentel Energel 0.4 - 0.7 on 300x400 220 gsm Fabriano F4

I’ve been working on this for a while and finally put it online: https://astrolume.ableproman.hu

It’s an endless map of single stars generated from a seed. Open a star and you get a rendered sphere on the left and a long list on the right with everything computed about it: mass, radius, temperature, luminosity, spectrum, rotation, age, how it will end, the habitable zone, and numbers for a planet at 1 AU such as the starlight it would get and how big the star would look.

How the generation works:

• The map is cut into chunks, and each chunk is generated on demand from the seed and its coordinates, so the same seed always gives the same stars. No star data is stored or downloaded, since each star is computed on your machine.
• Each star gets a population (thin disk, thick disk or halo), a mass from an initial mass function (Kroupa 2001), an age and a metallicity, and an analytic evolution track decides what it has become: a main-sequence dwarf, a giant, a white dwarf, a brown dwarf, a pulsating variable and so on.
• Everything else is derived from those. Temperature and luminosity come from the track, colour from a published calibration table, the spectrum from a blackbody with the main absorption lines, and the surface look (granulation, spots, gravity darkening) from rotation and activity.
• The sphere is rendered live in WebGL, and the whole app is one HTML file with no libraries.

Where a published relation exists I used it instead of putting false data, and rows that are rougher estimates are marked with an approximate sign. The only real star is the Sun, which sits at the origin with its measured values. Binaries, neutron stars and black holes aren’t in yet.

There’s also a compare mode that puts two stars side by side at true scale, so a red giant next to a white dwarf shows just how big the difference is.

I’d be glad to hear what looks wrong, especially from anyone who knows stellar physics better than I do.

I'm a solo dev making Seedborne Chronicle, a free-roaming guild RPG in the spirit of Lunatic Dawn IV: you wander, take jobs, make friends and pass your guild on.

You type a seed and a continent grows from it: the land and its coasts, 8 towns, 14 labyrinths and 28 adventurers with their own homes and stats.

The first version ran in the browser. When I moved it to Godot 4, I kept tests that compare the new generator with the browser build's output for four seeds, so the same seed still grows the same continent, down to the coastline.

The coastlines were the ugly part. Shores followed the tile grid, so water sat in steps wherever the height changed. Now the ground is one heightfield sampled three times per tile: the shoreline falls where land meets water, beaches slope into the sea, and grass, rock and snow blend at their edges. Images 2 and 3 are the same seed from the same camera, before and after.

How do you keep a seeded world stable while you keep adding features to the generator?

Image descriptions (in gallery order):

1. The Godot build's continent for the same seed: the same coastline, lakes and peaks, now with low-poly trees, towns and soft terrain.

2. Before: a lake next to the first town follows the square tile grid, with stepped square corners.

3. After, same camera: the lake has a curved shoreline with a sandy beach sloping into the water.

4. Eight continents from eight random seeds: islands, twin continents, a crescent bay and single landmasses.

During stumbling or falling, there are no keyframed animations anywhere, they are not even blended in.

When a character gets hit or experiences any form of physical force, the body behaves like a fully simulated physical puppet. Balance controller then calculates where to put each feet and how stiff each joint should be based on the momentum of the body and which way it goes. All of it is computed in real time.

It’s my take on the kind of physics euphoria by natural motions brought to gta and rdr games, thus the chosen name, despair physics. It will be one of the core mechanics in my upcoming fps prototype called "Upper Management".

If you are interested in where this ends up, best place to follow is my official site and a mailing list.

Hey guys!
I made a world generator that runs entirely out of your command prompt/terminal for my indie game CultGame. It's like like Dwarf Fortress-lite means South Park.

The world generation works by seeing a 2D map of ocean tiles with volcanic activity and then additively generating tiles near the continent starting points (the @ signs) with a chance to randomly generate a land tile anywhere to add some chaos and variance. Tiles have a higher chance of becoming land tiles the more land tiles adjacent to them.

Once all the land tiles are decided, I used latitudes, nearness to water, and random chance to start generating terrains everywhere. Once a few terrains start generating, nearness to existing terrains also plays into the generation of new terrains on tiles that are undecided.

Hope you enjoy!

You can check out the game this is from, CultGame, here: https://store.steampowered.com/app/2345980/CultGame/

More video details and this

I’m not tired; I just want to get it to a finished state

My mobile game has no audio files: the whole soundtrack is a gayageum (Korean 12-string silk zither) generated at runtime. I wrote up how it works, with a demo you can play in the browser (same code as the game):

https://boreumdal.app/devlog/gayageum/

The procedural parts:

The string. Karplus-Strong with a fractional-delay allpass for tuning. The "silk" tone comes from shaping the excitation: the noise burst is smoothed twice, then comb-filtered at 1/7 of the loop to imitate the pluck position. Each string is baked once from a fixed seed, so the same string always sounds the same.

The composer. It writes 12-beat phrases in a five-note mode (pyeongjo):

• each note moves one or two steps from the previous one, inside two octaves
• long notes get vibrato; short notes landing on one particular degree sometimes get a bend up to the next
• every phrase comes to rest on the 1st or 4th degree so it sounds finished
• a low string drones every three beats
• if a new phrase has the same shape as any phrase from the last 60 seconds, it's thrown away and rewritten (up to 8 tries)

Density and tempo follow the game state (76 to 102 BPM as you survive longer), and endless mode shifts the register through day, dusk, night and dawn.

The visuals are generated too (ink brush strokes with tapering, bleed and dry-brush streaks drawn on Canvas 2D), so the game ships without image files either; the iOS app is 13 MB. Happy to go into any part of it.

This is an updated verison of my earlier post, its roughly 4x as long and hopefully better highlights the visual features of the fire fronts.

It is a stochastic cellular automata based on the Drossel–Schwabl forest fire model implemented on a hexagonal grid using numpy + matplotlib

Fire starts on any cell with p_fire = 0.0001 by a "lighting strike", while trees grow on empty cells with p_tree = 0.01. Fire spreads to all neighboring trees.

more detail here: https://github.com/BaramiDev/MineAssembly/blob/main/docs/HOW_IT_WORKS.md

rough idea: - six noise fields (continentalness, erosion, temperature, humidity, peaks/valleys, hills) sampled every 4 blocks and lerped - height comes from the continuous values, not the biome id, so you don't get cliffs at biome borders - rivers follow the zero line of their own fbm. a wide band flattens the land toward water level and a narrow one digs the channel, in mountains you get gorges - biomes are a few rules (ocean/mountain/swamp/beach) + a temp x humidity table - caves: spaghetti where two 3d noises are both near zero, bigger caverns where a third one is high, lava below y=10 - trees that cross chunk borders: each chunk replays its neighbours' tree spots so all the worker threads agree

textures and sounds are generated too, there's no asset files at all

Lately I've been working on a driving game that can create playable maps of real-world locations using free OSM and elevation data. My main focus was making the roads accurate for lane count and heights to properly account for overpasses, bridges and tunnels.

I started with Dallas since I've lived there the longest and know it well enough to fine tune for accuracy so that it can scale to other areas eventually. Previously I was just rendering standalone levels but now I managed to get them connected efficiently for streaming nearby tiles as you drive. This current map only has 8.6% of the city but I'm planning to expand soon.

I'm new to a lot of this and having a fun time learning as I go so I'm open to any feedback! Still in the early stages while I work out the literal kinks in the road lol.

I recorded this with my RTX 2050 and managed to get 144 FPS with 60 FPS on mobile.

Hey everyone! I got tired of manually drawing, slicing, and aligning 2D isometric tiles, so I decided to fully automate my workflow. I’ve been working on a custom Python pipeline that generates dungeon architecture from scratch and pieces it together using Wave Function Collapse (WFC).

Since Reddit allows image carousels, I attached a few screenshots of the pipeline in action:

• Image 1 (The WFC Layout): The algorithm builds the maze, reserves paths for navigation, and scatters props. It also bakes in a "wear and tear" layer—thickening the hatching in corners for a procedural ambient occlusion effect, adding cracks, and placing cobwebs.
• Image 2 (The Tile Math): Everything is drawn mathematically based on a strict 2:1 projection. The engine uses Perlin noise for procedural crosshatching to simulate real ink pen strokes. Because it's math-based, the blocks snap together pixel-perfectly without any seams.
• Image 3 (The Godot Export): Since the generator knows the exact 3D geometry of every drawn brick and barrel, it automatically renders Normal Maps and calculates LightOccluder2D polygons. It exports a ready-to-use .tscn scene where the 2D monochrome hatching fully reacts to PointLight2D nodes, preventing light from bleeding through walls.

Generating a level like this takes just a few seconds. Next up, I’m planning to add non-linear corridors (using MST graphs) and procedural water animation.

What details or features would you add to make these generated dungeons feel more alive?

Play: https://axieyangb.github.io/world-explorer/

Code (MIT): https://github.com/axieyangb/world-explorer

Type a place, click the world map, or put coordinates in the URL. The world builds itself in seconds: 40 km × 40 km of terrain, roads, buildings, water and street life streamed from open map data.

Happy to talk about chunk streaming or keeping memory bounded. Feedback on performance very welcome.

Processing video vscxu0ae1yxh1...

After the dungeon post a few people asked if the pen could draw something other than grey stone. So I split out "style" and tried a desert tomb.

The hard part was the walls. Each tile draws its own wall pieces, but the paint has to read as one long wall. So the dado, the stripe band and the frieze are placed at absolute heights, and the columns of signs sit at fixed positions along the wall (5 per cell), not per piece. Neighbouring tiles agree by construction and nothing has to be stitched afterwards.

The signs are random picks from 8 simple shapes, drawn in the wall's own plane so they lean with the isometric face.

Sand drifts replace the dirt hatching, and quicksand is a new fluid that flows in 4 frames.

It's on itch if you want to see more: https://antahonist.itch.io/ink-dungeon-sand-tomb-isometric-godot-kit