Принципы перевода азиатских DOS-игр

Материал из Old-Games.RU Wiki
Перейти к: навигация, поиск
Creative Commons: некоторые права защищены
WERTA — автор этой статьи. Вы можете свободно копировать и распространять данный текст, но только при соблюдении условий, что оригинальное авторство и лицензия будут сохранены в производной работе. Текст распространяется под лицензией Creative Commons Attribution-Share Alike (by-sa) 3.0. Разрешается добавлять примечания и исправлять опечатки; остальные действия не рекомендованы.

Перевод азиатской ДОС-игры с двухбайтовой кодировкой наиболее оптимально может быть выполнен путём графической перерисовки в растровых шрифтах (например, с разрешением в 16х16 пикс.) с заменой квадратных азиатских символов всеми возможными сочетаниями пар русских (либо лат.) узких прямоугольных псевдосимволов (8х16+8х16), с последующей перекодировкой строковых ресурсов для их правильного отображения.

Конечно, для особых случаев можно и триплеты букв использовать, но, я думаю, это нереально, поскольку не все наши буквы удастся по три записать в растре 16х16. «М», «Ы» и «Ю» с трудом вписываются в растр 8х16 пикс.

По степени нехватки места в строковых ресурсах под наши символы можно грубо отсортировать игры на языках Восточной Азии в следующем порядке:

Китайский – мои исследования, основанные на собственном переводе различных статей с китайского на русский язык, дают оценку примерного отношения знаков в нормальном тексте – 1 иер./4 буквы. Для других европейских языков, я полагаю, будет сохраняться примерно такое же соотношение.

Корейский– не знаю языка, но тут очевидно сильное историческое влияние Древнего Китая, и нынешний хангыль – это вроде как, если бы китайцы вписывали звучание идеографа на пиньинь или чжуинь в квадрат вместо этого идеографа. Только корейцы как фонетико-лингвистическая мононация легко могут себе это позволить (с 15 века), а китайцы в силу внутренних, мягко говоря, очень пёстрых фонетических различий, – уже не могут. Поэтому, предположу, что по длине двухбайтовых строк корейский язык практически информационно эквивалентен китайскому. Да, и в Южной Корее ещё в KSC-кодировке остались около 5 тысяч иероглифов (ханьча). Но бывает, в корейском языке встречаются ещё и чисто корейские слова некитайского происхождения, и они многосложные (2–3 слога на хангыле). Отсюда вывод: в ресурсах игр на корейском языке должно быть немного побольше свободного места для алфавитов однобайтовой перекодировки.

Японский – всё-таки количество фонем в словах и предложениях в этом языке, по сравнению с китайским, побольше будет, плюс часто в японских строках идёт вместе с кандзи ещё и хирагана (корневая часть – кандзи, суффиксальная – кана). При транскрипциях на один кандзи, в среднем, идут два слога хираганы (канна – тоже двухбайтовые символы) и это уже намного лучше, чем в китайском языке.

Итак, вывод – наиболее жёсткие ограничивающие рамки нам следует ждать от игр на традиционном или упрощённом китайском языке.

Однако замена одного азиатского символа двумя однобайтовыми всё равно не снимает проблемы дефицита знакомест в строке. И здесь начинается виртуозная работа переводчика игры. Нужно знать игру досконально, максимально используя хоть какие-то отдалённые синонимичные формы, ну, и как самый крайний вариант – наиболее общеупотребительные аббревиатуры, ставшие в современном новорусском языке практически самостоятельными словами. Крайнюю сложность представляют очень распространённые двухиероглифные сочетания в кит. играх. Пример: список предметов в игре TunTown– 香蕉 [xiang-jiao] – из списка предметов ясно, что это банан, чтоб было понятно, запишем тремя псевдопарами: БА-НА-Н_, а по опыту перевода игры Colonial Project стало ясно, что если такие однотипные сгруппированные названия идут в меню, то они все будут иметь заведомо одинаковую выровненную длину и место в двоичных данных между ними будет разделяться только одним нулевым байтом, вот так, просто вообще может не быть свободного места для расширения двухбайтовой сроки. И понятно, эквивалента банану просто нет, потому что он – БАНАН, или даже ФР-УК-Т_ (всё равно три пары символов), в общем, такие ситуации возможны, и нужно уметь из них выходить. Но один такой приём, возможно, и не только для растровой графики, но и для символов текстов – есть! Китайское побеждается китайским – в переводе игры Colonial Project в некоторых, казалось бы, уже безвыходных ситуациях, когда при перерисовке графических надписей просто не хватало места, Vladimir 777 предложил использовать те же пиктограммки игры, что соответствуют или жёстко связаны с переводимыми надписями, а пиктограммки в играх – ну они всегда есть. Вместо иероглифа при перекодировке шрифта можно запросто нарисовать свою пиктограммку. Так что знайте, любой перевод текстов азиатской игры это, прежде всего, практически ручная, кропотливая работа, которую я не побоюсь назвать искусством.

Типы азиатских (тайваньских, гонконгских, корейских…) ДОС-игр по технической реализации перевода и перекодировки для основной текстовой информации (расположены по возрастанию степени сложности):

1. Текстовая информация содержится исключительно в графических ресурсах игры. Перевод – просто перерисовывание ресурсов. Пример – игра KingKong10.

