на чем пишут визуальные новеллы

0. Обоснование разработки движка.

Примечание: Если вам по каким-то причинам неинтересны технические подробности, можете переходить сразу к п. 4 «Разработка игры», однако Вы пропустите основную часть контента

0. Обоснование разработки движка

Разумеется, существует огромное количество готовых движков для визуальных новелл, которые, без сомнения, по всем пунктам лучше нижеописанного решения. Однако каким бы программистом я был, если бы не написал еще один. Поэтому давайте сделаем вид, что его разработка была обоснована.

1. Выбор платформы

Выбор, собственно, был невелик: либо Java, либо C++. Недолго думая, я решил реализовывать задуманное на Java, т.к. для быстрой разработки она даёт все возможности (а именно: автоматическое управление памятью и большую, по сравнению с C++, простоту, которая скрывает много низкоуровневых деталей и, как следствие, позволяет меньше акцентировать внимание на самом языке и думать только о бизнес-логике), а также обеспечивает поддержку окон, графики и аудио из коробки.

Для реализации графического интерфейса был выбран Swing, так как я использовал Java 13, где JavaFX уже не входит в библиотеку, а добавлять в зависимости десятки мегабайт OpenJFX было лень. Возможно, это было не лучшим решением, но тем не менее.

Вероятно, возникает вопрос: что это за игровой движок, да без аппаратного ускорения? Ответ заключается в отсутствии времени для борьбы с OpenGL, а также абсолютной её бессмысленности: для визуальной новеллы неважен FPS (во всяком случае, с таким количеством анимации и графики, как в данном кейсе).

2. Архитектура движка и его реализация

2.1 Постановка задачи

Для того чтобы решить, как что-либо делать, нужно определиться с тем, зачем это делать. Это я о постановке задачи, т.к. архитектура не универсального, а «домен-специфичного» движка по определению напрямую зависит от задумываемой игры.

Под универсальным движком я понимаю движок, поддерживающий относительно низкоуровневые понятия, типа «Игровой объект», «Сцена», «Компонент». Делать было решено именно не универсальный движок, потому что это значительно сократило бы время разработки.

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

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

Примечание: Под сценой я понимаю логически выделенную часть игры. Критерием сцены может служить одинаковый фон на протяжении этой самой части.

Также среди требований к движку была возможность воспроизведения аудио и показа сообщений (с опциональной функцией пользовательского ввода).

Пожалуй, самым важным желанием было желание писать логику игры не на Java, а на каком-нибудь простом декларативном ЯП.

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

По задумке, всё взаимодействие с пользователем должно было производиться через систему диалогов. При этом диалогом считался не обязательно диалог с NPC или что-то подобное, а вообще реакция на любой пользовательский ввод, для которого был зарегистрирован соответствующий обработчик. Непонятно? Скоро станет яснее.

2.2. Архитектура и реализация

Учитывая всё вышесказанное, можно поделить движок на три относительно большие части, которые соответствуют одноимённым java-пакетам:

В данном пункте я рассмотрю первые две части. Начну со второй.

Файловая структура квеста следующая:

Имеется отдельная папка для квеста, в корне которой лежит манифест, а также три дополнительные папки: audio — для звукового сопровождения, graphics — для визуальной части и scenes — для скрипто, описывающих сцены.

Хотелось бы в двух словах описать манифест. Он содержит следующие поля:

Стоит отметить, что во время инициализации дисплея, помимо всего прочего, происходил расчёт разрешения рендеринга: т. е. бралось требуемое разрешение из манифеста и ужималось в доступное для окна пространство так, чтобы:

Также при инициализации дисплея скрывается курсор, так как в игровом процессе он не участвует.

В двух словах о консоли разработчика. Она была разработана по следующим причинам:

На этом описание инициализатора и связанных вещей заканчивается, и можно переходить к описанию дисплея.

Его финальная структура имеет следующий вид:

Из постановки задачи можно сделать вывод, что всё, что придется делать, — это рисовать изображения, рисовать текст, воспроизводить аудио.

В моем случае было решено поступить немного по-другому. Так как для визуальных новелл текст и изображения имеют относительно перманентный характер, а также являются почти всем, что видит пользователь (то есть достаточно важны), они были сделаны, как игровые объекты — то есть такие вещи, которые нужно лишь заспаунить и они не исчезнут, пока их не попросишь. К тому же данное решение упрощало реализацию.

