исходный код движка source
Source Modding — Часть 1 — Основы основ
В мире существует множество игровых движков, но нет ни одного движка, похожего на Source своей историей и особенностями.
В этом (пилотном) уроке мы разберем простейшие действия с исходными кодами SDK, а также внесем наше первое изменение в код Half-Life 2.
Вступление
Немножко терминов
Сам по себе Source SDK — набор утилит и программ, помогающих в разработке собственных уровней и модификаций для игры, а также исходные коды Half-Life 2 и эпизодов.
Игра/Мод (Для сурса нет никакой разницы, игра это или мод :p) — скомпилированные исходные коды SDK.
Так почему же именно Source?!
Что нам необходимо?
Введение в сурс дела
Репозиторий
Исходный код SDK находится в репозитории на GitHub. Склонируйте его в любое удобное для вас место:
Выбор ветки
Если вы хотите написать свой первый мод для Half-Life 2/Episode 1/2, то используйте директорию sp/ и Source SDK Base 2013 Singleplayer.
Стиль кода
Поля класса именуются с префиксом m_, использование венгерской нотации рекомендуется (на то есть свои причины, которые здесь обсуждать нет смысла):
Структура кода
SDK, так же как и движок, разделён на несколько частей.
Вот пути до некоторых таких файлов:
ВАЖНО: При внесении ЛЮБЫХ изменений в VPC файл решение должно быть заново перегенерировано!
Генерация проектов
Исключение HL2
SDK имеет внутри себя также разделение на HL2 и Episodic. Использование второго позволит нам иметь некоторые фичи, например отдельную от стамины шкалу заряда фонарика.
И поэтому, чтобы не компилировать лишний код, мы можем просто исключить HL2 из скриптов:
Другие скрипты
Рядом с creategameprojects.bat также лежит его клон для bash а также два интересных файла — createallprojects.bat и его клон для bash.
Эти два скрипта заставляют VPC создавать проекты не только для чистых библиотек мода, но и для различных утилит, таких как vrad (Radiosity!) или height2normal.
Сейчас использовать я его вам настоятельно не рекомендую, так как свои собственные компиляторы карт нам пока не нужны.
Первичная сборка и запуск
Сборка
Чтобы удостовериться, что вы всё сделали правильно, необходимо собрать всё сгенерированное решение. Итак, собираем (вы же ведь открыли решение в IDE?):
После сборки в папке game/mod_hl2/bin/ или game/mod_episodic/bin/ должны появится наши клиентская и серверная библиотеки!
Запуск — Способ 1 — Steam
Запуск — Способ 2 — Visual Studio
Я рекомендую использовать именно этот способ — не копировать же бинарники мода каждый раз после сборки!
Если карта загрузилась и вы можете передвигаться и двигать камеру мышью — сборка успешна!
Первая модификация в коде
Функции семейства Msg()
Заключение
Чему мы научились?
[Я надеюсь, что] из данного урока мы выяснили:
Что дальше?
Во второй части мы разберем систему сущностей Source SDK.
Unity выложила исходный C#-код на Github
Код был выложен вчера, официальный анонс состоится только в понедельник.
Ложка дегтя: код может быть использован только в справочных целях. Полную лицензию на использование можно посмотреть здесь.
Впрочем, это ничуть не остановило товарища, уже оформившего пулл-реквест с фиксом производительности.
Далеко не секрет, что крупные студии (например, авторы Cities: Skylines) имеют доступ к исходному коду (и C#, и C++) уже довольно давно — для этого необходимо приобретать отдельную лицензию. Раньше это было критически необходимым, если вам требовалось модифицировать стандартный процесс рендеринга (начиная с версии 2018, можно будет менять все под себя при помощи SRP и кода на C#).
За данную инициативу дружно благодарим Aras Pranckevičius, который занимался подготовкой кода к публикации последние несколько недель.
Движок Unity становится более модульным и проходит масштабное обновление: в нем появился пакетный менеджер, появилась система задач C# (позволяющая писать безопасный многопоточный код), была переработана система ECS (Entity Component System) с учетом низкоуровневых оптимизаций, а к версии 2018.3 наконец-то появятся (sic!) Nested Prefabs.
Глубокий уход Unity в сторону data-oriented design происходит под чутким надзором Майка Эктона (Mike Acton, бывший глава разработки движков в Insomniac Games), присоединившегося к компании прошлой осенью вместе с другим соратником по Insomniac, чей подход к игровой оптимизации приобрел широкую известность после доклада на CppCon 2014 «Data-Oriented Design and C++»).
Интересное недавнее интервью CTO Unity, главой R&D и Эктоном можно прочитать на английском по ссылке. По всей видимости, публикация исходного кода — это еще один важный шаг для нового курса компании.
«Выжить почти невозможно»: как создавался движок Source 2
В конце концов Valve помог перенос на новый движок реальной игры.
Почти все игры Valve созданы на базе собственного семейства движков Source. Создание второго поколения движка заняло у Valve по меньшей мере пять лет: первый проект на Source 2 вышел в 2015 году, разработка движка началась не позже 2010 года. Почему так долго?
Свою версию событий предлагает Ричард Гельдрих — программист, почти пять лет занимавшийся графикой в играх вообще Valve и движком Source в частности. У себя в твиттере Ричард рассказывает, как создавался движок Source 2 и с какими проблемами сталкивалась его команда.
Одной из основных проблем Гельдрих называет действия ветеранов Valve. Для развития движка активно нанимали новых людей, оказавшихся не готовыми к интригам со стороны старых сотрудников компании. Дело было в бонусах.
Чтобы развивать движок, требовалось нанимать новых людей, способных по-новому взглянуть на проблему. Но вот в чем дело: новички не понимали, как на самом деле работает компания. Система бонусов все извратила, но об этом вам никто не рассказывал.
Напротив, старички — разработчики, создавшие первое поколение Source — прекрасно знали, как работает компания, как добиться максимальных бонусов и как доводить коллег до увольнения.
Успехи новичков могли помешать разработчикам-ветеранам получать привычные бонусы. Чтобы избежать этого, вспоминает Гельдрих, ветераны отслеживали успехи новичков, и как только чувствовали угрозу, начинали выживать их из компании.
Выжить было почти невозможно. Когда я пришел в компанию, то попал как раз в команду Source 2. Ощущение было такое, словно вас, окровавленного, бросили к акулам.
Мне удалось выжить лишь потому, что еще оставаясь в команде Source 2, я взялся за Portal 2 и начал исправлять баги рендеринга, которыми никто больше не мог или не хотел заниматься.
В команде Source 2 ко мне и многим другим коллегам относились как к мусору. А вот в командах проектов на движке Source 1 меня очень ценили: я помогал улучшить и поправить рендеринг еще до релиза игры.
У затягивания разработки Source 2 была и еще одна причина. Движок, объясняет Гельдрих, на самом деле долго нигде не использовался: программисты писали код, но реальных проектов на базе Source 2 просто не существовало.
На протяжении многих лет не было ни внешних, ни внутренних команд, делавших на Source 2 какой-то реальный проект. Постепенно разработка движка стала своеобразным конкурсом для программистов: кто сможет быстрее всего написать самую запутанную систему.
Невозможно объективно оценить новый движок, когда нет ни результатов, ни клиентов, а все отзывы подаются только ради максимальных бонусов.
В какой-то момент, вспоминает Гельдрих, он предложил изменить подход и выложить Source 2 хоть куда-нибудь — например, в Steam, чтобы с ним могли поработать другие компании и дать разработчикам хоть какую-то реальную обратную связь.
Где-то 10 лет назад я поговорил с парой руководителей проекта Source 2. К тому моменту движок болтался в подвешенном состоянии уже несколько лет, и я дал им два совета.
Либо выложите демку Source 2 в Steam, чтобы разработчики могли с ним поработать, либо перенесите на новый графический движок игру на базе Source 1.
В конце концов они решили так и сделать. После переноса на Source 2 уже успешной игры [речь идет о Dota 2] движок немедленно смог оправдать свое существование.
Впрочем, прошло еще немало времени, прежде чем сотрудники других команд Valve по-настоящему заинтересовались Source 2. В частности, команда Counter-Strike Global Offensive была очень рада, что ей не надо переходить на новый движок.
На окончательную доводку движка Source 2 у Valve ушло еще несколько лет. Первыми полноценными играми, с нуля разработанными на этой технологии, стали Dota Underlords и Half-Life Alyx, вышедшие в начале 2020 года.
Source Inside
Source Tools
Возможно вы новичок и не имеете представления что такое программирование на C++ и что стоит за этими всеми названиями: «компиляция», «класс», «интерфейс» и так далее, в таком случае, вы должны приобрести базовые навыки программирования на языке C++, после чего можно будет полноценно выполнять поставленные задачи перед программистом мода.
Source SDK предоставляет исходный код для модификации движка игры.
Это означает что вы обладая определенными знаниями и инструментами можете при наличии у вас этого исходного кода внести в него нужную вам функциональность.
Что такое движок?
Например есть некая игра которую вы запускаете на вашем компьютере.
Игра состоит из программного кода и файлов с данными.
Файлы с данными нетрудно понять что это — то из чего строится игровой мир, графика, модели карты,
А код — это то что выполняется процессором, грубо говоря, чтоб эти файлики могли отображаться на экране, двигаться и звучать.
Эту программную часть и называют «движок».
Движок состоит из нескольких систем, каждая отвечает за свою задачу (рендеринг графики, работа с файлами, обработка комманд, работа с сетью, организация игровой сцены, игровые объекты…)
2. Исходники из Source SDK. Скачать всегда можно при помощи Steam.
3. Microsoft Visual Studio 7.1. Работа над кодом производится в данной среде для работы с проектами Visual С++ 7.1 от фирмы Microsoft.
Возможно есть другие пути компиляции проектов Visual С++ но это отдельная тема.
4. Знание как устроен Source SDK.
Часто программисту нужно самому менять те данные которыми оперирует код и знать каким образом эти данные организуются.
Для этого необходимо:
— изучить документацию по Source SDK: http://www.valve-erc.com/srcsdk;
— знать какие есть команды и настройки консоли для разрабочиков модов;
— понимать как создаются карты (bsp);
— понимать как создаются материалы (vmt/vtx);
— понимать как создаются модели (mdl);
— понимать как создаются звуковые скрипты и ресурсные файлы.
Эти вопросы рассматриваются в других туториалах. 5. Игра Half-Life для запуска вашего собственного мода.
После того как вы создали новый мод (Play Games → Tools/Source SDK → Create a Mod → Modify Half-Life 2) открываем файл src/Game_sdk.sln
Файл sln — это Solution — решение, такой вот термин в Visual Studio. Почему не называют его проектом как в Visual Studio 6?
Решение (.sln) состоит из нескольких проектов (.vcproj), которые можно генерировать все сразу или по отдельности.
Данный файл решения состоит из двух проектов:
client — клиент
hl — сервер
Зачем их два, а если у нас например, не будет мультиплеера в игре?
В любом случае, будь то мультиплеер или синглплеер движок будет состоять из двух частей. Это обясняется тем что сам механизм имитации игрового мира разделен на две зависящие друг от друга стороны.
Что делает сервер, а что клиент, в чем их разница?
Сервер выполняет имитацию виртуальной реальности в реальном времени позволяя синхронизировать различные игровые объекты;
к серверу присоединяются клиенты которые тоже являются этими объектами, один или несколько, вообще в движке Source может быть до 255 клиентов.
В случае сетевой игры через интерент или локальную сеть, запускается общий сервер который синхронизирует всех клиентов, а в одиночной игре работают только свой локальный сервер и клиент.
За что отвечает клиент? Он выполняет ввод управления от игрока и вывод информации в том числе поступившей от сервера. Тоесть он реализует интерфейс с игроком.
Обычно все что невозможно (нет надобности) каким-либо образом выводить для игрока не выполняется на клиенте.
Вообщето клиент имитирует примерно то же что и сервер, но не может превышать больше полномочий чем сервер. Поэтому для сервера важно только то что клиент может передавать состояние игрока, и может вносить разные настройки сервера, предусмотренные разработчиками.
Вот мы и пришли к тому что в движке есть две разные стороны которые выполняются паралельно и зависят друг от друга.
Теперь как это выглядит в исходном коде.
Есть часть кода который отвечает за сторону клиента, есть часть кода сервера, и есть часть кода которая у них общаяя.
В результате компиляции этого кода получается два DLL модуля (клиент и сервер).
Серверный код находится в директории src/dlls.
В нем содержится иерархия серверных классов, в котором одни классы являются базовыми для порождаемых дочерних классов. При проектировании классов все общие свойства нескольких дочерних классов содержатся в родительском.
Серверные классы обычно имеют имена подобные CИмя (CBaseEntity, CBasePlayer).
Сервер отвечает за суть происходящего в игре, для него не важно как это нужно отображать на экране игрока, важна сама логика происходящего.
В результате сборки проекта src/dlls/hl_sdk.vcproj получается файл server.dll.
Код клиента находится в директории src/cl_dll.
Содержит иерархию клиентских классов. Классы клиента обычно имеют имена подобные C_Имя (C_BaseEntity, C_BasePlayer). Все классы игровых объектов которые участвуют в имитации мира имеют соответствующий класс на стороне сервера.
Здесь содержится код управлющий рендерингом моделей, озвучкой, обработка GUI-интерфейса, вывод текстовых сообщений, обработка ввода клавиатуры и мыши
В результате сборки проекта src/cl_dll/client_sdk.vcproj получается файл client.dll.
Если поместить DLL файлы клиента и сервера в директорию bin вашего мода, движок сможет их подключить при запуске.
Общий код лежит в директориях src/public и src/game_shared.
В директории linux_sdk содержатся файлы для создания специального для этой платформы файла компиляции — Makefile, если вы занкомы с Unix, то уже догадались что он нужен для компиляции порта сервера под Linux.
Кроме того в Source SDK есть разные вспомогательные исходники, которые непосредственно не относятся к движку игры, их можно найти в директории src/utils
Это различные утилиты, ну например вы решили сделать какойто свой редактор для файлов в форматах движка Source, вам могут потребоваться такие исходники.
Вникаем в подробности
Для начала сделаем первый шаг в программировании мода.
Открываем файл src/dlls/hl2_dll/hl2_player.cpp
Находим реализацию метода PlayerUse, который отвечает за нажатие на клавишу USE
CBaseEntity *pUseEntity = FindUseEntity ();
Сборка файлов выполняется коммандой Build → Build Solution.
В окне вывода (Output) мы можем видеть вывод процесса сборки:
Первая компиляция может занимать довольно много времени.
Если сборка произошла удачно, в самом конце вывода будет сообщено:
Build: 2 succeeded, 0 failed, 0 skipped
Сгенерированные в результате файлы автоматически копируются в директорию bin вашего мода (в соответствии установкам Custom Build Step).
Теперь если запустить игру с нашими изменениями при использовнии каких-либо предметов (поднимите какойто предмет клавишей USE) мы должны видеть сообщение «Hello MOD!».
Запускать мод можно с помощью файла run_mod.bat в директории вашего мода.
Рассмотрим подробнее параметры командной строки для запуски собственных модов.
Вот пример:
Запомните одну из очень ценных возможностей имеющуюся в Visual Studio — это поиск в файлах с кодом.
Find in Files — поиск в файлах или Ctrl+Shift+F с клавиатуры.
С помощью поиска вы можите исследовать исходный код, и находить самые важные для вас места для модификации.
Первым делом следует рассмотреть базовые вещи с которых нужно начинать знакомство с устройством движка.
Серверу и клиенту предоставляются различные программные интерфейсы которые предоставляют огромный список различных возможностей.
Например,
IPhysics — обработка физики;
IMaterial — огранизация системы материалов;
ICommandLine — работа с коммандами консоли;
IBaseFileSystem — запись/чтение файлов;
IEngineSound — вывод звука;
IInput — ввод клавиатуры или мышки;
и так далее…
Этот список довольно длинный, детальное рассмотрение требует большего объема чем данный туториал.
Чтобы в определенном месте кода сделать проверочный вывод информации на экран например чтобы проконтролировать как выполняется код — используйте вспомогательные функции:
UTIL_ClientPrintAll, ClientPrint или Msg
При дальнейшем изучении как устроен движок встретится много деталей которые важно будет понимать:
серверные и клиентские энтити и их система взаимодействия, таблицы строк, система сообщений, события, обработчики событий, система кэширования, и многое другое.
Все это рассмотрим в следующих туториалах.
Установка и Отладка Исходного Кода
В этой статье рассматриваются основные шаги по установке и отладке исходного кода.
Contents
Шаг За Шагом
Запуск мастера Create a Mod
Компиляция Исходного Кода
Общая информация о компиляции находится здесь: Выбор Компилятора
В настоящее время, код лучше собирается под VS2005. Хотя Visual Studio 2010 это лучший выбор для Source.
VCE2005 пользователям необходимо скачать Windows SDK (Windows 2000 пользователи: Platform SDK). Для Visual Studio и VCE2008 этого не требуется.
Отладка
Настройка параметров отладки
Запуск в отладчике
Альтернатива: интеграция во время выполнения
Ссылки
Хороший шаг после выполнения этой статьи, взглянуть на статью Ваша Первая Энтити, в котором вы будете вносить изменения в исходный код.
Если вы планируете интегрировать обновления кода от Valve, и если вы хотите иметь резервную копию кода и историю ревизий, взгляните на статью Использование Source Control с Source SDK.