OpenGoW

OpenGoW: Прогресс за ноябрь

Автор:

Наконец-то добрался до разбора основных классов, тут о них и расскажу. Кстати, информация ниже в большинстве своем является моими не особо опытными догадками и размышлениями, поэтому дополнения и поправки приветствуются в комментариях.

Структура движка


Как и у большинства других прослоек между играми и игроками, в God Of War (Kinetica, Jak II+3+X, The Getaway, SOCOM I+II, FantaVision - другие игры на этом движке) движок поделён на сущности. А этими сущностями управляют их соответствующие центральные классы со своими гигантскими методами Update. Так вот тут эти классы называются серверами (упоминания слово "сервер" как паттерна я не нашел. Ближайшим аналогом являются Manager классы из библии авторства Jason Gregory), по своей сути являются они смесью одиночки и фабрики.
+ На самом деле все немного сложнее

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


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

Итог


Игровой движок в роликах о создании игры позиционировался как очень гибкий. Что мы и видим, ведь, допустим, заменив привязанные к железу сервера, можно с минимум последствий перенести игру на другую платформу (соответствующие ресурсы придется перекомпилировать), что мы и скорее-всего и наблюдали при перевыпуске gow на ps3 и ps4. Еще заявлялось о гибкости для гейм-дизайнеров и художников, что видимо вытикает в то что большая часть игры (за исключением требовательных к скорости мест) лежит в игровых архивах.

Благодарности


Большое спасибо nonamezerox за помощь и наводки в нужном направлении.

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

todo


Основными целями сейчас исследование внутренностей. В идеале нужно разобрать форматы файлов от младшего к старшему (GFX > TXR > MAT > MDL), но пока выходит не очень ладно из-за наличия второстепенных классов и кучи интересных особенностей приставки ps2

#god, #god of war, #opensoure, #PS2, #reverse, #движки

24 ноября 2016

Комментарии [4]