что такое исходный код игры
Исходный код игры: что это такое и как можно его заполучить?
Исходный код игры — это тот самый код, который пишет программист, чтобы игра заработала. Он может быть написан на любом удобном программисту языке программирования.
Исходный код игры
Иногда разработчики используют такую практику — публикуют исходники игры в открытом доступе, чтобы каждый, кто смыслит в программировании, смог внести свою лепту в развитие игры. При этом авторское право сохраняется за разработчиками игры и регулируется соответствующими лицензиями и документацией.
Но большинство игр распространяются по другому сценарию. Когда программист пишет игру, он закрывает исходный код от посторонних глаз и затем распространяет игру в виде скомпилированного файла. Скомпилированные файлы могут содержать как двоичный машинный код, так и объектный код или код из ассемблерных команд.
В общем, нужно понимать простую вещь : в основном игры пишутся на компилируемых языках. А это значит, что код игры должен пройти процесс компиляции, для того чтобы его мог «понять» компьютер. А компиляция — это односторонний процесс, который всегда происходит только в одном направлении. Это означает, что обратное программирование — это всего лишь попытка воссоздать исходный код игры.
Исходный код игры: для чего закрывать и для чего его хочется заполучить
Для чего закрывают исходный код игры? На самом деле, ответ на данный вопрос — это тема отдельной статьи, где можно сравнить достоинств а и недостатки двух разных форм распространения игр и приложений:
с закрытым исходным кодом;
с открытым исходным кодом.
С закрытым исходным кодом такое не проходит. Однако качественная реверсная инженерия дает свои плоды. Она позволяет «уловить» основные алгоритмы и логику игры, что открывает возможность копировать игру без исходного кода и воссозда вать ее на любом языке программирования. Однако разработчики тоже не дремлют и прекрасно знают об обратном программировании, поэтому они максимально «запутывают следы», например, свой и сходный код они проводят через специальный подход обфу ск ации. Обфу ск ация — это процесс запутывания код а т аким образом, что даже исходный код не всегда будет ясен, если его вдруг украдут. Но обфусицированный код дополнительно проходит еще и компиляцию — это намного усложняет реверсную инженери ю и делает восстановление закрытого исходного кода практически невозможным.
Для чего нужен исходный код игры
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Открытый исходный код — благо или троянский конь?
Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?
Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!
Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.
Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.
Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?
Практическое руководство по взлому (и защите) игр на Unity
Когда речь идёт о программном обеспечении, термин «взлом» зачастую ассоциируют с пиратством и нарушением авторских прав. Данная статья не об этом; напротив, я решительно не одобряю любые действия, которые прямо или косвенно могут навредить другим разработчикам. Тем не менее, эта статья всё же является практическим руководством по взлому. Используя инструменты и методы о которых далее пойдёт речь, вы сможете проверить защиту собственной Unity игры и узнаете, как обезопасить её от взлома и кражи ресурсов.
Введение
В основе взлома лежит знание: необходимо понимать особенности компиляции Unity-проекта, чтобы его взломать. Прочитав статью, вы узнаете, каким образом Unity компилирует ресурсы игры и как извлечь из них исходные материалы: текстуры, шейдеры, 3D-модели и скрипты. Эти навыки будут полезны не только для анализа безопасности проекта, но также для его продвинутой отладки. В связи с закрытостью исходного кода, Unity часто работает как «черный ящик» и порой единственный способ понять, что именно в нём происходит — это изучение скомпилированной версии скриптов. Кроме прочего, декомпиляция чужой игры может стать серьёзным подспорьем в поиске её секретов и «пасхальных яиц». Например, именно таким образом было найдено решение финальной головоломки в игре FEZ.
Находим ресурсы игры
Рассмотрим для примера игру, собранную под ОС Windows и загруженную через Steam. Чтобы добраться до директории, в которой находятся нужные нам ресурсы, откроем окно свойств игры в библиотеке Steam и в закладке «Local files» нажмём «Browse local files…».
Извлекаем текстуры и шейдеры
Графический интерфейс программы не отличается удобством, а также она страдает от нескольких критических багов. Не взирая на это, программа вполне способна извлечь большинство текстур и шейдеров из игры. Полученные в результате текстуры будут иметь формат DDS, который можно «прочитать» с помощью Windows Texture Viewer.
С шейдерами ситуация обстоит сложнее: они извлекаются в уже скомпилированным виде и, насколько мне известно, решений для их автоматической трансляции в удобочитаемый формат не существует. Тем не менее, это обстоятельство не мешает импортировать и использовать полученные шейдеры в другом Unity-проекте. Не забывайте, однако, что подобная «кража» нарушает авторские права и является актом пиратства.
Извлекаем 3D-модели
Трёхмерные модели в типовой Unity-сборке «разбросаны» по различным ресурсам, а некоторые из них и вовсе могут генерироваться во время игры. Вместо копания в файлах, существует интересная альтернатива — получить данные о геометрии прямиком из памяти графического ускорителя. Когда игра запущена, вся информация о текстурах и моделях, видимых на экране, находится в памяти видеокарты. С помощью утилиты 3D Ripper DX можно извлечь всю эту информацию и сохранить в формате, понятном 3D-редакторам (например, 3D Studio Max). Учтите, что программа не самая простая в обращении — возможно, придётся обратиться к документации.
Взламываем PlayerPrefs
Защищаем PlayerPrefs
Помешать пользователю редактировать значения в системном реестре мы не в силах. А вот проверить, изменялись ли эти значения без нашего ведома — вполне реально. В этом нам помогут хеш-функции: сравнив контрольные суммы хранимых данных, мы сможем убедиться, что никто и ничто, кроме нашего кода эти данные не изменяло.
Приведенный выше класс — упрощенный пример реализации, работающий со строковыми переменными. Для инициализации ему необходимо передать секретный ключ и список PlayerPrefs-ключей, значения которых должны быть защищены:
Затем его можно использовать следующим образом:
Взламываем исходный код
Данных подход особенно эффективен для наших целей: Unity очень скупо оптимизирует исходный код игровых скриптов, практически не изменяя его структуру, а также не скрывает названия переменных. Это позволяет с легкостью читать и понимать декомпилированый материал.
Защищаем исходный код
Раз Unity не заботится о сохранности нашего кода — сделаем это сами. Благо, существует утилита, готовая автоматически зашифровать плоды нашего интеллектуального труда: Unity 3D Obfuscator.
И хотя программа отлично справляется со своими обязанностями, многие классы, адресуемые извне родной библиотеки, всё же не могут быть зашифрованы без риска нарушения связанности — будьте осторожны!
Взламываем память игры
Cheat Engine — широко известная программа для взлома игр. Она находит ту область оперативной памяти, которая принадлежит процессу запущенной игры и позволяет произвольно её изменять.
Эта программа пользуется тем фактом, что разработчики игр очень редко защищают значения переменных. Рассмотрим следующий пример: в некой игре у нас есть 100 патронов; используя Cheat Engine, можно выполнить поиск участков памяти, которые хранят значение «100». Затем мы делаем выстрел — запас патронов составляет 99 единиц. Снова сканируем память, но теперь ищем значение «99». После нескольких подобных итераций можно с легкостью обнаружить расположение большинства переменных игры и произвольно их изменять.
Защищаем память игры
Использовать нашу новую структуру можно следующим образом:
Если вы выводите значения переменных на экран, хакеры всё ещё смогут перехватить и поменять их, но это не повлияет на действительные значения, хранящиеся в памяти и использующиеся в логике игры.
Заключение
К сожалению, существует не так уж много способов защитить игру от взлома. Будучи установленной на пользовательское устройство, она фактически раскрывает все ваши текстуры, модели и исходный код. Если кто-то захочет декомпилировать игру и украсть ресурсы — это лишь вопрос времени.
Невзирая на это, существуют действенные методы, которые позволят серьёзно усложнить жизнь злоумышленникам. Это не значит, что нужно вдаваться в панику, шифровать весь исходный код и защищать каждую переменную, но по крайней мере задумайтесь, какие ресурсы вашего проекта действительно важны и что вы можете сделать для их защиты.
Исходный код компьютерной программы
Комментарии и документация, да и сам по себе исходный код программы, предназначен не только для понимания принципов и логики работы программы и отдельных ее частей, но и для обучения начинающих программистов, изучения применяемых техни и методологии разработанной программы. Совместное использование программного кода позволяет улучшать общий опыт работы программистов.
В случае применения таких модулей и компонентов, да и вообще, исходного кода самого по себе, важным моментом является переносимость на другие программные платформы, их правильная работа на этих платформах.
Переносимые модули и компоненты с исходным кодом могут состоять из одного и более файлов (десятки, тысячи файлов с кодом), а также написаны на разных языках программирования. Например, часть программы на языке программирования Си, может содержать части кода на языке ассемблера.
Для удобства и облегчения работы с исходным кодом существует множество инструментов, позволяющий автоматизировать написание кода, обеспечивать командную работу над кодом, создавать и контролировать различные версии программ.
Для компьютера, нет разницы и понимания «хорошего кода» или «плохого кода». Программисту же, для понимания что происходит в программе, написанной другим программистом, поддержки и написания новых частей программы, качество исходного кода является очень важной вещью. Ведь если код будет труден для понимания, его невозможно прочитать, а если возможно, но на это уходит много времени, то разработка и поддержка программы существенно усложнит жизнь программиста. Поэтому качество кода должно соответствовать следующим требованиям:
Опубликован исходный код Command & Conquer: смотрим, что внутри
Компания Electronic Arts открыла исходный код первой Command & Conquer, а также Command & Conqueror: Red Alert. Скачать его можно с GitHub.
Всё содержимое имеет лицензию GPL v3; кроме того, в исходном коде сохранены все комментарии. Отсутствует только changelog использовавшейся при разработке системы контроля версий. Похоже, всё просто недавно выложили на Git.
Я решил изучить, что же происходит внутри этого игрового движка. Не буду описывать каждую строку кода, но, по крайней мере, будет интересно взглянуть на то, какой была разработка на C++ в начале 1990-х.
Статистика
Почти все файлы имеют имена в верхнем регистре.
Кроме того, есть файл «RedAlert.vcxproj», поэтому можно предположить, что проект можно собрать в более новых версиях Visual Studio, но этого я не проверял.
Это всё?
Начнём с того, что в репозитории нет ресурсов, даже тестовых. Поэтому придётся каким-то законным образом получить их, например, купить игру у EA. Пока вы этого не сделаете, даже компиляция кода не может подтвердить правильность работы игры.
Этот файл реализует алгоритм сжатия LCW.
Поэтому мне кажется, что компания не опубликовала код порта на Playstation. Я даже не знаю, создавался ли порт на Playstation самой Westwood, или был передан подрядчикам.
Похоже, что в этом случае разработчики пробовали разные алгоритмы, в результате остановившись на LZO. То есть LZW был готов к работе, но не использовался.
Срок патентных притязаний компании Unisys на LZW уже давно истёк, поэтому об этом мы можем не волноваться.
Странные заголовки
В LZW.H и других файлах есть подобные странные заголовки:
Отсутствующий исходный код
Это не релиз полного исходного кода, но его должно быть достаточно, чтобы понять внутреннюю механику игры. EA заявила, что опубликовала код для упрощения жизни моддеров, и, кажется, справилась с этой задачей. Приложив значительные усилия, можно собрать самостоятельную игру.
Как игра запускается?
Я решил начать с изучения процесса запуска игры. Код запуска обычно даёт хорошее представление о том, как игровой движок взаимодействует с ОС. Описание представлено примерно в том же порядке, что и в самом коде, но не полностью. Все неинтересные части пропущены.
Функция main на C++
То есть, похоже, из игры убрана функциональность воспроизведения MPEG-видеовставок.
Следующей идёт проверка свободной памяти. Первая проверка выделяет 13 мегабайта памяти; если это срабатывает, код освобождает эту память. Есть ещё одна отключенная проверка, которая пытается выделить 13 мегабайт памяти в цикле. На каждой итерации цикла запрашиваемая выделяемая память уменьшается на 1 килобайт, пока не удастся её выделить. Думаю, можно спокойно считать, что у современных компьютеров, на которых запускают Command & Conquer, найдутся необходимые 13 мегабайт памяти, поэтому логично, что эту проверку отключили.
Так как в пути содержится «vcs», похоже, что использовалась какая-то система контроля версий, которая действовала как примонтированный в Microsoft Windows диск. В последний раз, когда я пользовался IBM Rational ClearCase, всё было так же. Вероятно, это сделано для того, чтобы люди не запускали игру с сетевого ресурса и не перезаписывали постоянно чужие сохранения.
Игра реализует собственную логику парсинга командной строки, написанную как встроенный в функцию main код:
Я не стал заморачиваться проверкой его работы; похоже, код сканирует элементы, указанные в командной строке в кавычках, а затем пытается интерпретировать их как разделённые кавычками ( » ) группы. Думаю, командная строка Windows не обрабатывала бы такую схему правильно, поэтому обработка выполнена в самой игре. На самом деле я не уверен, реализована ли в cmd.exe логика работы кавычек даже сегодня.
Похоже, разработчики после версии 1.08 игры очень не хотели, чтобы среди файлов присутствовал «conquer.eng». Поэтому при каждом запуске игры они пытаются его удалить. Я не знаю, почему он находится вместе с кодом Westwood Online.
Во второй половине 1990-х обе они были довольно популярными платформами для онлайн-игр. Думаю, что существует специальная сборка для поддержки MPlayer и TEN. Ни той, ни другой уже не существует. Подробнее о них я расскажу позже.
Затем игра запускает таймер Windows, ожидает ( sleep ) в течение 1000 миллисекунд, а затем проверяет, что системные часы идут. Если это не так, то игра завершается. Думаю, реализация sleep на некоторых платформах была настолько глючной, что приводила к сбоям проверки при запуске. Теперь этот код отключен.
Затем игра проверяет свободное место на диске и если его недостаточно, выполняет выход. Этот код теперь отключен.
Далее она переходит к загрузке конфигурации, сгенерированной из программы ccsetup из комплекта оригинальной игры. Она не делает ничего особо интересного, но я заметил это:
Была добавлена конфигурация «DebugQuiet»; похоже, она выбирает аудиовыход, который ничего не делает. Думаю, довольно сильно раздражало бы, если бы при тестировании игры постоянно слышался шум.
После этого игра готова к настройке разрешения экрана. Этот код чрезвычайно интересен. Первым делом проверяется высота экрана 400, что означает выбранный режим 640 x 400. Если его нельзя установить, то игра откатывается к 640 x 480. Все остальные разрешения используются напрямую. Что же такого особенного в режиме 640 x 400?
Для выполнения рендеринга игре нужен доступ к графической памяти. Если выбрана ширина экрана 320, то игра идёт по особому пути выполнения кода, используемого для инициализации буферов дисплея. Я предполагаю, что если кто-то запускает игру в режиме 320×240 (который тоже является VGA), то он работает на таком старом «железе», что код даже не пытается использовать аппаратные буферы. При всех остальных высотах экрана код пытается выделить аппаратные буферы под страницу видимой памяти и страницу скрытой памяти. Подозреваю, что используется двойная буферизация графики, отсюда и два буфера. Для страницы видимой памяти обязательна доступность аппаратной памяти. С выделением этой памяти связана довольно интересная логика:
Можно только предположить, что комментарий «Aaaarrgghh!» был добавлен после долгой отладки проблем с производительностью на отдельных машинах. На каком-то этапе кто-то догадался, что DirectDraw API (часть DirectX) может возвращать страницу системной памяти, даже когда запрашивается страница аппаратной видеопамяти.
Работа со скрытой страницей более расслабленная, но её логика и комментарии ещё лучше:
Совсем недавно, в 2019 году, в комментарии были внесены изменения с указанием даты и времени. Некто с инициалами JAS добавил проверку, выполняется ли запуск из редактора (вероятно, редактора уровней), чтобы в этом случае не производился перехват мышки. О ремастере было заявлено в ноябре 2018 года, поэтому логично, что за этот временной интервал должны были реализовать различные изменения и протестировать поддержку 4K с новыми файлами ресурсов.
В коде присутствует всевозможная отключенная логика о принудительном воспроизведении вступительного видеоролика при первом запуске. Такое ощущение, что у разработчика была биполярка и он не мог решить, должен ли пользователь на самом деле увидеть этот ролик. На каком-то этапе вся эта логика была закомментирована; скорее всего, во время разработки ремастера. Думаю, разработчики и тестеры быстро устали от просмотра вступительного видеоролика, поэтому подозреваю, что и во время разработки оригинала его тоже отключали.
Теперь можно начинать играть! Далее код выполняет Main_Game (из CONQUER.CPP ), которая и является самим игровым циклом. В комментарии к этому файлу указана дата начала «3 апреля 1991 года», то есть для выпуска первой Command & Conquer в 1995 году потребовалось четыре года разработки!
После завершения игры функция Main_Game может выполнить возврат. В ней есть код очистки, но прежде чем мы к нему приступим, взглянем на это:
Итак, предположительно, графика после DLL остаётся в странном состоянии, что, скорее всего, приводит к всевозможным утечкам памяти.
Другие открытия
Я решил подробнее изучить и другие заинтересовавшие меня по именам файлов аспекты.
Трассировки стеков Windows 95
Файл W95TRACE.CPP содержит комментарий:
Похоже, он свидетельствует о том, что разработка велась на Windows NT, но тестирование проводилось на Windows 95, чтобы гарантировать работу игры у целевой аудитории. Это кажется логичным, потому что NT могла быть доступной разработчикам игры ещё в июле 1993 года. Подозреваю, что трассировки стеков Windows 95 до ужаса бесполезны по сравнению с тем, что предоставляет Windows NT.
Компилятор Watcom
Это довольно интересно, потому что первый релиз компилятора Watcom с поддержкой C++ был выпущен в 1993 году. Есть другие примечания разработчиков, говорящие нам, что проект был начат ещё в 1991 году. Начинался ли он как проект на C, а затем перешёл на C++? Или у разработчиков был другой компилятор C++?
В том же файле есть и другое сокровище — кажется, некоторые разработчики компиляторов тогда не могли утруждать себя реализацией true и false:
Шифрование
В BLOWFISH.CPP реализовано шифрование Blowfish, которое, скорее всего, является хорошо известным шифром Blowfish. Я могу вообразить только один способ его применения — обфускация сетевого трафика.
Система сущностей
Класс CCPtr в файле CCPTR.H — это тип-указатель, использующий ID в качестве смещения кучи памяти. Это довольно стандартный подход, потому что он упрощает сохранение файлов на диск, если все объекты отслеживаются из одного места. Он используется как очень простой способ реализации системы сущностей. Если вам любопытны преимущества использования системы сущностей в видеоиграх, то подробнее об этом можно прочитать здесь.
Векторы
Класс VECTOR.H определяет класс шаблона, приблизительно напоминающий std::vector. Предположительно, он был разработан на ранних этапах для использования возможностей STL.
Дифтонги
По сути, это простой алгоритм сжатия, предполагающий, что мы сжимаем тексты, и выполняющий замену последовательностей.
Следующий код выполняется как часть распаковки сжатых данных:
Массив «InternetTxt» — это просто набор заранее заданных строк. Похоже, всё, что равно или больше «4567», считается заранее заданной строкой. Я думаю, эту константу разработчик выбрал, просто нажав на клавиши 4-5-6-7 строки с цифрами на клавиатуре. Когда мне нужно сгенерировать случайное целочисленное значение в качестве константы, я предпочитаю этот способ.
Total Entertainment Network и MPlayer
Как я говорил выше, похоже на то, что существовали специальные сборки для поддержки Total Entertainment Network и MPlayer. Это сервисы для многопользовательских онлайн-игр того времени.
Каждый сервис имел собственный код инициализации и настройки.
Файлы Total Entertainment Network (TEN)
Файлы MPlayer (MPATH)
Код «MPATH» вызывает множество функций «MGen», которые тоже отсутствуют. Однако мы можем легко найти их в исходном коде Quake. В Quake тоже можно было играть в обеих этих сетях. К сожалению, в публичных исходниках Quake нет кода TEN. Предположу, что интеграция MPlayer была реализована передачей студии-разработчику стандартной библиотеки и интеграции её в код игры.
Думаю, что EA была аккуратной, потому что понимала, что не владеет этим кодом, а id Software на момент выпуска Quake это просто не волновало.
Разумеется, на самом деле этот код никому не нужен. Просто это единственное, что осталось от стандартных для конца 1990-х игровых сервисов.
Дополнение: со мной связался Ларри Гастингс и внёс коррективы в некоторые мои догадки. Оказывается, исходный код, который, по моему мнению, был реализацией MPlayer, ею не является. На самом деле это ПО, которое называется «chunnel»; оно позволяет приложению, выполняемому в Windows 95 в режиме DOS, взаимодействовать с сетевым стеком, предоставляемым Windows. Также он поделился некоторыми подробностями об интеграции MPlayer с играми. Воспроизвожу их здесь без упоминания имён третьих лиц:
Во-первых, у большинства компаний не было собственной интеграции с Mplayer; они просто присылали нам фрагмент кода, и мы должны были разбираться, как собрать его и выполнить всю работу по интеграции. Но я думаю, что Westwood стала исключением из правил. Помню, что один из наших «инженеров по портированию» съездил перед выпуском Red Alert в Westwood. Его очень впечатлила сетевая модель RA!
Во-вторых, все активы Mplayer были проданы компании GameSpy, которой не нужны были никакие онлайн-сервисы (Mplayer / POP.X / Global Rankings). Всё, что ей было нужно — это база пользователей и… отдел продаж, возможно? Как бы то ни было, в 2013 году GameSpy закрылась, а все её активы были проданы Glu Mobile, поэтому, теоретически, всей интеллектуальной собственностью теперь владеет эта компания. TEN в 1998 году сделала поворот в сторону «классических» онлайн-игр, в 1999 году выполнила ребрендинг, превратившись в Pogo.com, а в 2001 году её приобрела… EA! Поэтому EA, скорее всего, могла спокойно выпускать код TEN. И я сомневаюсь, что сейчас кого-то волнует код Mplayer, этот сервис давно мёртв.
В-третьих, как я говорил, компании обычно присылали нам код и Mplayer сама занималась работой по интеграции. В случае id Software было так же. Код Mplayer, который есть в Quake 1 — это не интеграция с игровым сервисом Mplayer! На самом деле это технология, которую мы лицензировали компании id. Она называется «chunnel»; её написал британский программист по имени ***. «Chunnel» — это библиотека, которая позволяла DOS-программам в защищённом режиме 386 выполняться под Windows, совершая вызовы сетевого стека Winsock операционной системы Windows 95. Нужно помнить, что это было примерно в 1996 году, и экосистема видеоигр под Windows ещё не сложилась. Quake изначально был выпущен как программа для DOS, и его портировали под Win32 только спустя один-два года. «Chunnel» позволила id решить серьёзную проблему — обеспечила её DOS-программе в защищённом режиме 386 возможность участвовать в сетевой игре при работе под Windows. Частично благодарность компании выразилась в том, что каждая игра id использовала Mplayer (несмотря на то, что это всегда вызывало сомнения). При запуске первых версий Quake под DOS, например, первой shareware-демо, на экране заставки даже присутствовал логотип Mplayer (золотая осциллограмма) и пометка о «лицензированной технологии». Это также объясняет параметр командной строки «-mpath» в DOS-сборках Quake 😉
Перевод и локализация
Проверка #ifdef GERMAN встречается в коде 28 раз, однако #ifdef FRENCH встречается 37 раз. Возможно, перевод на французский просто был чуть более тщательным.
Разумеется, в DEFINES.H представлена самая лучшая реализация перевода.
Похоже, до перевода на испанский разработчики так и не добрались.
Защита донглом
На определённом промежутке времени в прошлом стандартным способом DRM-защиты различного ПО был аппаратный ключ-донгл. По сути, для защиты использовалось закрытое и обфусцированное аппаратное устройство, подключаемое к PC. Программа передаёт ему некий «запрос» и отказывается запускаться, если не получит нужный ответ.
Не думаю, что Command & Conquer когда-то продавалась с таким устройством, но в DEFINES.H есть одна-две закомментированные строки про него:
Virgin Interactive
Command & Conquer разрабатывала Westwood Studios, но этой компанией владела Virgin Interactive. В коде есть такая проверка с уникальным названием:
Думаю, что перед релизом Virgin Interactive получила специальную сборку, чтобы провести плейтестинг продукта.
Конец
Вот и всё. Я не исследовал весь код, просто посмотрел то, что мне показалось мне интересным и на что хватило времени. Я узнал немного больше о разработке видеоигр начала 1990-х, и, возможно, смогу использовать это знание в настоящем.
Возможно, в дальнейшем я вернусь к изучению этого кода. Мне бы очень хотелось сравнить его с портом игры на Playstation, но не думаю, что EA сможет выпустить этот код, даже если он у неё ещё есть.