Cfyz писал(а):Как утилитарная функциональность в библиотеке -- да, наверняка стоит оставить. Но конкретно в этом алгоритме построения лабиринта триангуляция, выходит, просто лишняя.
Она нужна при добавлении новых ребер, чтобы не проверять их на пересечения.
Ну и если просто брать минимальные - боюсь что могут артефакты быть (ну т.е. если все комнаты скучены слева, то и большинство коротких ребер будет слева, а при триангуляции шанс проходов у всех комнат будет зависеть только от топологии графа а не от физического расположения).
Или например можно для какого-то "жилого комплекса" взять число дополнительных связей >0.5 и получить почти полную триангуляцию с ровными треугольниками. А если брать минимальные то я не знаю что получится, может и фигня.
Cfyz писал(а):Именно поэтому я сказал "на случайном расстоянии N > 2". Треугольник получится только если между X и Y ровно N = 2 шага-ребра, дальше будет более длинный цикл.
А, я думал в клетках расстояние. Ну да, как-то так.
Cfyz писал(а):Да, мелкие комнаты потом используются для выгрызания ниш в коридорах -- но не проще ли будет построить аккуратные коридоры, а потом пройтись по ним и отдельно накидать эти ниши? Причем можно будет использовать варианты "порченья" коридоров, чтобы они выглядели по-разному.
Теоретически, когда ниши раскиданы заранее они более упорядоченно смотрятся, ну т.е. границы часто (но не всегда) выровнены и упираются в настоящие комнаты или образуют прямоугольные дырки. Хотя на практике я этого не очень замечаю.
Ну и если переделывать то появляется много дополнительных параметров - подойдет ли случайное раскидывание или нужно постараться ближе к краям сделать, как коридоры корежить, в общем когда я начинаю наугад решения принимать обычно получается фигня.
С другой стороны, плюсом будет что можно будет заранее число комнат указать, а не боятся что при маленькой карте их окажется 1 или 2.
Хм, хотя и в текущей версии можно просто N самых больших комнат брать, а не на порог ориентироваться.