The Future of Plugins in Gideros

john26 · November 2015

I want to start a discussion about plugins in Gideros. Currently adding features like ads and IAP to a Gideros exported project is quite time consuming as it involves manually copying files from the Gideros install directory. It is also necessary to make changes to the manifest file and main activity (in the case of Android). And of course, you have to do it again when exporting for a different OS, and yet again when upgrading using a new version of Gideros. Now that Gideros supports 7 targets the situation is likely to get out even more difficult. To address this we are considering several options:

The first option is that the user can chose which plugins he wants by ticking boxes within Gideros Studio which exports those files along with the rest of the project (referencing these as necessary in the manifest, project files). This would be the cleanest way, but it involves a lot of coding in Gideros Studio and this coding needs to be specific to each plugin and each OS. So there might be a delay in getting this to work.

The other option is to supplement the existing "bare bones" export with an optional "kitchen sink" export which includes all available plugins including all ads, IAP, social media, etc available in the Gideros repo. These files will of course also be referenced in the project files, manifest files etc. If you don't need all that stuff you can just delete the excess libraries but you will need to alter the manifest etc to reflect this. The idea here is that its easier to delete stuff than to add stuff. We would also bundle libraries that you currently need to download from external websites like Flurry and maintain these in the repo as part of Gideros. This approach is much easier for us to code but you may end up with a bloated export and some manual intervention is needed to remove stuff. The current "bare bones" export would still be available also.

So what is your experience of using plugins and how should they evolve in future? The original idea of plugins dates back to when Gideros was closed source and people needed to do intensive computations in native code or link to unusual 3rd party APIs. But I suspect most people are using them now for ads etc and mainly using the "standard" plugins provided by Gideros. In that case it might be better to export these by default. Please let me know how it works for you and what would be the best way to develop in future.

tkhnoman · November 2015

I think there is no difference between bare bones and kitchen sink, moreover, i think kitchen sink is more troublesome than clean export.

I myself don't have any problem for adding stuff to new export, since Gideros have player, it is not that troublesome to test things.
Not forget to mention, most of my plugin is modified, so i don't need plugin from export.

I also think that people here won't update to new version, unless they really need the new feature / bug fix, so updating won't be happening that much on user side (but of course so much in Gideros testing side)

simwhi · November 2015

@john26 I've discussed this very feature with my business partner. We would definitely go for the first option. I know it would take longer, but it could be rolled out plugin by plugin. You could also start with the most common plugins such as admob and IAB. I think this would make the development a bit more manageable, and we would get to test each plugin as they are rolled out.

NatWobble · November 2015

@john26 This would be fanatistic. It would really streamline our workflow. I agree with tkhnoman that the second option could get a little bit messy, and possibly counterproductive. As simwhi says, a gradual roll out might make things easier if that is feasible. I'm sure that certain plugins are far more popular than others. The same may go for platforms, concentrating on the most popular ones first such as iOS and Android

I have resisted upgrading to the latest version because of the hassle of re-configuring everything.

Including the asset catalogue with iOS is a great move forward and should go a long way to reducing the fiddly, time-consuming stuff in xCode. It would be fantastic if all the plugins were there too, especially all the libs you then have to include for each ad plugin etc. It would also be great to be able to set the display name, version number, target SDKs etc that you have to configure in the plist and their equivalents on other platforms.

It would all be well worth waiting for and would free up hours of dev time.

simwhi · November 2015

@john26 Further to my comments above, I would also add that this would resolve many issues that new developers encounter. This would reduce/remove these kind of problems.

amin13a · November 2015

I change IAB plugin for use in the android store in my country and it's worked.
Everything I need is a folder for each plugin and each platform with this files:
1- full documentation FOR DUMMIES.
2- libraries
3- Lua files (examples)
4- other important stuff (like manifest file for android)

AniketK · November 2015

@john26 if you just added all the ad libraries, that would add a hefty weight by itself to your app. An unnecessary weight if you just wanted to use two or three different providers.

