После нескольких месяцев работы над исходным кодом игры «Казаки: Снова война» я наконец-то могу умыть руки и представить результат своих трудов. В этой статье мне хотелось бы поделиться с вами опытом рефакторинга этого незаурядного проекта, в частности кодовыми курьёзами. Всем любителям некро-программирования посвящается…
Начало
Первое и одно из самых неприятных препятствий было не в коде, а в самих проектах. Всего их четыре:
- статическая библиотека CommCore.lib (сетевой протокол GSCp на базе UDP)
- динамическая библиотека IntExplorer.dll (игровое лобби на сервере)
- динамическая библиотека IChat.dll (чат в игровом лобби)
- исполняемый файл dmcr.exe
И эти ребята повидали некоторого кода! Из-за круговой зависимости между проектами IChat.dll и dmcr.exe для линковки требуется хотя бы один lib-файл из предыдущей сборки. Сами файлы проектов неверно конвертируются в Visual Studio 2015: они содержат ссылки к библиотекам, которые не отображаются в свойствах проекта, абсолютные пути к файлам в системе одного из разработчиков и прочие сюрпризы. В конце концов мне надоели танцы с бубнами, и я создал все проекты заново, попутно узнав, что в архиве присутствуют лишние файлы с устаревшим исходным кодом, который при включении в проект приводит к конфликтам. Ну и куда уж тут без особенностей линковки, для которой обязательно нужно исключить libc.lib.
Стартуем
Так, с проектами разобрались, теперь можно браться за дело. Компилятор рад за нас и приветствует множеством ошибок C2065: необъявленный идентификатор. Смотрим код и видим повсюду такую картину:
for (int i = 0; i < max1; i++) { /* Цикл №1 */ }
for (i = 0; i < max2; i++) { /* C2065 */ }
//Или такую:
for (int i = 0; i < max && arr[i] != value; i++); /* Пустой цикл для поиска индекса */
if (i < max) { /* Есть совпадение в массиве. И C2065 тоже есть */ }
Конечно, можно было бы выставить /Zc:forScope- и забыть об этом, но мы же не кочегары и не плотники. Правим ручками больше сотни таких отрезков кода, продолжаем.
Следующее препятствие заключалось в графическом элементе, точнее в DirectDraw 7. Он активно использует механизм замены системной палитры. И если ранее это было повсеместной практикой, то начиная с Windows Vista такие фокусы больше не проходят. Дело в том, что DWM вместе с Windows Aero вплотную работают с палитрой и не терпят конкуренции. В итоге множество старых игр страдают от искажения цветов.
Не являясь экспертом по DirectX, я стал искать готовое решение и нашёл его в версии «Казаков», опубликованной на Steam в 2010 году. Помимо самой библиотеки ddraw.dll в папке с игрой присутствует дополнительная библиотека mdraw.dll, которая экспортирует функцию инициализации DirectDrawCreate(). Скажу честно – я не знаю, что именно ребята из GSC написали в их библиотеке DDemu DirectDraw Emulator в 2008 году, но она прекрасно справляется со своей задачей. Недолго думая я добавил соответствующую обёртку в Ddini.cpp и забыл об этой проблеме.
Затем встал вопрос об отладке полноэкранного приложения. Здесь мне снова повезло – в коде был предусмотрен отладочный режим, в котором игра запускалась в углу экрана в безрамном окне с фиксированным размером. Мне требовалось лишь довести его до ума, добавить смену разрешения, обработать захват и возврат курсора в зависимости от того, в меню ли игрок или в активной игре и добавить соответствующие параметры при старте. Теперь можно было удобно запускать игру в отладчике с ключом /window.
Весёлая арифметика
Одной из моих целей было добавление настроек для многопользовательских игр, например, возможность отключать дипломатический центр и рынок или ограничивать доступные корабли в верфи. Расширив интерфейс игровой комнаты и добавив нужные ветки в коде, я увеличил массив PlayerInfo.UserParam[], в котором хранятся эти настройки, с семи до десяти элементов. Вот только протестировать новые опции никак не получалось — при старте игры ИИ начинал распоряжаться моими крестьянами вместо своих и играть за меня, при этом его крестьяне стояли неподвижно. Весело, но так не пойдёт.
Причина такого поведения ИИ крылась в следующем финте ушами при копировании настроек от хоста игры в буфер обмена:
//PlayerInfo PINFO[8];
//byte* BUFB = (byte*) ( BUF + 10 + 8 + 32 - 10 );
memcpy( BUFB, PINFO[HostID].MapName + 44 + 16, 16 );
А вот так декларирована структура PlayerInfo:
#pragma pack(1)
struct PlayerInfo {
char name[32];
DPID1 PlayerID;
byte NationID;
byte ColorID;
byte GroupID;
char MapName[36 + 8];
int ProfileID;
DWORD Game_GUID;
byte UserParam[7];
byte Rank;
word COMPINFO[8];
//… (ещё 12 элементов)
}
Как видим, по смещению MapName + 60 находится COMPINFO[8]. Соответственно, при увеличении массива UserParam[7] вызов memcpy() промахивается, и в буфер попадают неверные данные о том, за каких игроков должен играть ИИ. Проблема решается заменой офсетной математики на прямое обращение по адресу PINFO[HostID].COMPINFO.
В итоге я всё же принял решение не трогать UserParam[], а добавить массив UserParam2[3] в конце структуры, так как в одном из последних элементов хранится версия клиента и любое изменение структуры до него чревато неверным определением версий в игровом лобби. А так игроки с версией 1.35 будут видеть, что у других обновлённая версия игры.
Какие уроки можно почерпнуть для себя из этого?
- В структуре, передающейся по сети, первым элементом должна быть версия клиента.
- Никогда не исходить из того, что расположение структуры в памяти будет неизменным.
- Писать функции сериализации, а не полагаться на #pragma pack(1) и побайтовое копирование.
Невидимый Джо Дефайн
Разбираясь с механикой отображения внутриигровых текстовых сообщений с целью увеличения времени отображения и максимального количества сообщений на экране, я наткнулся на занимательную константу:
#define SIGNBYTE ''
void ShowCharUNICODE( int x, int y, byte* strptr, lpRLCFont lpr ) {
if (strptr[0] == SIGNBYTE) { /* юникод */ }
else { /* ascii */ }
}
«Ну и что в этом такого? — спросите вы — Всего лишь пробел в качестве константы». Ну, во-первых, пробел был бы крайне странным выбором для идентификации чего-либо в строке текста, а во-вторых это вовсе не пробел. SIGNBYTE определён как 0x7F, или управляющий символ DEL. И если ваш браузер достаточно осмотрителен и хотя бы показывает, что между кавычками что-то есть, то Visual Studio 2015 вероломно рисует '', между которыми курсор «спотыкается» на один символ.
Пожалуйста, если уж вы используете непечатаемые символы, то указывайте их в коде через шестнадцатеричное значение, а не как символ.
Правовой аспект
Всякий раз удивляюсь, когда для запуска игры требуются права администратора. И всякий раз думаю что-то вроде «ну как так можно игры программировать-то». Но в этот раз у меня и код на руках был, и собирал его я сам, а окно UAC всё так же не давало мне покоя.
Ответ нашёлся совершенно случайно, когда я подумал, что неплохо было бы вписать в свойства исполняемого файла информацию о том, что эта версия игры не оригинальная и не поддерживается разработчиками. Манифеста в проекте, естественно, не было, но был файл ресурсов Script1.rc. Каково же было моё удивление, когда после изменения блока VS_VERSION_INFO игре перестали требоваться права администратора!
Оказывается, ОС Windows начиная с Windows Vista применяет эвристический алгоритм для определения приложений, которым может потребоваться повышение привилегий. Называется эта функция «Технологией обнаружения установщика» (см. статью в ИТ-центре Windows), и обычно она реагирует на ключевые слова вроде install или setup. Но в нашем случае виновником оказался параметр CompanyName — если он содержит строку "-GSC-\0", то просыпается UAC и требует прав администратора.
Как уберечь своё приложение от такой эвристики со стороны Майкрософт, существующей и грядущей? А никак. Сегодня вы разрабатываете игры, а завтра уже стоите в одном ряду с Inno Setup и InstallShield.
Партизанский sscanf()
На этот баг я наткнулся, когда после добавления дополнительных настроек игры при проигрывании записей прошедших игр возникала ошибка синхронизации, т.е. запись не шла по тому руслу, по которому развивалась игра. При этом ошибка появлялась, по всей видимости, случайно и я долго не мог найти причину.
Опущу скучные детали отладки и перейду к самому соку. Настройки игры, вид карты и данные о выбранных нациях передаются через имя файла случайной карты, которое имеет формат
- RN0: префикс RN и размер карты (0 — 2)
- 1A3C: значение ГПСЧ для инициализации случайной карты
- 12345: Вид карты (ландшафт, горы, месторождения и пр.)
- 0KFH31CJ: Нации, которые выбрали игроки (0 — K)
- 4501326: Настройки игры (Артиллерия, PT и пр.)
А теперь посмотрим на отрезок кода, который обрабатывает настройки игры, считывая имя файла случайной карты при загрузке записи игры:
int v1, v2, v3, ADD_PARAM;
char ccc[32];
int z = sscanf( Name, "%s%x%x%x%d", ccc, &v1, &v2, &v3, &ADD_PARAM );
if ( z == 5 ) { /* Интерпретация настроек из ADD_PARAM */ }
Загвоздка здесь в том, что для четвёртой переменной указан тип %x, в то время как диапазон символов в ней выходит за рамки шестнадцатиричной системы и простирается до буквы K. Если в игре присутствуют игроки, которые выбрали нации с индексом выше F, то sprintf() преждевременно закончит парсинг и вернёт 4. Параметры не будут интерпретированы, у ИИ будет неправильная информация об игре и он будет принимать другие решения, что приведёт к рассинхронизации.
В дополнение к этому идёт тот факт, что sprintf() вызывается исключительно для ADD_PARAM — остальные переменные нигде не используются. Решение проблемы относительно простое:
int options = 0;
int z = sscanf( Name, "%*s %*s %*s %*s %d", &options );
if ( 1 == z ) { /* Интерпретация настроек из ADD_PARAM */ }
Флаг * указывает функции, что значение не следует сохранять в переменной. Кстати, пoсмотреть, каким образом я реализовал кодирование 10 игровых настроек на месте тех же 7 цифр можно здесь. «Зачем?» — спросите вы. А потому что менять длину строки с именем файла карты по своему усмотрению показалось мне не очень хорошей идеей (см. выше в «Весёлой арифметике»).
Самое интересное для меня здесь это тот факт, что баг проявил себя лишь при компиляции в
Памятка: Следовать в первую очередь требованиям документации, а не принципу «рабочий код — правильный код».
Тонкости языка
Локализация это отдельная тема для любого разработчика, но такое я увидел впервые:
#define RUSSIAN
#define _CRYPT_KEY_ 0x78CD
#ifdef RUSSIAN
#undef _CRYPT_KEY_
#define _CRYPT_KEY_ 0x4EBA
#endif
Если вам этого мало, предлагаю заглянуть под спойлер и посмотреть, для чего же нужен этот «крипто-ключ».
VOID CGSCarch::MemDecrypt( LPBYTE lpbDestination, DWORD dwSize ) {
BYTE Key = (BYTE) ~( HIBYTE( _CRYPT_KEY_ ) );
isiDecryptMem( lpbDestination, dwSize, Key );
}
void isiDecryptMem( LPBYTE lpbBuffer, DWORD dwSize, BYTE dbKey ) {
_asm {
mov ecx, dwSize
mov ebx, lpbBuffer
mov ah, dbKey
next_byte:
mov al, [ebx]
not al
xor al, ah
mov [ebx], al
inc ebx
loop next_byte
}
}
Вот таким нехитрым образом можно запороть локализацию на этапе компилирования. Если, например, «английскому» dmcr.exe подсунуть архив с ресурсами из русской версии, то всё, что останется от игры — окно ошибки access violation. Потому что ни до, ни после «isi memory decryption» содержимое буфера не проверяется. А вот если мы распакуем архив all.gsc, заменим файлы и запакуем его обратно, то в игре нас будет ждать русский интерфейс.
Посмотрев на эту XOR-вакханалию я решил ограничиться английской версией, но с поддержкой кириллицы в чате. Так как весь текст отрисовывается через собственные шрифты игры, я скопировал из русской версии ресурс mainfont.gp. Осталось только отловить символы, выходящие за пределы диапазона ascii, и правильно сопоставить коды букв с «индексом кадров» этого файла (формат GP используется в игре повсеместно для хранения графики, в том числе и для анимации). Не самое элегантное решение, зато работает безотказно, причём на сервере в чате с игроками под версией 1.35 тоже.
UDP без дырок
К сожалению, в оригинальных «Казаках» не был реализован механизм UDP hole punching, который позволил бы игрокам подключаться к игровым комнатам, даже если их хост находится по ту сторону NAT своего провайдера.
К счастью, товарищ, известный под ником [-RUS-]AlliGator, запустивший и поддерживающий сервер cossacks-server.net, выделил немного своего времени и мы договорились о дополнительном протоколе, по которому хост игры будет поддерживать UDP соединение с сервером, и по которому сервер сможет сообщать внешний UDP порт хоста игрокам, желающим к нему подключиться.
Все детали реализации можно посмотреть в классе UdpHolePuncher. Соединение инициализируется при создании игровой комнаты хостом, после чего он вплоть до старта игры поддерживает связь, отправляя небольшие пакеты. Это нужно, т.к. NAT может при каждом новом UDP соединении присваивать другой внешний порт, а так сервер наверняка знает, что в данный момент времени хост доступен из-за NAT по тому порту, с которого приходят пакеты.
Соответствующие изменения были внесены и в процедуру обработки команд сервера и в структуру RoomInfo в библиотеке IChat.dll. Поддерживаются следующие дополнительные переменные при создании игровой комнаты:
- %PROF: идентификатор игрока. С помощью него сервер сможет различать хостов
- %CG_HOLEHOST: адрес сервера, обрабатывающего UDP пакеты
- %CG_HOLEPORT: порт сервера, на котором слушается UDP
- %CG_HOLEINT: интервал, с которым клиент должен отправлять пакеты
Получив эти данные, хост игры открывает дополнительное соединение и поддерживает его. Желающие присоединиться получают дополнительную переменную %CG_PORT при подключении к комнате. И только если её нет, используется константа DATA_PORT.
Хотя весь этот механизм уже имплементирован в клиенте игры, протестировать мне его ещё не удалось, т.к. контакт с Аллигатором оборвался. Незадолго до этого он выложил в открытый доступ исходный код своего сервера, — спасибо тебе за это! — так что если кто-то готов поднять эстафетную палочку, я буду только за.
Послесловие
Статья и так уже вышла длиннее, чем я планировал, так что буду краток. Хотя этот проект занял продолжительное время и ощутимо истощил запас моего энтузиазма к реверс-инжинирингу и анализу исходного кода, я рад, что взялся за него. Рад, что написал тогда статью на Хабр с описанием своего первого, ассемблерного, костыля для «Казаков». Рад, что в комментарии пришёл Максим fsou11 и выложил в свободный доступ исходный код игры. Также я благодарен сообществу LCN за ценные советы, объяснения и помощь в тестировании.
Ссылки:
Комментарии (34)
mayorovp
12.05.2017 12:22+2Как уберечь своё приложение от такой эвристики со стороны Майкрософт, существующей и грядущей? А никак. Сегодня вы разрабатываете игры, а завтра уже стоите в одном ряду с Inno Setup и InstallShield.
А включение манифеста с явным отключением требований прав админа не помогает?
Ereb
12.05.2017 12:32+2Не проверял, но в данном контексте это не имеет значения.
Функция манифеста появилась лишь в Visual Studio 2005 / MSVC 8, а описанная эвристика — ещё позже. На момент написания Казаков нельзя было предвидеть и избежать такого поворота. Это я и хотел выразить в данном предложении.
VEG
12.05.2017 16:49+10Оказывается, ОС Windows начиная с Windows Vista применяет эвристический алгоритм для определения приложений, которым может потребоваться повышение привилегий. Называется эта функция «Технологией обнаружения установщика» (см. статью в ИТ-центре Windows), и обычно она реагирует на ключевые слова вроде install или setup. Но в нашем случае виновником оказался параметр CompanyName — если он содержит строку "-GSC-\0", то просыпается UAC и требует прав администратора.
Причина не в этом. В Windows встроена огромная база данных, которая описывает, какие фиксы совместимости к каким исполняемым файлам нужно применять. В этой базе и прописано, что эта игра должна запускаться с максимальными правами. Видимо, без них что-то не работало.
Вообще там очень много разнообразных фиксов, которые можно применять к приложениям. Многим старым программам прописано SingleProcAffinity, например, что заставляет выполняться их на одном ядре (иначе некоторые программы эпохи до появления многоядерных процессоров просто зависают). Или, например, есть фикс, который «врёт» программе о свободном пространстве на диске, гарантируя, что число не будет больше 2 гигабайт, что помогает некоторым старым программам работать без ошибок. Эту базу можно редактировать, добавлять или удалять свои фиксы каким-то программам. Для запуска некоторых старых игр часто предлагается инсталлировать в систему *.sdb патчи — это как раз оно, добавляет новые записи в эту базу.
И да, я не совсем понял, где собственно у вас был реверс-инжиниринг? У вас же были исходные коды.Ereb
12.05.2017 20:58+6Спасибо за информацию, не знал.
И да, я не совсем понял, где собственно у вас был реверс-инжиниринг? У вас же были исходные коды.
Реверс был в первых трёх статьях, до обнародования исходников. Назвал так, потому что эта статья логичное завершение начатого проекта. Ну и код местами довольно необычный, так что реверс тут был хотя бы мысленный ;)
Dzen1
13.05.2017 10:46Интересно. Спасибо за статью.
Меня вот, что интересует. Допустим я играл на старом «железе»(Pentium 3 800 mHz) были те же «тормоза», что и сейчас, на более быстром «железе». К примеру, когда большое количество юнитов на карте, игра начинает «тормозить» или же вылетать?!
Понимаю, может быть вопрос не по адресу, просто интересно отчего же так происходит, нет ли там кода, который искусственно «затормаживает» игру ?!..Ereb
13.05.2017 10:51Вылет при большом количестве юнитов на экране я пофиксил. На счёт тормозов точно сказать не могу, мне не довелось протестировать сетевую игру с 8.000+ юнитами. При ~5.000 юнитах тормозов не заметил.
Возможны артефакты при большом количестве трупов на экране — временно пропадают деревья, анимации выстрелов и огня. Раньше это так же приводило к вылету, теперь нет ;)
lgorSL
13.05.2017 18:20+1Никто не пытался воссоздать казаков на современных технологиях? (Новые казаки не в счёт, они как-то очень криво сделаны)
Я пару лет назад ради интереса написал примитивный прототип графики на libgdx. Самой игры не было, просто рисование расставленных человечков, деревьев и рельефа с помощью OpenGL ES 2.0 — телефон нормально справлялся, а на компьютере так вообще летало.
Если упростить управление — сделать поведение солдат и крестьян более разумными, чтобы игрок не страдал от необходимости микроконтроля на маленьком сенсорном экране и сконцентрировался на управлении отрядами, то может получиться довольно интересно. Но в одиночку было сложно, и я отложил проект до лучших времён, которые, похоже, так и не наступят.
Скриншоты с телефона в 1920*1080На человечка потратил несколько дней — моделировал в блендере, разукрашивал, потом рендерил с 16 сторон в маленькие картиночки вместе с картой нормалей… Деревья и траву взял готовые.
Ereb
13.05.2017 19:41Ух ты, респект!
На счёт проекта — извините, но я пас. Я с Казаками в последнее время уже натерпелся ;)
Но тема интересная, желаю удачи, если всё же возьмётесь.
andreytata
18.05.2017 21:33«Warcraft 2000» — родился через выдирание арта из оригинального «Warcraft». Но на своём движке. Который и стал основой для «Козаков». История повторяется? Прям мурашки по спине. Карма наверное.
Ereb
18.05.2017 21:43Не уверен, что
На человечка потратил несколько дней — моделировал в блендере
попадает под «выдирание арта». К тому же, Warcraft 2000, если я не ошибаюсь, никогда не являлся коммерческим проектом.
…вы мне, кстати, напомнили историю про то, как ребята из GSC когда-то предложили представителям Blizzard помочь последним с разработкой Warcraft 3, а то движок у Warcraft 2 тянул уж слишком мало юнитов на карте. И в качестве PoC показали им упомянутый Warcraft 2000. В итоге ребята из Blizzard обиделись и не стали дружить с GSC ^_^andreytata
18.05.2017 23:12GSC тогда арендовал трехкомнатную квартирку в жилом 16 этажном доме напротив метро Оболонь, и свёртывал все проекты, кроме арта к «Казакам» и «Warcraft 2000». Жестоко кончались деньги. А Андрей тогда был умельцем в ассемблере, а не в С++. И это не C++ был, а VC6. И нужен он был, поначалу, только для поднятия DirectDraw. Плюсами VC6 от Microsoft и не был. И смещения в структурах фиксировались для инлайн ASM. И если ASM остался в сырцах, убедитесь что это POD, не стоит из «это» класс делать, ибо С++11.
lgorSL
19.05.2017 13:10«Warcraft 2000» — родился через выдирание арта из оригинального «Warcraft».
Не, от Казаков я только деревья брал)
Для хранения анимаций человечков в Казаках используется какой-то хитро сжатый формат и ограниченная палитра на 256 цветов — я не стал с этим связываться.
Вдобавок, я вместе с человечком сделал карту нормалей. Человечек плоский и рисуется как два треугольника, но благодаря нормалям со стороны света он поярче, а с другой — в тени. (не путать с направленными тенями от человечков на земле — те рисуются честно). Я ещё хотел с деревьями так же сделать, но руки не дошли (как и до анимации человечка и вообще всего остального). По моим прикидкам, если делать спрайты 32*32 или 32*64 пикселей размером, в текстуру 2к*2к поместится 4 или 2 тысячи спрайтов. Если рендерить каждую модель с 16 сторон, останется 512 или 256 кадров. Этого хватит на то, чтобы сделать несколько типов человечков, но не хватит, чтобы сделать всё разнообразие юнитов, как в оригинальной игре. (Юнитов разных цветов можно получить изменением цветов в пиксельном шейдере.)
В итоге получилось нечто, достаточно быстрое даже на мобильных телефонах и при этом с красивостями типа теней.
P.S. К сожалению, история вряд ли повторится, больно уж много усилий придётся затратить. Единственное что радует — современные технологии и более мощное железо позволяют экономить время и делать некоторые вещи путь и не очень оптимально, но зато более простым способом.
andreytata
19.05.2017 20:24Всё правильно вы делаете, это не только проще, но и в сотни раз быстрее. Текстура со всей анимацией движения каждого юнита ложится на сторону видео, не нужно на прямую с пикселями маяться — пусть с ними GPU мается. Смещение UV в шейдер — на текуший кадр анимации. Ну и приближать-удалять сцену — проще. Рендерить достаточно с 8-ми сторон — остальные 8 это переворачивание UV. Для мелких юнитов и 3-х сторон вполне достаточно. (Визуально 6 направлений). GLES2.0 + QT + C++ ??
lgorSL
19.05.2017 21:21Рендерить достаточно с 8-ми сторон — остальные 8 это переворачивание UV.
Мне кажется, экономия в 2 раза — не очень много, а вот превращать левшей в правшей как-то неправильно. Раз уж я делаю 3д модельку, нет никаких сложностей отрендерить её со всех сторон. В любом случае, добавить эту фишку никогда не поздно.
GLES2.0 + QT + C++
Это долгая история :) 3 года назад я осваивал openGL, вызывал его из кода на java (в андроиде так можно), и потихоньку пилил свой движок и игру. оно даже есть на гитхабе, хотя большой практической ценности в проекте нет. Писал свои велосипеды для матриц, кватернионов, обёртку над шейдерами...
Потом мне надоело писать велосипеды, и я решил использовать libgdx — библиотека даёт удобные обёртки над openGL, вводом-выводом и прочим. Один и тот же код без проблем собирается и под PC и под android. Это очень ускоряет написание кода и отладку (да и на PC почему бы не поиграть). Скриншоты выше из версии с libgdx.
Если я возьмусь за это сейчас, буду использовать libgdx + scala. С++ знаю не очень хорошо, а scala позволяет быстро писать лаконичный и гибкий код. Ещё как вариант рассматривал kotlin, но scala больше нравится.
andreytata
21.05.2017 03:16-1В девяностых игры писались на С и на С++ со вставками ASM. Причем на ASM реализовалось большая часть кода. С приходом крайне медленных Android устройств, и слабых GPU типа Mali 100 тщательный подход снова стал актуальным. Но использовать ASM нельзя из соображений кроссплатформенности. Для меня решением дилеммы стал godbolt.org, пишу на С++, объектно, с паттернами, но каждую конструкцию «вымучиваю» в godbolt, пока нужные мне GCC -O3 -fno-rtti не выдадут правильный, с моей точки зрения, ASM. Мало чем отличается от нашей писанины 20 летней давности. Тогда мы просто смотрели на ASM порождаемый компилятором С++, долго ржали над ним, копировали в свой С++ сырец, как ASM вставку, и уже там облагораживали.
Psychosynthesis
15.05.2017 01:14Круто!
А почему на Github не выкладываете готовый исполняемый файл? Я б попробовал поиграть, но ставить ради этого MS VS и ковыряться с компиляцией очень не хочется.Ereb
15.05.2017 13:45+2Во-первых — гитхаб не для вареза :)
Во-вторых — исполняемый файл вам ничего не даст. Я немного изменил систему загрузки ресурсов, т.к. с существующеми архивами могут возникнуть проблемы (см. пункт «тонкости языка»).
В конце статьи есть несколько ссылок с дополнительной информацией, которые, возможно, вам помогут.
MaximSuvorov
16.05.2017 16:00О да, код Шпагина это боль для глаз. :) Когда я писал АИ для Казаков 3 — пришлось нормально выучить С++ %)
Ereb
16.05.2017 16:05Было бы интересно почитать о вашем опыте в разработке ИИ ;)
MaximSuvorov
16.05.2017 16:40Только давайте конкретные вопросы. :)
Ereb
16.05.2017 22:53С удовольствием :)
- Располагает ли ИИ в любой момент всей информацией о текущей игре или же играет «по честному», видя только в пределах тумана войны?
- Принимает ли ИИ решения лишь на основе доступной игрокам информации (т.е. практически «визуально» — по расположению юнитов), или же он моментально в курсе того, что игрок, например, отдал своим юнитам приказ атаковать конкретное здание?
- Выше вы писали, что для Казаков 3 вам понадобился C++. Разве там движок не на Delphi написан? Каким образом происходит взаимодействие с вашим ИИ?
MaximSuvorov
16.05.2017 23:43+21. Читит. Но и ставка была не на АИ — он должен развлекать игрока, а на сетевую часть.
2. Это и не требуется. АИ регирует по зонам опасности — к примеру, деверсанты ищут путь с минимальным весом опасности, а армии наоборот ищут «опасность»
3. С++ пришлось изучить что бы адекватно читать код оригинальных козаков (я не совсем программист, а игровой дизайнер), так как в момент старта мы хотели что бы Казаки3 игрались точно так же как и оригинал. Сейчас правда баланс сильно поменялся.
С технической стороны движок располагает набором внутренних функций, базовых, очень похоже на то как работает «Монобехевиор» в Юнити, только наши скрипты, а это 99,9% всей игровой логики написаны в скриптах и компилируются в память в рантайме, а не транслируются по надобности. Дальше просто идёт обычный asm: jmp на функцию движка с передайчей хендла объекта.Ereb
18.05.2017 21:32+1Спасибо!
А вы знаете, по каким причинам было решено писать свой интерпретатор для скриптов и делать движок на Delphi, а не использовать довольно распространённую в геймдеве связку из C++ и Lua? С производительностью у последнего, вроде бы, всё в порядке.
fsou11
Спасибо за статью и за ваш труд, отличная работа.
Если позволите, вопрос по внутренности реплеев:
1. Правильно ли я понимаю, что в файле реплея содержатся ничто иное, как последовательность действий каждого из игроков, которые передаются интерпретатору (движку игры) как если бы игра происходила в real-time?
2. Итоговая статистика (сколько каждый из игроков добыл, произвёл, убил) «аккумулятивна»? Другими словами, вычисляется в процессе воспроизведения записи или же хранится в виде «summary» файле?
Ereb
Всегда пожалуйста :)
1. Да, именно так. rec-файл в основном состоит из буфера команд (ExBuf), которые передавались по сети. Действия ИИ рассчитываются заново при просмотре, так что игра как будто играется заново.
В процессе игры постоянно задействуются псевдослучайные числа из файла random.lst, и в определённом такте текущее случайное число сохраняется в записи. Это один из способов, которым игра проверяет синхронизацию. Про механизм синхронизации Казаков вообще можно отдельную статью написать :)
2. Наверняка сказать не могу, но скорее всего вычисляется во время воспроизведения, т.к. в механизме экрана статистики я не заметил разделения на игру и запись. При этом вполне возможно, что значения ресурсов периодически сохраняются в файле записи для проверки синхронизации.
mayorovp
Добавлю: запись действий всех игроков в реплее — это очень популярное решение. Точно знаю что точно так же делает третий варик, наверняка так же делают оба старкрафта и вторая дота.
Ereb
Совершенно верно: для RTS это чуть ли не единственный метод, если вы не хотите, чтобы реплеи весили десятки (а то и сотни) мегабайт.
n0namerz
Здравствуйте!
Ветка комментариев заставила меня задуматься на одну тему, я не знаю пробовали ли вы играть в довольно новую игру от Blizzard «Heroes of the Storm», но говорят, она сделано на основе движка SCII, т.е. RTS. Так вот в игре есть занимательная вещь, если во время игры игрок по каким-то причинам вылетел (ошибка, дисконнект), то при повторной загрузке в игру, игрок сидит и ждет пока всё, что происходило без его участия (или вообще все действия с начала игры) воспроизводятся перед ним в ускоренном виде и когда этот «реплей» воспроизведется до текущего момента, игрок может продолжить игру. Меня это решение всегда ставило в ступор, ведь столько онлайн игр возвращают игрока без всего этого сразу и в текущий момент времени, а тут такое.
Возможно ли такое именно из движка и такого вот подхода к воспроизведению реплеев в нем?
Хотя с другой стороны есть сам SCII, в котором при дисконнекте такого не происходит.
Ereb
Здравствуйте,
с «Heroes of the Storm» я не знаком, но судя по вашему описанию всё обстоит именно так.
Альтернативным методом была бы передача полного состояния игры (расположение и даные всех юнитов, экономика и пр.) в момент реконнекта. Это заняло бы слишком много времени, другим игрокам пришлось бы ждать. К тому же в играх один на один вы бы полностью доверились другому клиенту при реконнекте, а так игра восстанавливается по записи с вашего клиента, затем догоняет пропущенные события (если я правильно понял).
T-362
Как наигравший в хотс и старкрафт думаю это просто фича для удобства пользователя, в хотсе реплаи вообще пишутся автоматически, и скорее всего на стороне сервера.
Еще нужно учесть что хотс не РТС, а сохранить и передать реплай нескольких минут действий 10 (герои) + 10-20-30 (не герои) юнитов не так затратно как старкрафтовский с 200-300 юнитов, или какойнить тоталворовский или казаковский с тысячами.