Please do not adjust official plugins or behaviors

For developers using the Construct 2 Javascript SDK

Post » Wed Jul 11, 2012 4:50 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,518

Post » Tue Aug 28, 2012 5:54 pm

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,

Lance
B
68
S
21
G
15
Posts: 701
Reputation: 15,604

Post » Tue Aug 28, 2012 6:18 pm

@lanceal - 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?
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,518

Post » Tue Aug 28, 2012 6:27 pm

@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 :)

http://www.scirra.com/forum/my-facebook-plugin_topic54963.html
B
68
S
21
G
15
Posts: 701
Reputation: 15,604

Post » Wed Aug 29, 2012 6:44 am

@Ashley

Totally agree.
So that I already had stopped maintain these kind of plugins.rexrainbow2012-08-29 06:50:48
B
97
S
22
G
176
Posts: 4,109
Reputation: 103,021

Post » Thu Aug 30, 2012 6:26 pm

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.
B
22
S
9
G
5
Posts: 122
Reputation: 5,386

Post » Thu Nov 08, 2012 1:48 am

Why dont you support formal extension methods aka the decorator pattern?
B
7
Posts: 24
Reputation: 590

Post » Thu May 23, 2013 4:49 am

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.
B
3
Posts: 5
Reputation: 212

Post » Thu May 23, 2013 6:47 am

@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!
Be nice until it's time to not be nice
B
36
S
9
G
9
Posts: 293
Reputation: 6,652

Post » Sun Jun 16, 2013 10:42 pm

@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?BurningWood2013-06-16 22:42:44
B
14
S
5
G
2
Posts: 164
Reputation: 2,926

Next

Return to Javascript SDK

Who is online

Users browsing this forum: No registered users and 0 guests