Войти
ФлеймФорумПрограммирование

Unity "по фэншую": максимальное использование возможностей движка vs свои/сторонние решения?

#0
12:48, 17 сен. 2020

Эта тема - форк этой темы, ради избежания оффтопа там.

dirmenbitz

скромное мнение: в случае юнити "по фэн-шую" – это использовать возможности движка по минимуму. ни за что не агитирую, просто рекомендую с осторожностью полагаться на решения, которые у них "как бы фирменные".

kkolyan

dirmenbitz
Спасибо за рекомендацию, но я ничего не понял)

1. О каких фирменных решениях идет речь? О том, что включено в базовый комплект? Или только о пакетах, которые можно доустановить, вроде hdrp и dots?
2. О каких мерах предосторожности речь?
3. По сравнению с чем опасны эти решения?


dirmenbitz
1. я не вижу принципиальной разницы между "базой/доустановить"
2. о построении кор-логики на основе апи, отдаваемых движком. вот мы в соседней теме про JVM обсуждали ограничения, которые должны пойти на пользу архитектуре. технически ограничения пользы может и не пренесут, но сама идея, "поменьше зависеть от движка" – она здравая.
3. по сравнению с не "вендор-локнутыми" решениями.

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

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

но повторюсь: это не значит, что не надо использовать навмеш. просто надо иметь в виду.

#1
13:22, 17 сен. 2020

dirmenbitz

> сама идея, "поменьше зависеть от движка" – она здравая.
она трудоемка.
да, есть паттерны типа ECS, которые позволяют писать код очень модульно, минимизируя связи между подсистемами.
но что-то большее, а именно превентивное подключение внешних либ и написание своих - это долго, это бажно. очень многие вещи в юньке делаются просто правильной галочкой после внимательного прочтения довольно лаконичных док с картинками (то, чем я пренебрег, заплатив несколькими часами). т.е. цена внедрения юнитевских подсистем копеешная. не нравится как работает с галочкой - ок, тут можно и своим заменить сразу всю подсистему.

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

> – даже если сейчас все работает, то сломать могут позже. и если куча логики написана поверх – может оказаться мучительно больно.
LTS и лок версии юньки на проект?

> просто надо иметь в виду
не уверен, что понял это

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

#2
14:21, 17 сен. 2020

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

Вот ряд примеров, с которыми я лично столкнулся:
1. Сериализация.
Глубина вложенности должна быть меньше, чем 7. Цифру 7 изменить нельзя. Сначала мне нужна была возможность просто рекурсивного хранения объектов. Юнитологи рекомендуют костыль: расплющить иерархию и в коллбеках сериализации её восстановить. Много кода, неочевидная логика, но саму сериализацию переписывать хотя бы не пришлось.
Потом оказалось, что в одном месте мне нужна глубина вложенности 8 (без рекурсии, просто, потому что сложная иерархия). Тут было гораздо больнее. Пришлось переписывать структуру классов.
А потом я захотел полиморфизм (не коварианты контейнера, которые понятно почему не поддерживаются, а просто что-то типа [SerializeField] object nestedData). Казалось бы, никакой проблемы, всё равно там под капотом рефлексия используется... Но нет. Для nestedData будет ВСЕГДА пустой объект.
В итоге пришлось прикручивать стороннюю сериализацию и переписывать весь проект.

2. Навигация.
Навмеш имеет одну неприятную особенность: он не умеет быстро определять достижимость точки. Если на навмеше есть "остров", и агент пытается построить путь до точки на этом острове, то происходит ПОЛНЫЙ ОБХОД всех достижимых точек, что просто безумно долго.
Делал перемещение для диаблойда - проблемы на каждом шагу. Движение с моментальным ускорением и торможением. Повороты без замедления.
Всё это в итоге кое-как закостылил, но тут больше наугад тыкаешься, т.к. в примерах всё не то, а документация выглядит примерно как Vector3 velocity - returns velocity.
Пока объектов немного, работает ок, но потом, вероятно, придётся перейти на что-нибудь более адекватное.

3. Никаких вложенных стейтов в animation controller.
Т.е. сущность с таким названием есть, но от вложенности там только название (это просто визуальная группировка нескольких блоков в один прямоугольник - на логику исполнения это никак не влияет). И добавить реальные вложенные стейты нельзя никак.