Объект (с точки зрения ООП), который описывает текст/изображение, назовём дескриптором. То есть для пользователя API движка существуют лишь дескрипторы, которые можно добавить в состояние дисплея и удалить из него. Таким образом, в финальном варианте дисплея имеются следующие дескрипторы (они соответствуют одноименным классам):

Дисплей содержит также поля для текущего приемника ввода (дескриптора ввода) и поле, указывающее на то, какой текстовый дескриптор сейчас имеет фокус и чей текст будет скроллиться при соответствующих действиях со стороны пользователя.

Игровой цикл выглядит примерно так:

Примечание: Возможно, возникает вопрос «Зачем рендерить поля для ввода, если для них созданы соответствующие текстовые дескрипторы, которые рендерятся на шаг раньше?» На самом деле рендеринга в пункте 7 не происходит — происходит лишь синхронизация параметров InputDescriptor ‘а с параметрами TextDescriptor ‘а — такие как видимость на экране, позиция, размер и другие. Это было сделано, как указывалось выше, по той причине, что пользователь не управляет напрямую соответствующим дескриптору ввода дескриптором текста и вообще о нём ничего не знает.

Стоит отметить, что задание размеров и позиций элементов на экране происходит не в пикселях, а в относительных размерах — числах от 0 до 1 (схема ниже). То есть вся ширина для рендеринга — это 1, и вся высота — это 1 (причем они не равны, о чем я несколько раз забыл и позже пожалел). Также стоило бы сделать, чтобы (0,0) был центром, и ширина/высота были равны двум, но я почему-то про это забыл/не подумал. Однако даже вариант с шириной/высотой равной 1 упрощал жизнь разработчику квестов.

Пару слов о системе освобождения памяти.

При её инициализации она как раз и добавляет в дисплей дескрипторы для фона, текста и т. д. Также она умеет показывать сообщения с опциональными иконкой, полем ввода и колбэком.

Тут всплыл небольшой баг, полное исправление которого потребовало бы переделывания половины системы рендеринга: если посмотреть на порядок отрисовки в игровом цикле, видно, что сначала рисуются изображения и только потом текст. В то же время, когда тулкит показывает изображение, он располагает его посередине экрана по ширине и по высоте. И если текста в сообщении достаточно много, то он должен частично перекрывать основной текст сцены. Однако так как фон сообщения — это изображение (полностью черное, но тем не менее), а изображения отрисовываются до текста — то один текст накладывается на другой (скриншот ниже). Проблема была частично решена вертикальным центрированием не по экрану, а по области над основным текстом. Полное решение включало бы в себя введение параметра глубины и переделывание рендереров от слова «совсем».

3. Скриптовый язык

Примечание: Если уважаемый %USERNAME% дочитал досюда, то он молодец, и я попросил бы его не бросать это делать: сейчас будет значительно интересней, чем было до этого.

3.1. Язык

Изначально хотелось сделать декларативный язык, в котором нужно было бы лишь указать все необходимые параметры для сцены, и всё. Всю логику бы на себя брал движок. Однако в итоге я пришёл к процедурному языку, даже с элементами ООП (едва различимыми), — и это было хорошим решением, так как, по сравнению с декларативным вариантом, давало возможность многократно большей гибкости игровой логики.

Синтаксис языка продумывался так, чтобы быть максимально простым для парсинга, что логично, учитывая количество имевшегося в наличии времени.

Итак, код хранится в текстовых файлах с расширением SSF; каждый файл содержит описание одной либо больше сцен; каждая сцена содержит ноль или больше действий (action); каждое действие содержит ноль или больше операторов.

Возможно, вы жаждете увидеть наконец исходный код на SL, вот он:

Теперь становится ясно, что такое оператор. Видно также, что каждое действие есть блок высказываний (statement) (при этом высказыванием может быть и блок высказываний), а также то, что поддерживаются однострочные комментарии (вводить многострочные не имело смысла, к тому же я и однострочными не пользовался).

Ради упрощения такое понятие, как «переменная», в язык не вводилось; как следствие, все значения, используемые в коде, — литералы. В зависимости от типа выделяются следующие литералы:

