Нефелия: сквозь облака

https://syjgin.itch.io/through-the-clouds/devlog/827915/v083-peaceful-airships-added-tutorial-and-ui-renew
На прошлых выходных всё-таки доделали версию 0.8.3, но благодаря багрепортам бдительных подписчиков уже насобирали исправлений на хотфикс, который выпустим в ближайшее время.
Параллельно с этим занимаемся механикой предыстории капитана, которая сможет влиять на сюжет.

А ещё параллельно занимаюсь большой правкой, которая должна исправить семейство багов, связанных с обращением к уже уничтоженному MonoBehaviour. Часть кода писалась, когда мой уровень владения C# и Unity был существенно хуже нынешнего, и теперь, похоже, пришло время рефакторинга.

Не встречал статей про ошибки такого типа именно применительно к Unity, поэтому, наверное, имеет смысл рассказать подробнее, может пригодиться кому-либо ещё.
Когда вы получаете откуда-то обычный объект C#, вы в целом безбоязненно можете подписаться на какие-то его события или присвоить его значение в качестве поля, главное — не забыть отписаться при уничтожении вашего объекта, чтобы избежать утечки памяти. Ну и в целом понимать, при каких обстоятельствах вы его можете обнулить, чтобы заранее убрать все ссылки на него, где они могут быть. Это достаточно просто, т.к. создание и уничтожение C# объектов находится под нашим контролем.
MonoBehaviour (объект скрипта Unity) в этом плане — куда более зыбкая почва. Я пробовал делать унаследованный от обычного List класс, который бы подписывался на событие удаления со сцены добавленных в него объектов, чтобы самоочиститься от невалидных ссылок, но это работало только иногда. Поэтому, в целом, я пришёл к тому, что попавший через коллайдер другой объект, который мы задетектили, нельзя добавлять напрямую в список видимых объектов, можно только забирать у него id, в за данными обращаться уже в централизованное хранилище, в котором все "живые" объекты обновляют свои данные, как только они поменялись (сейчас это работает по событиям типа изменения количества HP и отклонения более чем на 5 метров + 0.5 секунд от прошлых отправленных координат). И единственным источником данных о внешнем мире для UI игрока и логики NPC дирижаблей должна быть эта самая база данных того, что сейчас происходит в небе, а не сами объекты, которые могут в любой момент уничтожиться, если окажутся слишком далеко от игрока. Так как все данные лежат по своим словарям, это даже немного напоминает самопальную ECS:)

Проще говоря: если Unity объект является внешним по отношению к вашему скрипту логики, его нельзя заносить в поля, на его события нельзя подписываться

Когда кажется, что осталась пара мелочей, предрелизный билд попадает в руки к команде, и ящик Пандоры с новыми багами открывается, да так, что хватает работы ещё почти на целый день:)
Часть из них становятся новыми большими задачами, которые будем править уже к следующей версии, но большую часть всё-таки успели поправить и завтра на стриме в VK покажем, в каком сейчас состоянии проект и куда будем двигаться дальше.
https://vk.com/through_the_clouds_game?w=wall-199947235_1719
Присоединяйтесь:) Надеюсь, до завтра ничего нового-страшного уже не выловим и ближе к вечеру, наконец, выложим новый билд

Почти целый день приводил логику туториала в человеческий вид (т.е. максимально ограничивал точки пересечения сюжетной логики и игромеханики туториала).
В качестве побочного эффекта убрал несколько мест с дублирующейся логикой в коде: всё-таки как минимум принципы SOLID уже вбились в подкорку. Правда, при взгляде на остальной код уже снова хочется всё переписать на более реактивных принципах. С одной стороны, мы уже слишком долго топчемся без масштабирования демки, и нужно больше фич, приближающих к MVP, с другой — без рефакторинга растёт технический долг и потенциально ухудшается пригодность к переносу на новые версии Unity.
Но по крайней мере пока всё-таки буду находить время на исправления самых нелогичных на мой сегодняшний взгляд вещей. Например, добавил параллельную иерархию наследования для View (MonoBehaviour) и их презентеров через Generic, т.к. стыдно сказать, но до этого приходилось вызывать методы производных View через приведение типа. Не то, чтобы это очень сложно, просто реально руки не доходили.

В общем, новый туториал практически готов, осталось немного поправить визуал, а там уже и новый билд не за горами. Завтра пойду на это мероприятие: https://vk.com/wall-205086971_3643
Может быть, ещё насобираю багов, а может, всё сразу заработает идеально (ага, конечно), но в любом случае увижу знакомые лица и поиграю в чужие инди-игры. Приходите тоже, если находитесь в Петербурге)

В плане красивых скриншотов пока похвастаться нечем, кроме, разве что, того, в какую "красоту" всё превращается при выбранном разрешении экрана 640x480 (не в таких диапазонах, но саму возможность смены разрешения добавим в новом билде). Плюс то, как работает grayscale шейдер на UI: лёгкого удара при швартовке хватило, чтобы доктор опять вырубился. Почему-то на шоукейсах и при тестах ему не везёт больше других.

Оказалось, что в URP такого шейдера штатно нет, и при попытке сделать по гайду для shader graph отсюда https://www.youtube.com/watch?v=EXrX69Y6heM получается шейдер, игнорирующий маску, и с этого момента штатно через редактор Shader graph уже нет способа отредактировать, нужно править сгенерированный HLSL + ShaderLab шейдер руками. И в результате всех манипуляций альфа-канал исходной текстуры отображался чёрным цветом. С последним не понял, как поправить, поэтому взял готовый grayscale шейдер отсюда https://github.com/Reinisch/Darkest-Dungeon-Unity/blob/master/Assets/Shaders/UI-Grayscale.shader из уже древнего порта Darkest Dungeon на Unity. В результате всё сразу заработало как нужно.

