Как много раз вы задавались вопросами, как создаются русификаторы для игр, кто их делает и выгодно ли вообще переводить игру? В этой статье мы подберем программы и узнаем, как происходит процесс локализации программ и какие знания нужно иметь, чтобы сделать это.
Кто переводит игры?
- Игры переводят энтузиасты, работающие совершенно бесплатно для своей аудитории.
- Авторов нанимают для выполнения данной работы за деньги.
- Сотрудники, работающие в студии как переводчики, часто с такими людьми игры могут получаться и с качественной озвучкой.
Как самому переводить игры на русский язык?
Если вы уже обладаете знанием языка, игру на котором вы собираетесь переводить, то вы находитесь еще в самом начале пути.
Вы можете переводить игры самостоятельно, как это делает множество людей, и выкладывать их в интернет. Так и получаются неофициальные русификаторы.
Но в данном случае вы можете столкнуться с большим количеством проблем.
Во-первых, не все игры могут поддерживать кириллицу, поэтому, зайдя в игру, вместо русских букв мы увидим множество вопросительных знаков и других непонятных символов. Поэтому многие пираты, чтобы не мучиться с совместимостью, просто переделывают шрифты или пишут английской раскладкой "по-русски", из-за чего часто получается кривой перевод.
Во-вторых, не все игры могут переводиться одинаковым образом, это говорит о том, что вам придется искать различные решения перевода игры самостоятельно. Вам повезет, если в директории игры вы найдете файл с текстом меню и диалогами, однако это происходит очень редко, чаще всего он глубоко вшит в приложение. В этом случае вам понадобятся навыки взлома и расшифровки данных, или же вы можете использовать программу для поиска строк с текстом в файле.
Также определитесь с тем, что вы будете русифицировать. Можно ограничиться только текстом, однако можно перевести и всю игру полностью (текстуры, весь текст, звук).
Как правило, профессиональные переводчики очень хорошо знают язык, с которого переводят. Знают не один язык программирования, ведь нужно четко понимать, как устроена и написана та или иная программа. Поэтому вам необходимо потратить огромное количество времени на изучение языка, чтобы переводить все моментально, изучать программирование и проводить время в практике, локализируя небольшие игры и программы, чтобы в будущем перейти на профессиональный уровень и начать переводить большие проекты с морем диалогов и текста.
Также, как правило, над локализацией работает не один человек, а команда, которая берет на себя определенные задачи и отвечает за их качество. Ведь перевести игру на русский язык самому очень сложно.
Программ, которые делают все за вас. не существует, эта работа кропотлива и сложна.
Есть еще один вариант. Это обратиться к автору игры и предложить ему свою помощь в переводе игры. Тогда вы избавитесь от вопросов: а поддерживает ли игра кириллицу? Будет ли перевод игры на русский язык? Сможете приступить к работе по переводу.
Автор отправит вам файл с диалогами и текстом меню, которые вам нужно перевести на нужный вам язык, а после нужно отправить этот файл обратно. Поэтому автор — это один из самых надежных способов перевести игру.
Однако существуют нюансы, из-за которых вы можете не взяться за работу по переводу.
- Автору не нужно, чтобы вы занимались переводом игры. В этом случае вам придется перевести игру на русский язык самому.
- Студия уже наняла переводчика, который в скором времени выпустит перевод игры, в этом случае вам совершенно бессмысленно переводить данную игру, если она уже выйдет на русском языке.
- Автор сообщит, что кириллица в игре не поддерживается, в таком случае перевод игры вряд ли когда-либо выйдет.
Что нужно для перевода?
Убедиться, что в сети больше нет русификаторов, а если есть, то нужно протестировать, найти минусы и плюсы и написать лучше, чем предыдущий.
Уметь взламывать игру или приложение самостоятельно или с помощью различных программ (не обязательно).
Чтобы перевести игру на русский язык самому, вам нужно научиться находить шрифты и перерисовывать их.
Добавлять указатели или объекты, если они выходят за рамки или смещают другие объекты.
Если эта игра для консоли, то придется искать специальные эмуляторы для перевода.
Программы для русификации
Multilizer — мощная программа для создания локализации программ и документов промышленного масштаба. Система имеет огромный набор инструментов для качественного и быстрого перевода.
OgreGUI — редактор ресурсов для программ, игр, документов, отличительной особенностью которого является сканирование приложения по строкам.
Как перевести "Андроид"-игру на русский язык?
Для этого нам понадобится редактор notepad++, а также нужно уметь компилировать и декомпилировать apk файлы.
После успешной декомпиляции приложения вам необходимо перейти в папку RES.
Там вы увидите папки values с приставками, например, -en.
Переходим в папку values, где копируем 2 файла: strings.xml и arrays.xml.
Создаем папку values-ru и вставляем в нее эти документы.
Далее мы открываем их с помощью notepad. Теперь мы можем переводить весь текст, находящийся перед окончанием тега > и .
О чем нужно знать перед русифицированием?
В конце концов, чтобы самому перевести игру на русский язык, нужно очень много времени и сил, ежедневно улучшать свои знания. Так вы сможете дойти от новичка до профессионала и стать востребованным переводчиком игр и приложений для разных устройств. Запасайтесь терпением и получайте все больше новых знаний и у вас все обязательно получится.
Большинство наиболее популярных мировых игр выходит не на русском языке. Чаще всего это японский или английский. Но что делать, если вы не обладаете достаточными знаниями этих языков, а попробовать себя в новой игре уже хочется? В данных ситуациях поможет такое понятие, как русификация компьютерной игры. Для того, чтобы сделать перевод любой компьютерной игры на русский язык, необходимо применить русификатор.
- Если игра предполагает наличие русскоязычного интерфейса, то вам стоит еще при установке выбрать соответствующий язык в определенном разделе инсталляционного процесса. Если же игра уже была ранее установлена на компьютер и вы постфактум решили сменить язык на более удобный и привычный, измените его в разделе меню конфигураций. Это стандартное размещение функции смены языков в играх. Если в данном разделе вы не нашли такой функции, то стоит изучить описание к функциям игры, именно там всегда есть вопросы на возникающие вопросы.
Функция смены языка
Советуем вам посетить наш интернет-магазин! У нас самый большой выбор игр по самым низким ценам и мгновенной доставкой!
Видео: Как перевести игру на русский язык factorio
Любительская локализация — явление, затронувшее многих игроманов, и порой даже сыгравшее не последнюю роль в формировании их интересов и отношения к игровой индустрии в целом. Наверное, благодаря тому, что оно издавна преследовало в основном благие цели, у большинства любителей интерактивных развлечений при его упоминании возникают преимущественно положительные ассоциации, а порой даже и ностальгические эмоции.
В прошлый раз я излагал свой взгляд на явления как любительской, так и официальной локализации. Поскольку нашлись люди, которым эта тема близка или интересна, а также не обошлось и без желающих побольше узнать о технических деталях процесса, то мне ничего не остаётся, как об этом рассказать, пусть и в несколько специфичном стиле.
На картинке изображён логотип российского ромхакинг-сообщества по версии проекта Russian Romhacking.
Прежде всего, хочу сказать, что я обозреваю только тот опыт, который я имел возможность наблюдать или практиковать лично. Так что далеко не факт, что все неофициальные локализаторы придерживались описанных ниже методик и уж тем более это касается упомянутого инструментария. В первую очередь я буду рассказывать о подходе, который применял сам. Я считаю, что он в достаточной степени показателен и выигрывает у многих других методик, практикуемых иными энтузиастами. Впрочем, понятие методики тут довольно расплывчато и у многих оная отсутствует вовсе.
На всякий случай упомяну и о том, что мои действия, на которых основывается весь описанный опыт, никогда не преследовали корыстных целей и не носили деструктивный характер. Всё это делалось, в первую очередь, ради самого процесса и саморазвития, и было просто моим хобби.
Честно говоря, я долго думал, как именно структурировать статью и что именно в неё включить — сперва я хотел рассказать не только о технических особенностях процесса, но и расписать суть социальной составляющей. Однако, в какой-то момент я поймал себя на мысли, что из-за обилия критики статья пригодна скорей для несколько другого места, нежели для Хабра — корить большинство непрофессионалов за проявление непрофессионализма и отсутствие стремления к совершенствованию техник несколько цинично.
В итоге я решил описать только техническую часть и только в общем виде — подробного описания с примерами хватило бы на десяток таких статей, а то и на очередную бесполезную книгу, так что пока отложим это в долгий ящик. Несмотря на это, статья даже в незавершённом виде получилась довольно большая, и я решил разбить её на несколько постов. Насколько она вышла интересной или полезной — судить вам.
Если сделать небольшое разбиение процесса перевода на подзадачи, то можно получить примерно такой список:
- Обратная разработка — процесс, многим более известный под термином реверс-инжиниринг. Игру исследуют, разбирают форматы, определяют алгоритмы, находят нужные данные.
- Извлечение ресурсов — преобразование необходимых для перевода ресурсов в удобный для редактирования вид. Текст — в текстовые файлы, графику — в распространённые форматы изображений и т.п. Всё это может осуществляться как вручную (неисповедимы пути дилетантские), так и посредством инструментария — в лучшем случае написанного самими переводчиками.
- Перевод и редактирование — самая суть процесса. Результат именно этих трудов оценивают игроки.
- Сборка перевода — конвертирование ресурсов обратно в игровые форматы и замена ими оригинальных данных игры. В идеале этот процесс должен заключаться только лишь в запуске инструментария для автоматической сборки, но, к сожалению, у большинства переводчиков он заключается в ручном редактировании каждый раз при необходимости внести изменения.
- Тестирование — обязательный этап, позволяющий выявить многие ошибки и порой улучшить перевод. Среди вожделеющих поиграться в любимую игру на родном языке отбираются наиболее ответственные и грамотные, затем им вручается бета-версия перевода с просьбой воспроизвести как можно больше игровых ситуаций. Да и свежий взгляд со стороны — всегда хорошо, многие ошибки команда может просто не видеть.
Если углубляться в детали, то не существует одинаковой для всех случаев последовательности действий, которую необходимо выполнить, чтобы подготовить игру к переводу. Так же не существует универсальных методов, с помощью которых можно выполнить те или иные шаги. По сути это всегда импровизация, но всё же есть список задач, которые встречаются практически всегда.
Я постараюсь выделить наиболее часто возникающие и важные задачи, рассказав про каждую из них отдельно. В качестве платформы не будем рассматривать ничего конкретного — т.е. всё описанное ниже справедливо как для PC, так и для любой другой платформы — будь то любая из PlayStation, XBOX, да хоть Sega или Dendy (NES).
Поскольку в данном контексте большинство задач по реверс-инжинирингу можно решить средствами отладчика или дизассемблера, я буду упоминать о них только в отдельных случаях.
Определение кодировки текста
Казалось бы, вполне тривиальная задача — определить, в какой кодировке хранится текст. И в большинстве случаев это и правда не составляет труда, но и здесь мысль разработчиков не знает предела.
Далеко не всегда выводимый текст хранится именно как текст, чаще это просто набор индексов символов в шрифте, которые необходимо отобразить. Нередко их делают совместимыми или частично совместимыми с какой-либо кодировкой, преимущественно это первые 256 символов юникода. Как бы там ни было, всё равно надо установить точное соответствие между символами и их кодами. Впрочем, в современных играх всё чаще вместо индексов используют обыкновенные кодировки и сериализуют текст в форматы вроде XML — о производительности давно никто особо не задумывается.
Для представления кодировки используются «таблицы кодировки» — текстовые файлы, где в каждой строке некой последовательности байт сопоставлена определённая последовательность символов. Выглядит это примерно так:
Например, текст «Hero obtains Item!» был бы закодирован следующим образом: « 1E 20 20 6F 62 74 61 69 6E 73 20 1E 21 21 ». Однако, если оказывается, что полученная кодировка в достаточной мере совместима с какой-либо пригодной для использования кодировкой (скажем, с юникодом), то таблица в общем-то не нужна и этот шаг можно пропустить.
Самым распространённым способом определить кодировку и найти текст является так называемый «относительный поиск» (relative search). Суть его в том, что ищутся не какие-то абсолютные значения: критерием поиска служит разница между значениями искомой последовательности. Для этого достаточно взять какое-нибудь не слишком короткое слово, встречающееся в игре, и будут найдены все последовательности байт, в которых разница между элементами равна разнице между кодами символов исходного слова.
Например, для слова «WORLD» найдётся как последовательность «57 4F 52 4C 44», так и «77 6F 72 6C 64». Да хоть «13 0B 0E 08 00»! Найдя такие последовательности и убедившись, что это именно закодированное слово, мы может запросто составить таблицу кодировки. Самой известной программой, обладающей таким функционалом, является хекс-редактор Translhexion. Имеется и куча специализированных утилит вроде Search Relative. Да и многие из технически грамотных переводчиков писали для себя подобные утилиты.
Типичный случай: если сравнить данный скриншот с полотном шрифта, то видно, что найденная последовательность — это индексы символов в шрифте: 
В целом, такая методика хоть и применима в подавляющем большинстве случаев, но без некоторых ухищрений действует далеко не всегда. Ведь никто не гарантирует, что коды символов в кодировке идут в том же порядке, что и буквы в алфавите.
Например, в переизданиях многих частей Final Fantasy для GameBoy Advance и Nintendo DS символы в шрифте отсортированы по частоте встречаемости, а для кодирования индексов используется способ, напоминающий UTF-8. Т.е. любой символ с кодом больше 0x7F кодируется двумя байтами, в то время как первые 128 символов кодируются всего одним:
Более суровый случай на моей памяти — это Final Fantasy: 20th Anniversary Edition для PlayStation Portable. Для каждой локации там существовал свой шрифт, свой текст и, как следствие, своя кодировка. Шрифт состоял только из встречаемых в тексте символов, которые так же были упорядочены по частоте встречаемости. Впору бы использовать нейронные сети для распознавания кодировки каждой локации, но благо хватило попиксельного сравнения масок прозрачности символов.
В этих случаях относительный поиск тоже подходит для решения задачи, но необходимо искать не по разнице между номерами букв, а по разнице между индексами их символов в шрифте. Т.е. можно просто записать последовательность индексов — это вполне сгодится для такого поиска.
Как и другие ресурсы, текст может быть запакован или зашифрован. В таком случае поиск среди данных игры поможет только в случаях, когда в запакованных или зашифрованных данных всё же присутствуют хотя бы обрывки слов (такое часто бывает при использовании алгоритмов вроде LZ77 или RLE). Поэтому выходом может быть поиск в дампе оперативной памяти. Возможность добычи дампа зависит от платформы, для которой делается перевод. Для эмулируемых консолей и PC трудностей быть не должно — есть куча средств для получения доступа к памяти игры. А вот в других случаях нужна возможность во время игры запустить на консоли необходимый код, для чего, как правило, консоль должна быть «взломана». Про методики разбора самих алгоритмов я расскажу в следующей статье.
Поиск указателей
Если данные хранятся в сериализованном виде, этот пункт можно смело пропускать. Если же ресурсы хранятся в исполняемом файле (что практически всегда верно для консолей, использующих картриджи) в готовом для использования виде, то, как правило, на каждый такой ресурс есть указатель. Естественно, текста это тоже касается. Тем более, чтобы стало возможным свободно модифицировать текст, надо найти все указатели и ссылки на каждую из изменяемых строк.
Забавно, что для ряда новичков понимание концепции указателей является одним из самых сложных препятствий в освоении искусства любительского перевода. Как правило, такие люди долгое время не утруждают себя технической стороной процесса и переводят текст так, чтобы он вмещался в длину оригинальной строки. Ещё более забавно то, что для совершенствования навыков многие из них в итоге осваивают программирование. Стоило бы это сделать в обратном порядке — и всё было бы гораздо проще. Хотя стоит заметить, что люди, ставшие полноценными IT-специалистами, часто уходят с этой сцены и начинают заниматься вещами посерьёзней.
Очень часто все указатели хранятся в едином месте, которое обычно называют «таблицей указателей» — оно представляет собой массив из указателей или элементов, их содержащих. В таких случаях игра обращается к строкам по индексам, по которым, в свою очередь, из такой таблицы берётся указатель. Тогда достаточно найти указатель на любую строку в блоке текста — и таблица найдена!
Но не всё так просто… вернее, не всегда всё так просто. Одна из сложностей, мешающих искать указатели, называется «разницей смещений». Дело в том, что указатель может быть не только абсолютным (указывающим на логический или физический адрес ресурса), но и относительным (указывающим на смещение относительно какого-то адреса). Или же, скажем, на старых дисковых консолях вроде PlayStation данные часто хранятся в подготовленном для загрузки в память виде — т.е. пока они лежат в файле, невозможно просто так вычислить, на что будет указывать указатель, не зная адреса, куда будет происходить загрузка.
Пока не известна разница смещений, нельзя однозначно вычислить указатель. Поэтому первым делом обычно проверяют наличие таблицы — для этого может помочь тот же самый относительный поиск. В качестве элементов искомой последовательности берутся расстояния между началами строк — разница между значениями указателей будет точно такой же. Если таблица не находится — поиск повторяют, перебирая возможные размеры указателей и возможные расстояния между ними (если помимо указателей в таблицах содержатся другие данные).
Однако, не всё коту масленица — некоторые игры обращаются к строке прямиком по указателю без использования таблиц. Тогда уже разницу вычисляют как могут: например, путём визуального анализа данных или с помощью дизассемблера. Есть ещё один «дедовский» способ: участки данных «поганят», подменяя байты, и смотрят, отразилось ли это как-нибудь на игре. Таким образом, сокращая диапазон поиска методом исключения, можно локализовать участок кода, отвечающий за вывод какой-либо строки, и найти указатель. Для таких целей даже существуют целые специализированные инструменты вроде Поганка или Visual Poganka.
Без использования таблиц указатели будут раскиданы по всему пространству кода в исполняемом файле, и порой далеко не в единичном экземпляре. Если текст складирован в одном месте, эту проблему можно решить, просканировав его и найдя все указатели на начало каждой строки. И в большинстве случаев это не составляет труда — из-за особенностей адресного пространства вероятность коллизии значения указателя с другим значением минимальна (например, память адресуется в диапазоне 0x08000000-0x09FFFFFF или секция данных начинается с адреса 0x00472000).
Но бывает и так, что память адресуется менее удачным для переводчика способом: например, начиная с нулевого адреса. И тогда коллизий уж точно не избежать… Придётся вручную проверять каждое значение, встречающееся более одного раза, на предмет того, является ли оно указателем или же данными с таким же значением. А если ещё и сам текст разбросан по файлу, то автоматизировать процесса поиска указателей можно разве что написав какой-нибудь скрипт или плагин к IDA Pro.
Так или иначе, терпение и труд всё перетрут. Достаточно найти указатели один раз и дальше с этой задачей можно не заморачиваться, переходя к следующему шагу.
Извлечение текста
Способ «выемки» текста по таблицам зависит от уровня организации переводчиков. Так, самые неорганизованные ребята (как правило, новички) вообще не заморачиваются и переводят текст прямо в хекс-редакторах. Чуть посерьёзней — используют для извлечения программы-всёделалки вроде PokePerevod или тот же Translhexion. Люди с более глубокими познаниями используют более специализированные средства автоматизации вроде Kruptar. Самые продвинутые специалисты обычно пишут для этого свои скрипты или инструменты, что и вовсе позволяет им контролировать процесс полностью.
В любом случае, в чаще всего процесс сводится к преобразованию потока байт в пригодный к чтению и редактированию вид, используя информацию о кодировках, бинарных тегах и применяемом игрой байткоде, если он имеет место быть.
Но вовсе не факт, что разработчики изначально хранили текст отдельно и в чистом виде. Очень часто он является лишь частью других данных — карт уровней, сценариев и т.п. Если кто-нибудь знаком с игровыми редакторами вроде TES Construction Set, то он поймёт, о чём речь. В таких случаях, поскольку текст хранится совместно с другими данными, необходимо «распарсить» их структуру и аккуратно извлечь текст и прочую необходимую информацию — например, иногда помимо текста необходимо изменять ещё и такие данные, как координаты его вывода и размеры диалоговых окон. Порой для этого пишутся целые редакторы, которые частично воспроизводят функционал средств, которыми пользовались разработчики.
В целом, к извлечению текста у меня свой подход. Начнём с того, что стандартный формат таблиц кодировки довольно прост и не покрывает все случаи. Например, иногда важно знать, какие последовательности байт служат для индикации конца текста, переноса строки или очистки экрана. Также в игре могут быть использованы, к примеру, коды разметки, где определённая часть битов выступает в качестве параметра. В таком случае пришлось бы записывать всё это дело примерно так:
Поэтому существует множество надстроек над этим форматом — я даже разрабатывал своё собственное расширение, которое позволяло описать даже коды разметки и прочие байты с параметрами, а также поддерживало директивы вроде include (удобно, когда есть таблицы для разных языков, но в них есть одинаковые элементы).
Рассмотрим пример таблицы в расширенном формате:
Несмотря на некоторую кашу в таблице, на выходе получался довольно опрятный для игрового скрипта текст:
Jenica: I’ve served in this castle for quite
some time. I looked after both Princess
Lenna and Princess Sarisa.
—
[Av-0]: Sarisa?
->
Jenica: Princess Lenna’s older sister.
Sarisa was sailing with her father when
a storm hit, and she was lost at sea.
О роли опрятности будет сказано чуть ниже, а сейчас рассмотрим проблему байткода. В некоторых играх используются даже свои скриптовые языки, и хорошо, если текст в них используется в качестве внешних ресурсов. Но порой всё же приходится разгребать мешанину из текста и кода.
Если невозможно отделить код от текста, то обычно для каждой инструкции придумывают мнемонику и форму записи исходя из её назначения. Составив базу с информацией о всех инструкциях, несложно написать транслятор. Но чтобы не писать такие вещи каждый раз, я придумал ещё одно расширение для таблицы кодировки.
Инструкция в байткоде идентифицируется по определённым значениям некоторых битов. Допустим, у нас есть две инструкции размером с байт. У одной инструкции биты с первого по четвёртый равны 0101 , т.е. выглядит она как 0101nnnn ; у другой — первые два бита равны 11 , т.е. запишем её как 11nnnnnn . Самым простым способом идентифицировать инструкцию является сравнение по маске — т.е. надо произвести логическое умножение опознаваемого кода на битовую маску, выделив тем самым нужные биты, и сравнить результат с эталонными данными (далее по тексту будем называть это идентификатором инструкции). Таким образом, для первой инструкции маской будет 11110000 , поскольку мы должны взять только первые 4 бита, а идентификатором, соответственно, будет 01010000 . Для второй инструкции и маска, и идентификатор равны 11000000 .
Суть расширения в том, что для инструкций можно прямо в таблице записать битовые маски и идентификаторы, которые нужны для их определения и чтения параметров. А вместо простой последовательности символов можно использовать специальную строку, которая будет говорить о том, как форматировать и конвертировать текстовое представление инструкции обратно в байткод. Т.е. по таким таблицам можно было бы даже примитивно дизассемблировать исполняемые файлы.
Форма такой записи инструкции в таблице кодировки такова:
