Download

First draft of new tech specs -- community input wanted!

Hi all! There was a thread recently raising concerns about the lack of explicit technical specifications on some newly-released content that led to unhappy buyers. To combat this, we’re updating the technical specifications we require from submitters, and we’re going to be more strict about collecting and updating it. This will make it easier to understand exactly what you’re buying when you’re browsing the Marketplace.

Below is our first draft of what information we’ll require from submitters. This list is subject to change based on community input. The list starts off with general guidelines that applies to most asset types, and then I have different sections for specific additional information depending on what type of asset is being submitted (character, environment, Blueprint, audio, etc). We’d like to get the community’s input on this from both a submitter’s perspective and a buyer’s perspective to find what’s reasonable. The balance I’d like to strike is requesting enough information from the submitter that it isn’t a huge burden, while still being enough information for a buyer to have a clear idea of what they’re getting. :slight_smile:

As a side note, I’m working with the Epic team to find a way to script\automate the collection of as much of this information as possible within the editor to make it easier to gather. I want to make this as easy for submitters as possible.

So here’s the list so far. Questions, comments, concerns, additions, subtractions, let’s hear from you!

===

General guidelines:

PBR: Yes/No
Texture Size (please list textures for each resolution):
Collision: Yes/No
Number of In-Engine Vertices:
LODs:
Number of Meshes:
Number of Materials:
Number of Textures:

Compatibility:
Source Provided: Yes/No

===
Environments

Technical Detail
When delivering your asset pack, please provide the following technical details what will be displayed on your asset pack’s store page.

Number of Assets:
Average vertex count:
Texture Resolutions:
Number of Materials:
Number of modular pieces:

===
Characters & Animations

Technical Detail
When delivering your asset pack, please provide the following technical details what will be displayed on your asset pack’s store page.

Rigged: Yes/No
Rigged to Epic skeleton: Yes/No
Animated: Yes/No
Number of characters:
Vertex counts of characters:
Texture Resolutions:
Number of Animations:
Animation types (Root Motion/In-place):

===
Weapons & Props

Technical Detail
When delivering your asset pack, please provide the following technical details what will be displayed on your asset pack’s store page.

Number of Assets
Average vertex count
Texture Resolutions
Number of Materials

===
Materials & FX

Technical Detail
When delivering your asset pack, please provide the following technical details what will be displayed on your asset pack’s store page.

Number of Materials:
Do Materials derive from a Master Material with instances as variation?
Modular: Yes/No
Number of Textures:
Texture Resolution (complete list):

FX:
List of every effect:
CPU, GPU, and\or mesh emitters?
Number of Effects:
Number of custom materials/textures:
Number of Materials:
Number of Blueprints:
Number of Meshes:

===
2D Assets

Technical Detail
When delivering your asset pack, please provide the following technical details what will be displayed on your asset pack’s store page.

Number of Sprites:
Number of Textures:
List of Animations:
List of Materials/Material Instances:
List of Blueprints:

===
Blueprints

Technical Detail
When delivering your asset pack, please provide the following technical details what will be displayed on your asset pack’s store page.

Number of Blueprints:
List of Features (Please include a full, comprehensive list of the features of your Blueprint):

Video Link (Please include a 60-90 second video highlighting the features of your submission):

===
Audio

Technical Detail
When delivering your asset pack, please provide the following technical details what will be displayed on your asset pack’s store page.

Number of Audio tracks:
Number of Audio Cues:
Sample rate \ bit rate: (i.e. 44.1 kHz, 16bit Stereo WAVs)
List of included tracks:
Does music\audio loop: Yes/No
How many sound FX:
How many minutes of audio provided:

I think they are awesome :smiley: They all make a lot of sense and I can imagine that the quality of the marketplace will increase a lot with having all these information available for each pack.

What if environment pack contains particles systems, sound fx, different utility materials that accompany whole pack - should I include this data as well, or only what’s whole pack about?

Thanks John, I appreciate that!

zeOrb, if that’s included and it’s intended for use, definitely! The goal of the technical specifications page is to basically see a ‘bill of goods’ of what’s contained in the pack so buyers can make informed decisions with as little guesswork as possible.

Here’s a great example of a Blueprints features list: https://www.unrealengine.com/content/a22867b136314748af7437c635b9ddba

Particle Systems:

Whether they are intended to be looping or not. Especially important for things like muzzle flashes and the like.

3 questions.