Пару слов про парсинг языка. Имеется несколько уровней «загрузки» кода (схема ниже):

Теперь вкратце об операторах, чтобы появилось представление о функциональности языка. Изначально имелось 11 операторов, затем в процессе продумывания игры некоторые из них слились в один, некоторые изменились, и добавилось ещё 9 штук. Вот сводная таблица:

Операторы для работы со счётчиками — специфичными для сцены целочисленными переменными.

Была также мысль ввести оператор return (на уровне ядра интерпретатора даже была добавлена соответствующая функциональность), однако я забыл, да он и не пригодился.

В загрузчик скриптов встроено не так много проверок на правильность SL-программы, как хотелось бы. Например, всё, что может выброситься на этапе загрузки скрипта, — это исключение о непредвиденном либо неизвестном токене. Во времени исполнения ситуация лучше: есть проверки на типы аргументов операторов (да-да, операндов), на их количество, на наличие запрашиваемой сущности во время lookup ‘а, возможно, и другие, не помню. Однако нет таких проверок времени загрузки, как вызов только существующих действий или использование только существующих сцен в goto и lookup ‘ах, а также проверки типов аргументов и многих других.

В первую очередь из-за нехватки времени и во вторую — из-за того, что анализаторы всех операторов сделаны через базовый анализатор, который умеет только брать из потока n токенов (представляющих аргументов) и строить объект оператора. При этом никакой проверки на типы аргументов или правильность их содержания не производится, потому что анализатор знает только, что ему нужно забрать из потока n токенов и всё. Проверка происходит позже, в рантайме.

Кратко о диалогах. Приведу синтаксис оператора добавления диалога:

Как я прочитал в википедии, очень важной частью любого движка для визуальных новелл с произвольным пользовательским вводом является анализатор ввода на естественном языке. Разумеется, я решил несколько упростить задачу: игра реагировала не на смысл, заложенный во фразе, а лишь на форму самой фразы, которая задавалась регулярным выражением (схема ниже).

Таким образом, если пользователь вводил текст, который совпадал с одним из регулярных выражений (первый аргумент) одного из включенных (последний аргумент) диалогов данной сцены, то выполнялся колбэк (третий аргумент). Для упрощения регулярных выражений пользовательский ввод подвергался следующей обработке: один и более пробельных символов заменялись на один пробел, боковые пробельные символы удалялись, текст переводился в нижний регистр, «ё» заменялось на «е».

Возможно, стоило сделать ещё удаление знаков препинания (знаков вопроса, в частности)

Пример регулярного выражения для диалога, обозначающее «осмотреться»:

Учитывая всё вышесказанное, можно увидеть аналогию с ООП: сцены — классы, все члены которых статичны и публичны, а действия — методы.

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

3.2. Интерпретатор

Рассказывать про сам интерпретатор особо нечего: он тоже модульный, модули — это «исполнители» операторов (по одному для каждого). Больший смысл имеет рассказать про специальные действия и смену состояний дисплея.

Для самого SL специальных действий не существует, но для интерпретатора они все-таки есть. Вот они:

Примечание: init и first_come — вместе составляют некое подобие конструктора, что ещё раз намекает на легкий объектно ориентированный оттенок языка.

Это состояние состоит из состояния дисплея и состояния тулкита (обертки, которая добавляет понятие «фон», «основной текст», «поле для ввода» и т. д.). Стало понятно, что нельзя просто выбрасывать эти состояния, а их где-то надо хранить и как-то заменять. Проблема была в том, что все дескрипторы дисплея и тулкита хранились прямо в классах их представляющих (в полях), а сохранять вручную с десяток объектов никоим образом не хотелось.

На помощь пришла композиция и выделение состояния дисплея и тулкита в отдельный класс (что, вероятно, нужно было сделать сразу). Оставалась одна проблема: каким образом заменять состояния с текущего на старое? Ведь нельзя же во время игрового цикла, а именно во время итерации по спискам дескрипторов, просто взять и заменить эти списки. Поэтому тут пришлось добавить метод provideState в дисплей, в который передавался колбэк и состояние для загрузки; а после завершения очередной итерации игрового цикла это состояние заменялось и вызывался колбэк, в котором происходила замена состояния тулкита.

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

4. Разработка игры

