• Hey! Guest! The 39th GMC Jam will take place between November 26th, 12:00 UTC and November 30th, 12:00 UTC. Why not join in! Click here to find out more!

GMS 2 (Tip) Make your assets more user-friendly

matharoo

Udemy Instructor
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:
Code:
//Create
myMap = ds_grid_create(256, 256);

map_set_seed(myMap, 10);
map_create_instances(oTree, 0.5);

map_instantiate(myMap, 0, 0);
Why not make it like this instead?
Code:
myMap = map_create(0, 0, 256, 256);

map_create_instances(myMap, oTree, 0.5);
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:
Code:
asset description

category1
function
function
...

catergory2
function
function
...

catergory3
function
function
...
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:
Code:
asset description

main functions required to set up the basic asset

function
function

other functions
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!
 
Last edited:

Yal

šŸ§ *penguin noises*
GMC Elder
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.
This is a bit on the debatable side... there's been some assets I've essentially had to hack because I wanted to tweak something that I had no control over because the asset's creator figured the default values would work well for everyone. It's nice if there's a one-line-of-code function to get the basic functionality up and running, but it's also nice if it's easy to tweak the asset's behavior for your needs.
 

matharoo

Udemy Instructor
This is a bit on the debatable side... there's been some assets I've essentially had to hack because I wanted to tweak something that I had no control over because the asset's creator figured the default values would work well for everyone. It's nice if there's a one-line-of-code function to get the basic functionality up and running, but it's also nice if it's easy to tweak the asset's behavior for your needs.
That is why I said this:
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.
So, make assumptions and make the set up process simpler, but do give options & variables to tweak the meat of the asset as much as possible.
 

kburkhart84

Firehammer Games
In a general sense I agree with the tip. The easier it is to use, the better usage it will get, and hopefully more customers in the process. My FHInput for example doesn't make you create any variables yourself. You don't have to call an update function either because it makes its own controller object that updates itself. In the old days you would have to have an update script that gets called because you couldn't include objects as part of extensions. I remember getting around that for a time with code created objects(which were removed with GMS1 of course).

Another thing that I recommend to go along with this tip...if it is applicable to your asset, don't be afraid to make a little external program to assist. FHInput comes with such a thing, letting you use an actual GUI to set configuration stuff, and default controls as well. Then it copies code to the clipboard which you can easily paste into a GML script. This will be made even better of course if/when Yoyo adds the IDE addon stuff they are promising.

Yal also has a valid point I agree with. I shouldn't have to really code stuff if I bought an asset that does it for me, so it should indeed have any applicable options accessible by script calls(or at the least have a script you can change with macros(GMS2) or variables that apply. There should be sensible default settings so you can easily get started, but you should be able to tweak anything to your needs as well.
 

zbox

Member
GMC Elder
You don't have to call an update function either because it makes its own controller object that updates itself. I
Something to think about, because I do think this can be a good solution - Users can break it by using the activate/deactivate instance functions without knowing. Not sure how you remedy that.
 

kburkhart84

Firehammer Games
Something to think about, because I do think this can be a good solution - Users can break it by using the activate/deactivate instance functions without knowing. Not sure how you remedy that.
Yup, I have thought I that. I wish that there was a deactivate event.... Since there isn't(unless it was added without me knowing), I have a script that you call to re-activate FHInput's internal objects. Then of course I put that into the documentation as well so you know what to do in that case. I don't have a lot of sales, but I haven't had anyone mention an issue with it. It is for sure a valid point you make though. Anyone that has internal objects in their assets needs to consider this issue. I wonder if deactivation/activation events have been suggested to yoyo anywhere yet?!
 

zbox

Member
GMC Elder
Perhaps; I don't think it is an oft-used feature though as you say so the exceptions will indeed be rare exceptions that you can fix on a case by case basis.
 

kburkhart84

Firehammer Games
Perhaps; I don't think it is an oft-used feature though as you say so the exceptions will indeed be rare exceptions that you can fix on a case by case basis.
Indeed it is something that can be fixed, or worked around as they say. The problem I see is that if we just "let things go" just because there are workarounds, the software will never get better, because there are tons of things that can just be worked around. In any case, we are veering off topic at this point, although your suggestion about trying to make my asset better was on point and on topic.
 
Top