Насколько оно себя окупает? Ну затраты времени на то, чтобы сделать такой едитор и по сравнению с тем, сколько ты в нем копаешься обычно. Ну и еще вопрос, как сильно он нагружать будет инспектор юньки, а то у меня в недавнем проекте инспектор ложился из-за огромного количества данных в нем
Окупает с лихвой, т.к. не обязательно это самому делать, кто-то может уже что-то готовое написать и ты воспользуешься кастомный редактором. Например, есть классы или библиотеки SceneReference и они делают то, что юнити не сделала и добавляют возможность перетаскивать сцены в инспекторе.
Другой пример это OdinInspector, который упращает жизнь разработчику. Хотя я им не пользовался)
Еще без кастомных редакторов не добавить кнопки.
как сильно он нагружать будет инспектор юнькиНагружает не сильно, но это смотря как написано. Если выводить список или таблицу из 1000+ элеметов, то редактор будет заметно подвисать. (Если это не делать через специальный класс таблицы, которые специально под это заточен. А вот простые списки под это не заточены.)
Я бы еще добавил, к тому насколько он себя окупает, то делать его все-таки затратно и пример в статье не показетль, там можно обойтись и стандартными средствами. Поэтому, если не нужен, то можно не делать. Или есть свободное время и желание, то можно пробовать.
Имхо, окупает от случая к случаю - иногда сполна, а иногда выходит дорогой, но зато какой стильный пшик. Надо смотреть по ситуации более конкретно... Сам лично бы принимал решение, отвечая на следующие вопросы: 1. Какой объем функционала и надстроек предоставляет отдельный скрипт, требуется ли для этого более систематизированный инспектор? 2. Кто потенциальный пользователь скрипта (кодер, гейм-дизайнер, саунд-дизайнер и т.д)? 3. Какой дополнительный функционал требуется реализовать в скрипте, и нужны ли для этого дополнительные средства юнити? 4. Как часто скрипт планируется ре-использовать в будущем? 5. Насколько скрипт нравится лично мне о_О Если хотя бы 3/5 вопросов располагают к положительному решению, то почему бы и нет.
По времени, честно затрудняюсь ответить - в живом проекте мы вероятно копаемся в скрипте периодически все время разработки. Вопрос лишь в частоте копания, и у каждого будет свой ответ... На написание среднего едитора в лучшем случае уйдет час-два, в худшем - до дня.
По поводу нагрузки: действительно, в общем случае с представлением переменных и заголовков, кастомный инспектор совсем чуть-чуть может быть тяжелее обычного, хотя бы потому что он переопределяет метод базового класса. Но это настолько мелкий чих, что я бы даже париться об этом не стал. Более сложные конструкции и отображение графики тоже могут малым образом влиять на производительность - все еще не думаю, что это повод для беспокойства. А вот если мы пишем тул с кнопками, рассчитывающими мега сложный рекурсивный трипл А алгоритм для генерации миров с предпросмотром в окошечке, то тут конечно же будут ощутимые, а главное закономерные просадки. При желании, по нажатии кнопки можно и переполнение вызвать, крашнув движок.
Насколько оно себя окупает? Ну затраты времени на то, чтобы сделать такой едитор и по сравнению с тем, сколько ты в нем копаешься обычно.
Ну и еще вопрос, как сильно он нагружать будет инспектор юньки, а то у меня в недавнем проекте инспектор ложился из-за огромного количества данных в нем
Окупает с лихвой, т.к. не обязательно это самому делать, кто-то может уже что-то готовое написать и ты воспользуешься кастомный редактором. Например, есть классы или библиотеки SceneReference и они делают то, что юнити не сделала и добавляют возможность перетаскивать сцены в инспекторе.
Другой пример это OdinInspector, который упращает жизнь разработчику. Хотя я им не пользовался)
Еще без кастомных редакторов не добавить кнопки.
как сильно он нагружать будет инспектор юнькиНагружает не сильно, но это смотря как написано. Если выводить список или таблицу из 1000+ элеметов, то редактор будет заметно подвисать. (Если это не делать через специальный класс таблицы, которые специально под это заточен. А вот простые списки под это не заточены.)
Я бы еще добавил, к тому насколько он себя окупает, то делать его все-таки затратно и пример в статье не показетль, там можно обойтись и стандартными средствами. Поэтому, если не нужен, то можно не делать. Или есть свободное время и желание, то можно пробовать.
Имхо, окупает от случая к случаю - иногда сполна, а иногда выходит дорогой, но зато какой стильный пшик. Надо смотреть по ситуации более конкретно... Сам лично бы принимал решение, отвечая на следующие вопросы:
1. Какой объем функционала и надстроек предоставляет отдельный скрипт, требуется ли для этого более систематизированный инспектор?
2. Кто потенциальный пользователь скрипта (кодер, гейм-дизайнер, саунд-дизайнер и т.д)?
3. Какой дополнительный функционал требуется реализовать в скрипте, и нужны ли для этого дополнительные средства юнити?
4. Как часто скрипт планируется ре-использовать в будущем?
5. Насколько скрипт нравится лично мне о_О
Если хотя бы 3/5 вопросов располагают к положительному решению, то почему бы и нет.
По времени, честно затрудняюсь ответить - в живом проекте мы вероятно копаемся в скрипте периодически все время разработки. Вопрос лишь в частоте копания, и у каждого будет свой ответ...
На написание среднего едитора в лучшем случае уйдет час-два, в худшем - до дня.
По поводу нагрузки: действительно, в общем случае с представлением переменных и заголовков, кастомный инспектор совсем чуть-чуть может быть тяжелее обычного, хотя бы потому что он переопределяет метод базового класса. Но это настолько мелкий чих, что я бы даже париться об этом не стал. Более сложные конструкции и отображение графики тоже могут малым образом влиять на производительность - все еще не думаю, что это повод для беспокойства.
А вот если мы пишем тул с кнопками, рассчитывающими мега сложный рекурсивный трипл А алгоритм для генерации миров с предпросмотром в окошечке, то тут конечно же будут ощутимые, а главное закономерные просадки. При желании, по нажатии кнопки можно и переполнение вызвать, крашнув движок.