Создание сборки своей игры на базе CRYENGINE 5.3. Часть третья. Чистка и заключительные оптимизации.
Во второй части серии статей по созданию сборки своей игры речь шла про запаковку ресурсов, а в этой рассмотрим следующее: сборку библиотек и GameLauncher; удаление библиотек и прочих ресурсов редактора (Sandbox.exe) из сборки; генерацию шейдерного кэша; шифрование запакованных ресурсов; предзагрузка ресурсов (Precache).
Сборка библиотек и GameLauncher (.exe).
Сам процесс, увы, в этой статье рассматриваться не будет, но будут предоставлены полезные ссылки:
https://github.com/CRYTEK/CRYENGINE — официальный репозиторий Crytek на Github.
https://github.com/CRYTEK/CRYENGINE/releases — релизы SDK и наборов исходного кода.
http://docs.cryengine.com/display/CEPROG/CRYENGINE+Build+System — документация о сборке компонентов движка из исходного кода.
http://docs.cryengine.com/display/CEPROG/Visual+Studio+Supported+Versions — CRYENGINE 5 поддерживает сборку библиотек посредством Visual Studio 2015 Community.
http://noostyche.ru/blog/2016/07/19/sborka-cryengine-5-1-1-iz-iskhodnikov/ — статья на русском по устаревшему варианту сборки с применением WAF.
В крайнем случае можно использовать стандартные библиотеки, содержащие функционал GameSDK, но нужно будет их отделить от библиотек редактора, которые к распространению категорически запрещает лицензионное соглашение.
Набор библиотек для запуска игры.
Пример набора библиотек:
Могло что-то ещё остаться из лишнего, но самое важное заключается в удалении библиотек, связанных с редактором, как того требует лицензионное соглашение: http://docs.cryengine.com/display/CEPROG/Guide+to+releasing+CRYENGINE+V+projects#GuidetoreleasingCRYENGINEVprojects-CollectingFilesintoStaging
Ещё стоит обратить внимание, что из библиотек рендера оставлена только CryRenderD3D11.dll (DX11 рендер), когда по умолчанию есть CryRenderD3D12.dll (DX12) и CryRenderOpenGL.dll (OpenGL 4.3). DX12 всё ещё очень слабо распространён в плане аппаратной поддержки оборудованием игроков, а OpenGL в данном случае предназначен для Linux. Поэтому можно не добавлять эти библиотеки в сборку под Windows.
В списке библиотек можно было заметить steam.api64.dll и текстовый файл steam_appid.txt. Это компоненты, необходимые для релиза игры в Steam. Библиотеку можно будет найти в SteamSDK, а в steam_appid.txt находится номер игры. Если выход игры в Steam не планируется, то это всё не потребуется.
Компиляция шейдерного кэша.
Очень важный пункт, выполнение которого необходимо для оптимизации и для работы игры на Linux и консолях.
Официальная документация по теме:
http://docs.cryengine.com/display/CEPROG/Shader+Cache
Статья на русском о компиляции шейдерного кэша:
http://noostyche.ru/blog/2017/10/21/optimization-shadercache-generation-cryengine-5/
По итогу будет скомпилирован шейдерный кэш и запакован, причём запакован особым образом, а не по ранее рассмотренным вариантам во второй части:
Шифрование запакованных ресурсов.
Официальная документация:
Шифрование не обязательно в том случае, когда речь идёт про одиночную игру. Желающие при должном упорстве всё равно распотрошат, а остальным до этого особо нет дела. Мультиплеерную игру всё же стоит защитить, чтобы создать побольше преград энтузиастам взлома.
Я настоятельно рекомендую НЕ шифровать pak-архивы с графическим контентом, так как если внести даже малейшие изменения в их содержимое, то пользователям придётся перекачивать pak-архив целиком. В этом очень мало приятного, когда вес архива с моделями и их текстурами переваливает за 1,5 Гб, при этом какие-то мелкие правки порой приходится вносить чуть ли не каждый день после не особо удачного релиза (а безошибочный релиз в не одноклеточном продукте — вещь на уровне легенд). Игроки с неторопливым интернетом захотят сделать вам больно. В свою очередь, в не зашифрованном виде Steam отправит пользователям на скачивание только те файлы, которые были изменены, не смотря на то, что они находятся в pak-архиве. А вот за это игроки будут благодарны.
Получаем следующую картину, шифруем pak-архивы с графическим контентом только при острой необходимости, а pak-архивы со скриптами и прочими «лёгкими» файлами — шифруем, если есть желание.
Ещё можно зашифровать содержимое каталога engine, а именно engine.pak:
В engine.pak хранятся различные конфиги, поэтому если есть необходимость в их защите от модификации, то шифрование обязательно, а pak-архивы с шейдерами и шейдерным кэшем шифровать не нужно, там ничего интересного.
Чистка результата сборки.
На всякий случай стоит ещё раз убедиться, что никакие библиотеки редактора (Sandbox.exe) не попали в сборку, а так же в сборке НЕ ДОЛЖНО быть файлов логов и каталогов Code, Editor, logbackups, Tools и user.
- В простом случае с одним pak-архивом, который по объёму менее 2 Гб, должно получиться примерно так:
- Необходимые библиотеки собраны:
-
Шейдерный кэш должен быть сгенерирован и упакован, а system.cfg настроен под работу с ним:
Предзагрузка ресурсов.
Тестирование.
Сборка готова, осталось протестировать.
Рекомендую копировать собранную сборку в удобное для работы место и запускать её отдельно, не затрагивая исходную. Это даст гибкости в исправлении ошибок, докидывании недостающих ресурсов и избавит от необходимости чистки от создаваемых логов и каталога user.
После тестирования и исправления обнаруженных недостатков сборку наконец можно предоставить заждавшимся игрокам.
Первая ссылка 404
Движок, можно сказать, мёртв. Если интересен именно CE, то есть O3DE: https://o3de.org/ Это свободный движок, бывший Lumberyard. Развивается весьма активно, есть редактор для Linux.