The thing is though, a lower price at the onset of the placement on the marketplace would be punishing all sellers because of the behaviors of some. Remember marketplace items are already priced low enough as it is, because sellers are hoping to get a large volume of sales to account for the significantly lowered price. It’s already a risky business. Also as far as I’m aware the names on the reviews should be the same on the forums. They both use your UE4 credentials.
Welp, I agree that process could be improved… but it should not be THAT complicated!
Early access to Marketplace assets, discounts to early adopters and higher price for final product… IMHO it’s definitely not the way it should go.
As a client: I want to know what exactly I’m buying, how really good/usable it is and level of support after purchase.
I think basic tech specs AND extended tech specs would deal with the first problem.
Well known content curators from community could help with second problem, but it is a dangerous zone - at what stage community should help? Before epic stage or after? What if it’s biased? What if after bad review community will backslash? It’s really very controversial.
Third could be shown with customer reviews, comments and etc, but currently it’s waaay to hard for people to leave a feedback, because everyone use launcher for this stuff and don’t even aware of the ranking system(Well, it does not exist in Launcher, so…)
Also I don’t like that ranking system does not promote your assets and default sorting is alphabetical. What the point of high rating in web version if the first assets people see is “100 FREE MATERIALS” “33 TEXTURES” and etc. ~_~
I’m not against discounts, I just did about 2 weeks of that recently. =P I just don’t think they’re good to do at the beginning/very early on in a products life span.
Agreed, I think a big reason why products have minimal rating/comment activity is due to it being exclusive to the web version. I hope Epic is working on integrating it with the launcher. You’re also right with regards to the usefulness of the rating, there should be a way to filter by ratings.
List sounds good.
A few things I would like to see:
-
Implementation of the new Marmoset Viewer, see: Getting Started With Viewer | Marmoset (or something similiar like Sketchfab). Would be awesome if one could look at the models in 3D beforehand. Not very suited for environment art, but for characters/props it would be awesome.
-
A folder structure like in the Unity Asset Store. Shouldn’t be too hard to automate this process. Especially for Blueprints this would be quite good.
Hi all! Thank you for all the feedback and input. I’ll be responding to these in the order in which they were posted.
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.
[/QUOTE]
1: Vertex count is a more modern, meaningful measurement and our tech crew are pushing for that instead of polygon count. I was curious to see how people here responded to that.
2: Good point! I’ll include that.
3: Also good point. Those seem more like edge cases that should be mentioned if it’s there, but not necessarily required to list if it’s a reasonable assumption that they would or wouldn’t be. I’ll think on how to clarify this.
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.
[/QUOTE]
I like that. Will think on how best to show this off and embed it, and if\when we could.
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?)
[/QUOTE]
I like the device compatibility. That along with the list of supported platforms needs to be more realistic. My thought on that was to change the wording from “supported platforms” to “platforms tested” or something along those lines, then hold people strictly to that and verify as we can. Right now, I think people just check boxes and think it doesn’t matter. It’s going to. 
As the chap that probably inadvertently started all this, thanks 
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 
EDIT: Swear-filter works
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)
[/QUOTE]
re: Bit rate versus bit depth – I’ll verify internally with the tech team which of the two terms is proper in this context, and reflect that in the tech specs requirements.
While I like the idea of benchmarking, unfortunately that’s just not something we can scale up to do at this point. To hedge our bets against people claiming platform compatibility is to change the wording to ask them what platforms they’ve actually tested it on, and requiring them to prove it. If they can’t, all we’ll do is verify the platforms we test it on, and won’t allow them to claim compatibility otherwise. For the near term, that’s the best we can do.
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!
[/QUOTE]
Excellent! Added that to the specs.
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]
Yeah, definitely agree with you there! I’ll find out what our formatting options are and run some tests. This will get a bit easier after we unify the web Marketplace with the launcher, because both of those are set up in very different ways right now, and they’re not currently set up to have special case display rules between the different formats.
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.
[/QUOTE]
I like that. Will find out the easiest format for this.
@:
- 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]
Excellent points! I’ll address them in order:
Crowdsourcing QA – this has come up a few times, and on the surface it sounds like a great idea, but there are some serious practical issues with implementing that. First, there is an actual cost there that someone has to bear. Marketplace content isn’t free for Epic to use, so the money would have to come from somewhere to do this – Epic, or the content creator. Let’s say ten content releases per week, each at $25, sent to five community members for QA. That leads to three possible scenarios:
-
Epic pays, by purchasing these ‘complimentary’ assets each week at a cost of ~$1,250, or ~$5,000\mo. And that’s a low estimate, so Epic’s yearly cost for this would be at minimum $60,000.
-
The content creator pays by immediately forfeiting ~$125 in sales every time they release something new.
-
A split option where content creators choose whether or not to forfeit ~$125 in sales to run it through community QA. If they choose not to, that doesn’t really solve any problems. If they do choose to, that essentially puts their submission on a different production track that will take more time to publish and be more difficult to track than a straightforward submission would be.
Many other difficulties with this also exist. If anyone in community QA rejects a pack, does that mean the pack doesn’t get published? What if it’s a split decision? Does the pack still get published if the community QA isn’t answering email, or does the content get delayed? What if there’s a conflict of interest and one of the community members QAing content rejects something that’s competing with something they’re working on?
There’s also the matter of the additional management overhead (i.e. all the stuff I’m responsible for) of what would essentially be additional non-dedicated team members spread throughout the world in different time zones, and how much their input or lack of it has a bearing on publishing content. Publishing Marketplace content in a timely manner as well as managing the input of each of those distributed dependencies would have a massive and negative effect on the speed at which Marketplace content is published, which is the opposite of what the community and Marketplace team want.
Additionally, there are security and tech considerations that would require any sort of community QA to be legally contracted with Epic and given special permissions to access our VPN, test environments, early builds, etc. We’d have to put up safeguards and special processes to limit what they have access to and to be able to securely revoke those permissions, and setting up custom new rules like that is incredibly time-consuming and difficult to argue in favor of. I’m not trying to be a buzzkill, but I’m the details guy that would be responsible for solving every single problem involved in this, and I wanted to lay out in detail what doing this would mean and why it’s not happening, at least for now.
** What if we took this basic idea and created a ‘Community Picks’ section of the Marketplace? **
Filling out a form – that’s definitely a concern of mine, and that’s why I’m seeking to simplify and automate as much as possible. If the tech specs we’re asking for start turning away content creators because they’re too complicated, I must do all I can to avoid that, within reason. If they’re unable to fill out a reasonable list of technical specifications that would help them sell their content and communicate it clearly, then they don’t get to publish their content on the Marketplace. We’re reasonable and we work with people wherever possible, and we’re going to be patient and understanding while we get old tech specs brought up to date, but content creators need to do at least the bare minimum moving forward. But I’m not in the business of taking money away from people for stuff like this. I absolutely wouldn’t sell my content on a marketplace that did anything like that. 
Sure, we can continue down the road of release, revise, update, which is how it is right now essentially. But to be fair to buyers of new ‘unproven’ packs, the assets being sold should be clearly marked ‘as preview’ (as per the engine). They should also be priced accordingly during this trial / test period. This would have advantages to both buyers and sellers. A lower priced discounted pack at release marked as on-sale, would promote the pack and jump-start sales for the seller. For the buyer, it would eliminate some of the ‘red faces’ we’ve seen around here recently, as early adopters wouldn’t feel like guinea pigs (see PBR thread that spawned this one).
[/quote]
One of my concerns with doing a ‘preview’ area like that with price discounts is that it would pivot the Marketplace into a place where people only buy what’s extremely cheap or on sale, or they think that the rough-around-the-edges preview content is representative of all Marketplace content. Content creators would be incentivized to rush to market early, but not to finish developing their content, and to price it as low as they possibly can because raising the price later will cause people to complain. Despite the intent, this would basically make the Marketplace a flea market.
Internally, this would also easily quadruple our workload managing multiple states of published content and constant price changes, content updates, pulling content offline then back on, and dealing with customer service issues from people that don’t understand they’re working with preview content. Remember, considerations like that are not theoretical – I see everything people do and how they use the Marketplace, and even very intelligent people can become very confused, no matter how simple something may seem or how hard you try to make it simple.
- Implementation of the new Marmoset Viewer, see: http://www.marmoset.co/viewer/gettingstarted (or something similiar like Sketchfab). Would be awesome if one could look at the models in 3D beforehand. Not very suited for environment art, but for characters/props it would be awesome.
[/QUOTE]
We’re working on something along these lines. I don’t have an ETA or more details than that, but it’s one of the things I want most and I’m pushing for that.
Thanks, everybody! Let me know if you have any further questions or feedback.
I like the community picks idea. Someone mentioned a staff picks section elsewhere on the forums too.
We’re actually going to start doing Staff Picks promotions in the coming weeks, based on that forum feedback. We took a lot of it that feedback and have quite a bit in planning now.
But yeah, I’d be interested in hearing from the community if they’d be interested in a Community Picks section, and what that might look like. If there’s content that’s popular that a lot of people are using, it would be great to hear about that! We could potentially do a blog post for the community-picked items and get comments and feedback from people to attach to it. For example, “Here’s the Supergrid pack, and here are some of the projects using it and what developers had to say about working with it!” Promote the content, and promote the projects, while showing the community spirit.
How do you currently pick sales? Aren’t they technically already “staff” picked?
“First, there is an actual cost there that someone has to bear. Marketplace content isn’t free for Epic to use, so the money would have to come from somewhere to do this – Epic, or the content creator.” - . I certainly wouldn’t suggest anyone getting anything for free. The testers would get a non-commercial license and a limited download window. If they liked the pack and actually wanted it for a project, they could buy it like anyone else. As for the pack being held up because of the testers, testing could be a non-essential requirement. It would just be there as an extra set of eyes to catch problems with the pack before it goes forward (like bad collision meshes, non-standard texture dimensions, etc). If the testers don’t send in their results in a timely manner, the process could still continue (and those testers could be removed from the potential pool of testers).
I really like that idea! Can’t really see how you’d go about it though… the easiest way would probably involve someone on your team manually reaching out to people, but it would mean knowing what they’re working on and if it uses that pack they bought, which doesn’t sound like trivial information to access and collate. Another option would be to have forum polls that let users choose a community pick from a handful of staff-selected packages, but then you’d have no possibility of vetting whether they bought that package or not. Or you do targeted outreach by email to confirmed buyers of packages, soliciting reviews from them in exchange for a project spotlight on the blog post, which might actually be the solution that makes the most sense… It would still involve staff picking which package’s owners they contact… Hmm.
Based on some complaints I’ve seen in the forum, there should probably be a screenshot showing what the collision mesh actually looks like as well. In some cases it has apparently been there, but in a fairly useless state.
Not sure if this was already mentioned somewhere, in which case… I have just mentioned it again.
Only problem with screens is that they become a lot of work for environment packs with large mesh counts. Checking the collision should be, and as far as I’m aware is, part of the marketplace evaluation process. We shouldn’t administer one size fits all solutions for small, isolated problems that aren’t widespread. Saddling content creators with an over complicated submission process and product detailing will lead to fewer participants. I personally don’t feel the right solution is to punish all for the actions of very few.
I’ve experienced overlapping lightmapping issues as well as one-sided geometry on meshes (the M4A1 scope lacked any “glass” texturing when viewed from the opposite side so you just looked right through the mesh) and there should be a way that such is reviewed.
Hello everybody!,
My name is Joaquín. In my opinion this is a good initiative because I think that, like me, we are independent developers and we are beginning on UE4, therefore is very important promote content creation market.
Creating a thread in this forum to make suggestions to the creators of new content packages, depending on our needs, is an excellent way, as this could lead to suggest, not only the creation of new content, but example also of good quality upgrade packages already created.
I also agree with previous comments that the ideal would dispose of a viewer, as Sketchfab, where we could take a look at the models, materials or containing the package itself.
Greetings.
Thanks for the great info.
At first the Vertex count versus triangles/polygons is different but makes more sense.
Other tech considerations, more advanced but hey might as well as I hope for more of these types:
- Vertex Painted Enabled Meshes
- Morphtargets Included and counts
- Animations Frame Rate along with Looping or not
- Lightmap UV set included with static meshes
- Blueprint Packs, # of Functions, Macros, Libraries
- Blueprint Packs, Maybe suggest dependencies config file settings…ect…
That’s all I got for now. Keep up the great work! Thanks =)
Hi everybody! After taking everyone’s community input, then running it through the gauntlet at Epic, I’ve just published our updated Marketplace Submission Guidelines, including all of the new technical specifications requirements. This is a pretty significant overhaul to a LOT of our submission guidelines, and I’d be curious to see what people think.
Link:
Thank you all again for your awesome feedback, input, and constructive criticism! My feeling is that if you didn’t care, you wouldn’t say anything. It really keeps us on our toes, and we respect the time you spend telling us how you feel about the Marketplace and what could be better.
Regarding the folder structure: I recommend inserting a picture showing the folder structure as well.
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.
[/QUOTE]
This is a fantastic idea, though i think it can be taken one step further to help remove the problem where if the directory list is quite large, im sure Epic could introduce a function that dumps a string formatted version of the directory list including all files and folders. This could probably be included in the “Automated details collecting” by the submission process.
Regarding the video to showcase a Blueprint system.
There shouldn’t be any time requirements of that video.
Some systems can be shown in a few seconds, others need a few minutes.
Also, and that’s what i did in my video, when someone explains a lot, the video can get
longer, which is in my eyes pretty good. Nothing shows a Blueprint System better than a detailed video.
I’ll have to agree with that, but what I see in the submission guidelines is mostly a recommendation:
There is one part further down the page where it says, specifically for blueprints:
Ignoring the fact that the given lengths don’t match in both quoted parts, I think the “must” here refers to the fact that a video is required, not that it must be of that exact length
Spot on, good idea. Requesting that from the team today.
It’s not a firm requirement but more of a suggestion\request. I wrote that to set a standard that primarily addresses two types of submitters we get: people that submit Blueprints without a video (much more common than you’d think), and people that submit 30 - 60 minute long videos with their initial submission. The missing component there is that a potential customer is unlikely to wait through an hour-long video to make a purchasing decision. Attention spans are short, Blueprints are hard to explain, and designing promotional materials around attention spans is smart.
The description of how to make a video that I gave is essentially a guideline on how to make a commercial for your product. It’ll help you grab a viewer’s attention immediately, then funnel them toward a purchase. Including additional tutorial content is great, and I recommend it, but the tutorial is not what makes the sale. The tutorial and more detailed documentation is post-purchase support, or potentially the final decision points for patient and discerning devs deciding whether or not to purchase.
heheh, correct. Like I said above, it’s basically “please include a video, here’s what’s important in a video, and please make sure it’s not 14 million hours long.”