An idea to explore: JS stitcher

The title may have you scratching your heads, but that's the best short description I can come up with right now.

Right now, C2 plugins are rather at odds; third-party plugins can't be used for arcade and everyone that shares the capx needs to get those plugins as well. Then there is the whole mess with naming conventions and all that.

So I propose a reorganization, rather a project that would streamline and simplify the whole plugin-making business.

Let me list a few issues first:

• plugins are often used for a limited subset of features. The rest of features are dead weight, extra lines of code being loaded but never run. It is in our interest to keep HTML5 games as lightweight as possible.
• additional plugins create confusion. Naming convention, clutter and all that.

Having dabbled with Construct 2 SDK a bit myself, I've begun to wonder: what if there was a tool that let you pick the exact features you want for your game and combine them within a single plugin to include with your game?

So here we go, "stitcher" of sorts. A tool that could do the following:

• provide a set of available features, let's call them "snippets"
• merge the selected snippets into a single plugin, following set rules and ways of the SDK (ACEs and stuff)
• provide means for users to insert JS code and use it with their game without having to wade through the whole SDK process
• provide means for users to share their snippets

So what we would have is a library of code snippets that the tool could build into a custom-tailored plugin. By delegating naming conventions and such to the tool's ruleset, we wouldn't have to worry about naming convention or even conflicts - it all would be behind the scenes.

For example, we could have a library of math expressions. An extensive library of functions. Just pick the expressions we want and bundle them up for the game.

We could also use that neat custom movement behavior developed by another member. No problem, tick it and it's in.

Of course it would be kind of tricky to work fundamentally different features together, so the tool probably would have to create several separate plugins, but as far as user is concerned, it all would be in a package.

And there you have the potential: packages of features designed for a specific game type. RPG package. Platformer package. Strategy package. Classic point-and-click adventure package.

It would be just like a custom-tailored toolset to make your game with. Need a feature? Toggle it on. Need a custom version of the feature? Toggle it off and provide an altered version.

So, yeah. Feasible?

Um, kinda.

An "a la carte" method would be interesting. Say you didn't need the whole platform behavior, but you need gravity, or jump, etc.

The thing is that if Ashley and Tom want to allow some more plugins on the Arcade in the future, I suppose they need to certify some of their fonctionnalities, on the security side. It's already difficult to that for third-party "well" defined plugins, but I'm sure it's going to be hell for a bundle of tiny parts from everywhere.

Apart from that, it lightens the game for "regular" playing (i.e. over a connection on a website), so it can be good.

Any compiler worth it's salt implements "you don't pay for what you don't use".

This might not be true now, but it probably will be in the future - I think everyone who worked with the SDK thought of that at some point.

I wonder what Ashley's thoughts on the subject are.

Fimbul : it depends on the flags set up by Ashley for the Google Closure Compiler. Some of those flags keeps dead branches in the file.