Технические требования в этом разделе относятся только к формату файлов Unreal Engine (.uproject и .uplugin).

4.1 ИНФОРМАЦИЯ НА СТРАНИЦЕ ПРОДУКТА

4.1.1 Текст описания

4.1.1.a Для анимационных продуктов издатели обязаны включать 3D-модель в раздел «Галерея» или ссылку на видеоролик в подробном описании, демонстрирующий анимацию.
4.1.1.b Для аудиопродукции издатели обязаны указывать URL-адрес предварительного прослушивания аудиозаписи в подробном описании.
4.1.1.c Для проектов, созданных на основе Blueprint, издатели обязаны включить в подробное описание загружаемый демонстрационный проект или ссылку на видеоролик, демонстрирующий функциональность продукта.

4.2 ФАЙЛЫ

4.2.1 Файл проекта

4.2.1.a Файл проекта должен быть загружен как ZIP-архив и содержать только один проект Unreal Engine.

4.2.2 Поддерживаемые версии движка

4.2.2.a Издатели несут ответственность за обеспечение корректной работы продуктов в соответствии с заявленными характеристиками в поддерживаемых версиях движка.
4.2.2.b При первоначальной подаче и утверждении каждый продукт должен содержать версию проекта, в которой в качестве поддерживаемой версии движка указана последняя версия Unreal Engine.
4.2.2.c Издатели должны обеспечить поддержку как минимум одной из трех последних версий движка для всех публикуемых ими продуктов.
4.2.2.d Для каждой поддерживаемой версии движка плагина Code Plugin необходимо указать версию проекта, причем каждая версия должна содержать разные ссылки на файлы проекта, ведущие к разным папкам плагина, даже если это дубликаты с разными значениями в ключе EngineVersion в дескрипторах .uplugin.
4.2.2.e Издатели, желающие, чтобы их проект, содержащий только контент, поддерживал новую версию движка, могут либо просто добавить эту версию движка в последнюю версию проекта, либо отправить запрос на обновление файла для добавления новой версии проекта.

4.2.3 Поддерживаемые целевые платформы

4.2.3.a Издатели несут ответственность за обеспечение корректной работы продуктов в соответствии с заявленными характеристиками на поддерживаемых целевых платформах.

4.2.4 Метод распространения

4.2.4.a Для продуктов, предназначенных для интеграции в существующий проект клиента и их использования в рамках него, следует использовать метод распространения «Упаковка ресурсов».
4.2.4.b Продукты, распространяемые методом «Упаковка ресурсов», не должны включать чертежи уровней, обязательные файлы конфигурации (.ini) или другие ресурсы, которые нельзя легко добавить/перенести в другие проекты.
4.2.4.c Для продуктов, представляющих собой самостоятельные проекты или фреймворки, которые клиенты могут использовать в качестве основы для создания собственного продукта, следует использовать метод распространения «Завершенный проект».

4.2.5 Использование стороннего программного обеспечения

4.2.5.a Издатели должны заявить, включает ли их продукт стороннее программное обеспечение какого-либо типа, использует ли его, зависит ли от него или распространяет ли его. Стороннее программное обеспечение означает любые файлы, включая, помимо прочего, шрифты, графические элементы, звуки, API, контент, исходный код или скомпилированные библиотеки, из источников, отличных от издателя или Epic Games.
4.2.5.b Плагины кода, содержащие в описании использования стороннего программного обеспечения фразу «В данном продукте используется стороннее программное обеспечение», должны также предоставить более подробную декларацию в этой форме.

4.3 КОНТЕНТ

4.3.1 Общая информация

