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.