4. Inverse kinematics.
Работает только с humanoid avatar. Поддержку generic аватаров обещали добавить, если правильно помню, в 2015 году. Осталось недолго. Ждём.

5. Маски в UI.
Маски в UI работают через буфер трафарета. ID буфера глобальный под весь UI. ID, используемый масками, пересчитывается при изменений иерархии выше и (!) ниже. Т.е. если я добавлю дочерний элемент с маской, id трафарета родителя поменяется. Т.о., если я хочу где-то в середине иерархии использовать какой-то свой материал с буфером трафарета, то мне придётся следить за изменением иерархии, чтобы мой id оставался правильным.

#3
14:47, 17 сен. 2020

каждый решает для себя, решения "я готов вендорглокнуться и нести риски %ххх ради выгод" имеют право на существование. я высказал лишь свое понимание "фэн-шуя".
хорошо, когда проблему удается решить галочкой. могу лишь пожелать не оказаться в ситуации "галочку не подвезли" и в ситуации "почти нужный набор галочек, но есть нюанс: затраты на разобраться и подобрать нужное сочетание галочек больше, чем написать простое (частное, конкретное и надежное) решение с 0".

>LTS и лок версии юньки на проект?

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

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

компромиссы – это нормально, я триггернулся на словосочетание "по фэн-шую". если не воспринимать решения из коробки как благо по определению, но как компромисс, имеющий свою цену – то все в порядке.

#4
15:27, 17 сен. 2020

pahaa
спасибо за детальное описание!

> 1. Сериализация.
да, дефолтная сериализация юньки вызывает много вопросов... во всех предыдущих более-менее крупных прототипах я прикручивал сторонние сериализаторы и/или свои писал.
хотя, с другой стороны, вот сейчас обкатываю ECS (не юньковский) и при таком дизайне (много маленьких компонентов) сериализация юньки выглядит достаточной.

> 2. Навигация.
хм, судя по твоему описанию, я хожу буквально перед пропастью) ну посмотрим, насколько в чуть более простой игре чем дьяблоид, себя покажет эта система.

> 3. Никаких вложенных стейтов в animation controller.
а зачем они нужны? я щас настроил почти все что нужно в Animation Controller (осталось только вкорячить анимацию вращения на месте) и вроде вполне хватило. Анимированный моб управляется параметрами (running:bool, attacking:bool), ГГ управляется параметрами (attacking:bool, right:float, forward:float, runSpeed:float, moving:bool). В общем-то получатеся довольно удобное разграничение концернов между конфигурацией и кодом.

> 4. Inverse kinematics.
понятно, буду иметь ввиду.

> 5. Маски в UI.
хорошо, учту, когда дойду до гуя

#5
(Правка: 15:39) 15:39, 17 сен. 2020

dirmenbitz

под "фэн шуем" я имел ввиду:

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

  • это своего рода эксперимент, т.к. я больше склонен менять вещи под себя, чем себя под них.

    т.е. похоже ты правильно триггернулся)

    > могу лишь пожелать не оказаться в ситуации "галочку не подвезли" и в ситуации "почти нужный набор галочек, но есть нюанс: затраты на разобраться и подобрать нужное сочетание галочек больше, чем написать простое (частное, конкретное и надежное) решение с 0".

    спасибо, за пожелание :)
    на самом деле, я как раз хотел бы оказаться в этих ситуациях, если они действительно так релевантны при моем подходе. текущий проект достаточно невелик чтобы цена ошибки была приемлемой, а экспа будет бесценна.

    #6
    15:45, 17 сен. 2020

    kkolyan
    > а зачем они нужны?
    Например, последовательность idle->death->revive->idle
    Если я захочу разбить death на dying->decay, то мне придётся добавлять оба состояния на верхний уровень и добавлять два новых перехода (dying->revive и decay->revive).

    #7
    6:47, 18 сен. 2020

    pahaa
    хм, любопытно. так глубоко не копал еще. т.е. по сути, "вложенные стейты", которые тебя интересуют - это возможность повесить одинаковое условие выхода из сразу нескольких стейтов в другой? а это прям так нужно? предполагаю, что при полишинге с большой вероятностью все равно захочется дать переходам dying->revive и decay-revive разные параметры перехода. вот они решили не вводить новых сущностей, реализовав лишь визуальную группировку.

    ФлеймФорумПрограммирование