Как сделать свой русификатор для игры
Как сделать свой русификатор для игры
Как текстовый редактор он, несомненно, могет. Однако, перевод файлов игры через него очень геморный. Если программа дает вам сразу две строки и с одной вы переводите, а в другую пишете, то через Notepad так не выйдет. Вам придется стирать английскую версию фразы и вписывать вместо нее русскую. Так вы можете прямо на ходу печати забыть/перепутать/пропустить слово и т.д. Ну и еще выделять в нем очень длинные фразы, ♥♥♥♥♥♥♥♥♥♥♥♥, какая трудная задача. Строка не переносится на начало следующей при упоре в край экрана, а бесконечно тянется вправо. Одно случайное движение мышью вверх/вниз и вы выделили полфайла сразу.
Все это знаю по себе. Но тут уж вам решать. Хотите помучаться, значит есть зачем.
Переводить M&B через Notepad, все равно что кодить на стандартном Блокноте.
Лучше всего изменять/переводить не оригинальные файлы, а их копии. Чтобы получить их выполняем следующие действия:
Запускаем игру в оконном режиме. Ставьте галочку «Запускать в окне».
Менять будем именно их, чтобы не накосячить в основных файлах, которые пока еще используются игрой.
После скачивания программы, открываем наши скопированные файлы.
Чтобы сделать полный русификатор с нуля придется перевести и отпечатать вручную весь список файлов на картинке. В некоторых файлах больше двух тысяч строк. Не дай Бог, таким заниматься.
Вот так выглядит открытый в программе текстовый файл. Строка «Оригинальный текст» не редактируется и служит для перевода с нее. Строка «Ваш перевод» соответственно редактируется вами. После ввода вашего перевода в строку не забывайте нажимать «Заменить».
Когда закончите с файлом сохраните его. Можно сохранить его как копию открытого, в любой закоулок памяти ПК, а можно сразу назвать его как оригинал и заменить в той же папке.
При переводе строк не забывайте оставлять всякие
, и т.д. Они служат для вставки в диалог имен лордов, НПС, названий населенных пунктов. Если повредите, что-то может пойти не так. Пробелы тоже надо соблюдать.
Все, теперь вы можете открывать игру и выбирать русский язык для нужного вам модуля.
Как я уже говорил, переводить всю игру не нужно. Используйте эту программу для того чтобы поправить ошибки в фразах, перевести какую-то забытую строчку и изменить то, что вас раздражает.
К примеру, для себя я изменил манеру речи посредников в тавернах, убрав им немецкий акцент. Еще перевел вступительный отрывок при создании новой игры и исправил несколько опечаток в словах.
Работа непыльная, но способна доставить вам удовольствие на выходе.
Если вас заинтересовали мои гайдики, вы можете увидеть весь их список через менюшку или через обсуждения.
Перевод и озвучка игр: пособие для начинающих
Оглавление
Вступление
Как в представлении стандартного обывателя Интернета происходит процесс локализации игр? Человек берёт бумажку, садится перед микрофоном и зачитывает текст максимально монотонным голосом (завернувшись в одеяло — добавит обыватель продвинутый). Затем записанные реплики волшебным образом появляются в игре — и всё, продукт готов к употреблению!
реклама
Шутки шутками, но данная тема практически не раскрыта. В сети иногда всплывают различные интервью с переводчиками и актёрами дубляжа, где освещаются разные нюансы процесса адаптации проектов на русский язык, но это только элементы — общей картины из них не составить. А что делать тем, кто решил сам с нуля осваивать это нелёгкое, но занимательное ремесло? Давайте разберёмся.
Начну с краткого пояснения. Всё нижесказанное основано исключительно на собственном опыте, полученном во время работы над переводом и озвучкой Risen 3, Darkest Dungeon, Codex of Victory, Bastion и Transistor в составе студии GameSVoiCE. Это неофициальная и некоммерческая деятельность, и мне неведомо, насколько описанные в этом материале принципы работы совпадают с тем, что происходит на «кухне» профессиональных студий-локализаторов.
Но если вы хотите перевести и озвучить свою любимую игру, которая по какой-то причине была проигнорирована другими, или просто понять, какие преграды могут возникнуть в процессе работы, этот текст — ваш путеводитель, руководство и инструкция. Не обещаю, что написанное будет интересно читать, но много нового отсюда вы для себя определённо вынесете.
Итак, для начала призываю осознать, что локализация — процесс небыстрый, затратный и очень неблагодарный. Даже сравнительно небольшой проект может отожрать у вас несколько месяцев жизни и четырехзначную сумму денег, а в итоге на вас выльют ведро помоев только за то, что в одной из сцен герой произнёс реплику надменным, а не презрительным тоном, или за то, что ashen one вы перевели как «пепел». Поэтому первым делом на ясную голову ответьте на главный вопрос: надо ли оно вам вообще?
Далее следует определиться, за что браться. Если ваша цель: локализовать серию игр, начните с самой маленькой и короткой из списка, дабы на примере незначительных объемов понять, насколько хорошо справляетесь с поставленной задачей. Не рекомендую браться за игры с эпизодической моделью выпуска (как у Telltale) — с ними хоть и проще работать за счёт более понятной структуры, но рискуете подвести много людей, если после первой главы поймёте, что «не тащите» и решите соскочить.
Этап I: Разбор ресурсов и техническое тестирование
Началу работы предшествует изъятие из игры всех текстовых и звуковых файлов. Крайне редко это добро лежит прямо в папке, в незащищённом виде, поэтому вам понадобится помощь человека, имеющего опыт работы с файловыми библиотеками. Как и чем открыть тот или иной контейнер, можно посмотреть и в сети, но в этом деле знания важнее, чем умение слепо исполнять инструкции: даже если вскроете нужные архивы, не факт, что сможете потом правильно запаковать всё обратно, после редактуры.
Когда работаете в команде, на этом этапе обычно не возникает проблем. В GameSVoiCE есть штатный программист, разбирающий и собирающий ресурсы по запросу кураторов проектов. Единственной преградой в этом процессе становится время, ведь алгоритмы шифрования отличаются в зависимости от движка и формата, а они порой и опытного специалиста могут поставить в тупик.
реклама
Если вы пока сами по себе, стоит заняться поиском единомышленников. Прощупать почву на сайтах и сообществах, посвящённых выбранной вами игре, оставить запрос на специализированных по переводу площадках вроде Zone of Games, заручиться поддержкой студии озвучки. В одиночку тянуть весь процесс очень трудно — слишком большая нагрузка на плечи одного человека. А это время и силы.
Предположим, первая стадия успешно преодолена и у вас на руках папка с исходными материалами. Теперь вам предстоит оценить масштабы работ и сопоставить их с собственными возможностями. Часто все аудиофайлы свалены в одну кучу, и вам сперва нужно отделить фоновые звуки и музыку от непосредственно реплик героев. И даже если в папках прослеживается чёткая структура, лучше вручную прослушать каждый файл, ведь иногда и среди звуков встречаются строки, которые тоже следует переозвучивать.
Техническое тестирование — функция необязательная, но желательная. Лучше заранее убедиться, что ваши инструменты для внедрения текста и озвучки работают, и при внесении изменений в игровые архивы не наблюдается проблем с запуском и работоспособностью приложения. Заодно стоит проверить, как движок реагирует на специфичные символы: «ё», длинное тире, кавычки.
Этап II: Систематизация файлов и изучение лора
То, что вам прислал программист, ещё нельзя отдавать актёрам с объяснением «вот материалы, дальше разбирайтесь сами». Важно позаботиться об удобстве: как собственном, так и тех, кому ещё предстоит работать с вашими файлами. Подписи к субтитрам обычно хранятся отдельно от текстов меню и описаний, и их стоит перенести из «родного» формата в рабочую среду. Оптимальный вариант: таблицы Excel.
Для чего это нужно? Чтобы иметь быстрый доступ ко всем озвучиваемым репликам игры. Так легче производить поиск по словам, если цель — избавиться от неугодной лексики или устаревшей терминологии. Это позволяет подсчитать число строк, делать пометки и сортировать блоками в нужной последовательности. Такая таблица — ваш «оперативный штаб», сердце локализации. Она сослужит вам службу не один день, поэтому не бойтесь переусердствовать, наполняя её информацией, и не пренебрегайте её дизайном.
Первым делом вам нужно синхронизировать сами аудиофайлы c их субтитрами: понять, где именно хранится текст, а где звук. Универсальной подсказки для ускорения этого процесса не существует, ведь многое зависит от того, как изначально структурированы файлы. В Bastion и Transistor всё наглядно: в папке Subtitles тексты с разбивкой на уровни, в Audio — сами реплики. С помощью Total Commander массово копируем названия звуковых файлов из первой папки в Excel, далее напротив них вставляем тексты на английском и на русском. Прослушиваем звуки, сверяем их с субтитрами. Повторяем процедуру с оставшимися папками.
Моим коллегам, работающим с Dark Souls III, повезло меньше. В этой игре аудио разбито на архивы, в каждом заключено сразу несколько персонажей. Эти файлы не имели меток, поэтому сортировать реплики по ролям пришлось чуть ли не на ощупь, вернее, на слух, сверяя их с текстами на зарубежных фан-сайтах. В Risen 3 большая беда была с контекстными боевыми криками (SVM), когда в похожем ключе для каждого NPC из массива в 10 тысяч строк вычленялись нужные полторы сотни фраз.
Если игра предполагает одну ключевую роль (главный герой или сторонний наблюдатель комментирует события), имеет смысл сгруппировать блоки реплик в хронологическом порядке, в пределах уровней или миссий, а также делать пометки относительно развития сюжета. Вам эта информация вряд ли пригодится, а вот актёру поможет не терять нить повествования и лучше понимать историю.
В проектах с кучей средних и мелких ролей желательно выстроить реплики так, чтобы не нарушалась структура диалогов, а затем создать несколько таблиц по каждому из героев отдельно, специально для актёров. Строки других персонажей из таких текстовок лучше не удалять, а просто затемнить, чтобы было легче понять, какие манеры и интонации в той или иной ситуации стоит отыгрывать.
реклама
Наконец, вы сами должны обладать исключительными знаниями о вселенной игры. Ещё до начала всех работ несколько раз пройти сюжет, чтобы на ходу определять контекст большинства предложений. Если тексты перенасыщены короткими репликами вроде «Right back at you», сразу делайте пометки, при каких обстоятельствах они произносятся, ибо перевести такие выражения можно по-разному, и не всякий вариант подойдёт ситуации.
При дотошном подходе лучше вообще все найденные строчки отмечать, что проще всего сделать, просматривая чужие прохождения на YouTube. Это поможет выяснить процент неиспользуемых фраз (в проектах Supergiant Games таких почти четверть!) и проследить логику в изначальной сортировке строк. Например, в Bastion в конце блоков с субтитрами идут свежие исправления, поэтому если один контейнер звуков содержит две похожих фразы, актуальной всегда будет именно нижняя.
Этап III: Перевод и укладка текста
Ещё не надоело? Ну, хотя бы это читать… Первые две стадии — лишь подготовка, настоящая работа начинается отсюда. Не спешите радоваться наличию у игры официальных русских субтитров — если у издателя не хватило денег на озвучку, то и перевод наверняка доверили не лучшим специалистам, поэтому на выходе чаще всего получаем пресные тексты без явных ошибок, но слабым уровнем художественной подачи.
реклама
Работать с фанатскими переводами ещё сложнее. Во-первых, желательно добиться одобрения авторов на изменение текстов, а если русификатор старый, то и найти его создателей непросто. Во-вторых, в таких адаптациях обычно сохраняется лишь примерный смысл предложений: упускаются речевые обороты, игра слов, отсылки и аллегории. Качество страдает и от того, что на площадках вроде Notabenoid проект доступен десяткам людей с разным уровнем опыта и знаний, а у редактора нет яиц, чтобы вышвырнуть халтурщиков.
Перевод художественного произведения — настолько увлекательное, насколько и сложное занятие. Этот ролик как раз о таких подводных камнях.Многие недооценивают значимость творческого подхода, путаясь в самих понятиях «перевод» и «локализация». Русская версия в любом случае будет звучать и восприниматься не так, как оригинал, поэтому не пытайтесь усидеть на двух стульях, разрываясь между дословным пересказом и художественном стилем изложения. Иногда лучше полностью перестроить структуру фразы, чтобы она не звучала топорно.
Куратору проекта вообще необязательно в совершенстве владеть иностранными языками. Ваша первоочерёдная задача — контроль. Оформить глоссарий и привести все термины к единым значениям, помечать спорные фразы, выбивающиеся из контекста. Полезно иметь на подхвате парочку переводчиков, которым можно доверить адаптацию самых замысловатых выражений, но вносить правки в ту самую «главную таблицу» стоит именно вам, чтобы ни одна мелкая деталь не осталась незамеченной и неучтённой.
реклама
Но даже наличие изначально прекрасного перевода не освобождает вас от головной боли, ведь тексты ещё предстоит уложить, подогнав длину локализованных строк под оригинал. Нужно это для того, чтобы избежать «синдрома Ведьмака», где реплики персонажей ускорялись или замедлялись из-за жёсткой привязки к их времени произношения. Причём актуально это не только в тех проектах, где важно попадать в лицевую анимацию: если в Bastion одна закадровая реплика «налезет» на другую (при условии, что обе не связаны и отвечают за разные действия), то вторая попросту не произнесётся.
Значимость укладки определяется ещё на стадии технического тестирования. В Fallout 4 она ни к чему — там движок автоматически подстраивается под длину строчек (это и позволило одной команде энтузиастов «озвучить» игру синтезатором речи), а вот в Risen 3 отклонение от изначального тайминга приводит к вылету. Важен этот процесс и с точки зрения сценария: если в оригинале персонаж ограничился парой слов, нельзя, чтобы в русской версии он мямлил, разжевывая свой ответ.
Недобор по символам обычно не так критичен, как перебор, но и встречается реже, так что готовьтесь хладнокровно резать тексты, избавляя их от лишних местоимений и наречий, а порой даже прилагательных. В безвыходном положении отталкивайтесь от заложенного в предложении смысла, перестраивая мысль так, чтобы выразить то же самое, но короче. Большой словарный запас — ещё одно из ваших преимуществ.
Закрепим материал парочкой примером из игры Bastion. Даны реплики «Want to know how to find an Anklegator lair?» и «You use a Kid as bait.», идущие последовательно. Дословный перевод этой цепочки звучит так: «Хочешь узнать, как найти логово кротодила? Используй Мальца как приманку». Первая строчка в порядке, а вот вторая заметно длиннее. Заменяем окончание на «Лови на Мальца»: первоначальный посыл не изменился, но бонусом реплика приобрела ироничную окраску. Дословность — Адаптация — 0:1.
Как создать свой русификатор?
Итак, для русифицирования нам понадобится совсем немного, а именно:
1.Rescourse-хаковская прога. (я использую Restorator 2004).
2.Собственно то, что Вам нужно русифицировать.
3.Немного терпения.
Итак, для русифицирования нам понадобится совсем немного, а именно:
1.Rescourse-хаковская прога. (я использую Restorator 2004).
2.Собственно то, что Вам нужно русифицировать.
3.Немного терпения.
Стоит сразу сказать, что не каждую программу можно перевести таким способом. На некоторых программах стоит защита (Download Master, CBId), из-за которой внутрь файла пролезть нельзя. В других можно, но после русификации они отказываются запускаться (CPU-Z). А, например, в браузере Opera (да и не только) совсем другой алгоритм русификации. Там нужно писать специальные файлы-переводы (.lng), что совсем не сложно. Главное знать язык, с которого переводишь. Но что-то я отклонился от темы. Пожалуй, начнём. Я буду экспериментировать над простенькой прогой для редактирования БИОСов ATI Bios Edit.
Итак, мы в файле! В Ati Bios Edit в каталоге “Dialog” хранятся все окна, которые вообще есть в программе.
Как можно заметить на этом скрине, все слова, которые требуется перевести, находятся здесь. Но вот незадача, и здесь ничего нельзя изменить! Да, здесь нельзя, но можно вытащить файл из редактора, и уже в Блокноте править всё что нужно. Жмём в левой части правой кнопкой мыши по подкаталогу, в котором находятся нужные слова (в моём случае это 102 см. скрин выше). Там жмём Exreact>Extrarct as. Вуаля, и на Вашем рабочем столе появился файл 102.rc. Открыть этот файл можно с помощью Блокнота. После того, как Вы поправите файл, сохраните его. Теперь необходимо опять засунуть его в редактор. Для этого опять давим правой кнопкой по подкаталогу 102, жмём Assign>Assign to и указываем путь к файлу, который Вы только что правили в Блокноте.
Результат, как говорится, налицо. Вот и весь способ русификации. Я думаю смысл Вы поняли, и теперь будете разбираться сами, по ситуации. Ведь в любой другой программе каталоги будет построены немного по-другому, например так (ATI Tray Tools):
Ну вот собственно и всё. Как я уже сказал, не все программы можно русифицировать таким способом, но большинство (причём важное большинство) всё же поддаётся (WinAmp, ATT,SpeedFan, DivX. ). Вы, наверное, обратили внимание, что можно не только перевести текст, но и заменить иконки, шрифты, размеры окна и т.д. Вообщем Rescousre-редакторы дают много возможностей. С помощью них можно даже создавать темы для Windows XP. Пользуйтесь и экспериментируйте!
Любительский перевод игр: анатомия процесса, часть первая
Любительская локализация — явление, затронувшее многих игроманов, и порой даже сыгравшее не последнюю роль в формировании их интересов и отношения к игровой индустрии в целом. Наверное, благодаря тому, что оно издавна преследовало в основном благие цели, у большинства любителей интерактивных развлечений при его упоминании возникают преимущественно положительные ассоциации, а порой даже и ностальгические эмоции.
В прошлый раз я излагал свой взгляд на явления как любительской, так и официальной локализации. Поскольку нашлись люди, которым эта тема близка или интересна, а также не обошлось и без желающих побольше узнать о технических деталях процесса, то мне ничего не остаётся, как об этом рассказать, пусть и в несколько специфичном стиле.
На картинке изображён логотип российского ромхакинг-сообщества по версии проекта 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.
О роли опрятности будет сказано чуть ниже, а сейчас рассмотрим проблему байткода. В некоторых играх используются даже свои скриптовые языки, и хорошо, если текст в них используется в качестве внешних ресурсов. Но порой всё же приходится разгребать мешанину из текста и кода.
Если невозможно отделить код от текста, то обычно для каждой инструкции придумывают мнемонику и форму записи исходя из её назначения. Составив базу с информацией о всех инструкциях, несложно написать транслятор. Но чтобы не писать такие вещи каждый раз, я придумал ещё одно расширение для таблицы кодировки.
Суть расширения в том, что для инструкций можно прямо в таблице записать битовые маски и идентификаторы, которые нужны для их определения и чтения параметров. А вместо простой последовательности символов можно использовать специальную строку, которая будет говорить о том, как форматировать и конвертировать текстовое представление инструкции обратно в байткод. Т.е. по таким таблицам можно было бы даже примитивно дизассемблировать исполняемые файлы.
Форма такой записи инструкции в таблице кодировки такова:
Где OpcodeMask — маска, OpcodeID — идентификатор, ValueMasks — перечисленный через запятую список битовых масок параметров, а FormatString — строка для форматирования текстового представления инструкции и конвертации её обратно в байткод (представляет из себя модифицированный эквивалент форматных строк для функции printf).
Попробуем декодировать его с помощью таблицы, в которой есть такая запись:
Получаем такой результат:
Obtained an item!popup(1, color)
Now you can open the door.
Не совсем удачно сочетается с текстом. Поэтому попробуем прибегнуть к помощи тегов. Пусть это будут XML-теги:
Now you can open the door.
Но ещё лучше было бы, если бы вместо «магических констант» мы видели текстовое представление параметров. Для этого я ввёл возможность объявления перечислений в виде:
Допустим, такая инструкция применяется только для трёх предметов: бомбы с номером 0, ключа с номером 1 и монеты с номером 10:
Как видно, заодно и для цвета я применил более привычную запись. Конечно, глупо поступать таким образом с восьмибитным представление цвета, но это лишь пример, взятый из головы для наглядности.
Дальше нам остаётся только включить подсветку тегов и можем получить более-менее читабельный текст:
Если семантика инструкций не так важна (т.е. перевод не подразумевает их редактирования), то лучше прибегнуть к более краткой записи, а то в некоторых местах кода может получиться больше, чем текста. Например, так:
Для инструкций с ровно одним параметром я предусмотрел укороченную форму записи. Ниже следует две эквивалентных по смыслу строки:
Как видно из записи, вопросительными знаками я выделил биты параметра, остальные биты считаются единичными битами маски, а идентификатор получается путём замены вопросительных знаков на нули. К сожалению, такая запись возможна только для инструкций, где размеры параметра и идентификатора кратны четырём битам, т.е. размеру одного шестнадцатеричного символа.
Представление текста
Это одна из самых важных частей процесса, потому что извлечённый текст попадёт прямиком к переводчикам, и от того, насколько он опрятен, зависит не только продуктивность их работы, но и количество структурных и семантических ошибок, которые они допустят. По сути этот процесс — доработка механизма извлечения текста таким образом, чтобы максимально упростить работу переводчиков.
Если рассматривать описанный в предыдущем пункте текст, то для переводчика достаточно краткого экскурса о назначении тегов и прочей белиберды, особо его напугать ничего не должно. Но, надо заметить, что основной, на мой взгляд, ошибкой в представлении текста является зашкаливающее количество технической информации. У большинства дилетантов такой текст выглядел бы совсем по-другому:
Jenica: I’ve served in this castle for quite^
some time. I looked after both Princess^
Lenna and Princess Sarisa.^
[#C2][#A5][#C2][#B3]: Sarisa?^[#C3][#91]
Jenica: Princess Lenna’s older sister.^
Sarisa was sailing with her father when^
a storm hit, and she was lost at sea.
На месте переводчика я бы сказал: «и как прикажете это переводить?»
Это, конечно же, запросто может быть чревато тотальными ошибками, ибо обычно весь контроль качества производится вручную, несмотря на простор для его автоматизации. Как-то раз у «коллег» в релиз укатился очень крупный перевод без единого тире — все их молча скушал Word, подменив на «правильные», которые конвертору текста были не знакомы.
К сожалению, порой от трудно читаемого текста не спасает ничего. К тому же, в некоторых играх теги не компилируются в байткод, а так и хранятся в текстовом виде, т.е. игра обрабатывает их при выводе текста. Да что там говорить, вот вам пример:
&just=left;Data indicates Energy Cell is connected to &push;&main-color=#FF6705B3;processing&pop; containment core.&endif;
Согласитесь, глаза сломать можно, что уж говорить о неустойчивости к ошибкам (легко сделать, трудно заметить). Выходом из ситуации мог бы послужить WYSIWYG-редактор, или, по крайней мере, конвертация текста в формат любого такого редактора и последующая конвертация обратно. Но это довольно дорогостоящее (в плане человекочасов) решение, да и от тегов и инструкций оно не сильно-то и спасает.
Раньше я пытался производить декомпозицию (разделение на две сущности) текста и других данных настолько, насколько позволяет конкретный случай. Например, теги можно группировать, заменяя на один тег вроде «» или «< >», при этом вынося в отдельный файл. Но, поскольку теги тесно связаны с текстом, да и головной боли от такого решения только прибавляется, я впоследствии от этого отказался.
Но какой-никакой выход всё-таки нашёлся, и заключается он в подсветке синтаксиса. Т.к. все технические данные обычно легко обрабатываются автоматически, то и выделить их среди остального текста тоже не проблема.
Для этих целей я использовал возможности всем известного Notepad++ — в нём есть инструмент для создания своего механизма подсветки. Мне повезло с тем, что переводчик, с которым я работал, сам использовал Notepad++, поэтому уговаривать никого не пришлось. Несмотря на ограниченность в создании правил подсветки, этой возможности оказалось вполне достаточно, хоть и приходилось порой прибегать к разнообразным костылям.
С этим уже вполне можно жить. А иногда я заходил ещё дальше и писал визуализаторы — программы, которые отображали текст так же, как бы он выглядел в игре. Ну, или почти так же…
Впрочем, это обычно касалось случаев, когда необходим был жёсткий контроль качества на предмет корректного вывода текста в диалоговых окнах. А гораздо проще контролировать это ещё на этапе перевода, чем потом отлавливать тысячи косяков, связанных с выходом текста за отведённые ему рамки. Хорошо, что во многих играх всё же существует автоперенос.