Деконструкция математики движка провода из моей игры DETOUR

В прошлый раз я рассказывал, как мой экшен-паззл DETOUR взял 8-ое место по "Инновации" на прошедшем Ludum Dare. В этот раз я расскажу про то, как я реализовал поведение провода в игре (а потом написал с нуля нормальный математический движок). Начну с понятного разбора на пальцах без единой формулы, закончу текущей реализацией и её кодом. Поехали!

(это перепост моей статьи, которую я вчера случайно запостил в личный блог вместо Gamedev. Если вам кажется, что вы её уже видели — вам не кажется.)

Определимся с ТЗ. Чего мы хотим по итогу от провода (который я буду иногда непроизвольно называть верёвкой)?

Так как времени на геймджемах не очень много, хотелось сначала продумать методы, не требующие написания большого количества кода. В целом, был только один такой метод — "физический движок". Колонны это физические объекты с коллайдерами, провод это "цепочка" с кучей звеньев, каждое из которых физический объект с коллайдером... Я думаю, понятно почему я отбросил эту идею достаточно быстро. Физические движки достаточно неточные, верёвка будет непредсказуемо вести себя на изломах, в целом болтаться влево-вправо — в общем, прямая противоположность того, чего хочется видеть в головоломке на точный просчёт и скорость.

Так что, вздохнув, я обратился за помощью к "задротскому" подходу через математику. На деле оказалось проще, чем казалось изначально. Собственно, эта статья как раз родилась как идея показать, что сложные концепты часто можно разложить на понятные составляющие.

Для написания игры я использовал Godot и некоторые его встроенные объекты, но уверен, что читателю будет несложно представить объекты из любого другого движка, или даже просто математические абстракции.

1) Для визуальной составляющей я использовал Line2D, который просто по порядку соединяет линией заданные точки.

2) Эти точки хранятся в коде в массиве. Первая точка всегда неподвижная зарядная станция, последняя — всегда робот-игрок. Игрок может двигаться, мы тогда обновляем координаты последней точки.

3) Каждый кадр, когда игрок двигается, мы дёргаем специальную функцию, которая обновляет коллизию у верёвки. В этой функции мы смотрим все пары соседних точек верёвки и строим между ними прямоугольные коллайдеры (CollisionShape) нужной длины и ширины:

4) У объектов-колонн добавляем по небольшому квадратному коллайдеру в каждом из углов. Когда такой коллайдер детектирует столкновение с каким-то коллайдером провода из предыдущего пункта, то он посылает сигнал со своими координатами в код, где мы работаем с массивом точками провода. Код просто добавляет по этим координатам новую точку в массив на предпоследнее место, перед роботом — фактически деля последний отрезок провода на две части.

5) Также все углы запоминают, какие именно два новых участка провода они касаются, чтобы не создавать бесконечно новые изломы в одной и той же точке.

Уже выглядит неплохо, но самое сложное впереди: нам нужно научиться отлеплять провод от углов. Тут и пригодится математика!

6) Как проверить, нужно ли всё ещё касаться угла? В целом, весь секрет — сравнивать нужные углы! Допустим, последний отрезок в проводе составляет угол Y с горизонтом, а предпоследний — угол Y:

До тех пор пока Y>X, верёвка натянута вокруг угла. Если игрок начнёт идти влево-вниз, в какой-то момент Y станет меньше чем X (на рисунке это пространство слева от пунктирной линии), и тогда надо отлипнуть от угла, что в коде равнозначно удалению предпоследней точки.

7) Вычисления выше верны, если мы заходим за угол слева; справа всё почти то же самое, кроме того, что надо ждать, пока Y станет больше чем X, а не меньше. Как нам проверять "сторону"? Опять сравнивая углы! В момент столкновения верёвки и колонны сравниваем два угла:

8) В зависимости от знака больше/меньше получаем сторону, сохраняем её в коде в соседнем с точками массиве, и используем в момент "отлипания верёвки", чтобы выбрать знак больше/меньше в пункте 6.

_______________

Вот и всё! Как это выглядит?

Поиграть в итоговую конкурсную версию игры можно тут:

Разумеется, это решение неидеальное, а также было много "но", которые я опустил, потому что это уже детали имплементации. Основные проблемы и "костыли", с которыми я столкнулся:

В рамках геймджема сойдёт и то, что получилось в предыдущем разделе, но для полноценной игры хочется чего-то надёжнее и точнее. Хотелось поддержать подвижные колонны, разобраться с касанием нескольких колонн одновременно, и по-хорошему заменить коллайдеры на что-то более точное.

Я не буду мучать ни себя, ни вас подробным построчным разбором итогового кода нового "движка", который я писал неделю, но ниже расскажу про основные изменения, а особо пытливые могут посмотреть исходный код:

Как у меня это часто бывает, я не мог нормально работать, спать и просто существовать, так что на несколько дней пока всё не заработало как надо моя жизнь превратилась в кошмар. Но к счастью движок собрался, всё работает как задумывалось, а я свободен от этого проклятия и могу написать эту статью.

Я не очень знаю, для кого эта статья будет полезной, и зачем её вообще писал. Возможно, показать что сложные концепты можно всегда разбить на простые? Или может просто дать "behind the scenes" для людей, далёких от разработки игр, но которым очень интересно?

Или выпендриться, какой классный движок я по итогу написал?..

Поиграйте в эту игру, что ли: https://nozomu57.itch.io/detour

До следующих встреч, пишите комменты, подписывайтесь, надеюсь ещё увидимся.

#long #опыт #blog #gamedev #геймдизайн