4.3.1.a Все продукты должны соответствовать требованиям к контенту, изложенным в Требованиях к контенту Unreal Engine, для указанного типа продуктов.
4.3.1.b Ресурсы в рамках одного продукта должны быть правильно масштабированы относительно друг друга и ориентированы в одном направлении, при этом ось Z должна быть направлена вверх.
4.3.1.c После первоначальной отправки и одобрения Epic проверит продукты, чтобы убедиться, что они работают в последней основной версии движка, как и заявлено.
4.3.1.d В описаниях продуктов, включающих экспериментальные или находящиеся в бета-версии функции и плагины Unreal Engine, необходимо четко указывать зависимость от этих компонентов. Если поддержка экспериментального плагина прекращена, продукты не смогут поддерживать более новые версии движка, если зависимость от него не будет удалена.
4.3.1.e Для неиспользуемых зависимостей плагинов в проектах, содержащих только контент, соответствующий ключ Enabled в дескрипторе .uproject должен иметь значение False.
4.3.1.f Необходимые зависимости для проектов, содержащих только контент, должны быть доступны через Fab и четко указаны в описании продукта.
4.3.1.g Значительные фрагменты исходного кода, чертежей (Blueprints) и/или чертежей материалов (Material Blueprints) от Epic Games должны использоваться исключительно в качестве примеров.
4.3.1.h В проектах необходимо очистить указатели перенаправления.
4.3.1.i Контент должен функционировать в бинарных сборках Unreal Engine. Хотя продукты могут предоставлять дополнительную функциональность клиентам, использующим версии Unreal Engine, собранные из исходного кода, они не должны полностью зависеть от сборки Unreal Engine из исходного кода для их использования.

4.3.2 Карты

4.3.2.a Для каждого проекта, содержащего ресурсы или функциональность, которые должны отображаться в 3D-окне Unreal Engine, необходима карта, демонстрирующая их.
4.3.2.b Для карт должно быть выполнено построение освещения.
4.3.2.c При загрузке или запуске режима воспроизведения в редакторе карты не должны содержать ошибок или существенных предупреждений.
4.3.2.d На картах не должно быть артефактов наложения поверхностей (z-fighting) или необоснованного перекрытия полигонов.

4.3.3 Искусство

4.3.3.1 2D-ресурсы

4.3.3.1.a Текстуры следует предоставлять в максимально возможном разрешении или в разрешении, соответствующем их предполагаемому использованию. Для одного ресурса можно предоставить текстуры с несколькими разрешениями.
4.3.3.1.b Оба параметра каждой текстуры должны быть степенью двойки (например, 1024x512 или 1024x4096), где применимо, за исключением случаев, когда используется система, в которой MIP-текстурирование не требуется.
4.3.3.1.c Текстуры должны иметь максимальный размер по любому из измерений 16384.

4.3.3.2 3D-ресурсы

4.3.3.2.a Продукты, рекламирующие модульное использование своих ресурсов, должны иметь сетки, опорные точки которых расположены таким образом, чтобы обеспечить плавную сборку.
4.3.3.2.b В продуктах, рекламирующих модульное использование своих ресурсов, должны быть сетки, которые аккуратно соединяются друг с другом на заданной координатной сетке.
4.3.3.2.c Статические сетки не должны иметь перекрывающихся или выходящих за границы UV-разверток для карт освещения.
4.3.3.2.d Сетки не должны иметь дефектов материала, видимых швов или проблем с картами освещения.
4.3.3.2.e В соответствующих случаях сетки должны иметь корректную коллизию.
4.3.3.2.f В сетках необходимо корректно использовать LOD-уровни, а в описании продукта должно быть указано, какие LOD-уровни включены (даже если LOD-уровни отсутствуют).
4.3.3.2.g Статические сетки не должны иметь индекс координат карты освещения равный 0, за исключением случаев, когда на них ссылаются исключительно системы частиц.

4.3.3.3 Анимации

4.3.3.3.a Анимация должна быть четкой, последовательной и визуально функционировать так, как задумано.
4.3.3.3.b Все скелетные сетки, не привязанные к скелету Epic или MetaHuman, должны иметь собственный, относительно масштабированный скелет и анимации, распространяемые вместе с ними, или полноценный Control Rig.

4.3.3.4 Персонажи

