I did not look at how you did the RNG but if you want to be a fair 1% you need to use a “bag” based approach. So you have a table with 100 values in it from 1-100 and each time you take one item out of the table at random. If the item == 1 then you display the ad with you key, the other 99 values use their key. Then when bag is empty make a new bag with 100 fresh values. That way every 100 you’re guaranteed to get 1 display, and they are guaranteed to get 99 display per 100 display.
It might make people feel better if you let people pick the %. Then some people might pick a higher %, and you could set a higher default % too.
If you did it based on a simple counter that would work too.
Thanks for the input, however the bag approach isn’t fair. If I display my ads first and say a user only runs the game once a day and sees only one ad per session, then all the ads would go not to the developer. If I display it last, then I might never reach it because of short sessions.
My approach is fair enough, it’s basically
if math.random() <= 0.01 then use_my_id = true end
Random function is guaranteed to be uniformly distributed as close as possible by the OS.
Setting up a custom % is a surprising idea, heh, I will think about that.
To keep it fair you need to keep some storage tracking over sessions which should be doable. Or let user accept that it’s 1% based on sessions with your impression always showing first per session and then theirs the next 99 after over 100 periods of the active session.
Trusting simple RNG is inadvisable! You’ll make much less too.
The bag approach I described wouldn’t guarantee yours would be shown first but a counter version would unless you put your counter a few impression inward instead of being 1 then still loop counter at 100.
Even with a storage it isn’t fair. Say 100 people download the game and run it only once - same situation. If it’s based on randomness there is a fair chance for everybody, if based on a counter - one always loses.
Trusting random generators is really ok. However I would not be surprised if other mediation SDK use the counter approach to gain advantage.
Uniformity is only for long periods of generation. And it’s worse because people will run the apps at random times so it’s not really 1% of the ad impressions it’s a 1% gamble at the mercy of RNG.
Having a 1000 sessions of your game across all users makes it pretty uniform already, much closer to uniform distribution than with any counter approach.
I assure you, using the random generator provided by the OS is really ok.
Oops, turns out there is a bug in Defold preventing the extension from building for Android when used as a remote dependency. Resources don’t get bundled.
As a workaround please download the extension from github https://github.com/Lerg/extension-admob/archive/master.zip and copy the admob directory into your project. And the extension has to be removed from the dependencies list if added already in game.project.
@sergey.lerg do you perhaps have more info on what’s going wrong with the resources? Don’t they end up in the bundle or what? I tried to verify the problem with another extension, but there the file seemed to end up in the correct place in the apk.
Oops, late response. I am not sure what’s happening, but seems like resources don’t get copied on build and the building process fails. Have you tried?
New Version
I’ve updated the extension. Fixed the interstitial loading bug on Android.
And added more targeting options, like tag for children, birthday, gender, location, etc.
I’ll be adding this to a project soon for banner ads so hopefully it makes you some money. If you ever add % support I’ll increase it to 3% like payment processors usually charge.