В этом (2022) игре "Шторм" ("Echelon") исполнился 21 год. Являясь представителем довольно редкого жанра фантастического авиасимулятора, игра практически не имеет конкурентов, однако 21 год не пошёл на пользу. Хотя на некоторые скриншоты ещё приятно смотреть, в самой игре "туман" и размытость прямо-таки бросаются в глаза, да и запустить игру на современных ОС является тем ещё квестом. Идеальным решением был бы римейк на современном движке (к примеру, Unity или Unreal Engine), но это требует серьёзной работы.
В тестовых целях была проверена возможность переноса ресурсов в Unity с положительным результатом, но вряд ли автор этого руководства доведёт проект до завершения. Впрочем, это не исключено, однако если кто-то воспользуется этими наработками и самостоятельно сделает такой римейк, автор будет только рад.

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

Файл описания карты. Этот самый маленький файл (644 байта) из всех файлов описания карты содержит описание карты:

• uint32 ширинаКарты
  
• uint32 высотаКарты

Последующие данные не опознаны.
Высота и ширина карты указаны в блоках по 128 пикселей.
К примеру, в карте Continent (это карта кампании оригинального "Шторма") указаны размеры 2A 00 00 00 и 2F 00 00 00. Числа в файлах игры хранятся в little endian, поэтому меньший байт числа впереди, таким образом размер карты получается 42x47 блоков 128х128 пикселей. Итого размер карты получается 5376 x 6016 вершин. Кстати,именно такое разрешение имеет и bmp файл с картой континента в "Шторм:Солдаты неба"

В файлах вида *.l01 сохранены предварительно рассчитанные тени.
Вершины в карте сгруппированы в блоки 16х16 вершин, элементом является:

• char картаВысот1
  
• char картаТеней1
  
• char картаВысот2
  
• char картаТеней2

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

Формат полностью соответствует таковому для .l* файлов

В файлах .sq содержится основная геометрия карты.

Данные в файле .sq сгруппированы в блоки по 32х32 вершины.
Элементом такой группы является:

• short картаВысот
  
• usort Флаги

Всё карты "чёрно-белые", раскрашены для удобства - у каждого значения свой собственный цвет.



Флаги точки карты.
В флагах перечислена проходимость этот точки карты, тип поверхности (НЕ текстура)и признак симметричности. Из флага нужный параметр можно извлечь при помощи битовых операций:

• проходимость (PASS_MASK) XOR 0x1800
  
• симметричность SQF_SIMMETRY (1<<15);
  
• SQF_GRMASK тип поверхности 0x07

Во флагах указан именно тип поверхности. Соответствие текстуры и типа поверхности можно найти в описании файла .vb
В оригинальном "Шторме" есть всего 8 типов поверхности:
WATER=0,SAND=1,DESERT=2,GROUND=3,GRASS=4,ROCKS=5,SNOW=6,PEAK=7

В файле .vb хранятся несколько субкарт с не совсем понятным предназначением.
Данные сгруппированы в блоки по 16х16 вершин, на каждую вершину используется 16 байт таким образом один блок 16х16 вершин содержит информацию о текстурах для 4 блоков вершин геометрии.
Элементом данных является:

• char неизвестнаяКарта1
  
• char неизвестнаяКарта2
  
• char неизвестнаяКарта3
  
• char неизвестнаяКарта4
  
• char неизвестнаяКарта5
  
• char неизвестнаяКарта6
  
• char неизвестнаяКарта7
  
• char неизвестнаяКарта8
  
• char картаТекстур
  
• char картаТекстур2?
  
• char неизвестнаяКарта9
  
• char неизвестнаяКарта10
  
• char неизвестнаяКарта11
  
• char неизвестнаяКарта12
  
• char неизвестнаяКарта13
  
• char неизвестнаяКарта14

Назначение карты неизвестно

Назначение карты неизвестно

Назначение карты неизвестно. На картах "подкрашена" область учебного центра. Зачем - неизвестно.

Карта текстур. Есть всего 32 текстуры:

Каждая текстура относится к определённому типу поверхности. Всего типов поверхности 8:
{WATER=0,SAND=1,DESERT=2,GROUND=3,GRASS=4,ROCKS=5,SNOW=6,PEAK=7}
Карта "чёрно-белая", раскрашена следующим образом:

Назначение карты неизвестно. Содержимое похоже на карту текстур, но "разбавлено" FF. Предположительно - поворот или смешение текстур.

Назначение карты неизвестно.

Ресурсные файлы игры можно разделить на три основные группы:
1. Файлы ресурсов
Это собственно файлы ресурсов. Характерным примером может могут быть файлы карты
2. Набор ресурсов
Это файл, содержащий в себе файлы ресурсов
3. База данных
Это файл, содержащий в себе базу данных. Формат свой собственный, кроме собственно данных может содержать набор ресурсов.

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