4.3.3.4.a Для корректного масштабирования при импорте в новый проект скелетные сетки должны быть масштабированы в соответствии со скелетом Epic или MetaHuman.
4.3.3.4.b Скелетные сетки должны обеспечивать ожидаемый диапазон движений во всех суставах без видимых дефектов.
4.3.3.4.c Гуманоидные скелетные сетки должны быть привязаны к скелету Epic или MetaHuman. Если предпочтительнее использовать собственный, относительно масштабированный скелет, все необходимые анимации должны распространяться вместе с ним.
4.3.3.4.d Для продуктов, использующих скелет Epic или MetaHuman, необходимо использовать одинаковые имена костей, IK-суставы должны оставаться невзвешенными и находиться на одном и том же месте в иерархии, а ориентация суставов не должна изменяться. Если скелет содержит дополнительные кости или какие-либо модификации, это должно быть задокументировано и доступно на странице продукта.
4.3.3.4.e Физические ресурсы должны корректно охватывать скелетные сетки там, где это применимо.
4.3.3.4.f Физические ресурсы должны давать результаты, соответствующие предполагаемому использованию продукта, при моделировании в редакторе физических моделей.

4.3.3.5 Материалы

4.3.3.5.a В продуктах следует по возможности использовать экземпляры материалов.
4.3.3.5.b Если продукт включает материалы Substrate, они должны быть включены в настройках проекта.

4.3.3.6 Визуальные эффекты

4.3.3.6.a Визуальные эффекты должны иметь уровни детализации (LOD), если они предназначены для просмотра с разных расстояний.
4.3.3.6.b Имена генераторов должны быть точными и релевантными. Не используйте имя «Particle Emitter», если только это не единственный генератор в данной системе частиц.
4.3.3.6.c Визуальные эффекты должны быть оптимизированы для их предполагаемого использования (в относительном масштабе).

4.3.4 Аудио

4.3.4.a Аудиофайлы необходимо импортировать в движок в формате .wav.
4.3.4.b Аудиофайлы не должны содержать непреднамеренных прерываний или искажений и должны быть предоставлены в максимально возможном качестве.
4.3.4.c MetaSound должен быть аккуратно разложен для организации логической структуры.
4.3.4.d MetaSound не должен содержать несвязанных узлов, за исключением случаев, когда они прокомментированы в качестве примера/обучающего материала.
4.3.4.e MetaSound не должен генерировать ошибок или существенных предупреждений.
4.3.4.f При использовании MetaSound на странице продукта должно быть указано: “This product supports MetaSounds for Unreal Engine 5.0+” (Этот продукт поддерживает MetaSound для Unreal Engine 5.0+).
4.3.4.g При использовании MetaSound пакеты ресурсов должны включать документацию, в которой объясняется, как включить MetaSound, или содержать ссылку на документацию Unreal Engine по MetaSound.

4.3.5 Чертежи Blueprints

4.3.5.a Чертежи Blueprints должны быть четко структурированы и разумно использовать функции для организации логической структуры.
4.3.5.b Функции, переменные и события должны иметь имена, отражающие их предполагаемое назначение или использование в чертеже Blueprint.
4.3.5.c Чертежи Blueprints не должны содержать несвязанных узлов, за исключением случаев, когда они прокомментированы в качестве примера/обучающего материала.
4.3.5.d Чертежи Blueprints не должны вызывать ошибок или существенных предупреждений.

4.3.6 Плагины кода

4.3.6.a В дескрипторах .uplugin должен присутствовать ключ EngineVersion, значение которого указывает основную версию движка (например, 5.x.0), для которой предназначен плагин. Например, если плагин предназначен для Unreal Engine версии 5.3:

"EngineVersion" : "5.3.0".

4.3.6.b В дескрипторах .uplugin каждый модуль должен содержать ключ PlatformAllowList или PlatformDenyList, указывающий на компиляцию для соответствующих платформ, для которых предназначен модуль, с помощью чего-то подобного:

"PlatformAllowList": [ "Win64", "Win32", "Mac", "IOS", "Android" ]

Примечание: для плагинов Unreal Engine 4 вам потребуется использовать ключи WhitelistPlatforms или BlacklistPlatforms.

