Продолжаем уроки! Создание локализации на Unity
Всем привет! Создание уроков по Unity продолжается, на этот раз разбираем тему создания локализации. Приятного просмотра!
Прошлый урок:
Всем привет! Создание уроков по Unity продолжается, на этот раз разбираем тему создания локализации. Приятного просмотра!
Прошлый урок:
1. Обращение к UI элементам (Text, Image и т.д. ) - это довольно затратный метод. Менять кучу текстовых объектов в апдейте просто ради смены языка - это бессмысленная трата ресурсов. Сотня-другая таких объектов и одна только смена языка будет отжирать 25-50% производительности.
Решений тут два: первое и самое простое - вызывать проверку языка только один раз при старте сцены. При смене языка сцену нужно будет перезапустить.
Второй вариант - подписать метод смены языка на определенное событие через корутины. Проверка смены языка будет вызываться лишь один раз, при нажатии на определенную кнопку. Смысла в этом особого нету - лишний код ради функции, которую игрок за всю игру активирует единожды.
Поэтому оптимально будет сделать данный функционал только в главном меню. Если так уж нужна смена языка "на горячую" и без перезапуска, то лучше привязать элементы главного меню именно к нажатию кнопки, но никак не плодить кучу Update() там, где это не нужно.
2. Сам метод работы с локализацией удобоварим, если у тебя текста на пару десятков объектов. В ином случае, ты замучаешься работать с таким объемом окошек и объектов. Лучший метод для работы с текстом - вешать в скрипт объекта только его ID. В объекте должен быть только персональный ключ и всё. А весь остальной функционал нужно вызывать из некого синглтона, в котором и находятся все методы для работы с текстом.
То есть, ровно так же, как ты создал статическую переменную со значением текущего языка, ты создаешь целый статический класс, с методами и текстовыми массивами. В эти методы и обращается твой текстовый объект при старте. Он отсылает свой ID и получает по нему текст, который к себе применит.
Это обязательно нужно делать, потому что текстовых файлов у тебя может быть тысячи и при смене методов работы с локализацией, тебе нужно будет перенастроить их ВСЕ. Поэтому их функционал не должен содержать никаких уникальных данных, кроме одного - ключа, ID, который определяет, что именно это за слово или текст. А вот синглтон у тебя один. И менять его ты можешь как и сколько хочешь, без ущерба для своих объектов.
3. Сами текстовые данные лучше хранить в отдельном текстовом файле. Какая там будет верстка и формат - вопрос открытый. Кому-то гугл-таблицы нравятся, а кому-то html-формат - самое оно. Но это актуально, если у тебя объем текста выше 30 слов и далеко не пара языков на выбор.
Пока что это видео про то, как делать нельзя ни в коем случае.
exooman, спасибо за развернутый ответ и критику!
Такие комментарии приятно читать, даже если Вы пишите, что то что я сделал не совсем верно. И я сам понимаю, что там далеко все не идеально.
Я постараюсь в дальнейшем не допускать таких ошибок. Еще раз спасибо.
В точку сам так делаю. Кроме пункта 3 потому что у меня всего два языка и текстов пока не супер много. Обычные двумерные массивы в классах выводящих в интерфейсы. Как правило один класс на сцену. Они берут индекс выбранного языка из статического класса прикрепленного к объекту который не уничтожается при загрузках. Смена осуществляется в главном меню. Носитель создается в 0 сцене.
Проверять выбранную локализацию в апдейте? Отличный план. Даже названия методов транслитом. Вот это я понимаю - уровень
Вы видимо пропустили, я там не только ее проверяю, но и меняю. У нас ведь язык может поменяться в настройках. И чтобы не нужно было перезапускать сцену, все идет также в апдейте.
А на счёт транслита, то если я напишу на английском, то метод будет как-то по другому работать?
Я считаю, что для инди игры, самое важное, чтобы все нормально работало и не вызывало багов и т.д.
А то что транслитом оно написано или как-то по другому, это дело последнее.
Комментарий недоступен
Статья классная! Вот серьезно. Можно много чего подчерпнуть.
Но самое главное, это нужно понимать, а нужно ли все это для твоего проекта. Может, это все излишне.
Если у тебя мега-игра, убийца Скайрима, Дарк-соулса, ГТА и т.д. то да, вот такое там прям очень нужно.
А если у тебя небольшая игра, то система локализации из статьи будет сложнее чем сама игра, и будет попросту излишне.
Но повторюсь, статья ТОП! Уметь подобное это круто.