Epic Games

Support Center

Marketplace Submission Guidelines: Preparing Your Assets

Last Updated: Jul 05, 2017 06:30AM EDT

Preparing Your Assets

 
  1. Submission Requirements
  2. Particle Effects
  3. Animations
  4. Blueprints
  5. Meshes
  6. Materials
  7. Textures
  8. Characters
  9. Weapons
  10. Audio
  11. Code Projects and Plugins
  12. Required Levels and Maps
  13. Asset Naming and Folder Structure
  14. General Quality Standard
  15. Restricted Content
  16. Submission Process
  17. File Distribution
 

 

1. Submission Requirements

 

 

Asset Types

 
Currently Marketplace content can fall into the following categories: 2D Assets, Animations, Architectural Visualization, Blueprints, Characters, Code Plugins, Environments, Visual Effects (FX), Materials, Music, Props, Sound Effects, Textures, and Weapons.
 

2.   Particle Effects:

  1. LODs are required for all particle effects that are, by nature, intended to be viewed at multiple distances.
  2. Emitter names must be relevant and accurate to the effect they are displaying.
  3. Effects must utilize appropriate optimization for their intended use.
 

3.   Animations

  1. Each animation must be imported from its own .FBX file for each animation.
  2. Animations must be clean, consistent, and function visually as intended for their purpose.
  3. All assets must be scaled to the Epic skeleton and appear relatively scaled as intended when imported into a new project.
  4. Humanoid character animations must be rigged to the Epic skeleton.
    1. Epic skeleton IK joints must stay in the skeleton hierarchy.
    2. Seller should not weight any part of a character to the IK joints.
    3. Do not reposition the joint orientations.
    4. Skeleton must not be scaled.
    5. Assets that are an exception to this rule are at the discretion of the Marketplace review team.
 

4.   Blueprints

1.    General Requirements

  1. An in-editor tutorial or implementation guide in the form of a video, documentation or tutorial blueprint asset that walks users through implementation, application and modification of the assets must be included.
  2. Blueprint nodes included in a submission must add new functionality, or condense a sizable amount of manual work into much fewer nodes.
 

2.    Organization:

  1. All Blueprints must be neatly laid out and make reasonable use of Blueprint functions to organize the overall logic structure.
  2. Functions, variables, and events should all use names that reflect their intended purpose or use in the Blueprint.
  3. Blueprints must be thoroughly commented with explanations of the function and operation of the Blueprints.
 

3.    Custom Blueprint Nodes:

  1. New Blueprint nodes must be consistent in data types with relevant pre-existing Blueprint nodes.
  2. If there are intentional inconsistencies, they must be explicitly stated in the node title or at least described why in the node description.
  3. When using custom blueprint nodes in a plugin be sure they are categorized with the plugin name as a preface.
  4. All custom blueprint nodes require the “Static” prefix.
 

5.   Meshes

  1. Submissions with less than five major assets must be rigged and animated.
  2. Assets must be positioned relative to the point of origin
  3. Assets must snap together cleanly on the standard 10 cm grid where possible
  4. Assets must be UV mapped so that 1 texture tile covers 1m in the game world.
  5. Assets must be free of material discrepancies.
  6. Must not have any visible seams.
  7. Must not have any material stretching.
  8. Must not have any lightmap issues.
  9. All assets must be scaled to the epic skeleton and appear relatively scaled as intended when imported into a new project.
  10. Assets must be modular in design, purpose, and function.
  11. All meshes must have proper collision where applicable.
  12. Assets must make proper use of LODs.
 

6.   Materials

  1. All materials must be PBR
    1. General use assets must include effective inputs in the Base Color, Roughness, and Metallic nodes.
    2. Mobile assets must use only BaseColor, Roughness, and Normal to come from textures.
    3. Specular should not be specified
    4. Metallic can be a constant
    5. Material packs should use material instances where possible
 

7.   Textures

  1. Dimensions must both be a power of 2
  2. Textures must be an appropriate resolution for the intended assets.
  3. General Use
    1. A maximum size of 8192 in either dimension.
  4. Mobile Platforms
    1. A maximum size of 2048 in either dimension.
    2. Only use TC_Default or TC_NormalMap in the Compression Settings.
    3. The sRGB property should be enabled.
    4. Textures should use the correct texture group depending on its purpose.
    5. sRGB for masks should be disabled.
    6. Grayscale image must be in grayscale or alpha compression.
 

