И сразу же первая загвоздка — все расширения делаются только с помощью кода. Никакого визуального программирования и блок-схем, WYSIWYG, перетаскивания кнопочек по формочкам. Только C #, только хардор. Изменил размер кнопки — будь добр пересобрать весь проект, чтобы увидеть изменения. Соответственно, написать новое расширение или поправить скаченное из Asset Store не программисту — практически непосильная задача.
Пытаться делать в редакторе Юнити вещи, для которых он не предназначен - плохая идея. Вы гробите туеву хучу времени на борьбу с API и UI, вместо того, что бы задействовать сторонние тулсы, написав импорт данных в пару десятков строк.
На примере вашего локализатора - да боже мой, импорт из Excel был бы в 1000 раз удобнее.
Только пожалуйста, не надо писать очередные десериализаторы XML, json и прочих сторонних форматов! И уж тем более, класть их потом в папку Resources (почему-то очень популярный у начинающих разработчиков варварский подход). ScriptableObject сериализируется в прекрасный и читаемый YAML, и большинство гейм-дизайнеров скажут вам только спасибо, если игровые данные можно будет отредактировать сразу в движке, не занимаясь никакими импортами – а удобство гейм-дизайнеров это всегда основная задача разработчиков тулзов.
Локализация это, пожалуй, единственный пример где импорта стороннего формата имеет смысл, ведь локализаторы это сторонняя компания. Но и при работе с локализацией гейм-дизайнеров должны писать исходные тексты на «основном» языке, пока контент не готов к отправке на перевод, прямо в движке.
Чем длиннее работа над одной итерацией, тем меньше итерация, тем хуже итоговое качество продукта. Не надо вставлять палки в колеса продукту.
И да, и нет. Основной вопрос - работа с ключами. Чтобы ключи не повторялись, чтобы для каждого языка был ключ, чтобы можно было удалить или добавить фразу на всех языках одновременно...
Я бы сказал, что расширения юнити и Excel должны дополнять друг друга. Например, чтобы дать текст на перевод стороннему человеку, а потом загрузить его обратно в игру. И при этом ничего не сломать. Нельзя недооценивать человеческий фактор)
Вообще не понимаю нытье по этому поводу - у юнити лучшая кастомизация редактора что я видел. У меня на всех проектах весь пайплайн валидации контента которого много построен на редакторах и я не помню чтобы у меня что-то горело. Плюс не забывайте что они добавили UIElements и теперь все стало гораздо проще и быстрее писать (если конечно вы не делаете это в моем стиле)
Ого, что-то новенькое. Пошел читать, спасибо за наводку.
Прочитал вчера твой этот коммент, сегодня решил попробовать на очередной задаче, залез - ни документации, ни апи нормального, и вообще всё экспериментальное.
Нафиг-нафиг экспериментальщину на живом проекте трогать. Подождать пару лет, пока все схватят все шишки и апи стабилизируется, и потом уже перелазить. Для редактора старый добрый imGUI по-прежнему вполне рабочий.
Для работы с Editor есть, кстати, очень неплохой плагин OdinInspector. У него там и сериализация своя есть, чтобы выводить в Инспекторе всё подряд, и очень много встроенных функций, чтобы некоторые штуки делать просто и легко через аттрибуты.