Комментарии 15
Не нравится мне такой подход. Стараешься, геймплуй придумываешь/продумываешь, самореализовываться и улучшать уровень игрок будет так, способности у него будут либо такие, либо сякие итд итп, а в конце просто кидаешь его на месиво из комнат.
Мне больше импонирует Joris Dormans — (у него что-то сайт не работает, скинул ссылку на презентацию). Кроме концепции циклических уровней у него есть ещё отличная идея, что уровень надо строить не с генерации комнат, а с генерации того, что игрок будет делать — то есть всякие двери, головоломки, монстры — то бишь генерация геймплея — а уже потом комнаты.
НЛО прилетело и опубликовало эту надпись здесь
Так второй алгоритм перед работой и делает поле «не квадратным». Можно просто выкинуть первый этап. Или имеется ввиду непрямоугольная сетка?
НЛО прилетело и опубликовало эту надпись здесь
<грязный хак>
можно в 1м алгоритме при наличии свободного места коридоры и комнаты поворачивать рандомно. Или даже заложить это место при генерации
</грязный хак>
А изгиб… Собственно тот же хак с запасом места при генерации и последующим скруглением углов. Вместо квадратных комнат (если таковые будут) можно генерить круглые и т.д.
Если совсем упороться, можно предварительно генерить, например, диаграмму Вороного и в качестве сетки использовать её. Ну или просто считать большие полигоны комнатами, узкие — коридорами. Форму в пределах соседей можно постобработкой подрихтовать.
можно в 1м алгоритме при наличии свободного места коридоры и комнаты поворачивать рандомно. Или даже заложить это место при генерации
</грязный хак>
А изгиб… Собственно тот же хак с запасом места при генерации и последующим скруглением углов. Вместо квадратных комнат (если таковые будут) можно генерить круглые и т.д.
Если совсем упороться, можно предварительно генерить, например, диаграмму Вороного и в качестве сетки использовать её. Ну или просто считать большие полигоны комнатами, узкие — коридорами. Форму в пределах соседей можно постобработкой подрихтовать.
Смотря что понимать под «неквадратными»:
- Если про неквадратное поле, то с этим всё ок — изначально поле может быть прямоугольным.
- Если про стены не под 90 градусов — то я в эту сторону не копал, т.к. для моих целей это не нужно (скорее наоборот, мне очень нужно чтоб все стены были под 90 градусов). Вероятно, можно вместо «полибоксов» делать обычные полигоны, и сглаживать углы.
Спасибо за интересную и красивую статью. Узнал для себя много нового.
Здорово конечно, спасибо за статью.
Интересно, как определяется сложность уровня. Количеством/размером комнат?
Также сказано, что время неважно. Но сколько уходит на генерацию уровня, несколько секунд, минут?
> Интересно, как определяется сложность уровня
Не исследовал этот вопрос. Вероятно, когда уровень уже будет в реальной игре, то сложность будет определятся не сколько хитроумностью лабиринта (в игре есть карта), а скорее количеством врагов, их «крутостью», количеством аптечек, патронов и т.д.
> Также сказано, что время неважно. Но сколько уходит на генерацию уровня, несколько секунд, минут?
На глазок — пару секунд. Думаю, если убрать всё что связано с логгированием и записью промежуточных картинок, то должно отрабатывать примерно мгновенно.
Не исследовал этот вопрос. Вероятно, когда уровень уже будет в реальной игре, то сложность будет определятся не сколько хитроумностью лабиринта (в игре есть карта), а скорее количеством врагов, их «крутостью», количеством аптечек, патронов и т.д.
> Также сказано, что время неважно. Но сколько уходит на генерацию уровня, несколько секунд, минут?
На глазок — пару секунд. Думаю, если убрать всё что связано с логгированием и записью промежуточных картинок, то должно отрабатывать примерно мгновенно.
Не исследовал этот вопрос. Вероятно, когда уровень уже будет в реальной игре, то сложность будет определятся не сколько хитроумностью лабиринта (в игре есть карта), а скорее количеством врагов, их «крутостью», количеством аптечек, патронов и т.д.
То есть по объему все уровни одного размера? Для игрока не будет скучновато? Ведь приятнее, когда первые уровни маленькие и проходятся быстрее, а более сложные уже и запоминать надо что где
Другой вопрос. Сценарий получается линейным? То есть комнаты открывается проходятся как A->B->C или всё-таки предусмотрена нелинейность A->C->B->D. Из статьи не совсем понял этот момент
> То есть по объему все уровни одного размера?
Размер уровня зависит от изначального размера поля, оно конфигурируемо (и не обязательно квадратное).
> Сценарий получается линейным?
В этом генераторе сценарий всегда линеен (т.е. не может быть такого, что, например, игроку сразу доступно два ключа, которые нужны будут потом).
Но это не означает что не придётся походить, например, итоговый путь может быть такой: A -> B -> A -> C -> A -> D -> E (при этом сценарий линеен — A открывает B, B открывает C, С открывает D, D открывает E)
Размер уровня зависит от изначального размера поля, оно конфигурируемо (и не обязательно квадратное).
> Сценарий получается линейным?
В этом генераторе сценарий всегда линеен (т.е. не может быть такого, что, например, игроку сразу доступно два ключа, которые нужны будут потом).
Но это не означает что не придётся походить, например, итоговый путь может быть такой: A -> B -> A -> C -> A -> D -> E (при этом сценарий линеен — A открывает B, B открывает C, С открывает D, D открывает E)
У меня вопрос. В алгоритме много сложностей и мест перерасчета связанных именно с сеткой 3x3. Скажите а вообще рассматривалась возможность генерации без стен и дальнейшим разбиением на стену\проход, ведь по факту основная сущность генерации именно «проходимое пространство», а уже затем отделение кусков друг от друга стенами\проходами? С этим связаны более сложноразрешимые проблемы? Или это требование дизайна уровня?
Генератор писался под конкретный движок, в котором стену нельзя поставить между двумя рядом стоящими тайлами (т.к. сама стена размером минимум 1x1 тайл)
Я имел ввиду в процессе генерации рассчитывать сразу генерацию <1 тайл генерации> = <3x3 в конечной карте>. А затем после генерации разметить где из этих 3x3 будут стены и проходы с учетом смежности комнат. Соответственно вопросы в силе :)
Да, это сработает. Но на мой вкус будет меньше гибкости — в текущей реализации комната может быть 3x3, 4x4, 5x5 и т.д., а в реализации где тайл генерации — 3x3 в карте комнаты будут 3x3, 6x6, 9x9 и другие кратные 3м.
Но если вы будете использовать подобный метод генерации для вашей игры, и вас это будет устраивать — why not?
Но если вы будете использовать подобный метод генерации для вашей игры, и вас это будет устраивать — why not?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Процедурная генерация уровней