Using this list to precheck your own assets may help speed up the review process, but doesn’t guarantee approval. Please keep in mind that while the Marketplace may pass a submission based on these criteria, it does not exclude overlooked items, or issues not covered by this list from a seller’s support requirements. In other words, just because it’s not on the list or because we didn’t catch an error the first time, doesn’t mean we won’t require an issue to be fixed in the future. On the same note, if a live asset doesn’t meet every criteria on this list, it doesn’t automatically grant refund approval for buyers. It’s up to sellers to support their own content. The TRC is here to make sure it meets the specific needs of the Marketplace (based on the attached criterion) before we agree to release it.

Now that we’ve refreshed our TRC, we are updating the “Preparing Your Assets” portion of the Marketplace Submission Guidelines to reflect the items in this TRC. We will include a description and an illustration for each point, which should help explain the basis for each line item being checked. We want you folks to have all the same info we are using so there can be less guess work and shots in the dark for what we are asking from you.

Comment

For landscape packs where there are many maps included in the project I've discussed this with Stephanie before and she agreed to giving each map a unique name i.e SnowyMountains, GrassyHills and so on instead of Demonstration_01, Demonstration_02 etc. With unique names people would know which landscape it is they're looking for among +10 included landscapes. Just wanted to see if you're cool with that for our future submissions.

Comment

For landscape packs where there are many maps included in the project I've discussed this with Stephanie before and she agreed to giving each map a unique name i.e SnowyMountains, GrassyHills and so on instead of Demonstration_01, Demonstration_02 etc. With unique names people would know which landscape it is they're looking for among +10 included landscapes. Just wanted to see if you're cool with that for our future submissions.

Mike will probably clarify if I'm wrong, but given the legend at the bottom of the guidelines R for the demo map and overview map naming means that should be fine so long as it's clear and concise. There may be suggestions though if the naming doesn't have an outright pass failure.

Comment

For landscape packs where there are many maps included in the project I've discussed this with Stephanie before and she agreed to giving each map a unique name i.e SnowyMountains, GrassyHills and so on instead of Demonstration_01, Demonstration_02 etc. With unique names people would know which landscape it is they're looking for among +10 included landscapes. Just wanted to see if you're cool with that for our future submissions.

Mike will probably clarify if I'm wrong, but given the legend at the bottom of the guidelines R for the demo map and overview map naming means that should be fine so long as it's clear and concise. There may be suggestions though if the naming doesn't have an outright pass failure.

I'll be sure to outline some of this in the "Preparing Your Assets" update, but yes. That's fine.

There are Overview, Demo, and Showcase maps. Naming your map "Overview" or "Demo" is required if that map-type is required. We want buyers to easily identify those. Showcase maps are up to you guys how to name it, as long as it uses naming conventions consistent with the rest of the pack (ex: using "map", "level", or "showcase" in the prefix/suffix "SnowyMountains_map", "SnowyMountains_s", "L_SnowyMountains", etc...).

Overview = Shows included assets
Demo = Shows how included assets function
Showcase = Shows off how pretty everything can be when used correctly

Comment

Is "appropriately going to be defined in some fashion? Not as to the content of the comment, but will each node that comprises the blueprint, going to require a comment node as well?

"68 Blueprints are clean and easy to read"

Beauty is in the eye of the beerholder... Clean and easy is not the same for everyone. Personally I hate to keep scrolling horizontally to the right, and seeing functionality that while it may consist well in the larger work of a particular function, has little to nothing to do with prior code. Hence I will use a sequence, to break it down. As an example, assume that one is creating an Object, that is comprised of say 4 subparts, of which the subparts, are themselves comprised of say 4 to 10 static meshes. then breaking the code to use a sequence to me makes sense, in that each subpart has a wire coming off the sequence node, to create that subpart, then flow to the next. Yet others may find this not so clean and easy.... So how is this going to be defined, as to what is "clean and easy"?

"69 Casts contain both a pass and fail condition"

Are casts going to be allowed to have crossed wires? Will Datatables? If this is not the case, then I presume to wrap the cast in a macro, to where the pins can be flipped, will be allowed?

For 71, custom blueprint nodes, makes sense, in that it's going to be a C++ library more than likely. Yet for 70 it is not defined, is that the same thing? As well as are macros and function libraries considered to be "Custom Blueprint nodes" ?

Well on this one, I just hope the reviewer thinks the same way I do, because this is subjective as all get out.

As well as I see nothing in the list of items for blueprints, concerning crossed wires. I was really hoping this process was going to become more empirical, such that it could be put to bed, once and for all, as well as the sellers, when submitting the assets, could have a high degree of confidence of the asset passing.

And we gave you lot of feedback there. So why we have a new topic opened by another person while your team didn't reply to recent feedback there?
I hope it's just a slight communication issue in the team

Comment

This is a good start but is still too vague to be super useful. What is needed is a list of all of the reasons an asset can be rejected based on each of the items in this checklist. I imagine after a week or two of reviewing submissions you guys probably have a nice long list of rejection reasons so plenty of the checklist items. For example, last year we were told to always check iOS and Android when submitting, even though our packs are designed for PC however the last rejection reason we received was that 'Metalic maps aren't compatible with Mobile projects' because we have full PBR materials and have ios/android checked in our submission.

First off, it would have been a lot more useful in the first place if the rejection reason was 'You have ios/android checked as supported platforms but have metallic maps in your project, which are incompatible with mobile. We spent a solid 30 minutes searching through the project for individual metallic textures as we first assumed this meant that we had stand alone metalic textures instead of RMA maps. When none showed up we went through and made sure we didn't set the project platform to mobile. After that we went to the submission history and assumed that it was because we had android/ios checked(as per instructed).