8.   Characters

  1. All assets must be scaled to the epic skeleton and appear relatively scaled as intended when imported into a new project.
  2. Humanoid characters must be rigged to the Epic skeleton
    1. Epic skeleton IK joints must stay in the skeleton hierarchy.
    2. Seller should not weight any part of a character to the IK joints.
    3. Do not reposition the joint orientations.
    4. Skeleton must not be scaled.
    5. Bones should not be renamed
 

9.   Weapons        

  1. All assets must be scaled to the epic skeleton and appear relatively scaled as intended when imported into a new project.
  2. All weapons with moveable parts must be rigged and animated.
 

10.   Audio

  1. Audio files must be imported into the engine as .wav files.
  2. All sound files must have sound cues attached to them.
  3. Cues and wavs must be separated into separate "Cue" and "Wav" folders within the “Audio” folder.
    1. Folder structure of audio submissions should follow the ideology of "Content > Pack Name > Cues" and "Content > Pack Name > Wavs". Adding subfolders to the Cues and Wavs folders is fine, but the submission should prioritize splitting the sound cue files from the wav files over sorting files of the same filetype separately.
  4. Audio files must be of high fidelity with no bit-crunching or other audio defect.
  5. Must have sample rates of 44100 Hz or 22050 Hz
 

11. Code Projects & Plugins

Programming Standards

1. Readability and Maintainability
  1. All code must have consistent indentation
  2. All code must have consistent use of braces
  3. TODO comments must be used in places where extra or alternate functionality is planned but yet to be implemented
  4. Any debug code must be useful and clearly commented
  5. All properties that are exposed to the editor are required to have a category specifier in their declaration.
 
2.  File Organization
  1. Multiple classes within a single file must be highly related, or unusable without each other.
  2. The content of each header file is in the following order:
  3. A commented copyright notice (not the auto-generated Epic Games text)
  4. The #pragma once directive to prevent multiple inclusions of header files
  5. Any #include directives; the system header files first, followed by the non-system header files, followed by TPS header files
  6. Any #define directives
  7. Class or function declaration(s)
  8. The content of each source file is in the following order:
  9. A commented copyright notice (not the auto-generated Epic Games text)
  10. Any #include directives; the system header files first, followed by the non-system header files, followed by TPS header files
  11. Any #define directives
  12. Any using directives
  13. Class or function definition(s)
 
3.  Include Files
  1. No absolute or relative paths to header files are permitted.
  2. Include files that are not actively being used must be completely removed prior to submission.
 
4.  Comments
  1. All code must make full use of comments to explain what a section of code is doing and why.
  2. Class and function definitions must contain a comment describing the overall problem they solve
  3. All comments must be in English
 
5.  Naming Schemes
  1. File names must be clear, unambiguous, and succinct while avoiding over-abbreviation
  2. Classes, Structs, Functions, Variables and Macros must all be have names that reflect their intended purpose or use case.
  3. Classes, Structs, Functions, Variables and Macros must all be named consistently within their respective grouping
 
6.  Safety and Performance
  1. Type conversions must be done explicitly.
  2. Any global variables must be necessarily useful and clearly commented.
 
7.  Source Code Distribution
  1. Any source code which requires Unreal Engine source code to compile must be provided to the user.
  2. It's only acceptable to include externally compiled code which does not include or reference any Unreal Engine source code in a static library and/or .DLLs.
 
8.  Third Party Code and Software
  1. Source code or compiled libraries from sources other than the seller or Epic Games is to be considered third party software that must be declared in THIS FORM.
  2. Third party dependencies may only be used with proof of permission and must be placed in a Third Party folder located inside the Source folder.
  3. Even if the plugin doesn't use any Third Party Software, seller must still declare this by completing the form.
 
9.  Plugin Structure, Compilation, and Packaging
1. Custom Folders
  1. Folders included in the overarching plugin folder besides the Content, Resources, or Source folders (like Documentation folders) must be filtered through our build process by ensuring within the Config folder there is a "FilterPlugin.ini" that contains something similar to:
    [FilterPlugin]
    /Docs/...
    /MyOtherFolder/...
 