2. Текстовая информация содержится в виде шрифтовых псевдострок (пример – игра Galaxy Fleet). Кодированных строк нет, а эти псевдостроки напрямую берутся для брифингов и сообщений из псевдошрифтовых файлов с иероглифами размером 16х16 пикселов. Т.е в шрифтовом файле имеются строки с уже нарисованными и размеченными на абзацы символами. Перевод – просто перерисовывание файлов псевдошрифтов. Лучше это делать парами неазиатских символов в иероглифическом знакоместе, поскольку есть ещё и графические рамки, ограничивающие размеры надписей у текстов игрового перевода.

3. Текстовая информация содержится в виде строк в одной из стандартных азиатских кодировок (BIG5, GB2312, ShiftJIS, KSC) в ресурсах ехе-файла. Имеется обычный шрифт 16х16 пикс. Внутренней игровой перекодировки нет. Символы берутся напрямую из шрифта с размером символов 16х16 пикс. Перевод – перерисовка части символов шрифта для всех возможных сочетаний пар неазиатских псевдосимволов (8х16+8х16) и с соответствующей переводу перекодировкой строк в ехе-файле, для того чтобы отображались уже перерисованные псевдопары в символах игрового шрифта. Пример игры – The Heaven Sword and Dragon Saber.

Причем сама суть старых двухбайтовых кодировок (они восходят к EUC-Extended Unix Code) основана на полной сочетаемости однобайтовых и двухбайтовых символов вместе в азиатском тексте. Т. е. последовательность байтов 31 А140 32 А140 33 А140 34h… должна движком игры (хотя для технической реализации игр это не строгая догма) выводиться как: 1<ASIAN_MONOSPACE>2<ASIAN_MONOSPACE>3<ASIAN_MONOSPACE>4.

Это вообще позволяет тогда без длительной перерисовки символов перерисовать только маленький английский шрифт (который обязательно бывает в таких играх) и затем перекодировать строки напрямую в HEX-редакторе, вводя только однобайтовые символы, что автоматически в два раза увеличит полезный размер строки относительно первоначального. Но опять же, если текстовый движок игры это точно поддерживает. И ещё одно неудобство – лат., греч. символы в начале неанглийского основного шрифта игры нарисованы как моноширинные квадратно-двухбайтовые. Это сильно сокращает место для строк при прямом перекодировании 1 иерогл./1 буква, поскольку на один иероглиф в информационном плане приходится около 4-х символов алфавитных языков.

4. Текстовая информация также содержится в виде текстовых строк в одной из азиатских кодировок в ресурсах ехе-файла. Но, шрифт 16х16 имеет в себе только используемые иероглифы и связующим звеном между строками стандартной кодировки (BIG5) в ехе-файле и выводом иероглифов на экран становится таблица перекодировки шрифта. Яркие примеры – игры: Colonial Project, TunTown. Число знакомест в таком случае резко сокращено по сравнению со стандартным вариантом кодировки без внутренней игровой перекодировки основного шрифта. Крайне удачным моментом в Colonial Project является то, что для русских двухбуквенных сочетаний отведено всего лишь 672 знакоместа – этого было мало, но, как оказалось, не смертельно. Пришлось пожертвовать некоторыми мелочами, и перевод строк в основном файле той игры – aps0.exe недавно был удачно завершен. Это показывает, что даже такое небольшое количество – 672 знакомест уже достаточно для полноценного русского перевода с использованием описываемого тут метода формирования пар всех возможных сочетаний псевдосимволов по формуле 16х16=(8х16+8х16). Да и для англификации этой игры заведомо хватает места 26х26=676, ведь двухбуквенных сочетаний для английского языка существенно меньше. В игре TunTown места в основном шрифте намного больше – более 2000 символов. Это позволит группировать внутри русских пар сочетаний псевдосимволов даже основные знаки препинания и служебные пиктограммки.

Перевод таких игр возможен только в спец. приложении с подгрузкой таблицы внутренней перекодировки шрифтов и таблицей преобразования пар вводимых текстовых однобайтовых русских или английских символов.

5. Самый худший вариант – нестандартная кодировка строк, применённая из разных корыстных побуждений. Тогда найти строки становится очень тяжело, но возможно. Далее их нужно раскодировать. Хотя, скорее всего, кодировка может быть и прямой по отношению к положению символа в основном шрифте. Например, в Big5 первый символ (азиатский пробел) кодируется как A140h а при таком подходе он в шрифте может идти под номером 0001, поскольку находится в начале. Таких примеров я пока не встречал.

Загадкой остаётся игра Danger Zone. Строк в ехе-файле не найдено. Даже откровенно растровые 16х16 иероглифы, плавно идущие в интро – их тоже в текстовом виде я не нашёл в интро-файле. Вероятно это сжатые графические ресурсы игры. Даже последовательно и посимвольно выводимая строка иероглифов в конце кампаний этой игры – для нее тоже ничего не найдено текстового. Будем дальше работать.

В заключение хочу ещё отметить азиатские игры на платформе Windows. Казалось бы, вроде, если есть Windows – подразумевай есть и кодировка Unicode, но тогда тоже не исключены некоторые проблемы. Перекодировка будет только двух байтовая один к одному, а если используются системные ttf-шрифты, то и легко перерисовать их будет уже невозможно. Т.е править ttf-файлы смысла нет, поскольку потом замучаешься с хинтингом, а без хинтинга символы будут выглядеть весьма неряшливо. Да и сами символы в Windows выводятся не моноспейсом, а с переменной шириной (неазиатские). Лишь бы хватило места под строки в самом ехе-файле при перекодировке один к одному. Но посмотрев игру Colonial Project 2, а она издана именно на платформе Windows, я опять в ехе-файле увидел строки старой доброй кодировки BIG5. А иероглифы в этой игре используются свои собственные, растровые. Похоже, что не всё так плохо…