Wanted
Rivers should be able to travel through the settlement the way watabou's MFCG does (reference: Dragonbark Keep screenshot): the river enters at one map edge, threads through or past the built fabric, and exits at another edge. Wherever a street or road crosses the river, a bridge is drawn — and bridge count should be plausible (main streets bridge the river; minor alleys dead-end at the bank). Watabou's village generator does the same at village scale with small bridges/fords where paths cross (reference: village screenshot).
Concretely:
- River corridor in the mesh — the river carves through patches; buildings never overlap the water, and riverbank patches can still host wards (MFCG happily names a ward "Silk Bank" along the water).
- Entry/exit points — the river's entry and exit bearings should ultimately come from FMG river geometry in burg-local coordinates, the same way
coastlineGeometry works for the sea, so the on-map river agrees with the world map.
- Bridges — placed where the street graph crosses the river polyline; count scales with settlement size/street importance. A wall circuit crossing the river needs special handling (water gates, or the wall terminates on each bank).
- Confluence with existing water — estuary case: river meets the coast where a harbour may also live.
Current state
GenerationParams.riverPath?: Point[] already exists (src/generator/generation-params.ts:458) but is a dead stub — the declaration is the only reference in the codebase.
- Water handling today is ocean-only:
coastlineGeometry polygons or the oceanBearing half-plane feed classifyWater; rivers are not represented in the mesh at all.
- The input layer knows rivers only as a route modifier:
RoadEntry.followsRiver (valley roads).
- A
sm-bridge symbol already exists in the symbol library (src/assets/symbol-manifest.ts, batch001) but nothing places it.
Pointers
src/generator/model.ts — classifyWater, buildStreets, buildWalls are the phases a river corridor has to thread through
src/generator/generation-params.ts:458 — the riverPath stub; probably wants to grow width info, or become a polyline+width like a thin coastlineGeometry
- Settlement water was parked 2026-07-06 with open problems — river work should revisit that before building on top
- Related: the wall/water interaction and tile-cache invalidation notes from the parked water work
Wanted
Rivers should be able to travel through the settlement the way watabou's MFCG does (reference: Dragonbark Keep screenshot): the river enters at one map edge, threads through or past the built fabric, and exits at another edge. Wherever a street or road crosses the river, a bridge is drawn — and bridge count should be plausible (main streets bridge the river; minor alleys dead-end at the bank). Watabou's village generator does the same at village scale with small bridges/fords where paths cross (reference: village screenshot).
Concretely:
coastlineGeometryworks for the sea, so the on-map river agrees with the world map.Current state
GenerationParams.riverPath?: Point[]already exists (src/generator/generation-params.ts:458) but is a dead stub — the declaration is the only reference in the codebase.coastlineGeometrypolygons or theoceanBearinghalf-plane feedclassifyWater; rivers are not represented in the mesh at all.RoadEntry.followsRiver(valley roads).sm-bridgesymbol already exists in the symbol library (src/assets/symbol-manifest.ts, batch001) but nothing places it.Pointers
src/generator/model.ts—classifyWater,buildStreets,buildWallsare the phases a river corridor has to thread throughsrc/generator/generation-params.ts:458— theriverPathstub; probably wants to grow width info, or become a polyline+width like a thincoastlineGeometry