Теперь занимаюсь переделкой туториала: в ходе его синхронизации с Ink (нарративным языком, на котором работают диалоги в игре) он безобразно оброс костылями, так что появился 1 кейс, который невозможно поправить в рамках старой логики, и придётся ограниченно переписать на новую, в которой минимизируем точки соприкосновения между туториалом и сценарием. Большая часть первого будет завязана не на ход обучающей миссии, а на действия игрока и таким образом будет меняться гораздо реже. По поводу самой логики нового туториала есть надежда, что она на этот раз сделана достаточно простой и расширяемой, чтобы дожить без изменений до релиза игры. Надеюсь, что до конца года получится хотя бы ещё 1 игровую подсистему довести до такого же состояния "осталось добить контента, логика меняться уже не будет". Как-то так

Правки по багам завершены. Правда, несколько замечаний, которые мы и поигравшие на Стачке заметили, по размеру вылезли за пределы багов и отправились в улучшения.
Теперь осталось формализованно описать эти изменения, получить добро от геймдизайнера и приступить уже к ним.

Самые весёлые из исправленных багов были связаны с балластом: в одном случае, команда сброса балласта оповещала об успешном сбросе, даже если сбрасывать нечего (при определённых условиях), и можно было устраивать бесконечную бомбардировку ящиками.
В другом — ящик, вернувшийся из пула с другими координатами, в первом кадре возвращал не те координаты и его коллайдер включался раньше, чем нужно. Как итог — можно было "убить" свой дирижабль ударом о свой балласт при сбросе. Поэтому более просто работающую логику, в которой коллайдер ящика начинал работать после того, как расстояние от сбросившего больше минимального, пришлось переписать. Теперь балласт может наносить повреждение только другим дирижаблям, хотя его коллайдер включен всегда.

Правим баги, обнаруженные на Стачке.
Самый заметный, выражающийся в том, что дирижабли летают где-то рядом с платформой, вместо того, чтобы держаться у своей причальной мачты, был связан сразу с несколькими причинами, большую часть из которых уже удалось устранить.

Во-первых, NPC не "видели" коллайдер платформы: я проверял на более мелких объектах, у которых логика и обработка столкновений висела на одном и том же GameObject'е Unity. Здесь коллайдеры и логика, которая сообщает NPC "в пределах видимости появился объект, с которым можно столкнуться" висели на разных объектах из-за того, что большой объект вроде платформы состоит из нескольких небольших, объединённых физической связью. Пришлось задействовать скрипты-"делегаты", основная функция которых — сообщить столкнувшемуся с ногой слона о том, что эта нога принадлежит объекту типа "слон", и в другую сторону — сообщить мозгу слона, что с нашей ногой кто-то столкнулся.

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

В-третьих, NPC неправильно считали координаты цели благодаря политике библиотеки GOAP v2: координаты переставали обновляться до тех пор, пока цель не будет достигнута, т.е. снос ветром не учитывался.

В-четвёртых, пришлось добавить логику, связанную отступом от основной цели: если нам нужно стремиться не к координатам мачты, какими они были на момент спавна уровня (платформу тоже сносит ветром и координаты меняются), и не к координатам самой платформы (т.к. в этом случае мы просто врежемся в неё), а к текущим координатам мачты, то приходится частично перейти в полярные координаты. Цель задаётся через базовые координаты объекта + угол от его текущего локального "вперёд" (чтобы быть, например, всегда справа, независимо от того, куда в данный момент повернулся объект) + расстояние по этому "лучу", повёрнутому от носа + вертикальное смещение (может быть положительным или отрицательным). Благодаря такой нотации становится возможным преследование или сопровождение объекта с попыткой держаться на одном и том же расстоянии с определённой стороны. Пока работает не идеально, но на базовом уровне уже работает. Позже на этом будет базироваться атакующий с расстояния ИИ.

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

Надеюсь, за октябрь успею поправить всё оставшееся.

Спасибо "Стачке" за новый улов багов:)

Ещё был фидбек по возможным улучшениям, которые тоже постараюсь внедрить в новую версию. Правда, править это всё, возможно, будем ещё месяц. Но, может быть, это у страха глаза велики.
Двойственное ощущение: с одной стороны, большую часть этого года мы делали то, что будет заметно только потом (ИИ дирижаблей и переход к модели плавучести с баллонетом вместо необратимого расхода газа в полёте) и в новой версии не будет ничего сильно нового по сравнению с весенней; с другой, теперь точно ясно, что нужно делать в первую очередь, а что отложить.
Нам нужно как можно быстрее прийти к финальной модели спавнера неба + добавить возможность полёта с отключённым двигателем (чтобы основная механика игры была в более-менее итовогом виде) + добавить то, что будет отвлекать игрока от монотонности полёта (случайные события).
После этого игровой опыт уже можно будет назвать похожим на то, что мы хотим увидеть в итоге. Хотя это всё равно пока ещё будет даже не MVP.
И до этой фазы, по самым оптимистичным оценкам, ещё полгода как минимум. Но теперь уже только продолжать работу, альтернатив особо и нет. По крайней мере, то, что зависит от меня, я сделаю