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

Community Marketplace
1

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:

2

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.

3

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?

4

Thanks , 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

5

Particle Systems:

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

6

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.

7

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

8

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
[/QUOTE]

+1 screenshot of hierarchy

9

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.

10

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

11

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)

12

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)
[/QUOTE]

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!

13

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

14

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

15

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!

16

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!
[/QUOTE]

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.

18
  • 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.

[/QUOTE]

+1, That’s a good idea.

19

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. =)

20

: 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.

23

The more eyes the better, sure. However it could also make the process more inefficient, lengthening the time it takes to submit a package for the marketplace. That would be my concern.

I actually agree with the intent behind your suggestions, I just don’t know if it’s the most efficient way to go about it. The manpower and time it would take to do this could inevitably contribute to an increase in the submission process length. As I alluded to above, community involvement can really help rectify this issue. Whether posting feedback in a forum thread, or using the support email the community can inform each other as well as the a potential bug in the pack. The author would then be able to address it and submit an update to correct the problem. The marketplace guidelines state that authors are required to keep their content up to date, and in working order. If they choose not to comply, the pack can be removed until the issue is resolved. In reality the community has the tools to be able to enact this sort of quality control, but few ever use it. Whenever I’m about to order something on Amazon, I always read a good portion of the reviews and they inform me of the pros and cons of what I’m about to purchase, which helps to make informed decisions. Negative constructive reviews can also force a company to address the issues that consumers are experiencing. You mentioned dishonest reviews, I’d like to think we wouldn’t have to worry about that as the UE4 community has been exceptionally professional in my experience here.

I agree with your sentiments regarding paperwork. I don’t really think the requirements posted above are bordering on that severity, but I wouldn’t want it to head down that slope either. People want to have as much information as they can to make informed purchases, and as a fellow consumer I get that. But there comes a point where there’s an unnecessary dump of technical details especially on a per asset basis where as you suggested it wears down the developer with paperwork, so to speak. These are just my opinions on the matter though, as both a consumer and content creator. They may not even be the best solution either, so it’s good that we are having a discussion of ideas so that we can arrive upon an optimal solution. =)