1: what about tri/poly count for the 3D stuff?

2: why is there no “Rigged: yes/no” and “Animation: yes/no” for weapons and props?, for example guns or animated chests, actually thinking about it there is no reason someone couldn’t do animated environment stuff either (like plants that grow from animated morphs…ect).

3: why is there no “Modular: yes/no/both” option?, I saw the “number of modular pieces” in the environments section but things like characters and guns can be modular as well, I might have missed it but I don’t think I did:p.

Not only should the number of blueprints be listed, but also the hierarchy of files and folders to visualize what is going on. This would also help to see if something is stupidly made and is unfeasible to actually use in one’s project.
MarketplaceBPhierarchy.png

+1 screenshot of hierarchy

Off the top of my head it would be nice if packages including any kind of UI would specify input device compatibility, i.e. mouse, keyboard, gamepad, touch.

Others have raised concern about correctly set up physics assets for characters (or is this more of a requirement, not optional, now?)

I also like the modular: yes/no/both option, and giving a preview of the file/folder structure! :slight_smile:

For all meshes, LOD information would also be helpful.

Good list. Having automation would be nice for the tri/vert averages at least - for those with high mesh counts doing those by hand are a pain. =P

As the chap that probably inadvertently started all this, thanks :smiley:

Can I just be really **** (impromptu swear-filter test!) and request that ‘Bit Rate’ be changed to ‘Bit Depth’ for Audio ;D

One thing I would also like to suggest just because, is if the package provides a test level - could Epic benchmark it on one of their rigs and post the average results? One thing I have noticed in the past is people declaring that content will work on PS4 & Xbone etc, but unless those guys have access to expensive devkits they probably can’t prove that. If Epic could either vouch for it, or request that they test it on those platforms first, that’d be pretty swag :slight_smile:

EDIT: Swear-filter works :wink:

EDIT #2: Someone suggested this above and this is probably not something you can add at the same time as this, but a previewer of some kind of the included assets and perhaps even the folder structure could also be a great giveaway to the content you’re buying.

EDIT #3: Also just had a thought… another indicator for all types of content packs could be whether they include documentation or not. (E.g., PDF’s or Wiki links etc)

I like this one. I’d add to it: “Includes usage examples: y/n” - for example, for blueprint systems, example levels in which they’re set up correctly.
Another one would be whether a package includes in-editor tutorials!

On the materials one, what do you mean by modular? Seamlessly tiling?

I think that refers to the use of material instances and master materials, with constants and such that you can tweak.

Also, I want to request some sort of table to display all this data, because such giant list could be a little bit difficult to read!

I think epic should send a standardized spreadsheet to the submitter that they are required to fill out. It will give epic a quick glance to see what the pack is and isn’t so they can properly QA the package. This also can be screenshot and used to display instead of a big wall of text.

@Jon Jones:

  • Certain problems only arise through the practical use of assets in a realistic scene or level, from bad Collision to bad Pivots, all the way to catching Pack-Incompatibilities due to quality-control differences between packs by the same author (foliage etc).

  • Because of this greater need for more practicality in the vetting process, why not send complimentary packs to a select pool of experienced community members from moderators to modelers for their evaluation? I’d rather read advance reviews about limitations of packs, than have to scrutinize data-heavy-tables supplied by the vendors.

  • Filling out a form is a risky vetting procedure. It risks pushing a heap of red-tape and regulation onto Indie-Modelers & Small-Biz-Owners. And at the end of the day, what forces any of them to comply? Are there looming penalties like forfeiture of revenue for inaccuracies, omissions, deceptive practices etc…?

+1, That’s a good idea.

The only thing about that is it becomes redundant, as that is already the job of the marketplace team. As far as reviews from fellow members go, this can be achieved easily by including a prompt once purchasing a content pack or a few days after asking the buyer to rate and post their thoughts. Not many people feel inclined to do that on their own right now, however that will be the most efficient way of gathering community consensus on a product. I’m also not sure I like the idea of fines or penalties, that’s a quick way to deflate any interest in marketplace participation even by developers who are trying to do right by their customers, out of fear of strict regulations. Its a similar approach to DRM, put in place to weed out the bad guys but also hurts the good ones in the process. These are merely my thoughts on the matter. =)

SE_JonF: redundancy can be good. I don’t think the marketplace team is that large, so they could easily miss something in the mass of submissions they get. Sending the packs to an external group of testers for evaluation might be helpful.