Поддержка файлов игры с закрытым кодом

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

Очень важно знать алгоритмы для построения траекторий набигания домиков

А как их можно узнать? Должны же быть какие то программы.

Задача коммивояжера, если про «огибание».

А про «набигание» почитай Лурку.

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

Какой игры?

пароли с кошельков будет собирать

Очень старенькая игра, единственное что на неё есть, это плагин на 3ds max 8, и на totalcommander

Блин, ты название можешь сказать? Я не телепат.

Vietcong, думаю ты не знаком с ней.

стопудов не знаком, он вообще нихрена не знает

Может вы что подскажете?

Если правда хочешь увидеть эту игру на новом движке в ближайшие ~5-6 лет, забудь про написание собственного. Используй Unity или Unreal. Посмотри, какие в оригинале используются форматы контента. Скорее всего это что-то распространённое, но каким-то образом запакованное / зашифрованное. В литературу нет смысла углублятся, в интернете полно статей про бинарные форматы и их реверс-инженеринг. На хабре точно с десяток видел, недавно про один из форматов 3d-моделей. Перегони весь контент в подходящий для выбранного движка и начинай воссоздавать уровни. Потом код, скрипты... Если лет за 5 успеешь, будет большим успехом.

И вообще, судя по вики, для этой игры есть мощный редактор карт для создания дополнений с функцией экспорта 3d-моделей в 3d-max. Я уверен, это редактор умеет разбирать и все остальные ресурсы игры и позволять их редактировать. Мне кажется, это всё, что тебе нужно.

Нет, дело в том, что сам движок игры имеет нестабильности, к тому же его нету на Linux. Кстати, почитал немного про реверс-инженеринг, мне кажется это то что нужно, спасибо.

Я реверсил некоторые форматы игр, правда до3Dшной эпохи, поделюсь соображениями.

Обычно нужен только мозг и hex редактор - смотришь на байтики, мозг сам видит закономерности и повторяющиеся структуры. Видишь повторяющиеся структуры, смотришь чем они различаются, становится понятно что они есть. Для поиска различных bitmap данных (несжатые картинки, текстуры, карты высот и т.д.) помогает открыть бинарник в gimp с типом файла = raw (остаётся подобрать ширину). Можно действовать и обратно - зная данные искать их в файле (например, у юнита 2600 здоровья и 300 брони, ищем эти числа рядом, находим таблицу с типами юнитов). В DOS играх таким способом, если не было компрессии, явной обфускации или куски данных не были зашиты в код, там можно расковырять всё.

Если ресурсы игры лежат в одном файле непонятного формата, на 99% в начале его будет к-во ресурсов, а потом таблица ресурсов содержащее как минимум смещение и размер (часто также название, что сильно помогает) для каждого - пишем распаковывалку за десять минут, смотрим на отдельные файлы. Натравливаем file, strings. С неизвестными смотрим на размер: файлы одного размера это сигнал, файлы красивого размера большой степени двойки (65536, 131072, 196608) скорее всего битовые карты, т.е. текстуры, спрайты, карты высот, изображения для миникарты и т.д. (в данном случае с большой вероятностью 256x256 картинки с палитрой, 16битным либо прозрачность+палитра, RGB цветом соответственно). Не забываем про палитру, 66304 байт например это 256x256 картинка + 256*3 палитра. Бывают свои хитрые форматы*. Над неизвестными файлами начинаем медитировать начиная с самого маленького.

Если не получается, берём в руки отладчик. На первом уровне не нужно даже знать ассемблер, ставим breakpoint на DOS прерывание чтения файла (а можно ещё проще, запустить dosbox под ktrace или systrace (или как там это в linux)), и смотрим какого размера блоки читаются → уже имеем представление о структуре файла. На самый крайний случай оставляем дизассемблер - я лично им реверсил только алгоритмы декомпрессии.

