Please do not adjust official plugins or behaviors

0 favourites
  • Hi SDK developers,

    We're repeatedly running in to some difficult compatibility problems due to third party plugins and behaviors that are basically a copy of an official plugin or behavior plus a minor change. The benefit of the minor change is negated by compatibility problems in the long run. So on the whole this approach to plugin development appears to be harmful.

    Plugins which take this approach usually have a lifespan like this:

    1. Developer releases extension of OfficialPlugin, for example OfficialPluginX, with a minor change.

    2. Over time, OfficialPlugin gets bug fixes and eventually gains the features of OfficialPluginX as well.

    3. OfficialPluginX is not maintained and does not get any bugs fixed.

    4. Users keep using OfficialPluginX, and running in to bugs that are already fixed in OfficialPlugin. We end up supporting these users.

    5. It is difficult to replace OfficialPluginX with OfficialPlugin in events, because every event has to be changed manually. It is also difficult to add a feature in Construct 2 which can do this automatically, because the plugins are regarded as completely different and therefore incompatible by default.

    The minor benefit added by OfficialPluginX ends up being harmful to users in the long run, causing them to experience more bugs, and making it difficult for them to switch back to OfficialPlugin.

    On the other hand, I understand the benefit of third party plugins allowing users to use features before they make it in as an official feature. However, I would recommend the following approach for third party plugins and behaviors based on official ones:

    1. If the change is very small, please just suggest it as an official feature. It can probably be added quickly in to the next beta release. This removes the need for a third party plugin at all.

    2. If at all technically possible, design a standalone plugin which is not based on a copy of an official plugin, and just affects a different object. For example, if you wanted to add a 'Load random image from Flickr' action to Sprite, follow this process:

    • Make a new plugin from the empty template.
    • Add a single action, 'Load random image from Flickr in to Sprite'.
    • Use an object parameter so the user can select the sprite to affect.
    • In your code, check the properties exist as expected, so it is not broken if the user chooses a non-Sprite object.
    • Affect the chosen Sprite object from your plugin.

    Since this approach does not duplicate the entire plugin it is easier to maintain, and easier for the user to swap for the official action if it comes. However it will still require some maintenance in case the properties of Sprite change between releases.

    3. If the change is really big enough to deserve its own third party plugin, please change the plugin ID and release it as a separate plugin. Changing an official plugin which is maintained by different developers causes compatibility problems, but if you change the plugin ID the editor will treat it as an entirely separate plugin. This means both plugins can be updated independently without breaking each other. Please also bear in mind:

    • Please be diligent about following the changelogs of every C2 release carefully, and update your plugin whenever the official plugin is changed, in particular to adopt any bug fixes. You may need to use diff tools to track every change that is made, e.g. windiff.
    • If the official plugin ever gains the features of your third party plugin, I would request that you voluntarily de-list your own plugin and add a recommendation that all users should switch over to the official one, to minimise ongoing compatibility problems. This is possible if your plugin has a different plugin ID; it is extremely difficult for users to update if you have modified the official plugin directly.

    Please be aware that modifying an official plugin, behavior or effect is actually hostile to end-users and will likely cause them difficult compatibility problems or leave them with unfixed bugs. Never modify official code; at the very worst, publish a separate plugin as described above.

  • Just noticed this now after uploading my additions to the Facebook plugin(needed birthday, email and group info) so I added the permissions and expressions. Thought I would upload and share but I see that probably wasn't a good idea. So do I have the ability to delete the post under plugins or do you need to?

    Thanks in advance,


  • - it would be best just to keep your plugin private and suggest those as additions to the official plugin. Can you link me to the thread you want deleted?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Ashley

    Here's a link to the thread and I would love to see those and more included in the Facebook plugin. I'm using birthdate to give out in game gpresents and I'll be using the groups info as a in game grouping feature(alliance) the email I'll be using for support issues in game. I'd love to see that stuff included :)

  • Ashley

    Totally agree.

    So that I already had stopped maintain these kind of plugins.

  • Interesting, I have one of these that I never published because I was afraid of what you just described. So here's my suggestion:

    I needed to control the total number of particles spawned. I wanted to be able to fire 10 particles, then a little later 15, and so on. The existing particle count expression was not enough because it only counts existing particles. So I added a 'set max particles spawned' and 'reset max particles spawned counter' actions which just count the total number of particles spawned and wrap the spawning code in an if statement that doesn't spawn any over the maximum.

  • Why dont you support formal extension methods aka the decorator pattern?

  • One way to mitigate this problem would be via Git or some other DVCS. If the official plugins were hosted somewhere like Github, developers could submit pull requests for the case where it really is a modification to existing functionality.

  • Ashley

    Regarding this topic, what's the license on the official plugins?

    I think license info on the official plugins would answer most of these questions!

  • Ashley, Are there physic limits to C2? If so, I was told that the JavascriptSDK could help me create more advanced physics with JS, deal with frame rate issues, etc, no?

  • I just found out about github, which is a good idea.

  • BurningWood - you shouldn't need the SDK for that. Construct 2 has good built-in physics.

  • Ashley,

    Perhaps I am mis-understood the test below. For the box frame rate issue they are showing, is it a problem with porting the game to a OS system, if so, then would a Javascript plug-in fix issues on other OS's?

    What are your thoughts?

    Thanks :D

  • BurningWood: CocoonJS will soon have its own support of the box2D library which should fix those performances issues on mobile.

    (Actually, C2 already has it implemented but I think it's still a bit buggy on CocoonJS' side but a new version of the launcher should be released this week and probably fix this issue).

    This test is 3 months old and not really reliable imo.

    Mainstream comparison of people who hardly took the time to master any of the engines they are talking about to do some "stats" and views.

  • [...]In your code, check the properties exist as expected, so it is not broken if the user chooses a non-Sprite object.[...]

    I wish the SDK would support a "types of object allowed" parameter, so we would be able to specify that a behavior can only attach to sprite/tiled background/button/etc

    Why dont you support formal extension methods aka the decorator pattern?


Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)