Набор ресурсов содержит один или более файлов ресурса. Расширение файла может быть любым, в оригинальном "Шторме" это .dat и .sfx, однако .dat файлом может быть и файл базы данных, поэтому ориентироваться стоит по первым четырём байтам файла.
Первые четыре байта могут быть различными, однако наборы ресурсов кодируются одним способом:

Это "волшебные данные", указывающие на тип набора ресурсов, к примеру DSFX,DATA или TEXS. Особо на этот параметр не стоит обращать внимание, главное чтобы не был EVG1 (это файл базы данных)

Количество ресурсов в наборе

Размер блока данных ресурсов

Размер блока имён ресурсов


Идентификатор ресурса. Он будет часто использоваться как ссылка на ресурс в других файла. Получается из crc32(resourceName) XOR -1 (хотя использование этого в других ресурсах я не нашёл). Уникален в пределах одного набора ресурсов.

Отступ в блоке списка имён ресурсов (см.далее)

Отступ в блоке данных ресурсов (см.далее)

Размер ресурса

• BYTES[dataSize]

Просто блок идущих подряд байтов.

• BYTES[nameSize]

Просто блок идущих подряд байтов. Имена разделены NULL символом (0x00)

Файл базы данных содержит в себе собственно базу данных в собственном формате.
Файл БД легко определить по первым четырём символам EVG1

• String[4] magic
  
• uint32 RATSize

Идентификатор файла. Должен быть EVG1

Размер таблицы размещения записей

• uint32 recordID
  
• uint32 recordSize

repeat until <RATSize

Индекс записи

Размер записи

Блок MIKH следует за таблицей размещения записей и содержит собственно записи

• magic
  
• dataSize

Идентификатор блока. Должен быть именно MIKH

Размер блока данных

Bytes[dataSize]

Сама БД представляет из собой связанный список, начинающийся с 1 элемента. Элемент 0 это NULL элемент.
Запись rec выглядит как:
Тип записи
Индекс ресурса со значением

Элемент может быть (в зависимости от значения type):

• Ассоциативным массивом (type A8FA05F7)
  
• Простым массивом (type 3F776657)
  
• Набором данных (type AA0E7175)
  
• Целым числом (type B9969518)
  
• Дробным числом (type 1DC7CF3F)
  
• Строкой (type AF3C29AF)
  
• Вектором (type 5DC6F92A)
  
• Данными миссии (type A05F049E)

Количество элементов в массиве

Элемент массива

Смещение в списке ключей

Список ключей. Представляет из себя просто строку, разделённую NULL (0x00) символом

Не сильно отличается от ассоциативного
Количество элементов в массиве

Элемент массива

См. описание формата файлов набора данных
Используется редко - в файле кампании используется в карте дорог

Целое число (в формате little endian)

Дробное число

Строка в кодировке CP1251. Встречается, впрочем, и CP866

Просто набор из трёх координат в дробных числах

см. Ассоциативный массив.
В описании миссий юниты указаны в виде 4-байтового идентификатора, не совпадающего ни с чем. Как выяснилось, идентификатором является имя из набора ресурсов gdata.dat, подвергнутого crc32 XOR -1
Пример:
В миссии C1-1 (это первая миссия в ветке пропуска обучения первого Шторма) группа "Альфа" в первом юните содержит значение поля "Name" -2142616657.
Смотрим поле Flag (описание этого поля будет отдельно) - в нём 3907. Смотрим 5-8 биты. В 1 установлен 6-й бит, значит это Craft. Перебираем каждое название (именно название, т.е. из блока Craft("CHORT_V_STUPE") берем "CHORT_V_STUPE") из этого файла, используя следующую функцию crc32(name) XOR -1. Получаем совпадение со строкой "Human_BF1", таким образом в группе "Альфа" первый юнит это Human_BF1 (BFF1-112 Tempest)

Этот набор ресурсов содержит модели. Только модели, без текстур.
Каждая модель состоит из:

• Файла метаданных
  
• 1-4 Файла описания вершин
  
• 1-4 Файла описания полигонов

Каждая модель может иметь один или несколько вариантов. Судя по их внешнему виду - зависит от повреждения. В основном используются три варианта отображения - "целый", "повреждённый" и "уничтоженный", но у мешей кабин есть ещё один вариант отображения - "вид изнутри"

Файл метаданных выглядит как имя_Im0 (варианта - _Im1,_Im2).
Имеет следующий формат:

• uint32 header
  
• uint32 lod0
  