4.3.6.c В дескрипторах .uplugin должен присутствовать ключ FabURL, значение которого определяет адрес программы запуска Epic Games, по которому движок будет загружать отсутствующие плагины, если пользователи попытаются открыть проекты, зависящие от них. После отправки продукта на утверждение значение FabURL должно содержать идентификатор в конце URL-адреса издательского портала продукта. Например, если издатель обнаружит, что URL-адрес плагина кода продукта выглядит следующим образом: https://publish.unrealengine.com/v2/edit-product/ad53b85f109c87b4a8bf580898186114, в файле .uplugin должны присутствовать следующие ключ и значение: "FabURL" : "com.epicgames.launcher://ue/Fab/product/ad53b85f109c87b4a8bf580898186114".
4.3.6.d Плагины могут зависеть от плагинов Unreal Engine, распространяемых вместе с движком, но не должны зависеть от других плагинов Unreal Engine, созданных пользователями.

4.3.6.1 Код

4.3.6.1.a Плагины кода не должны быть «закрытыми» в отношении любого кода, созданного издателем, для компиляции которого требуется исходный код Unreal Engine; этот код должен быть включен в заархивированную папку плагина. В заявку могут быть включены только такие скомпилированные извне статические библиотеки или DLL-файлы, которые не содержат исходного кода Unreal Engine и не ссылаются на него. У клиентов должен быть исходный код плагина, зависящий от исходного кода Unreal Engine, чтобы они могли попытаться скомпилировать его с версиями движка, собранными из исходного кода.
4.3.6.1.b Все исходные и заголовочные файлы должны содержать прокомментированное уведомление об авторских правах (а не автоматически сгенерированный текст Epic Games), указывающее название издателя или компании, а также год предполагаемой публикации.
4.3.6.1.c Плагины должны содержать как минимум один модуль кода на C++, но могут также содержать контент.
4.3.6.1.d Плагины должны добавлять новые функции редактора, интегрировать Unreal Engine с системами сторонних разработчиков или предоставлять сложную игровую логику для использования в Blueprints. Хотя дополнительные скрипты и ресурсы могут распространяться вместе с плагином для использования во вспомогательных инструментах (таких как программное обеспечение для 3D-моделирования, системы управления базами данных и т. д.), большая часть представленного проекта должна содержать дополнения или модификации, предназначенные для непосредственного использования в Unreal Editor.
4.3.6.1.e Плагины не должны распространять файлы с расширениями .exe или .msi.

4.3.6.2 Компиляция

4.3.6.2.a Плагины кода не должны генерировать ошибок или существенных предупреждений.
4.3.6.2.b Плагины будут распространяться вместе с бинарными файлами, собранными инструментом компиляции Epic, поэтому издатели должны убедиться, что окончательная отладка завершена, нажав кнопку «Упаковать...» на своем плагине в окне «Плагины» редактора, чтобы проверить компиляцию перед отправкой новой версии плагина. Издатели также могут запустить эту команду из установленных бинарных сборок каждой версии Unreal Engine, для которой они хотят скомпилировать свой плагин: Engine\Build\BatchFiles\RunUAT.bat BuildPlugin -Plugin=[Path to .uplugin file, must be outside engine directory] -Package=[Output directory] -Rocket
4.3.6.2.c Плагины, созданные для версий движка 4.18 и выше, будут гарантированно совместимы с IWYU. Издатели могут добавить следующее в файлы .build.cs плагина, чтобы включить IWYU: PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs.
4.3.6.2.d По умолчанию Epic Games собирает плагины издателей только для трех последних основных версий движка. Сборки для более старых версий движка могут быть выполнены по запросу.
4.3.6.2.e Плагины, собираемые для версий движка 4.20 и выше, которым необходимо включать файлы из собственного каталога плагина, должны добавить эти пути включения, используя свойство ModuleDirectory в своем файле .build.cs. Если в начале файла .build.cs присутствует строка «using System.IO;», издатели могут использовать следующий синтаксис, где «MyFolder» — это имя каталога в текущем модуле, который они хотят включить: PublicIncludePaths.Add(Path.Combine(ModuleDirectory, "MyFolder")).

4.3.6.3 Примеры проектов

