26 мая 2022
О проблемах инспектора Unity
Окно инспектора очень сильно упрощает и ускоряет разработку игры, являясь по своей сути реализацией Dependency Injection без кода. Аналог инспектора есть, наверное, в любом игровом движке с визуальным редактором.
Но, по своему опыту могу сказать, что использование инспектора затрудняет понимание того, что происходит в проекте и усложняет отладку. На это есть ряд причин.
Ошибки теперь может производить не только код
Настройка полей через инспектор приводит к тому, что при работе с кодом ты не знаешь, какие значения будут при запуске игры. Это может привести к неверному исполнению игровой логики, если что-то было упущено при настройке. Можно забыть что-то заполнить, или же объект, на который ссылается поле, будет удалён.
Таким образом, если при исполнении игры произойдёт ошибка, понадобится искать причину не только в коде, но и в инспекторе.
Неупорядоченное исполнение логики, нет возможности видеть список всего исполняемого кода
В основном, к этому приводит возможность добавлять компоненты в любом месте иерархии префаба вручную. В длинном списке дочерних объектов легко упустить из виду какой-либо скрипт, который будет продолжать работать и может создать неожиданное поведение.
Проблемы сериализации
Не все виды полей можно полноценно сериализовать (интерфейсы, например), при настройке через код эта проблема отсутствует.
Невнимательность или баги Unity могут привести к потере сериализованных данных, код же всегда стабилен.
Сложные для сериализации объекты (словари и прочее) могут привести к проблемам автоматического merge в git, что в командной работе сильно усложняет жизнь.
Поиск значений по коду
При настройке всех параметров внутри кода, легко найти место, где настроено значение, вбив его в поиск в IDE.
В случае с инспектором, нужно держать в памяти все файлы настроек, имеющиеся в проекте, а поиск по значению становится почти неосуществимой задачей.
Выводы
В общем, инспектор создаёт множество проблем, которых можно было бы избежать, задавая все значения через код. Плюсы существования инспектора - скорость и удобство настройки всевозможных параметров с помощью визуального интерфейса - достигаются ценой уменьшения стабильности проекта.
Стоит ли оно того? Наверное, да. Сейчас мне трудно представить разработку без инспектора: скорость настройки значений прямо на префабе при поиске наилучших параметров для гейплея решает. Но в крупном проекте стоит несколько раз подумать, прежде чем действовать так прямолинейно.
Для себя я составил список рекомендаций, позволяющих снизить шанс возникновения проблем:
- Сократить количество ссылок на другие сущности в полях инспектора до необходимого минимума.
- Отдавать предпочтение хранению в полях инспектора простых данных, как минимум отказаться от излишеств по типу ассета Odin Inspector.
- Хранить данные в Scriptable Object когда это возможно. Это сведёт набор параметров в префабах до минимума, хотя и увеличит количество файлов в проекте. Такой подход мне кажется довольно гибким: проще создавать вариации данных, не привязываясь к префабу, ведь на нём находятся и другие компоненты - в вариациях префаба они будут задублированы без изменений. SO лишены этого недостатка, и их проще мёржить в гите.
- При командной работе, сократить взаимодействие геймдизайнеров с движком - по максимуму вынести настройку игровых параметров в понятный для геймдизайнеров инструмент - Google-таблицы. Это не решает всех проблем, но хотя бы избавляет от технических моментов, связанных с Unity и git.
- Стараться не размещать MonoBehaviour-компоненты на вложенных объектах, чтобы не возникало трудностей с их поиском.
Отмечу так же, что всегда необходимо использовать здравый смысл. Если очевидно, какая для проекта требуется структура, то нужно использовать её, а не следовать каким-либо рекомендациям, которые, скорее всего, были придуманы в совершенно иной ситуации. :)