Насчёт более поздних игр (windows и cdrom эпоха) могу сказать что байты экономить перестали, зато стали экономить время разработчиков, поэтому форматы упростились - с большой вероятностью можно встретить широко известные форматы (tga, bmp, gif для текстур, wav, pcm и всякие древние кодеки, file о них знает а mplayer даже играет, zlib и zip компрессия, plaintext и т.д.). Не имел дела с 3D, нужно вспомнить какие в то время были популярны форматы для моделей и анимации - что-нибудь типа формата из первокваки который изучен вдоль и поперёк. Если формат моделей свой, берём hex редактор, и вперёд - для статичных моделей ничего принципиально нового изобрести нельзя, будет что-то типа: [число вершин][x y z]{* число вершин}[число треугольников][n1 n2 n3]{* число треугольников}, координаты скорее всего во float, вариации включают формат вершины - x y z, x y z w, наличие нормали, текстурных координат и т.д. Как хранят анимацию честно говоря не знаю - наверное набор вершин множится для каждого keyframe + данные о последовательности keyframe и таймингах.

Ещё можешь посмотреть http://rewiki.regengedanken.de/wiki/Main_Page - там примеры форматов игр, возможно какая-нибудь документация и ссылки на инструменты.

Если разберёшь формат, напиши лучше сначала библиотеку для его разбора - будет чище, проще, и если ты не осилишь последователям будет откуда продолжить. За совет Unity или Unreal я бы в лицо плюнул, естественно нужно брать свободный движок (ogre/irrlicht/osg например, см. openmw) - ремейк хорошей игры обязан быть полностью свободным, а проприетарный крап ничем не лучше оригинального глюкалова в dosbox или wine.

* Так просто в качестве примера, в commandos текстуры хранились интересно. Точно правда уже не помню. Цвет хранился в несжатом виде, 1байт/пиксель + палитра, а прозрачность, которой было всего 3 уровня (прозрачно/непрозрачно/полупрозрачно) была RLE сжата, и всё это было перемешано. Типа [непрозначно * 3 пикселя][цвет][цвет][цвет][полупрозрачно * 2 пикселя][цвет][цвет][прозрачно * 3 пикселя](для прозрачных цвет не хранился)х[непрозрачно * 3 пикселя][цвет][цвет][цвет] и т.д. Чтобы понять это тоже было достаточно помедитировать в hex редактор.

ТС, не теряй зря время, ничего у тебя не получится пока, поскольку игровой движок штука сложная, а вопросы твои детские. Класс эдак 5-ый.

Все ответы на твои вопросы такие:

то есть архив с моделями, текстурами, звуками

Бери самые простые и популярные форматы, например obj, mtl, flac/wav, png/jpeg. Если надо чтобы из не скопировали, шифруй асимметричным шифрованием, если надо чтобы не подменили проверяй электронную подпись.

Ближе к делу: что нужно знать, посоветуйте знакомую вам литературу на эту тему.

Надо знать C++, C, OpenGL/DirectX, теорию, математику (не простую, а сложную, ВУЗовскую, про всякие матрицы и т.д.), геометрию, физику, компьютерную графику. Начинай с Порева, только потом почитай что-нибудь по современному OpenGL/DirectX.

После написания примитивного и не оптимизированного движка тебе станет более-менее понятна ситуация.

Очень старенькая игра,
плагин на 3ds max 8

Прекращайте делить на ноль.

А по теме, если у вас возник такой вопрос, то вам нужно начать с азов.

Бери самые простые и популярные форматы, например obj, mtl, flac/wav, png/jpeg.

Если надо чтобы из не скопировали, шифруй

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

Ну а я осмелюсь безответственно (в том смысле, что расхлёбывать придётся не мне) посоветовать автору поковырять Qt3D. Он достаточно высокоуровневый, дурную работу, вероятно, удастся, свести к минимуму. Вряд ли подойдёт для современных YOBA-игр, но чтобы вдохновить жизнь в ресурсы игры 2003 года, вполне возможно, его и хватит.

Но разумеется:

• придётся подтянуть C++, хоть там и есть скриптование;
• придётся позаниматься ковырянием форматов, о чём выше толково написал slovazap.