Anyways, if we had access to a spreadsheet that contained a record of this rejection reason we would have known that the policies changed and that we shouldn't be checking android/ios before submitting and saved us the month or two now that we've lost because we have to resubmit this pack with those two options unchecked.

Comment

Again, I'm glad Epic is investing some time and efforts to better the Marketplace;
Hired more staff, are leaning towards automation and creator self-management with time. I like it, one of possibilities I see for my future would be to become a dedicated Marketplace seller which is still not possible for me just yet, but I hope in near future I could just drop contract stuff and become a full time Marketplace developer once things are mature enough around such echosystem, looking forward for more development and more investments on the platform, ty Epic

Comment

Point63: No overlapping Lightmap UV's --> oh yeah but you also could check the UV space, sometimes in some pack, people just do an automatic unwrap for the map channel 2 (map 1 in the engine by default) and the lightmap is just inappropriate. My two cents...

Comment

First, excellent questions and feedback! I'm putting together the "Preparing Your Assets" update and this gives me a good look at what information you guys want.

[MENTION=50524]jayice[/MENTION]
Blueprints: We have tried to simplify the meaning of "clean" and "commented". The quick answer is there should be no “spaghetti” and if there is a portion of a blueprint that does a specific thing, let people know.
The pass and fail conditions for casts are not required but may be recommended. If you have another way of setting it up, I'm sure it will be fine.
"Static" and PluginName prefix: I don’t entirely understand your question. Would you mind expanding on it a bit? Though when in doubt, I’d suggest setting it up as best as you can, and if it's not working, we'll help figure it out.
"Names that reflect intended purposes" just means "don't call it 'event1' or 'thingy'. Use a name that reflects what it does.

[MENTION=69]kjustynski[/MENTION]
I will look through the previous post and see if there's any actionable feedback that I missed before we delete anything.
The new "Preparing Your Assets" will be even easier to read

[MENTION=4917]Ironbelly[/MENTION]
As far as a list of rejection reasons go, I hope there isn’t any misconception as to the difference between a “fail” condition on the review sheet vs a “rejection”. A failed condition simply means we need some changes or adjustments in order to proceed. A rejection is when a submission is beyond repair or would require a ground-up rebuild/redesign in order to be distributed.
As an aside, Metallic nodes on mobile is tricky. It is available on some high-end mobile devices, but if you want to maintain compatibility for other mobile devices and keep your metal textures you need to use the Feature Level Switch node. We do try to check that assets do what their description says, but there's always the option of updating the description instead.

I know the list here may appear a bit vague, but we will clarify many of these requirements in our "Preparing Your Assets" document. A lot of this is meant to be more liberal in order to allow you guys to do your thing the way you do your thing best. Making hard fast rules that limit creativity isn’t our goal. We try to give you the best resolutions and we do enjoy the quests you guys send us on to resolve and research some of these specifics.

Thanks,

Mike V

Comment

[MENTION=4917]Ironbelly[/MENTION]
As far as a list of rejection reasons go, I hope there isn’t any misconception as to the difference between a “fail” condition on the review sheet vs a “rejection”. A failed condition simply means we need some changes or adjustments in order to proceed. A rejection is when a submission is beyond repair or would require a ground-up rebuild/redesign in order to be distributed.
As an aside, Metallic nodes on mobile is tricky. It is available on some high-end mobile devices, but if you want to maintain compatibility for other mobile devices and keep your metal textures you need to use the Feature Level Switch node. We do try to check that assets do what their description says, but there's always the option of updating the description instead.

Mike V

That is a good point, I did indeed mean fail condition as apposed to rejection. It's good to make that distinction.

Comment

Ok, spaghetti, being the criteria makes more sense, than just "clean and commented". Still is there going to be exceptions for crossed wires for nodes, concerning a failed cast, or the usage of datatables? OR, will placing those nodes inside of Macros, such that the Success and Failure exec pins can be moved around (Success staying at the top of the node, and Failure going to the bottom, with the output pin being in the middle), thus allowing access to the output pin the Success exec pin, without crossing the wire from the Failure Exec pin? Casts and Datatables both have this set up for the exec and output pins. I don't wish to waste time on this, after submission, much prefer to know up front and just do it that way and be done with this. The idea of having to resubmit, etc. is not one I relish. If Casts and Datatables are exceptions to the "no wires being crossed", that's fine, so long as macros can be used to work around it.

As to "Static" and "Pluginname" prefix: are those required to be in the macro name as well. I.e. all my macros out of a macro library and function library are prefixed with "IW - XXXXXXXx", as well as using a Green color for the "titlebar of the node". Is something like this acceptable?

I won't argue about "event1" being a "good/bad" naming convention (in that if dealing with a large enough Finite state machine, just numbering very well may be the best way to go, assuming the state machine has 50+ states)

Thank you for your time,

Jay

IceWare

Comment

Thanks for releasing this document! What exactly is meant by n° 88 "Skeleton is not scaled"? I'm not sure how or in which editor i would scale the skeleton. Just asking to make sure i haven't done it by accident somewhere

Comment

Thanks for releasing this document! What exactly is meant by n° 88 "Skeleton is not scaled"? I'm not sure how or in which editor i would scale the skeleton. Just asking to make sure i haven't done it by accident somewhere

It means you must be sure all the bones in your skeleton have a scale of 100% or 1.0.