There are some things I wanted to share about making assets for the Marketplace. It might or might not be actually helpful, but just sharing because I wanted to.
Control
Make your asset easier to use for the user.
It is a product. The experience your customers have while using your products determines whether they will like it and whether they will give it 5 stars.
If you are making an asset, it is good if your asset takes away control from the user and handles most of the stuff itself.
For example, let's say you are making a map generator asset, and this is how you use it:
Why not make it like this instead?
This is just a basic example, and might or might not make sense to everyone, but I hope you get what I mean. The asset needs to be simpler & quicker to use.
Basically, you want the asset to be simple to use, even for the beginners, no matter how complex or advanced it might be under the hood (of course, this doesn't apply to all assets).
Another concept that you could use to make your assets user-friendly is making assumptions. Assume what the situation would be like for most of the users, and tailor your asset accordingly.
On the surface, take away as many options from the user as possible to make the process simpler, but do give the user the actual ability to modify the asset as much as possible if they need to.
Documentation
Assets really benefit from having a documentation. You can either make one in a script, or on some site like Google Docs or GitHub.
You have to list all the functions & variables in the documentation, that much is important, but there is another crucial thing that helps the reader understand your asset better: the order in which the data is listed.
For example, you might be listing your functions like this:
This tells what types of functions there are, but there is no proper order in which the data is revealed. There are some functions that the user must know of first, the ones that are required to set up the basic asset. So, do it like this instead:
Global Info
If you want to initialize any global info to be used by your asset, use gml_pragma("global", "code") to run a script when the game begins. That way you can move some stuff into that script to be automatically initialized, reducing the time it takes the user to set up the asset.
Code
Do not assume that the user is not going to read your code. When writing an asset, make your code well-organized and commented, because there will be users who will want to know why & how your asset works, and to modify it.
So, that's all. I am not sure whether this is helpful info, so let me know!
Control
Make your asset easier to use for the user.
It is a product. The experience your customers have while using your products determines whether they will like it and whether they will give it 5 stars.
If you are making an asset, it is good if your asset takes away control from the user and handles most of the stuff itself.
For example, let's say you are making a map generator asset, and this is how you use it:
Code:
//Create
myMap = ds_grid_create(256, 256);
map_set_seed(myMap, 10);
map_create_instances(oTree, 0.5);
map_instantiate(myMap, 0, 0);
Code:
myMap = map_create(0, 0, 256, 256);
map_create_instances(myMap, oTree, 0.5);
Basically, you want the asset to be simple to use, even for the beginners, no matter how complex or advanced it might be under the hood (of course, this doesn't apply to all assets).
Another concept that you could use to make your assets user-friendly is making assumptions. Assume what the situation would be like for most of the users, and tailor your asset accordingly.
On the surface, take away as many options from the user as possible to make the process simpler, but do give the user the actual ability to modify the asset as much as possible if they need to.
Documentation
Assets really benefit from having a documentation. You can either make one in a script, or on some site like Google Docs or GitHub.
You have to list all the functions & variables in the documentation, that much is important, but there is another crucial thing that helps the reader understand your asset better: the order in which the data is listed.
For example, you might be listing your functions like this:
Code:
asset description
category1
function
function
...
catergory2
function
function
...
catergory3
function
function
...
Code:
asset description
main functions required to set up the basic asset
function
function
other functions
If you want to initialize any global info to be used by your asset, use gml_pragma("global", "code") to run a script when the game begins. That way you can move some stuff into that script to be automatically initialized, reducing the time it takes the user to set up the asset.
Code
Do not assume that the user is not going to read your code. When writing an asset, make your code well-organized and commented, because there will be users who will want to know why & how your asset works, and to modify it.
So, that's all. I am not sure whether this is helpful info, so let me know!
Last edited: