Nah. I think Ashley is talking about "backwards compatibility for c2 plugins".

I don't think it is possible or even wanted. The editor will change so much that the edittime side of current plugins will probably be unusable, unless there's some sort of converter (I personally think this is a waste of time - throw C2 plugins out the window if you have to).

As for your case, it's probably OK to keep going with your project using C2, you have a long time before C3 arrives, and a long time after that before C3 reaches feature parity with C2 (I wouldn't dare guess how long, though).

People, keep in mind that this thread is for architectural features in C3.

I'm going to give a list of suggestions that ARE NOT APPROPRIATE for this thread:

• Path Movement (I'm not talking about pathfinding, but a simple "follow the nodes" movement): If we can have plugins and behaviors drawing on the canvas, this will already be possible with the SDK, so this is a shitty suggestion for this thread, even if it is immensely useful for development. Same goes for bezier curves, for instance.
• Instead of asking for pin behavior should take size into account, why not ask for expressions during edittime? this way we could set the X position of an object to something like "parent.X*parent.size+self.variable", turning the pin behavior almost obsolete (don't take the pin behavior out, though, beginners can still use it before they wrap their heads around variables)
• AI Editor or similar. Ask instead for "plugins should be able to define and spawn their own editing windows, just like the sprite animation editor", this way we'd be able to create finite state machines, 3D map editors and all sorts of things
• Instead of asking for multiple collision masks, why not ask for collision masks to be decoupled from the animation? This way different objects can share the same collision mask. Even better, why not ask for "collision mask" to be something you can store in a variable? Heck, it doesn't even have to be a "collision mask", it can be just a "mask", that we can crop, apply effects to, etc. Also who said masks have to be edited? Maybe I can just choose on a list from a few presets, such as a circular mask, or a square mask, or an editable mask. Maybe I can have a little "mask editor" where I can do operations such as "fit inner" or "fit outer"

There's no point asking for features piecemeal, it's about asking for architectural changes that will enable us to create the most things using the least stuff. It's about making the engine versatile instead of a bag full of special cases (i.e. the tilemap and spriter extensions)

Also, for people talking about exporters, this is crazy talk. Don't ask for "native XYZ exporter", ask instead for "an exporter SDK"! I may or may not agree with you, but at least it's an architecture request.

No, there's no plan to do it - the whole point of Construct 2 is that there isn't any programming like that.

That's not entirely true.

You can use the SDK if, like me, you really like coding. There's nothing stopping you from doing everything but the highest-level coding in raw javascript.

If you're really patient, you can bypass the event system entirely, though I don't recommend you do it. check it out!

With C3 it seems we'll be getting an editor SDK, so you'll get even more bang for your buck.

If your main use case is to run in node, then there would need to be a huge set of new features to access all of node's features from the event system (such as hosting servers, opening sockets, accessing databases etc).

What? We just want to be able to skip draw calls so we can get 100K objects or something similar without having to recode the entire thing. Like I said, this is especially useful for multiplayer projects using the authoritative server model. There's no need to expose node's APIs, we can do that ourselves with extensions.

If you can cut off the DOM as well (which is another source of slowdowns), we'd be able to run it inside webworkers, further extending this usecase.

Without that you pretty much just have an interactive game with no interactivity, which isn't very useful.

You have an easy, hassle free multiplayer server that you can keep running without wasting CPU/GPU time with drawcalls that no one wants anyways.

So this sounds like a pretty huge feature request - almost another product by the sound of it.

While I'd love a corporate version of construct geared towards app development, and might pitch that idea sometime in the future, I don't think this is that idea. What we're proposing is just ripping the canvas off, nothing needs to be added.