In my opinion, the difficulty information should answer the question “How much learning is necessary to use this item?” Beginner level means that one can simply drag-and-drop things into their level without need to know how they work. More advanced levels mean that learning is necessary in order to integrate the system to a project.
The problem with this is that everyone’s knowledge is different. Is it a blueprint expert, or a material expert? Level designer? Artist? Programmer? Student that doesn’t know a lick of anything yet? What is difficult for one person, is extremely easy for someone else. How do you set expectations for something if you have no idea who is going to be using it?
Hmm,
thats an interesting topic 
I wouldnt call it “Difficulty” but maybe more like “Complexity”.
See, on one hand, you could drop in i.e. my AI from the TopDown Toolkit into your own project, set some aggro range/damage values and it works already. So it’s difficulty would be “Beginner”, right?
On the other hand, around half of my customers see the Toolkit as a learning resource, so they look at the features and how they are implemented and we are already “Advanced” now.
Great, so we now label it as “Advanced” (as some people mentioned). As a customer, how do you know if its difficulty is
- Advanced to use
or - Advanced to learn when dissecting
Also, with some assets the problem is that they contain more than one specific thing. Take the Topdown Toolkit or i.e. the Shooter Sample; Most of it may be very simple to use, but maybe there is just one thing inside thats already advanced to use. Is the whole asset now advanced?
Going further, maybe everything inside a package is really easy to use, but very advanced to be extended. I mean i.e. AI - you just need to drop the enemy into the level and he does his stuff, with some checkboxes and other values to drive his actions. Easy, right? But if you want to extend the logic, you suddenly need to know how to use the BehaviourTree and the state of the enemy in the correct context -> Advanced again.
So, to sum it up, i dont think its a good idea to have something like a difficulty-attribute customer-facing. Even if splitting it up into “Usage” and “Extendability” its never going to be right actually.
Cheers,
Hey!
To your first point, in case you haven’t seen it yet this thread offers some good insight into how the ratings/review could be improved to enhance both the consumer and content creator experience. Please give it a read whenever you get the chance. =)
I like the idea of documentation better than assigning subjective difficulty levels. I also think the nature of the documentation should vary based on the type of asset a you are selling. For example a blueprint may call for more documentation and explanation than a simple asset pack which would likely require little. As Stephanie says, at minimum it should describe how to implement the pack and utilize the advertised features. If this isn’t a requirement now, but a suggestion - making it a requirement may be the best solution. Just my thoughts. =)
I agree fully with thankstipscom’s comments. While a difficulty level is a bit too vague, I think it would be great to have something which conveys some information about how the product is used in a concise way.
How about having a predefined list of tags (some tags would be applicable only to certain types of product), which are integrated into the search system, and displayed next to the product as a series of small icons? The content creator would assign applicable tags, but this could be verified by Epic, and/or adjusted based on feedback from buyers.
This system could be used for all aspects of a product, not just ease of use. So for example, a material asset could have a ‘PBR’ tag, a model could have a ‘Collision Included’ tag. For BP/code assets, things along the lines of ‘Plug & Play’, ‘Components Only’, ‘Blueprint Ready’, ‘C++ Extensible’, etc.
I also think he makes a good point about categorization - in particular, ‘Blueprint’ should not be a category. It is of no relevance how an asset was created, all that matters is how it can be used by the buyer. As an example, say I made an automated defense turret actor. I could make it in C++, blueprints, or a combination of both, but all that is relevant to the user is that it can be dropped into the level from the editor placement panel, and can be interacted with via blueprint. So I think it would make sense for that to go into something like a ‘Game Entity’ category, with blueprint-related information left to the tags.
Tags would be great
A link or tie-in to the Forum Support thread on Marketplace Item Page would be nice and welcomed addition.
Perhaps the Difficulty Rating can be driven by the community using the same 5 Star Rating system: 1 = Beginner…5=Expert?
For Blueprints it would be nice to know if it requires Creating Project or Add to Project. BPs that tend be Create Project require a little more knowledge to integrate into an existing project.
Ensuring proper documentation is a must because not everyone is . <smiles> With that said, the person making the content may have a target audience in mind and that audience is not a beginner…so, perhaps, for the more advanced items some knowledge is assumed, thus the need for robust documentation is not needed…???
I dont think proper documentation is must be, especially when it comes to blueprints because of their self explanatory nature and you don’t need to be “” to understand it, you always can open and watch how it works, unless its too complicated, so commentary required, but not a documentation, there are a documentation from epic, how engine works, if you cannot use those - more documentation wouldn’t help you al all.
Self explanatory nature, yeah
IMHO Blueprint system requires the most proper documentation. And I see comments as a part of documentation
Disagree. At least a minimum level of documentation should be required. And, yes… there are different levels of understanding, even in Blueprints. If what you suggest is true, why do we have so many tutorials on Blueprints if they are “self explanatory”? Also, the BP API’s are not complete, some nodes have very little documentation, so what you suggest about Unreal documentation is not true. Have you reviewed the BP docs? Sorry, but a ton are empty with very little of the “why” and the “how”.
Requesting completed documentation from both Epic and the content provider is reasonable and only helps the community as a whole.
Ok, but you gotta admit that the blueprint from the screenshot should never be allowed in the marketplace this way. Throwing in some variables, functions/macros and comments, and everything starts being more understandable.
But i have to admit myself, that for parts of the blueprints some more documentation is needed, especially on how to use it. When you start having 50 config settings in one blueprint you dont have the time to learn about all that functionality and most probably just want to use it. here is where the documentation comes in.
Cheers,
+1 on the How to Use…
That’s what we’re working on balancing, and to be honest, a lot of it is simply learned as we go. The Marketplace is intended to be a haven for creators, not a burden. For sufficiently complicated Blueprints and packs, we’ll review the documentation and request more if we think it’s necessary to be able to use the content. If it seems like something that’s very advanced and requires more depth of knowledge than can reasonably be expected to document, we’ll suggest (but not require) adding a note to the description that it’s for advanced users, or to link to external learning resources, or something to that effect. In the end, we just want people to be able to use stuff, and we’ll take it case-by-case and see what we learn.
I like the idea of specifying demo levels being available. At the very least, we’ll start requiring the inclusion of the demo level used in the screenshots. For animations, dropping them onto a 4.8 skeleton is already pretty easy. For Blueprints, I like the idea of mentioning whether or not they’re commented. That’s a selling point. I’ll think on this. For documentation in general, if it’s included, people always mention it in the description. If it’s not mentioned, it’s likely not included. And thank you! It’s important for us to listen to the community and find out how people use the Marketplace, what could be better, what needs to be looked at, and even to have our ideas and way of doing things challenged at times… within reason. 
Those are all very good points. For now I think we’re going to keep the definitions of these internal-only and loose, but suggest to sellers that clarifying the usability and terms of their more complicated content might help their customers.
Tagging is an excellent idea. I’ll talk to the team about this, and I added this to our feature backlog\wishlist.
Since June or July or so we’ve been recommending linking to support threads from the product page on the Marketplace, but this is purely voluntary by the sellers. I think more\most people should do this, but I’m stopping short of making it a requirement. We already ask a lot of our sellers, and I’m more in favor of recommending things I think are smart, nurturing them so more people can see them, and seeing how many people adopt the practice and how successful they are with it. It keeps the Marketplace lively and experimental without creating rules all the time.
In that particular case, in order to even get to the example in the image to make the view appear messy, you have to open a clean blueprint, go into a sub-Blueprint (also clean), and then into another sub-Blueprint just to see it. The Blueprint in question is commented and is complex because it has to be for the functionality offered, and how it integrates with other parts of the set.
Thanks for the feedback, everyone! This has been really interesting and productive, and I’ve been adding a lot of these ideas to our feature backlog\wishlist as I go. This is such an awesome community, and it’s great seeing everyone’s different perspectives come together and analyze a complex problem like this. I’m grateful to be here.
I have to admit, not all of them self explanatory, because people are different. About proper documentation vs basic i meant commentary of pretty much every single node, why are we check is “Enemy array” contains our “Target actor” in function named “Is target enemy”, i dont think those needed. But I do agree, description for every function and variable is needed.
i saw it posted on adam stream, this is from actual marketplace content, some guy came and shared his experience with newly purchased asset.