So yeah, all for Construct 3 with a fresh IDE. I don't mind the wait and will happily pay for a new license (provided C2 projects can migrate over to it).

Considering the project files are currently XMLs, if construct 3 maintains an open architecture with XML or JSON, I might be able to make a converter myself.

"Namespaces" sounds too much like proper namespaces, which I guess is a worthwhile feature in it's own right.

Variable grouping, however, is purely cosmetic, and wouldn't affect the way variables work at all.

If, as Ashley states, it could potentially take up to a year to recode the IDE with virtually no updates to C2, this looks like commercial suicide to me.

• Most current feature requests, besides modularity, are for editor improvements (In fact, you can even make a solid argument that modularity is actually and IDE feature instead of a runtime one).
• A multiplatform localized editor has potential to bring in a lot of money.
• The new asset store would bring in a ton of revenue if people could mod the IDE. Remember scirra takes a 30% cut.
• Scirra is very lean, and a construct 3 MVP would only take a few months to reach market. The thing that would take more than 1 year would be feature parity with c2, but we can tolerate that since we'd be paying for early access. We've done it once before with the move from CC to C2, we can do it again. It's not like scirra is ripping us off, anyone who knows even a tiny bit of c2 can make the money back easily.
• I don't mean to be rude, so please don't take this the wrong way, but IMHO ultimately it's not our place as a community to evaluate the business viability of an idea, just to express demand (or lack thereof) for it. Let Scirra be the judge of what risks they should and shouldn't take. I'd hate for people to vote against an idea just because it might not be viable technically/commercially.

DuckfaceNinja, I had a lot of trouble understanding your post, tell me if I've got this right:

• If C3 is ever going to happen, you'd rather it be a 3D engine
• However, you are against C3
• Because you think scirra would need to expand in order to keep C2 and C3 supported simultaneously before C3 matures enough that C2 can be retired

is that it?

If so, lets take this in parts:

making C3 (if it is going to happen at all) a 3D (and 2D) game engine, as easy to use as C2

Well Ashley has already posted his views on the subject before. Even though I'd love to see a 3D construct as well, I don't think browsers are ready for it. Maybe in 2 or 3 years.

I believe you're already working at your max capacity

I agree, but switching to an HTML5 based IDE would mean less work in the long run, not more (since it would all be javascript instead of javascript & C++).

There's also the problem that hiring new developers to work on ongoing projects tends to make projects take longer.

I don't see the practicality moving on to another runtime framework

You misunderstand. There will be no new runtime framework. We're talking about a new editor only, the HTML5 runtime engine will remain the same.

Out of curiosity, where do I find your to do list? It might be helpful to the community if you sticky the list, so that we are kept informed with what's coming and going on.

Officially, there is no public todo list, but in practice, it's pretty easy to find it

I've not seen any web UI frameworks that in my estimation compare to what we use at the moment.

I'm not sure I understood what you mean. The web is miles ahead of the desktop in terms of styling and widgets. There's no desktop equivalent for CSS, and although there are many desktop UI widgets, they're hard to integrate if they come from different sources, and none of them are as extensible as their javascript-based counterparts.

The only reason we don't have a browser-based photoshop or zBrush is performance, not features, and the C2 IDE is mostly static, so such concerns should be no issue (especially since javascript text-based IDEs are feasible, as proven by brackets).

