Patch-Flap Map Generator

Notes:

• Built for use with Patch Flap tileset (gitlab)
• If you want to save a map, remember its seed and height/width parameters. The same seed but different height/width will alter the outcome of map_nw a lot after the first line. Using the same seed but larger height/width will actually expand map_c maps (!)
• Algorithms may run into a dead-end in generating the next viable tile if two existing neighbouring tiles have disjoint sets of possible candidates for their shared neighbour. In this case, they will backtrack, discard the previously tried tile, and try to move forward again. This may result in a longer generation process than usual. If there are too many failures, it will abort.
• map_nw: original, starting from nw, se water bias
  This algorithm starts in the north-west corner and goes left-to-right, then top-to-bottom. It has a bias towards south-east diagonals. When selecting a tile from the candidate neighbours for its north and west neighbours, it takes the intersection of both neighbours neighbour option sets and picks a random tile from that. If one of the two neighbour's neighbour sets is Much Larger, it will disproportionately bias the outcome. (Uh oh!)
• map_c: from the centre, spiralling out, senw; recursive, slower
  
  • This starts in the centre of a square map with an equal, odd number of tiles wide and high.
  • This one uses recursion to facilitate backtracking. However, that limits how deep you can go based on JavaScript's limits.
  • As noted above, some maps end up with trick dead-ends that they try to back out of, but they're too deep down an non-viable path, so eventually we just abort after too many backtracks ('uh ohs').
  • Neighbouring tile's candidate neighbour sets are provided as squared percentage frequency tables. Using percentages for candidates instead of tile count lists, it avoids the bias of one neighbour having a possibly-much-larger list of candidate tiles.
  • Squaring the percentages also makes the most likely from before even more likely (the square), which addresses the following issue:
    • An existing neighbouring tiles is a horizontal road, and it really wants a 95% change of continuing the road, and a 1% chance of it being a + intersection. However, the other neighbour is just a tree trunk, and it just simply lists which tiles are possible below it, giving a +, grass, rocks, and some water each 25% chance. The result of simply merging it would thwart the bias of the horizontal tile,
      (0.01 + 0.25) / 2 = 0.13 (13%)
      meaning we'd see a lot more + than we'd ever hoped. Using the square, continuing the road becomes ~91% likely and getting the + is now
      (0.01² + 0.25²) / 2 = ~3%
      
• map_field: not implemented, but a design for an algorithm that starts with a map where each cell initially starts as any possible tile, but with some randomness and tile neighbour probabilities, over many iterations it refines itself and settles on a viable map.