Вход на сайт в состоянии починки, простите за сложности :(

Diyu: Впечатления программиста от работы с Defold

Всем привет, меня зовут Алексей «byton» Анисимов и я тот человек, который программирует эту игру.

С Defoldом я впервые столкнулся 30 августа, как только увидел этот gamejam, поэтому опыта работы с движком я не имел. Сейчас я бы хотел рассказать о +/- движка, которые являются по моему мнению, а так же трудности с которыми я пока что успел столкнуться при разработке.

Хочется сказать, что огромного опыта в разработке игр я не имею. Хорошо знаком с алгоритмами, знаю языки Java, JS, c++, c, c#, работал с Unity 3 года. Ну как сказать работал, я скорее наращивал теоретический потенциал. Узнавал как работают компоненты внутри. Хотя были и готовые/брошенные проекты.

Поэтому все +/- являются моим субъективным мнением.

Плюсы Defold:

Минусы Defold. Среди минусов в основном содержаться разные методы из api:

Пока что это на этом все, какие +/- мне запомнились от движка.

 

Теперь я хочу рассказать о трудности возникшей передом мной. А именно о обзоре игрока.

С самого начала я хотел делать динамические тени и просидел несколько дней за изучением этой темы и подбирая похожие решения. Все мои (и не мои) идеи упирались в то, что Defold не позволяет нам оперировать вершинами объекта (т. е. треугольниками). Понимая, что сидеть над раздумьем можно много, а делать что-то надо, то я решил переключиться на более простой вариант. А именно: т. к. наш мир разбит на клетки, то можно освещать/затемнять всю клетку целиком. Хорошо, с идеей мы разобрались. Как её сделать?

  1. Для начала надо найти все клетки в определенном радиусе от игрока. Расстояние между двумя клетками будет считать по манхетонскому расстоянию (в канале слака мне предложили использовать обычное расстояние, я сразу решил проверить, что будет и обнаружился баг. Т.к. времени мало, то я решил не думать об этом пока что. А если в конце время будет, то посмотрим, как выглядеть лучше станет). Т.к. в тайлкарте у нас пол и стены имеют разные значения, то в данном случае использовав обычный обход в ширину/глубину можно найти все клетки (по которым ходить можно) в радиусе n и центром в позиции игрока.
  2. Мы имеем все клетки, до которых можно добраться, но не факт, что их видит игрок. что делаем теперь? В tilesourse назначим геометрические коллайдеры wall нашим стенкам. Теперь будем пускать raycast из позиции игрока в клетку из нашего набора, которую мы проверяем в данный момент. Если в ответ нам пришел raycast_response, значит мы столкнулись со стеной и мы должны немедленно убрать нашу клетку из списка.
  3. Теперь мы получили все клетки на которые может ступить игрок и которые он видит в данный момент. Далее можем делать с этим списком все, что угодно. Лично я решил сильно не морочиться и ставить в каждую клетку свой объект, который имел свой спрайт и осветлял все, что находится под ним.

Такой вариант достаточно прост и быстр в реализации, но мне самому не нравится, если честно, но я понимаю, что если сейчас буду работать над обзором, то ничего другого не успею. Так же есть в данном решение небольшие баги. Например, иногда мы не видим тайлов по диагонали, когда стоим на углу. Это потому, что луч пересекает самый угол стены. Но баг не так критичен для игры. И в целом обзор выглядит не ужасно, а играбельно вполне.

И на этом моменте вроде бы все, но как вы могли заметить, но у нас освещаются и стенки тоже. Если честно, то освещение стенок заняло примерно 80% от разработки этого алгоритма. Я перепробовал очень много вариантов реализации, но везде были свои баги. Как мы решил в итоге? Как итог мы разделили наши тайлы на 3 режима:

  1. может проходить игрок
  2. может проходить свет
  3. никто не может проходить

Теперь мы можем добавлять видимые клетки таким алгоритмом: Из 1 можем пойти в соседнюю клетку 1 или 2. Из 2 можем пойти только во 2. И не забываем проверять манхетонское расстояние. Все, теперь наши клетки и стены освещены.

 

И сейчас вы подумали, что все чудесно? А зря. Помните, я в минусах указал то, что physic_raycast отсылает нам ответ только в on_message. А проверка то у нас выполняется в update. И что же такого, спросите вы? А то, что когда мы построим наш набор клеток, которые должны быть освещены, то через какое-то время некоторые из них удаляться. И удаляться только те, по которым ходить можно. Ведь мы не будем бросать луч в объекты с коллайдером wall. Тогда у нас может быть случай, что из клетки X (которая принадлежит 1) мы перешли в клетку Y (которая принадлежит 2). А потом raycast нам сказал, что клетку X на самом деле не видно. А как нам теперь сказать клетки Y, что её не видно? Ну допустим мы как-то ей передали эту информацию. А теперь представьте, что клетку Y было видно из двух клеток? И на самом-то деле она должна остаться видимой. В этом моменте остается много вопросов и не меньше решений. И после этого мы можем сказать, что мы сделали освещение. Пожалуй, оставлю решение этой проблемы вам на подумать)

Может быть я сделал что-то неправильно, и есть алгоритм, который всем известен, а я почему-то пишу велосипеды, с удовольствием услышу мнение на этот счет или предложение/критику)

P.S. У меня появилась идея, как можно реализовать динамическое освещение, использовав шейдер и рейтресинг по текстуре, но пока времени нет, то не буду за это браться.


blog comments powered by Disqus