Пытаться делать в редакторе Юнити вещи, для которых он не предназначен - плохая идея. Вы гробите туеву хучу времени на борьбу с API и UI, вместо того, что бы задействовать сторонние тулсы, написав импорт данных в пару десятков строк.
На примере вашего локализатора - да боже мой, импорт из Excel был бы в 1000 раз удобнее.
Только пожалуйста, не надо писать очередные десериализаторы XML, json и прочих сторонних форматов! И уж тем более, класть их потом в папку Resources (почему-то очень популярный у начинающих разработчиков варварский подход). ScriptableObject сериализируется в прекрасный и читаемый YAML, и большинство гейм-дизайнеров скажут вам только спасибо, если игровые данные можно будет отредактировать сразу в движке, не занимаясь никакими импортами – а удобство гейм-дизайнеров это всегда основная задача разработчиков тулзов.
Локализация это, пожалуй, единственный пример где импорта стороннего формата имеет смысл, ведь локализаторы это сторонняя компания. Но и при работе с локализацией гейм-дизайнеров должны писать исходные тексты на «основном» языке, пока контент не готов к отправке на перевод, прямо в движке.
Чем длиннее работа над одной итерацией, тем меньше итерация, тем хуже итоговое качество продукта. Не надо вставлять палки в колеса продукту.
И да, и нет. Основной вопрос - работа с ключами. Чтобы ключи не повторялись, чтобы для каждого языка был ключ, чтобы можно было удалить или добавить фразу на всех языках одновременно... Я бы сказал, что расширения юнити и Excel должны дополнять друг друга. Например, чтобы дать текст на перевод стороннему человеку, а потом загрузить его обратно в игру. И при этом ничего не сломать. Нельзя недооценивать человеческий фактор)
Вообще не понимаю нытье по этому поводу - у юнити лучшая кастомизация редактора что я видел. У меня на всех проектах весь пайплайн валидации контента которого много построен на редакторах и я не помню чтобы у меня что-то горело. Плюс не забывайте что они добавили UIElements и теперь все стало гораздо проще и быстрее писать (если конечно вы не делаете это в моем стиле)
Прочитал вчера твой этот коммент, сегодня решил попробовать на очередной задаче, залез - ни документации, ни апи нормального, и вообще всё экспериментальное.
Нафиг-нафиг экспериментальщину на живом проекте трогать. Подождать пару лет, пока все схватят все шишки и апи стабилизируется, и потом уже перелазить. Для редактора старый добрый imGUI по-прежнему вполне рабочий.
Для работы с Editor есть, кстати, очень неплохой плагин OdinInspector. У него там и сериализация своя есть, чтобы выводить в Инспекторе всё подряд, и очень много встроенных функций, чтобы некоторые штуки делать просто и легко через аттрибуты.
Одной из основных фишек Одина, на мой вкус, получается что он позволяет не множить файлы и описывать функции кастомного эдитора прям в классе. Хотя возможно это идеологически не очень правильно. И все же Один значительно казуальнее родного механизма кастомизации интерфейсов. Ну и там есть много приятных вещей "из коробки"... сериализация Dictionary, удобное табличное отображение List, сразу содержащее механику ReorderableList, всякие подсказки, кастомные механики кнопок и прочего...
За последнее время произошел разлад в голове девелоперов, есть движок, и есть редактор. Статья про редактор - никто не мешает сделать свой редатор ресурсов, юнити для этого идеален просто. Не хотите в юнити работать - сделайте внешний.
Локализацию делаете своими силами, а затем тратите тонну времени на "вбивание буковок"? А чтоб внешний райтер что либо отредактировал - ему нужно отправлять целиком проект или часть проекта?) Не учите людей плохому, пожалуйста.
Рекомендую пользовать локализацию так: XLS (или CSV) файл, конвертер в бинарник, загружать на старте игры/редактора. Доступ к строкам после выгрузки в бинарник можно получить нативными средствами. Если не забыть слеши, то вообще красиво можно сделать редактор. А главное удобно. PS: еще регексы в помощь, чтоб встраивать всякие разные штуки в текст, но для этого придется написать еще свой небольшой парсер.
Нет, просто в статье речь не про разработку игры, а про разработку дополнительных инструментов для разработки игры. Они не являются обязательными, и тут все зависит от проекта. А так Юнити вполне доступен для понимания.
Вообще смотрю на всё это и почему то в голове крутится мысль - что это всё не оправдано, на банальные вещи делать такие вот кастомизации, есть масса способов сделать это проще. На локализацию если хочется с ключами - можно тот же json сделать, и его могут править сами локализаторы. И можно будет сколько угодно раз заменить и добавить. Айтемы хоть из экселя, хоть опять же джейсон.
Знаю одну известную компанию. Они наоборот большую скриптовую часть из юнити вынесли и для этой части отдельно гуй написали с интеграцией некоторых вещей из юнити(мб просто парсили скрипты, не знаю). Потом результат этой программы подключают в юнити. Не спрашивал почему так, но видимо интерфейс через юнити им не подошел.
Пытаться делать в редакторе Юнити вещи, для которых он не предназначен - плохая идея. Вы гробите туеву хучу времени на борьбу с API и UI, вместо того, что бы задействовать сторонние тулсы, написав импорт данных в пару десятков строк.
На примере вашего локализатора - да боже мой, импорт из Excel был бы в 1000 раз удобнее.
Только пожалуйста, не надо писать очередные десериализаторы XML, json и прочих сторонних форматов! И уж тем более, класть их потом в папку Resources (почему-то очень популярный у начинающих разработчиков варварский подход). ScriptableObject сериализируется в прекрасный и читаемый YAML, и большинство гейм-дизайнеров скажут вам только спасибо, если игровые данные можно будет отредактировать сразу в движке, не занимаясь никакими импортами – а удобство гейм-дизайнеров это всегда основная задача разработчиков тулзов.
Локализация это, пожалуй, единственный пример где импорта стороннего формата имеет смысл, ведь локализаторы это сторонняя компания. Но и при работе с локализацией гейм-дизайнеров должны писать исходные тексты на «основном» языке, пока контент не готов к отправке на перевод, прямо в движке.
Чем длиннее работа над одной итерацией, тем меньше итерация, тем хуже итоговое качество продукта. Не надо вставлять палки в колеса продукту.
И да, и нет. Основной вопрос - работа с ключами. Чтобы ключи не повторялись, чтобы для каждого языка был ключ, чтобы можно было удалить или добавить фразу на всех языках одновременно...
Я бы сказал, что расширения юнити и Excel должны дополнять друг друга. Например, чтобы дать текст на перевод стороннему человеку, а потом загрузить его обратно в игру. И при этом ничего не сломать. Нельзя недооценивать человеческий фактор)
Вообще не понимаю нытье по этому поводу - у юнити лучшая кастомизация редактора что я видел. У меня на всех проектах весь пайплайн валидации контента которого много построен на редакторах и я не помню чтобы у меня что-то горело. Плюс не забывайте что они добавили UIElements и теперь все стало гораздо проще и быстрее писать (если конечно вы не делаете это в моем стиле)
Ого, что-то новенькое. Пошел читать, спасибо за наводку.
Прочитал вчера твой этот коммент, сегодня решил попробовать на очередной задаче, залез - ни документации, ни апи нормального, и вообще всё экспериментальное.
Нафиг-нафиг экспериментальщину на живом проекте трогать. Подождать пару лет, пока все схватят все шишки и апи стабилизируется, и потом уже перелазить. Для редактора старый добрый imGUI по-прежнему вполне рабочий.
Для работы с Editor есть, кстати, очень неплохой плагин OdinInspector. У него там и сериализация своя есть, чтобы выводить в Инспекторе всё подряд, и очень много встроенных функций, чтобы некоторые штуки делать просто и легко через аттрибуты.
Одной из основных фишек Одина, на мой вкус, получается что он позволяет не множить файлы и описывать функции кастомного эдитора прям в классе. Хотя возможно это идеологически не очень правильно. И все же Один значительно казуальнее родного механизма кастомизации интерфейсов. Ну и там есть много приятных вещей "из коробки"... сериализация Dictionary, удобное табличное отображение List, сразу содержащее механику ReorderableList, всякие подсказки, кастомные механики кнопок и прочего...
Какой ад.
Вот поэтому мне ни один движок не нравится и пишу свой : )
Я тоже свой писал когда-то, над XNA. Это, конечно, весело - но к готовой игре имеет мало отношения, к сожалению.
Комментарий недоступен
на ассемблере, разумеется?)
За последнее время произошел разлад в голове девелоперов, есть движок, и есть редактор. Статья про редактор - никто не мешает сделать свой редатор ресурсов, юнити для этого идеален просто. Не хотите в юнити работать - сделайте внешний.
Локализацию делаете своими силами, а затем тратите тонну времени на "вбивание буковок"? А чтоб внешний райтер что либо отредактировал - ему нужно отправлять целиком проект или часть проекта?)
Не учите людей плохому, пожалуйста.
Рекомендую пользовать локализацию так: XLS (или CSV) файл, конвертер в бинарник, загружать на старте игры/редактора.
Доступ к строкам после выгрузки в бинарник можно получить нативными средствами.
Если не забыть слеши, то вообще красиво можно сделать редактор. А главное удобно.
PS: еще регексы в помощь, чтоб встраивать всякие разные штуки в текст, но для этого придется написать еще свой небольшой парсер.
У меня вопрос не по теме: у вас в офисе такие флаги висят?
Шутку понял, смешно))
Вся разработка игр такой ад? Я тогда даже лезть не буду. Может есть попроще что-то, понагляднее?
Это ещё не ад, это ещё приятные и прямолинейные вещи.
Ад начнётся, когда вы полезете разбираться, как разные платформы разные семантики шейдеров воспринимают, например. Или как пробить NAT.
Нет, просто в статье речь не про разработку игры, а про разработку дополнительных инструментов для разработки игры. Они не являются обязательными, и тут все зависит от проекта. А так Юнити вполне доступен для понимания.
А вы думали разработчики только "текстурки рисуют и в игры играют"? :D
Это вы ещё не видели, как в крупных компаниях движки пишут
всегда можно упростит задачу так чтобы избежать проблем, для решения которых еще нет готового средства. например "даже не лезть" :)
Привет. Спасибо за текст, поправили чутка и закрыли редактирование, чтобы в соцсети вывести. Если что-то изменить захотите — пишите.
Вообще смотрю на всё это и почему то в голове крутится мысль - что это всё не оправдано, на банальные вещи делать такие вот кастомизации, есть масса способов сделать это проще. На локализацию если хочется с ключами - можно тот же json сделать, и его могут править сами локализаторы. И можно будет сколько угодно раз заменить и добавить. Айтемы хоть из экселя, хоть опять же джейсон.
Знаю одну известную компанию. Они наоборот большую скриптовую часть из юнити вынесли и для этой части отдельно гуй написали с интеграцией некоторых вещей из юнити(мб просто парсили скрипты, не знаю). Потом результат этой программы подключают в юнити. Не спрашивал почему так, но видимо интерфейс через юнити им не подошел.
ну правильно, зачем всем сотрудникам юнити ставить и учить с ней работать, это кодер стресс не испытывает т.к со средой знаком.
Да, зачем пилить UI на юнитевском imGUI когда есть божественный HTML.