• uint32 lod1
  
• uint32 lod2

Заголовок, всегда 0.

Идентификатор (см. описание файлов набора ресурсов) файла уровня детализации 0

Идентификатор (см. описание файлов набора ресурсов) файла уровня детализации 1

Идентификатор (см. описание файлов набора ресурсов) файла уровня детализации 2

Значение идентификатора может быть FFFFFFFF. Это означает, что такой уровень детализации у модели отсутствует.

Этот обычно самый большой файл может иметь разное имя (но обычно заканчивается на _Vert00), однако формат его прост:

• float32 x
  
• float32 y
  
• float32 z
  
• float32 norm_x
  
• float32 norm_y
  
• float32 norm_z
  
• float32 u
  
• float32 v

Координаты вершины.

Координаты нормали.

Текстурные координаты. Хотелось бы отметить, что в некоторых случаях потребуется "переворачивать" либо текстуру либо вертикальную (u) текстурную координату.

Этот файл содержит нужные для создания модели данные.
Формат по сравнению с остальными сложен

Заголовок, всегда 0

Количество групп блоков данных в модели (число субмоделей)

Назначение неизвестно.

Назначение неизвестно. Предположительно - изменение размеров или поворот

Идентификатор из соответствующего object файла. Назначение неясно

Заголовок блока материала. всегда 0

Идентификатор текстуры из набора ресурсов textures.dat

Идентификатор материала из набора ресурсов materials.dat

Заголовок блока описания вершин группы (04 00 00 00).

Номер группы.

Смещение индекса вершины для текущей группы.

Количество вершин в группе

Количество индексов в группе

Заголовок блока описания вершин (12 01 00 00)

Общее число вершин в файле вершин

Идентификатор ресурса вершин в наборе ресурсов mesh.dat

Индексы

Небольшое пояснение. Под "Группой" в этом разделе подразумевается "Субмодель". К примеру, в грузовике есть две субмодели - сам грузовик и его водители. Вершины модели идут сплошным потоком - для примера a b c d e f G H I (большими буквами - вершины, относящиеся к водителям). В этом случае blk_count в файле будет 2 (т.е две субмодели), для группы 0 (сам грузовик) смещение будет 0, для группы 1 (водители) смещение будет 6
Таким образом, при генерации модели для группы 0 ничего смещать не надо, для группы 1 к полученному индексу потребуется добавить groupVertOffset. Впрочем, можно генерировать модель грузовика отдельно от модели водителей - в этому случае смещение можно не использовать.

Этот набор ресурсов содержит иерархию отдельного юнита. В терминах игры "юнитом" является любой объект на карте, к примеру - крафт игрока, танк, мост или статуя Владычицы Озера (серьёзно, кто ещё может быть женского пола в Новом Авалоне? Моргана?).
Иерархия блоков представляет из себя связный список. Каждый следующий блок в списке потомков "родительского" блока прописан в предпоследнем dword Mesh_block, последний dword указывает на блок-потомок текущего блока.
Файл иерархии состоит из следующих элементов:
Блок слота. Слотом является место "крепления" другого юнита к текущему юниту. Характерным примером является слот оружия на крафте, турель на авианосце или выхлоп из дюзы.
Имеет следующий формат:

Slot_Block 0x30 bytes
• u4le unknown
  
• u4le blockId
  
• u4le blockIndex
  
• Vec3 localPos
  
• 6*4 bytes unknown

Блок описания субмодели юнита. Собственно, отдельная видимая часть юнита.
Имеет следующий формат:

MeshData_block 0x24 bytes
• u4le meshId //идентификатор модели. StormCRC32 от имени файла.
  
• u4le meshId
  
• 7*4 bytes unknown

Блок элемента юнита. Собственно, отдельная видимая часть юнита. Именно к ней "привязаны" слоты. Блок _обязательно_ содержит 4 блока MeshData_block - это "варианты" отображения блока. В основном это варианты вида "блок целый", "блок повреждённый", "блок разбитый", четвёртый вариант встречается редко - в основном это "детальные" (ну, тогда детальные - текущий момент детальность так себе) внутренние виды кабины.
Имеет следующий формат:

Mesh_block 0xC8 bytes
• u4le unknown
  
• u4le blockId
  
• u4le slotCount //количество слотов на текущеё субмодели
  
• Vec3 localPos
  
• 6*4 bytes unknown
  
• 4xMeshData_block
  
• u4le next_Mesh_block_offset //относительное смещение
  
• u4le child_mesh_block_offset //относительное смещение

Структура самого файла проста:

• 0xC8 bytes Mesh_Block
  
• 0x30*slotCount Slot_Block
  
• repeat until EOF