Cool, the interactive visualisation is a great way to explain it.

Maybe a similar-ish idea could be done in a continuous 2d space, without a grid, using 2D computational geometry operations (e.g. GEOS's [1] buffer operation to grow shapes by a given radius & so on).

Each component is a point-set -- a subset of points in the 2d space we're working in.

  1. sample a bunch of seed points from some distribution. these define initial connected components
  2a. grow each component by radius r. union any components that touch.
  2b. shrink each component by radius r + delta. delete components that contain no points
  3. delete any components that are 'too small': shrink each component by r_min, delete any components that now contain no points, then grow each surviving component by r_min again
  4. link the surviving connected components somehow:
  4a. identify pairs of components that are adjacent (e.g. compute voronoi 'triangulation' using components as seeds instead of points, if two resulting triangles border then their components are neighbours)
  4b. propose candidate corridors linking the nearest points between each pair of adjacent components
  4c. find a minimal/interesting spanning tree on component-corridoor graph using corridor lengths as edge weights
  4d. carve selected corridors by growing each coridoor line by some radius
  4e. everything should be some big connected component
  5. sanity check that we got something playable (maybe based on area). if it's too small/uninteresting, reject & try again from step 1

I'm not sure of an efficient/reasonable way to do step 4a in the plane - it'd be simple & efficient to do this on a graph (Voronoi-triangulating a graph has similar computational cost to finding all shortest paths from some source - it's like a multi-source BFS with bookkeeping to recover a shortest path to the closest source, with a little extra bookkeeping & logic).

Nethack's cellular automata gnomish mine algorithm on a small grid is of course going to be massively faster than stuffing about with masses of GEOS Buffer & Union calls, but it's fun to think through how much of this extends.

[1] https://libgeos.org/