4.3.6.3.a Все приобретенные и импортированные плагины будут установлены как плагин движка (в папку «\Epic Games\EngineVersion\Engine\Plugins\Fab»), а не как плагин проекта, поэтому издателям настоятельно рекомендуется создать пример проекта для использования совместно с плагином, чтобы продемонстрировать его функциональность новым клиентам.
4.3.6.3.b Издатели, решившие распространять примеры проектов для своих плагинов кода, должны добавить в техническое описание, рядом со спецификацией «Пример проекта:», ссылку на хостинг (например, Google Drive/Dropbox/OneDrive и т. д.), где можно загрузить пример проекта.
4.3.6.3.c В примерах проектов должны быть дескрипторы .uproject, зависящие от плагинов продуктов, но не должно быть самих плагинов, поскольку клиенты должны устанавливать только те, которые предоставляются Fab.

4.3.7 Структура файлов

4.3.7.1 Соглашение об именовании

4.3.7.1.a Имена папок и файлов должны быть точными и соответствовать соглашению об именовании в контексте их собственного проекта.
4.3.7.1.b Имена папок и файлов не должны быть расплывчатыми, например «Assets», «NewFolder» и т. д.
4.3.7.1.c Имена папок и файлов должны содержать только английские буквенно-цифровые символы и символы подчеркивания.

4.3.7.2 Проекты, содержащие только контент

4.3.7.2.a Папки проекта не должны содержать неиспользуемые папки, папки плагинов или локальные папки (такие как Binaries, Build, Intermediate или Saved). Таким образом, для проекта, который может называться MyProject, для отправки необходимо заархивировать следующие файлы и папки:

MyProject
|----- Config
|----- Content
| └── MyProject
|----- MyProject.uproject

4.3.7.2.b Для уменьшения конфликтов при миграции после импорта файлов проекта все ресурсы, относящиеся к конкретному проекту, должны храниться в одной папке верхнего уровня внутри папки Content; в папке Content не должно быть других папок или файлов.
4.3.7.2.c Ресурсы, находящиеся в корневой папке под папкой Content, должны быть отсортированы по папкам в зависимости от типа ресурса или определенных наборов соответствующих ресурсов.
4.3.7.2.d Включая название папки верхнего уровня внутри папки Content, все пути к файлам ресурсов должны содержать не более 140 символов.

4.3.7.3 Плагины кода

4.3.7.3.a Папки плагина не должны содержать неиспользуемые папки или локальные папки (такие как Binaries, Build, Intermediate или Saved), поэтому для плагина, который может называться MyPlugin, необходимо заархивировать для отправки следующие файлы и папки:

4.3.7.3.b Для папок в общей папке плагина, предназначенных для распространения, помимо папок Content, Resources или Source (например, папок Docs), должна существовать папка Config, в которой находится файл FilterPlugin.ini, содержащий что-то подобное:

[FilterPlugin]
/Docs/...
/MyOtherFolder/...

4.3.7.3.c Начиная с основной папки плагина (той, которая содержит папку Source и файл .uplugin), все пути к файлам должны быть не длиннее 170 символов.
4.3.7.3.d Использование сторонних зависимостей допускается только при наличии подтверждения разрешения, и их необходимо размещать в папке ThirdParty, расположенной внутри папки Source.

4.3.8 Документация

4.3.8.a Продукты, требующие специальных знаний по настройке или использованию, должны содержать, распространять или направлять клиентов к бесплатной документации, охватывающей внедрение, применение и/или модификацию соответствующих продуктов. Сюда относятся инструкции для пользователей о том, как загрузить, установить и/или интегрировать любое необходимое стороннее программное обеспечение, которое нельзя распространять напрямую через файлы продукта.
4.3.8.b Документация должна представлять собой веб-руководства, текстовые/PDF-файлы, комментарии к коду/чертежам, видеоролики или обучающие материалы по чертежам, встроенные в редактор.
4.3.8.c Документация должна быть представлена на английском языке, но издатели также могут включать переведенные версии своей документации.
4.3.8.d Предоставленные ссылки для скачивания не должны инициировать загрузку автоматически.