2. Specifying Build Platforms
  1. Plugin authors must test their plugin on all the platforms they intend to support.
  2. The appropriate platforms the plugin is intended to be built for must be whitelisted in the appropriate module(s) of the .uplugin descriptor with something similar to: "WhitelistPlatforms": [ "Win64", "Win32", "Mac", "IOS", "Android" ]
 
3. Specifying Engine Version
  1. Plugin authors must ensure there is an EngineVersion field in the .uplugin descriptor file like so:"EngineVersion" : "4.x.0",
  2. This must reflect the major engine version the plugin is intended to work with (eg. 4.x.0), and not hotfix versions (4.x.1).
 
4. Compilation for the Marketplace
  1. To build the plugin as closely as possible to how the Marketplace team will build the plugin, plugins must be packaged from within the Plugin Browser of the editor.
  2. Code must not produce any warnings or errors during compilation.
 
5. Packaging for Distribution
  1. Any files that start with "UE4" in the Binaries folder must be removed prior to submission.
  2. Build and Intermediate folders must also be removed prior to submission.
  3. Compress overarching plugin folder into a zip file for submission.
 

12. Required Levels/Maps

  1. Either an Overview map or a Demonstration map are required. Both can be included or may be required if the submission meets the requirements.
  2. Lighting and geometry must be built before submitting.
  3. Maps must not display any errors upon loading or during execution.
  4. Audio submissions should not feature an example map as these files can be previewed in editor. Please do not include an example map with audio submissions.
  5. Overview Map
    1. All submissions that include static meshes, particle effects, or 2D assets are required to include an overview map.
    2. Settings and Protocol:
      1. Atmospheric Fog removed
      2. Light Source set to 5.0 intensity
      3. Skylight added
      4. Reflection capture added
      5. Cloud Opacity set to 0
      6. Assets are evenly spaced out
      7. No z-fighting present
      8. BSP bases use the default grid, with MI_Template_BaseGray_03_Metal on the sides
      9. BSP Bases have lightmap resolution set to 8
      10. Lighting must be built
      11. All materials have textures
      12. No default textures are shown on any assets
  6. Demonstration Map
    1. All submissions that include blueprints are required to include a Demonstration map.
    2. Content must be logically placed, lit, and represented in its intended manner.
    3. Demonstration must present available functionality offered within the pack.
 

13. Asset Naming and Folder Structure

  1. Asset names must be relevant and accurate to the asset.
  2. May only contain the English alphabet.
  3. Dashes, commas, and other non-alphanumeric symbols are not permitted.
    1. File names cannot start with underscores
  4. Numbers can be used but cannot be the first symbol in the title’s sequence of characters.
  5. The packaged folder, the .uproject file, and the name of the first-tier folder must be named for the project.
  6. All of the project content should reside within the first folder, that has been named after the submission
  7. Differing asset types should be separated into separate sub-folders within the Content folder.
  8. Folder structure must be shallow where possible and stay within the path length limit of 115 characters.
  9. Folder names should be plural where appropriate.
  10. The folder structure should appear as follows in engine:
                         Content
                            MyProject (main project folder)
                                        Asset Types (subfolders)
  11. The folder structure should appear as follows on the hard drive:
             MyProject (main project folder)
                Config (folder)
                Content (folder)
                            Asset Types (subfolders)
                MyProject.uproject (file)
  12. Naming conventions must be consistent within the project.
  13. It is suggested to adhere to Unreal Engine Naming Conventions.
 

14. General Quality Standards

  1. All assets must be complete and fully functional upon submission.
  2. Unreal Engine units are expressed in centimeters, with 2D editor viewports clearly displaying a scale legend. All content should adhere to these units.
  3. If content has directionality, it should be oriented with its front facing in the direction of the X-axis when imported into the engine.
  4. Projects with Plugin Dependencies
    1. Any plugins used in the project must be available on the UE Marketplace.
    2. Any unused plugins must be disabled before packaging the submission.
  5. Submissions must have clear value, usefulness and worth.
    1. Assets must not be easily reproduced.
    2. All content should achieve a professional level of quality, regardless of artistic style.
    3. Must deliver aesthetically pleasing visualization, be built with usable design, and display refined functionality.
    4. All assets contained within a submission should be stylistically consistent where expected.
    5. Content should be easily interchangeable with other projects where expected.
  6. Submissions must add distinct variation, superior quality, or higher overall value than what is currently available on the Marketplace.
  7. All redirectors must be cleaned up.
  8. Performance must be optimized and not display any discrepancies.
  9. All unused content and folders must be removed.
  10. Submissions that include exceptions to any guideline are at the discretion of review and may be limited by the functionality of the UE Marketplace.
 