To add all the plugins at once, would be maddening and you wouldn't even be sure what to take out.

I like the idea of a box you can tick to add particular plugins. I think i'll take up the backend processing of this since I have some idea but I'm not sure how to do the UI parts.

MobAmuse · November 2015

I'd like to see Ads support built in if possible.

john26 · November 2015

Thanks very much for your replies. It seems the idea of choosing which plugins to install in Gideros Studio is much more popular so let's do that! @ar2rsawseen has already thought of a way to specify which files to copy in XML files associated with each plugin. Once we've written the code in Gideros Studio, perhaps others can contribute and maintain XML files for each plugin? That way we spread the work load.

The main objective of this work is:
1) Users should never have to copy files manually out of the Gideros install directory. This is accident prone and tedious.

2) Users should not need to download libs from the internet eg for ads. Gideros should host and provide all libs related to standard plugins (and test they work with the current Gideros version).

On a related matter, how many people compile their own players (eg Android player) and why? Is it mainly so you can test ads in the player? I'm thinking perhaps the players should have all/most plugins built in...?

keszegh · November 2015

i also agree that choosing plugins is the best idea (this info should be in the proj file, so a property of the project), at least for the most popular ones. for the rest, if there is an easily findable (in reference page e.g.) clear explanation on how to add them, that's also enough.

john26 · November 2015

Well I think that's the whole problem, there isn't an "easily findable clear explanation" for most of the plugins and what documentation there is, is getting out of date. Since Gideros went open source there isn't much time/money to maintain documentation so a benefit of this automatic plugin install system would be to reduce the need for documentation.

Besides writing docs along the lines of "copy file x to directory y, add line z to the manifest etc" takes just as long as writing code in Gideros Studio to do the same thing!

simwhi · November 2015

@john26 I use the player mainly for ads and IAP on Android and iOS.

john26 · November 2015

@AniketK, thanks for the offer of help. I think the best thing you could do is write some XML files for the plugins once we have that system working. A XML will be needed for each plugin and each OS, so lots of them eventually. They will of course be hosted on the Gideros Github repo.

john26 · November 2015

@simwhi, so you build your own bespoke player using the ads and IAP plugin? Would it be better for the player provided by Gideros supports these by default? Is there any reason the player should not include these?

SinisterSoft · November 2015

@john26 some advert/iap systems need id code information either as a file or in the manifest. Along with libs that is why they need a custom player.

simwhi · November 2015

@john26 I use a custom player to test IAB with Android. A beta version needs to uploaded to the Google Play Store for this to work.

john26 · November 2015

So you create a custom Android Player and upload it to Google Play? And then install the player from Google Play to your test device?

ar2rsawseen · November 2015

I think there is no need to download it back. You just need to upload it, and when Google sees there is an apk, you can test iaps. Maybe also need to get some hashes, don't remember

SinisterSoft · November 2015

You can add the IAP stuff to the play backend, then don't even bother uploading it to them - just use the correct id stuff in your custom player and side load it.

john26 · November 2015

So is there any merit to us preparing Gideros players with ad and IAB support built in?

ar2rsawseen · November 2015

That would again raise the question, which IAB and which ads, there are alot of them

antix · November 2015

I don't plan using any ads and other such plugins so I'd not be too happy if I was forced to compile all that junk into my apps.

simwhi · November 2015

@john26 I upload an APK with com.xxxx.yyyy name to the google play store and then install the same APK onto my test devices.

I wouldn't have ads/IAB pre-built, but just as export options.

MikeHart · November 2015

I am for option number one.

pie · November 2015

It would be great to flag needed plugins and let gideros embed them for you, but I must say that on Android is pretty easy doing it by hand once you understand what to do. The pain comes when you need a clean export and you have to reconfigure everything.

I've used plugins only for a short time, but it seems fast enough to clone the exported game folder (with plugins embedded) and remove the asset directory to use the same Eclipse project as a dedicated test player.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

The Future of Plugins in Gideros

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

The Future of Plugins in Gideros

Comments