Генерация лабиринтов

[TomCaT]

сделаю маленький пример, лабиринт 3x3, 9 клеток:

+-+-+-+
|1|2|3|
+-+-+-+
|4|5|6|
+-+-+-+
|7|8|9|
+-+-+-+

клетку 1 - в А, остальные - в Б. по очереди будем выбирать такие пары А-Б: 1-2, 2-3, 3-6, 6-9:

+-+-+-+
|1 2 3|
+-+-+ +
|4|5|6|
+-+-+ +
|7|8|9|
+-+-+-+

потом 6-5, 5-4, 4-7, 5-8

+-+-+-+
|1 2 3|
+-+-+ +
|4 5 6|
+ + + +
|7|8|9|
+-+-+-+

разве не получились тупики?

+-+-+-+
|     |
+-+-+ +
|     |
+ + + +
| | | |
+-+-+-+

Да, я понял. Вы действуете с А и Б в пределах одного прямоугольника. Действительно, м/б быстрее. Я всё же думаю, MAZIACS сей алгоритм не применяли, а там лабиринты О-ГО-ГО какие качественные. Хотя может, я ошибаюсь...

кроме того, при соотв. выборе ГСЧ, получается произвольный заранее заданный лабиринт, как и в Вашем алгоритме. они делают примерно одинаковые лабиринты

Нет. В моём алгоритме не используется ГСЧ. На самом деле предварительно составляется список всех поднимаемых стенок, а затем список "рассортировывается" по ГСЧ, который сложным образом зависит от дата/времени. Т.о. повторяемость лабиринтов минимальна. Но это на IBM. Для Спекки такое малоприменимо. Разве что подсчитывать время, в течение которого юзер разглядывает меню, а затем использовать как SEED

Это ещё не связность, а лишь наличие пути между двумя точками его тут достаточно. да и обход по руке будет более оптимален, чем обходы в глубину или ширину. кажется, тут уже ничего алгоритмически не сделаешь, нужно думать, как оптимально накодить обход по правой руке (ну, или алгоримт с А-Б заюзать)

Тогда объясните, что вы понимаете под проверкой связности. И почему путь между двумя точками (если эти две точки - в комнатах по обе стороны только что поднятой стенки) не указывает однозначно на наличие/отсутствие связности?

2All:

как и обещал, высылаю выдранный из MAZIACS генератор. Не удосужился дебаггнуть. Если кто-то хочет его использовать, но не знает как, пишите мне на мыло или сюда, я раскопаю свой Labirint на BASIC'е и припомню вх./вых. параметры процедурки.