15. Restricted Content

  1. The Seller must have legal rights to redistribute all components of the content.
  2. The content must not use any logos or branding for which the seller does not have appropriate legal rights.
  3. Submissions must be free of any trademarked or copyrighted designs and/or materials (unless owned by or adequately licensed to the Seller).
  4. Content must consist primarily of original work and differ from the result of public tutorials.
  5. Public Domain Content
    1. Use of unmodified public domain content is limited to assisting with presentation and cannot be the majority of the submission.
    2. Public domain content must have been modified so as to bring new value to the assets.
    3. Seller must cite the source and include a link to the source content on the product page that includes clear public domain usage information. Epic will verify via that link that the content is in the public domain and fully redistributable.
  6. Content must function independently of any unauthorized third party requirements.
  7. Submission must not rely on third-party content not created, owned, and distributed by the seller in order to function.
  8. Submissions must not be dependent on content that is not available through the UE Marketplace.
  9. The content must not contain anything that may be deemed offensive.
  10. Content that could be considered offensive includes, but is not limited to, depictions of violence, sexuality, religion, or cultural discrimination.
  11. Content is subject to regional prohibitions and restrictions.
 

16. Submission Process

1.  Initial Submission Requirements

1.   Product Title

  1. Must be relevant and accurate to the product being sold.
  2. The title canNot exceed 30 characters, including spaces.
  3. May only contain the English alphabet.
    1. Underscores, dashes, commas, and other non-alphanumeric symbols are not permitted.
    2. Numbers can be used but cannot be the first symbol in the title’s sequence of characters.
  4. Words pertaining to Epic Games, Unreal Engine, or implications of sponsorship by any organization other than the seller’s own properties are prohibited.
  5. Adjectives or any other descriptive language used in the title must be truthful and accurately represent the assets and/or functionality of the pack.
  6. Titles cannot be offensive, vulgar, or slanderous toward any person, group, organization, product, or in any way defacing of Epic Games, Unreal, or the marketplace.
  7. All titles are subject to the policies held by Epic Games and may be changed at the reasonable discretion of the Unreal Marketplace.
 

2.   Short Description

  1. Must be relevant and accurate to the product being sold.
  2. The title cannot exceed 100 characters, including spaces.
 

3.   Long Description

  1. Must be relevant and accurate to the product being sold.
  2. The title cannot exceed 1500 characters, including spaces.
 