Тут я кратко опишу саму игру и процесс её разработки. Как в 2019-м и 2018-м, я решил начать с чего угодно, кроме графики, и начал с истории.

4.1. История и разработка логики игры

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

Стоит сказать, что игра линейная: игрок не сможет пойти туда, куда игра не хочет в данный момент, однако сможет позже, когда игре это будет надо. Отчасти это было сделано для уменьшения количества возможных вариантов развития событий, благодаря чему разработка становилась проще и быстрее, а количество возможных багов снижалось.

Как оказалось, для разработки задуманной игры мне не понадобилось 25% (5) существующих операторов, а именно: все операторы, связанные со счётчиками; оператор анимирования ( animate ), а также оператор внешнего вызова ( call_extern ).

Помимо основной игры, для ознакомления игроков с кор-механиками игры был разработан демоуровень (скриншот ниже), который состоял из одной сцены (двух, если быть точным, но вторая — просто заглушка, типа «You won»).

4.2. Графика

Во время разработки логики и тестирования вместо изображений использовались заглушки, как видно на скриншоте ниже:

Как видно по изображению до ката, рисование не моя стихия, однако нужно было как-то обеспечить хоть какую-то графику на уровне «не отвратительно». Достигнуть его помогли следующие условия:

5. Статистика и итоги

На разработку первой версии движка и языка (с 11 операторами) у меня ушло 30 часов 40 минут. На реализацию дополнительных 9 операторов ушло ещё 4 часа 55 минут. Разработка логики непосредственно игры (вместе с демо) потребовала 7 часов 41 минуты. Рисование графики —

4-6 часов (графика не учтена в 45 часах из заголовка).

Примечание: Время кодинга мерялось через расширение «Darkyen’s Time Tracker» для продуктов JetBrains (абсолютно не реклама).
Примечание: Я начал писать это все за 2 дня до Нового года, но не успел — релиз пришлось перенести на Рождество. Так что 45 часов из заголовка были распределены примерно на 8 дней.

Количество чистых строк кода для движка: 4777, для игры (без демо) — 637.

Целью было создать 30 минут игрового времени. В итоге прохождение (с моими подсказками) заняло: демо —

8 минут, основная игра на первую концовку —

24 минуты, на вторую (с быстрым прохождением до момента разветвления) —

8 минут. То есть план был выполнен.

Размер квеста — 232 мегабайта (так много из-за музыки, записанной в WAV).

Было нарисовано 28 изображений (и ещё 3 для демо). Это была моя первая игра с адекватным аудио сопровождением — всего с просторов интернета было скачано и запихнуто в игру 17 единиц звуков/музыки.

Все жалобы на игру заключались в абсолютно не юзер-френдли интерфейсе ввода: очень часто регулярные выражения не покрывали вводимых фраз, хотя смысл этих фраз был более чем верный. То есть, например, игрок вводил «вставить ключ в дверь», а предусмотрено было лишь «вставить ключ». Однако были и моменты (один, насколько я помню), когда пользовательский ввод с первого раза совпадал с задуманным (и это было даже не «да»/»нет» или что-то очевидное).

Очевидное решение — просто выдавать игроку список вариантов того, что он может сделать. Но тут есть и очевидная проблема: вся игра сведется к методичному прокликиванию всех вариантов. Скучно. Поэтому, в итоге после обсуждения был сделан вывод, что максимально приятным и не слишком «открытым» интерфейсом был бы следующий: варианты диалогов даются лишь при диалогах с NPC, а действия с миром производятся мышью, путем клика на определенные участки экрана (например, нажать на куст — обыскать его и т.д.).

Также я считаю, что не смог адекватно раскрыть историю: остались недосказанности, непонятные моменты и даже маленькие противоречия.

Ещё один косяк — в демо. Оно было сделано слишком подробным, а именно: найти ключ, вставить ключ, открыть дверь, выйти в неё. В то время как сама игра не была настолько требовательной к описанию каждого действия. Вероятно, это создало у игроков неправильное представление о том, чего ждет от них игра, что, конечно, нехорошо.

Теперь к коду. В целом качество кода меня устраивает (хотя это ещё ни о чём особо не говорит), однако есть следующие моменты:

Кстати, во время игры багов выявлено не было и всё отработало без единого краша, что приятно.

Исходный код движка может быть найден по данной ссылке на GitHub.

Демо и основная игра находится в файлах (assets) в разделе «Releases» для версии «v1.0» там же.

Источник

Как за 3 дня создать игровой движок для новелл

Одним дождливым питерским днем мой проект в UE4 перестал загружаться, и из-за этого я захотел сделать свой собственный движок. И одна новелла подтолкнула меня сделать движок именно для новелл. Если вам хочется узнать побольше и вы не боитесь goto, gosub и других ужасов, добро пожаловать под кат.

Оглавление

Этот же друг зная, что я пытаюсь создать игру уже третий месяц предложил мне портировать Катаву на iPad без Jailbreak. Выбор пал на smart BASIC, так как я пользуюсь этой программой уже полтора года и знаю синтаксис её внутреннего языка программирования (также у smart BASIC есть SDK для XCode).

Сразу же был скачан архив со всеми файлами игры кроме текста. Но ни он не я не знали, что это приведет к созданию своего движка для удобства разработки.

Акт 2. Разработка

1. Текст

Файл Katawa Shoujo Port.txt будет подгружать все скрипты.

Файл colorcodes.txt будет содержать RGB цвета имен для рендера, для примера возьму Сидзунэ и ее синее выделение:

Основные приготовления сделаны, теперь можно писать скрипт для показа текста. В Катаве, как и в любой визуальной новелле, текст показывается в поле, и над текстом пишется имя персонажа, от чьего лица этот текст.

За это будет отвечать скрипт speak.txt.

Для начала в файл load.txt я прописал загрузку спрайта bg-say.png (поле для реплик) и шрифта playtime_cyrillic:

После я решил использовать в скрипте сценария знак “|” как разделитель команды, цели команды, вторичной цели, действия и аттрибута.

Источник

Реверс-инжиниринг визуальных новелл (часть 2)

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

Прошло уже много времени с момента того, как мы научились разбирать архивы движка визуальных новелл Yuka, настало время взяться за самое интересное из того, что мы там нашли — собственно, скрипт. Забегая чуть-чуть вперед, сразу предупрежу, что скрипт, конечно, куда более сложная материя, чем просто архив с файлами, поэтому за одну статью нам с ним не разобраться, но сегодня мы попытаемся понять, из каких частей он состоит и получим доступ к текстовым ресурсам.

Перед тем, как погружаться в пучины бинарных дампов, давайте прикинем, как работают большинство движков визуальных новелл. Визуальная новелла сама по себе состоит из текста (реплик героев, диалогов, промежуточного повествования), графики и звуков. Для того, чтобы ее воспроизвести пользователю, явно нужно свести все это воедино с помощью какого-то управляющего воздействия. В теории можно было бы зашить это все прямо в exe-файл, но в 99% случаев (ладно, вру, в 100% виденных лично мной) так все-таки не делают, а хранят такие инструкции отдельно в виде отдельной программы-скрипта. Как правило, скрипт пишется на особенном языке программирования (специфичном для движка), который выглядит как-то так:

Это фрагмент исходника скрипта из одной VN на Ren’Py — одном из наиболее популярных свободных/бесплатных движков. Оставляя за рамками этой статьи вопрос, насколько хорош Ren’Py сам по себе, просто пока отметим, что же обычно входит в скрипт визуальной новеллы и что нам нужно будет найти:

еще бывают команды:

Разумеется, в реальном мире зачастую у нас не будет доступа к исходному коду скрипта. Люди уже лет 50 как научились писать компиляторы (в противовес интерпретаторам), поэтому обычно исходник скрипта компилируется в некий бинарный код (байт-код), который затем исполняется виртуальной машиной внутри движка визуальной новеллы. Иногда везет и для некоторых популярных движков есть легально или не очень легально доступные инструменты — отладчики, компиляторы, декомпиляторы, валидаторы скриптов и т.д, но чаще жизнь не бывает столь простой.

Всего 103 файла в YKS/all/. Напомню, мы абсолютно честно скачали и исследуем триальную версию — но, судя по всему, разработчики несколько поленились и, видимо, в trial/ лежит скрипт для триальной версии, а в all/ — для полной.

Вообще, исходя из минимального опыта, у строителей движков визуальных новелл есть 2 подхода: либо все пакуется в один гигантский файл, либо файлов много и в каждом из них какая-то своя сцена или событие. Тут похоже, что второе. Кроме того, есть еще отдельный ScriptStart.yks — но он как таковой скорее всего будет нам практически неинтересен: дело в том, что зачастую разработчики хотят сделать движок как можно более универсальным и реализуют всякие пользовательские интерфейсы, менюшки-загрузки-сохранения-опции и т.д. тоже средствами своего скриптового языка. Разбираться с этим можно, но довольно скучно и неплодотворно: поэтому предлагаю брать быка за рога и начинать с собственно сценария игры.

Что мы можем сказать из поверхностного визуального осмотра? Во-первых, т.к. игра работает под Windows, то ее вполне реально запустить и посмотреть, как это выглядит. Тратим n-ное количество времени, находим машину с Windows, запускаем, смотрим, что происходит сразу после нажатия кнопки начала новой игры:

Нас встречает вроде бы начало повествования. Здесь есть фон (после недолгих поисков в BG/ находится файл bg01_01.png с этим фоном), и есть текст. Этот текст нам еще понадобится, поэтому стоит его перенабрать с экрана:

Если есть проблемы с набиранием японского текста, могу порекомендовать освоить три-четыре приема, которые сильно упрощают это дело и при определенном терпении дают возможность набирать японские тексты тем, кто абсолютно не представляет, что же это за закорючки. Каждый значок рассматриваем по отдельности:

Текст нужен нам будет для двух вещей. Во-первых, собственно как текст — понять, что происходит (даже если не владеете японским — можно вставить в гугл-переводчик и понять, что нас здесь благодарят за скачивание триальной-версии этой игры => т.е. это еще не реальное начало сюжета, а некое вступление, «от автора»). Во-вторых, этот текст или его кусочек мы можем взять, сконвертировать в ShiftJIS (а скорее всего, как мы выяснили в предыдущей заметке, все будет именно в этой кодировке) и поискать его в файлах. Возьмем кусочек с конца и подготовим то, что будем искать:

Сделаем еще одно лирическое отступление: давайте ознакомимся с тем, как работает кодировка ShiftJIS. В японском языке, очевидно, значков сильно больше, чем в европейских: в ShiftJIS каждый из значков кодируется минимум 1 байтом, максимум 2. Как видно из этой таблички, значения байтов 00..7F совпадают с ASCII, а вот байты 81..9F и E0..EA означают, что это двухбайтовая комбинация, причем для совместимости опять же с бинарным чтением, второй байт будет иметь не какое угодно значение, а что-то между 40 и FF.

Микроэкскурс в японский язык: в языке используются 3 группы значков:

Что это дает нам в сухом остатке? Очень просто: частотную таблицу. Берем готовый скрипт первой попавшейся под руку визуальной новеллы на японском, быстренько подсматриваем в юникоде границы диапазонов всех трех групп и прогоняем на нем такой скрипт (простите за каламбур):

и получаем на выходе что-то вроде:

т.е. в типичном тексте будет

25% kanji, 65% hiragana и 10% katakana.

Базовый синтаксис шаблонов Kaitai Struct мы изучили в первой части статьи, поэтому, кто пропустил / подзабыл о чем речь — самое время с ним ознакомиться / освежить в памяти.

Итак, быстро смотрим на дампы 3-4 файлов и понимаем, что в качестве отправной точки нам подойдет такой шаблон:

Можно сразу провести аналогии с форматом YKC. Т.к. там в начале шло описание «заголовка», начиная с его длины, то с большой вероятностью фиксированные 0x30, встречающиеся в magic2 везде — это длина первоначального заголовка, поэтому предлагаю зачитывать сразу все до 0x30. Получается 7 чисел, сейчас будет пытаться угадывать, что это такое.

Для Yoyaku.yks (сам файл 27741 байт):

Для trial_00100.yks (файл 91267 байт):

И, для сравнения, какой-нибудь файл из all, например all_00010.yks (12968 байт):