Whatever we did, a radical technology shift or reworking of the editor (at least to support Mac + Linux) would take a considerable amount of time, pushing things back a long way while we catch up with what the editor already has. (We're too deeply tied in to Windows and MFC at the moment for it to be practical to port what we have already.)

There are already tradeoffs with continuing the C++ editor, and those will only get worse with time. We are already hitting a ceiling on what the editor can do in terms of modularity and extensibility - I'm sure you agree an IDE SDK is just as much a pipe-dream than a HTML5 IDE.

Linux+Mac support are two other things that would take a ridiculous amount of time.

The longer we wait with the current editor, the worse the cost becomes. Besides, we've been sitting on the bleeding edge for a long time, it will be nice to let the wrappers/browsers/devices catch up a bit and get better organization features, which are currently preventing big projects from becoming a thing with construct.

Skinning was a major feature that ended up limited to recoloring/resizing only (imagine the power of CSS based reskinning).Translation practically flopped. There are many widely-used translation APIs for javascript, and they're mostly plug-and-play.

To what extent are those wanting editor enhancements willing to wait for this to happen?

I'd rather see modularity first, before a huge push for IDE enhancements, but after that I don't think there are many major runtime features left (the biggest one was multiplayer and that's already in).

We could keep extending the C++ editor, which is relatively painful, and further invests ourselves in a Windows-only English-only editor.

I don't think you're too fond of that idea yourself. The mac+linux versions might be incentive enough for you to port, and those would probably represent an extra 15% of the total income (though I imagine Tom would have a better idea).

A translated editor would also go a long way towards acquiring new customers, so I thing it's a good idea from a business sense.

Or we could think about reworking the editor sooner rather than later, which in the long term could bring a lot of wishlist features but would probably be on the order of at least a year or more, during which updates to the current editor and runtime would probably be sparse. And we'd probably call that "Construct 3" given the vast scale and cost of the reworking.

We've done it before with the move from Construct Classic to Construct 2, and that took time but I think it paid off amazingly well.

IMHO those make sense both from a business and engineering perspectives. For me at least it's clear the engine has outgrown the IDE.

This time around we could keep the same runtime which makes it less work. Thoughts?

You'd also keep the exporter, the XML project structure, the runtime debugger and the runtime SDK, as well as most of the eventing scheme (one could call it the "construct standard library"). Extensions would be easy to convert if you keep the runtime SDK. You could also make a tool to convert c2 projects to c3 projects.

As for construct 2, I've been extremely satisfied with it, and I think I got more than my money's worth out of it. I'm not sure anyone in the community can disagree, especially considering the free (and frequent) updates we've been getting all this time.

I'm in favor of a Construct 3. Why don't you post a poll discussing it?

Variable grouping would serve the same purpose, you could hide the non-configurable variables under an "internal" group or something like that. That also has the benefit of allowing you to configure variables in a sane way for other use-cases, such as my other post and followup

currently my solution is to name them _varname

In the long term we are thinking about where to take the editor in future, and how to solve this problem to make it really easy to add UI features - and how to allow third party addons to extend the UI usefully as well which helps take the pressure off us much like third party plugins already cover lots of niche/specific use/alternative features in the engine. This will be no small job though. I hope everyone can be patient, because to make a "dream" UI is going to take a lot of work... but it's in our sights!

Why not kill 100000 birds with 1 stone? Ditch the C++ IDE and port the whole thing to CEF.

• Linux/Mac/PC compatibility out-of-the-box
• Mobile versions are simpler to make
• Vastly fewer discrepancies between Edittime and Runtime (especially in regards to effects)
• Component reuse across codebases
• No need to switch between languages / Single standard library
• IDE SDK becomes easy to make
• Tons and tons of high-quality UI libraries
• Possibility to make a "cloud" version
• Easier collaboration (stuff is more abstracted than with C++)
• Big community support
• No need to make single-purpose C++ interfaces for plugins such as spriter - the developer would be responsible for integration

I don't see any point to sticking to C++, especially since you said yourself that you wouldn't make native exporters and don't like "maintaining multiple codebases". Even if you were to add an editor SDK, if it was made with C++, I doubt a lot of people would use it, considering most here that can program tend to do so in javascript.

It wasn't a viable option back when construct was still in alpha, but it has become an option now. Check out how easy it would be to make interfaces with something like jQWidgets and unsemantic! They'd be insanely better than what we currently have in the editor!

I might post a topic with mockups.

If the exporter was a commandline tool, I'd be tempted port the whole thing myself (well not really since I would be in a legal mess with Scirra in regards to IP Ownership but you get my point).

We would be a long way behind where we are today if we had, because we would be having to maintain multiple codebases. Writing two codebases isn't twice as hard, it's more like squared (to the power two) as hard, because of all the extra effort to make sure both codebases are functionally identical in all circumstances, and that extra work never goes away if you keep adding features like we do.

Need more arguments?

what I meant by that is that there should not be any difference for the user apart from a better experience

Exactly. The developer doesn't have to change anything in order for things to "just work" on 64-bits chrome.

However, it's important to realize that the benefits can be quite significant: 32-bits applications have a <4Gb memory ceiling (in practice <2Gb), which means having a ton of open tabs/windows will slow the browser to a crawl.

Games love to consume memory, and browser-game-players love keeping multiple tabs (with multiple games) open, so this change will mean better performance in practice.

I don't know whether this change affects Double's (the value type) precision, or if it will allow higher limits for graphics or AI processing, but it definitely makes 3D Web-GL in-browser games more viable than they were before.

Well loss of an expected profit margin means nothing if people won't buy it at a higher price.

ne of the big characteristics of good business acumen is being able to identify opportunity costs. Is the time spent writing javascript for a plugin more valuable than the time spent writing javascript for something else? In my opinion, not with a $5 per-dev license.

You just need to add more value, more bling, and more shiny, to get more people interested... which is what I'm looking at.

uite the contrary: spending more effort means raising the costs of production - if you can't pass on those costs to the market, you lose money. The best solution with a $5 ceiling would be to make tons of low-effort plugins (thus lowering the cost of production).

A lot of what is being discussed here and feedback we've received does makes sense

hank you.

I really am sorry if this is a big disappointment so close to launch, but they are categories we do want to support in the future.

'd love to see a "premium tutorials" type section as well, is that possible? It's functionally similar to the e-books section, but a bit shorter in scope and not limited to text (you could add video, exercises, step-by-step capx, commented source, powerpoint presentations, etc).

Tom Make a list of rules of plugins, if they break one rule, then the plugin submission will be rejected. That's simple.

don't think the issue here is with plugins breaking the rules. The problem is plugins adhering to the rules but breaking the spirit of the store, and making rules for those is a highly subjective process with tons of caveats and exceptions. Manual curation is already being done, I'd like to see manual pricing (by scirra staf, in case that's not obvious) as well.

In fact all plugs up until recently have been free.

ree and commercial content are produced for entirely different reasons. For instance, I have lots of ideas for cool plugins, but I don't make them because they take A LOT of time and time=money, which I need in order to survive.

Also, commercial plugins require constant support (you can't just let them die) and documentation (which you can forgo if your plugin is free).

But if you wish to continue the argument then lets look at something comparable, say for example Spriter.

Its an editor, and a plug, and costs $24.99.

Can you make something of that quality?

priter can be sold mass-market, and plugin costs count as a feature for the software itself, which is the main product. That's not the case with a construct-exclusive plugin.

Let me make an analogy: photoshop is sold to millions of people for a (arguably) low price, and is a very high quality product. The euphoria middleware, a much less complex product (though still pretty complicated), costs millions of dollars. How do they get away with it? Simple: euphoria is a niche product and thus can't be sold mass-market, just like c2 plugins, but on a much bigger scale.

If you could provide a turnkey solution (a plugin bundle plus a game with source) for, say, a top-down MMO-game in construct 2 - which is quite possible and something I've considered briefly - I don't think charging upwards of $1500 would be a stretch, even if it ends up being less complex than Spriter. The possibility goes to hell instantly if you cap prices at $5.

The way most people do is add a [request] in the topic title

So your topic should be renamed

[REQUEST] Select multiple sprites[/code:2as4idqt]

Cheers!

It is intentional and was documented in the changelog a few versions ago.

The wav files were never used for anything and were just taking up space, so Ashley removed them.

Arima you should just leave the spam. Tom is never going to do anything about it if you keep cleaning it up. If you leave it he will see the extent of the problem. I think it's now going beyond the work a volunteer should do for free on behalf of another company.

But then tom will have to come up with a solution, which means less time dedicated to the scirra store.