4.   Technical Details

  1. Must be relevant and accurate to the product being sold.
  2. The title cannot exceed 1500 characters, including spaces.
  3. Must clearly identify plugin dependencies, prerequisites, or any other requirements for use.
  4. Information in the Technical Details section of each product must include the following specifications:
    1. List of Features: (Please include a full, comprehensive list of the features of the product)
      Supported Development Platforms: (Please include a list of platforms on which the product can be used for development)
      Supported Target Build Platforms: (Please include a list of platforms for which the product can be targeted in a packaged build)
      Documentation: (Replace these parentheses with a link to (or a description of where users can find) the documentation)
      Important/Additional Notes:
  5. Information in the Technical Details section of each product must include any and all specifications from the following list that are pertinent to that product:
    1. Number of Animations:
      Animation types: (Replace these parentheses with Root Motion/In-place)
      Sample Rate / Bit Rate: (Replace these parentheses with rates i.e. 44.1 kHz, 16bit Stereo .WAVs)
      Minutes of Audio:
      Number of Audio Cues:
      Number of Audio Wavs:
      Does Audio Loop?: (Replace these parentheses with Yes/No)
      Number of Blueprints:
      Number of C++ Classes:
      List of Modules: (Please include a full list of each code module and it's type (Runtime, Editor etc.))
      Number of Characters:
      Type of Emitters: (Replace these parentheses with CPU, GPU, and/or mesh emitters?)
      Number of FX:
      List of FX:
      Input Mappings: (If any input is included in a Complete Project, please include which methods of input are preconfigured (Gamepad, Keyboard, Mouse... etc.))
      LODs:
      Number of Meshes:
      Vertex Count:
      Collision: (Replace these parentheses with Yes/No, and specify which type -- custom, automatically generated, or per-poly?)
      Number of Master Materials:
      Number of Material Instances:
      Network Replicated: (Replace these parentheses with Yes/No)
      Number of Textures:
      Number of Widgets:
 

5.   Images

  1. Must be relevant and accurate to the product being sold.
  2. File sizes cannot exceed 1mb for each image.
  3. Images can not contain any unlicensed third-party copyrighted material.
  4. Seller must identify if images have been visually edited outside of engine.
 

    Image Types Required

1.     Featured
Image must be 894px by 488px, in png format, and named <ProductName>_Featured.png.
 
2.     Thumbnail
Image must be 512px by 512px, in png format, and named <ProductName>_Thumb.png.
 
3.     Screenshots
  1. Image must be 1920px by 1080px, in png format, and named <ProductName>_Screenshot.png.
  2. One Screenshot is required for audio packs.
  3. Five or more Screenshots are required for all other asset packs
  4. For packs containing static mesh and/or particle effect assets at least one screenshot must be of the overview map.
    1. Must be captured from within the engine and cannot be edited in a manner that adjusts the visual appearance of assets.
 

6.   Price

  1. Price must reflect the value offered with the submission.
  2. Free content submissions are limited to Plugins or at the request of Epic Games.
 

7.   Demonstration/Preview

  1. URL of a video demonstrating content in action is required for Blueprints and all animated submissions.
    1. The video should be in the form of a Featurette/Example video, like a commercial for the product, displaying the functionality in action and should be no longer than 1 or 2 minutes in length.
    2. Tutorials are optional for non-blueprint submissions but may be requested during the review process or required for acceptance.
  2. Link to audio previews are required for Music and Sound FX submissions.
 

17. File Distribution

1.   Content Submission

1. Asset Packs
  1. This is the basic Marketplace asset and is intended to be used in a buyer’s existing project.
  2. Will be assigned as an “Add To Project” after it is downloaded and must function when injected into an existing project.
  3. Should not include Level Blueprints, mandatory Config files, or other assets that cannot be easily added to other projects or migrated.
 
2. Complete Content-Only Projects
  1. This is a stand-alone project or a framework that buyers will use as a foundation to build their projects off of.
  2. Will be assigned as “Create Project” after it is downloaded and must function as a stand-alone project.
  3. Should be reserved for projects dependant on custom mandatory Config files, or other assets that can not be easily added to other projects or migrated.
 
3. Plugins
  1. All plugins purchased and imported from the Epic Launcher will be installed as an engine plugin (installed to "\Epic Games\4.x\Engine\Plugins\Marketplace")
  2. Should be reserved for modules of C++ code that will be installed to the engine, making them available to every project.
  3. Content-only plugins are not permitted.
 
4. Complete C++ Projects
  1. This is a stand-alone project or a framework that buyers will use as a foundation to build their code projects off of.
 

2.   Supported Platforms

  1. Seller is responsible for assisting buyers with the implementation of content with whichever platforms the seller identifies in the description.
  2. Seller must select at least one or as many as all of the following platforms to support: Windows, Mac, Linux, Playstation 4, Xbox One, Android, iOS, Oculus Rift, SteamVR / HTC Vive, Gear VR, HTML
 

3.   Package Delivery

  1. Files must be compressed in, a .zip, .7z, or .rar folder.
  2. Files must be hosted by the seller and accessible to the Marketplace staff until seller has been notified that their submission is staged and scheduled to go live.
    1. Suggested hosting sites include, but are not limited to, Google Drive, Dropbox, and OneDrive

Contact Us

0b4c5e725dabfd13129a608f44c26b1f@epicgames.desk-mail.com
http://assets1.desk.com/
false
desk
Liquid error: undefined method `gsub' for nil:NilClass
seconds ago
Liquid error: undefined method `gsub' for nil:NilClass
Liquid error: undefined method `gsub' for nil:NilClass
Liquid error: undefined method `gsub' for nil:NilClass
Liquid error: undefined method `gsub' for nil:NilClass
Liquid error: undefined method `gsub' for nil:NilClass
Liquid error: undefined method `gsub' for nil:NilClass
about
false
Liquid error: undefined method `gsub' for nil:NilClass
/customer/en/portal/articles/autocomplete