Что видно? Во-первых, это все эпично похоже на смещения или размеры в файле, т.к. при размере файла в 91K числа плавают в районе 25-63K, а при размере в 12K — в районе 3-9K. При ближайшем рассмотрении, смещения и размеры скорее всего только unknown2, unknown4, unknown5 — они делятся на 4 и достаточно большие. Во-вторых, unknown7, кажется, всегда 0. В-третьих, unknown6, видимо, задает что-то очень штучно-считаемое. Это может быть, например, размер области зарезервированной памяти виртуальной машины под переменные, число сменяющихся сцен/спрайтов/бэкграундов или еще что-нибудь такое.

Сразу за 0x30 даже невооруженным глазом в людом хекс-редакторе видна таблица возрастающих (или почти всегда возрастающих чисел). Вряд ли это сам байт-код: для байт-кода характерно как раз постоянное повторение одних и тех же последовательностей. Это тоже скорее всего какие-нибудь смещения — например, это могут быть смещения, определяющие начала команд в байт-коде, или какие-нибудь начала-концы строк переменной длины или что-нибудь еще такое. У нас есть 7 unknown-значений, это не так много — давайте переберем и посмотрим, похоже ли одно из них:

Практически первая же попытка подходит очень неплохо: unknown1 оказывается количеством элементов в этом разделе, а unknown2 оказывается указателем на начало следующего раздела. И, таким образом, похоже, что на практике unknown2 = 0x30 + unknown1 * 4. Добавляем сразу описание, заодно перенеся заголов в явно выделенный тип header, а открываемые секции начинаем называть sect1..sectX:

В итоге trial_00100 начинает выглядеть вот так:

На самом деле теперь уже заметно, что это не просто возрастающие значения — это вполне может быть байткодом. В этом файле заметные возрастающие числа идут, видимо, от 0 или 1 и в итоге увеличиваются до 2375. Внезапно, unknown3 = 2376 — очень похоже на число этих самых значений. Т.е. байткод ссылается на еще одну какую-то таблицу, в которой 2376 различных значений (видимо, от 0 до 2375 включительно). Что же это может быть?

Смотрим на следующую секцию, просмотрев что там бывает на экрана 3-4 вперед:

По-моему, более-менее очевидно, что это записи по 16 байт (1 строчку) длиной, причем в них есть опять же что-то поразительно похожее на явно постоянно неравномерно увеличивающиеся смещения или индексы. Будет ли таких записей 2376? Проверяем, переименовая unknown3 в sect2_qty и добавляя тривиальный кусочек, чтобы собрать sect2 из 16-байтовых записей:

и, кажется, бинго, это оно и очень точно:

Невооруженным глазом хорошо видно, что эти самые стройные 16-байтовые записи действительно кончаются ровно после sect2_qty штук и дальше начинается уже что-то совсем другое. Что мы тут видим? Это явно не длинные 4-байтовые числа, примерно все ненулевое. Какой-то явно периодической структуры тоже не прослеживается, по крайней мере на первый взгляд. Обилие 0xaa. Много 0x28, чередующихся через раз. Смотрим в конец файла, пытаясь обнаружить еще какие-то секции — кажется, нет, в конце примерно такая же фактура:

Вообще есть даже «тяжелая» артиллерия в виде программ типа XORSearch, которые пытаются угадывать такие преобразования перебором, но тут все еще банальнее и у меня получается угадать со второго раза. Обилие 0xaa позволяет предположить, что там много нулей, которые XOR’ятся с 0xaa, что дает 0xaa. А внезапно 0x82 ^ 0xaa как раз равно 0x28. 0xaa — вообще одно из самых банальных предположений, которые стоит проверять по хорошему в первую очередь, т.к. 0xaa = 0b10101010, т.е. xor с ним тупо переворачивает каждый второй бит.

после чего мы, наконец, сможем наблюдать богатый внутренний мир строковых констант наших подопечных скриптов:

Подытожим, что у нас получилось:

На этой маленькой победе, думаю, мы завершим наши сегодняшние изыскания, так как статья очередной раз получается неприлично большой. В какой-то степени — если, например, стоит задача перевести визуальную новеллу — достигнутого сегодня уже достаточно для того, чтобы выдрать тексты и отдать их переводчикам. Берем sect3, находим в ней все, что похоже на SJIS, аккуратно выбрасываем все остальное — вуаля:

Спасибо всем, кто дочитал до этого места. В следующий раз мы доберемся до собственно байткода и попытаемся понять, как устроены sect1 и sect2. До встречи!

Источник