Concerns from a "Serious" developer

Ashley can I get a direct response from you please?

Okay, wow, now a 17 page thread.

I'm not sure what anyone here thinks we should actually do. We've already announced things like our own mobile app build service and new IAP/ad plugins for C3, so that is on the way. We've got Xbox One support just around the corner. Mobile support from what I've seen is pretty solid with WKWebView and Android 5.0+, all supporting JIT-compiled JS and hardware-accelerated WebGL. Maybe we could tweak the way we advertise certain things. Maybe some people have bugs, or unoptimised cases, in which case please file reports, or send me .capxs to profile for performance improvements (as ever, I always ask, and either get sent nothing, or just projects with silly performance-destroying mistakes, hence my skepticism).

Do you want us to rebuild the C3 editor? I would go so far as to say that would probably ruin us, and waste a brilliant opportunity. Do you want us to build native engines? I've covered that in this blog with our rationale around that, which nobody ever really directly argues against, there's just vague accusations of how HTML5 is "poorly optimised" or something, which really is not the case given the potency of modern JIT compilers and the native-equivalent performance of WebGL.

So what have I missed? What do you think we should actually do differently that isn't something we've already covered? If I can't make sense of any specific complaints or clear suggestions on what to do, then I don't see why we shouldn't just carry on as we are - I think we already have a strong plan for the future.

Ashley after reading the many many comments on this and my thread I believe what people are asking for is this:

1- Go ahead with C3 as it may at least be useful to people using Mac and Unix even though most C2 users have said they do not want a Chrome browser based subscription engine.

2- Make an update or addon package of exporters and features for C2 that users have been asking for and fix the bugs you have been promising to fix for years. Put that new team of programmers to work on that along with C3.

We all understand Scirra has to make money and I believe you understand that if you lose your long time C2 users by not listening to us your chances of staying in business are pretty damn small.

So this is a reasonable request and you can charge your $99 for a great package of features and exporters for C2 and I will bet you will sell many more of those packages than you will C3 browser versions.

It also would prove you actually intend to honor your license and advertising that said those exporters would be included in C2 and would probably keep your base happy and maybe they would be interested in C3 later after you get all the bugs worked out.

It seems to me you would want those long time C2 users to hang around and support Scirra but reading through the comments on many threads they are dropping out and pretty disappointed in Scirra right now.

So what do you say?

Can we get a package of features and working exporters for the existing C2 engine at a reasonable price with no subscription Ashley?

Keep it polite - no personal attacks.

Seriously? That's as polite as I can be to a troll who continues to bait Ashley and Tom with repetitious questions, tells others their cheerleaders, says people run interference, which is three I've counted so far, and heck, even more than I feel like saying now.

I guess if you can't say anything nice to someone, don't say anything. I'll just abide by that rule, but you guys should seriously think about the constant negativity coming in most of these threads from one ring leader and what you should do about it.

My personal opinion.

A game engine markets itself by the games that have been created with it. Nothing else really works as effective as that.

You Scirra are currently losing faith from the people that create these "serious" games.

We were obviously expecting some users to not like the model.

I thing the majority of them are the ones I described above :/

Having said that, we do have a feature-voting system planned anyway but I am going to strongly caveat it with warnings that "votes are not a guarantee of implementation", for exactly the reason we had with multiplayer. Also I can easily imagine things like 3D becoming #1 voted features, and there are a wide range of reasons why we're holding off on that.[ > 1) An smart Idea might be to create a REP based voting system. 30.000 rep = 3 votes or whatever, getting significantly less unexperienced and emotionally driven votes

2) Rep locked forums for specific feedback

Generally, it's as good as the browser engine is.

Maybe this sentence on your marketing banners with an asterisk

Yes, lots on the way here, as announced.

Everyone hopes this works out well, plz be more transparent

Ashley Tom - I think the build service is going to be fantastic if it works without too many crazy hoops to jump through. As NotionGames has said, being able to feel confident to be able to deploy your games properly when they are complete is very important to instill confidence in your subscribers.

The upcoming poll voting system for future features sounds like a great idea too so that you get a clearer idea of what's a priority from the community.

A roadmap as other have suggested of upcoming C3 Features will help people get on board with paying for a subscription and let them know that they are contributing to the future of scirra. A lot of people feel like C3 (right now) is just an online version of C2 with bits of future C3 information spread across different threads etc. The blog posts help, but having all of the plans in one easy to see location would be much easier to refer to for everyone.

A tool that converts C2 2 plugins into C3 compatible plugins. I've spoken to rexrainbow and he thinks that if he has re-write his hundreds of plugins that it will take him a year to do so. So many people rely on addons that if they have to wait a long time to be able to use them (or to import C2 projects in C3 that rely on them) that they won't subscribe to C3. I'd go so far as suggest you either give them free access to C3 or hire them on your team full time. Plugin creators like him and everyone else who extends C2 are so valuable you don't want them to drop contributing to Construct.

I've seen how far C2 has come since the first version, i can't wait to see how C3 progresses over time.

Is there c2 plugin support for in c3? i mainly ask because if there isn't then yes, a export package of some kind or even access to the cloud exporters (or whatever is going on with c3) could be extended to c2 devs who have projects that rely on plugins. I know all of my c2 games do.

Ashley about the voting system. I do remember that people voted for multiplayer support. So I do understand the hesitation to implement something like that again. But honestly, once the exporters are solid then the rest is just bonus features. Regardless of whether or not people are using the features, if they're paying a subscription and getting what they asked for, then that's fine, right?

I could not agreed more into this, recently i have problems porting my first game called BSB Hero http://www.gameorb.com.br/games/asd2/, into mobile, mainly because i could not get a proper performance and the exti issue from intel xdk.

So i moved into cocoon.io and another 100 usd to pay, thi is a lot from brazil since 1 usd is almoust 4 reais.

I would love to see C3 as a very final project, so i only need external editors as tools to make a one great game and i mean, photoshop, spriter and etc.

My next game quasar http://www.gameorb.com.br/games/quasar/, i have done TONS of work, and i am already concearn on how to make a good deploy so it is a good start, and for both projects i dont even do some sales.. im doing it for free but how to be able to go to a nintendo, microsoft or even steam if other developers already had issues with it.

I do like to saty on construct, but im also thinking about moving into gamemaker.

Maybe off-topic? But since Ashley brought up the poor multiplayer plugin... it is actually pretty feature complete, I think people just have trouble wrapping their head around multiplayer concepts. They have some preexisting assumptions about how it should work, and walk away discouraged before realizing the multiplayer plugin is pretty adaptable.

Someone mentioned missing directly connecting instead of via signalling server, but utilizing a signalling server is pretty much superior any way you look at it (users ARE directly connecting to each other, the signalling server just takes the work out of making that connection). For example if you want to connect to someone by IP, use that as your room name instead.

The second big thing is understanding lag and latency and the fact that no two users will ever see the same thing at the same time. The tutorial spends a lot of effort explaining this and the implications AND the solutions, but I think it turns off a lot of people. This isn't something you can just wish away or ignore when developing multiplayer games, but people go in to it not realizing how important it is. This is no shortcoming of the plugin itself, rather the users. The plugin actually has tons of built in behaviors to make things like interpolation and lag compensation easier to handle for the developer.

I think the last thing is that many people envision server-client architecture for their game, which isn't exactly how the plugin was positioned but it is perfectly capable of doing so. Probably could use a specific tutorial to set up such a system (kind of like how there are two basic tutorials for top down shooter and side platformer - one can be foor peer-peer and another could be for client-server). Doesn't mean it is superior to a fully featured backend service, but those are out there already with working plugins.

Back on topic - while the multiplayer plugin might be under utilized, I think it is still a huge selling point, especially for "serious" developers down the line if some of the other issues get addressed. Even as a feature checkbox, I think not having it would be a fair reason for a prospective customer to turn to another engine.

TLDR: Basically wanted to say voting on features is important regardless of utilization, it usually is a fair metric of what people are looking for, regardless of weather or not they are capable of utilizing it.

Since I haven't weighed in on this thread yet, just going to mention in my opinion the two biggest priorities for "serious" developers down the line would be exporting (already/soon to be addressed) and monetization (ad service support/tutorials).

Also I think an official perlin noise plugin/function/support is something a lot of people are looking for and trending recently, but I suppose a voting system would show if it is or not.

Ashley

Was implementing multiplayer really a waste of time though? Is your use data based only on your signaling server activity levels? If so, then it's quite obvious that the majority of users won't be using it much; it's a lot of work to make a multiplayer game and beyond the capabilities of beginners. But simply having multiplayer as a feature in C2 probably sold a lot of copies of the engine. Even if it goes unused. People buy things based on what they want, and not necessarily on what they will end up using. I'm sure a ton of hobbyist's first question on reading about C2 was "can it do multiplayer." And the answer is yes, so they bought it. It sounds cool to them and they like the idea. In reality, 99%+ won't ever make a multiplayer game, or even a single request? to the signaling server. But they bought C2 because they know the option exists. The poll on the forum clearly showed that there was a lot of interest in that option.

Do you want us to build native engines? I've covered that in this blog with our rationale around that, which nobody ever really directly argues against, there's just vague accusations of how HTML5 is "poorly optimised" or something, which really is not the case given the potency of modern JIT compilers and the native-equivalent performance of WebGL.

Actually I and others do have a problem with the arguments in that article, as well as the article on "HTML5 games faster than native"

Let's see:

WebGL is close enough to OpenGL to be considered the same performance-wise. In other words, Construct 2 games render in practically the same manner a native engine would.

...

We already cover Xbox One and Wii U - so that only leaves PS4. Currently we're blocked by Sony not providing an easy way to publish HTML5 games to the PS4. Given how well our Xbox One support worked - requiring no significant changes to our engine to work on a console - we are keen to see Sony supporting HTML5 on their console too.

There's a few arguments against those lines of thought:

Listing GPU fillrate as the main cause of a games slowdown... and then stating that the WiiU is a viable export platform is quite funny. WiiU doesn't support WebGL, meaning not only regular GPU "fillrate issues", but no special FX and low performance.

5FPS after losing WebGL and FX is still not playable for a platformer. We didn't even make an HD title, just a retro 16bit platformer with 32x32 to 64x64 pixel sprites on average.

As for fillrate being "the main culprit", there are many instances where CPU should be considered too (eg: most enemies and players using the platformer behavior) and, no matter the optimizations, aren't going to be able to combat the issues of JavaScript without emscripten. But, if you make a tool that exports to HTML5 through emscripten it might as well also export the actual C/Cpp (to port to the JS, best of both worlds).

Even the mobile games developed with Unity and Unreal put C2 at the ground... How you can even compare?

- Native games is WAY better in lower and mid hardwares, and this is AMAZING because more people will play your games.

->>Scirra depending on thirdy-partys for realese our game. Remember when you guys drop support to Cocoon as exporter? That's why I droped C2.

...

By the way, The Next Penelope is being ported to C ...

To me the main issue I had with html5 games is that on low-end devices (iPad 2) they perform not really well at all. The same simple app on iOS, even with the super accelerated safari, tends to have small hickups and feels not smooth compared to the same done in a native engine (love2d in this case).

The situation seems a bit better on newer devices (iPhone6), but still showing those small jerks every now and then (are they GC related?).

All of this scares me away from trying to do something serious with html5 engine.

While it's true most devices support webgl it doesn't mean we get the same performance as native in that respect. In my experience it varies per device, and it's just not about the hardware capabilities. Case in point, for me in CC rendering is way faster than in C2. This goes against your benchmarks so that leads me to believe webgl gives native performance on only certain devices. The argument that the hardware is the limit doesn't fly when changing software and doing the same thing performs a lot better.

The browser's hardware support is primarily about having everything work instead of having everything have good performance imo. Even things like the vsync jank is still there on some hardware. This is probably what causes the disparity between the issues users see and what is tested.

I don't know if native support would fix this, and I realize doing so would cause a load of different issues and multiple code bases, but there seem to be core issues with how browsers do things that are not performant.

Now, in regards to "HTML5 faster than Native?":

Construct 2's WebGL renderer is faster than our previous native C++ DirectX 9 based engine - the one we developed for Construct Classic.

This is a completely wrong comparison, because C2 is largely an improvement and optimization on CC, you already learned from past mistakes and found new ways to optimize. It's the software form of a "straw man" argument against native.

If you back-ported those optimizations back to C++ you'd find that the results suddenly return to native being the fastest and smoothest. We can tell this ourselves from simply our experience of porting to Unity in C# with our current game and seeing it run much faster and with more lighting, special effects, and enemies on-screen than our C2 prototype.

Then there's also the people who didn't see the results that are promised in that article with C2 vs CC:

97151 - WebGL

128458 - Native

i3 - 3220 / GeForce GTX 550ti with small factory overclock / Win 7 64 / nvidia driver 306.97 / 8Gb RAM

Intel E2180 2Ghz, 4GB RAM, Win7 64 bit, SP1, Geforce 210, Nvidia 306.97 driver

Native/DX 25613

WebGL:

Chrome 22: 3801

Chrome 23: 4482

Chrome 24: 3901 (dev)

Chrome 25: 3503 (chanary)

FF16: 3254

i7 9203.6ghz, 48gb, win7 64bit , amd7970 3gb, catalyst 12.11(beta)

Native/dx: 118040

WebGL:

Firefox 16.0.2: 58712

Chrome 22: 103761

WebGL Performance (Google Chrome 23): about 10400 objects

Native Performance: about 24000 objects

My notebook: Processor Intel Core i5-2410M 2.3 Ghz, 8 GB Ram, Graphic card Intel HD Graphics 3000, OS Windows 7 Ultimate 64-Bits

I'd like to point out two things from all of this:

1.) Like the data above, some of the "still-Steam-average" hardware still sees native far out-performing WebGL, and desktop is currently the best supported platform for HTML5 + WebGL. The results may be 4 years old, but the average 2D gamer (based on customer support issues on Steam) hasn't updated their PC/laptop/even just the graphics card in a long time.

Even with an Intel i7 6700k and GTX 1070 which has much better WebGL support than most of my customers I get:

Sprites/objects >= 60fps with no drops below

"Native"/dx/CC: 86k

WebGL/Chrome/C2: 95k

This may not be the number of sprites that will appear in a game, but it still reflects an underlying performance gap between Construct Classic (which could be argued to be almost as un-optimized as C2 is optimized) and WebGL. HTML5 is not faster than native. It can get close with WebGL + Emscripten, but it inherently is just not capable of being as fast as native, and I wish that Scirra would stop trying to compare the two this way.

2.) You can't just ignore comments/evidence/arguments against your company/public statements about your engine and then claim "nobody ever really directly argues against" them!

Bonus: That multiplayer plugin would probably have been used a lot more if people were able to export their games and "publish everywhere". It's also possible the users are waiting for more helper functions/plugins/behaviours that make tracking objects much easier (Eg: a behaviour for syncing objects). I know multiplayer is generally a hard feature, but it's a great one to have even if it doesn't get used as often as other plugins.

Like others are saying, yes, export matters 100% more, but I still am glad Construct got multiplayer.

Although, it seems some other users had a better time using their own multiplayer solutions:

Using Electron instead of nw.js made my games smaller and better working, using my own networking solution with central socket.io based server destroyed weird, random connection problems that disallowed me from even testing my game. And made multiplayer a lot smoother. Being able to write my own rendering code allowed me for much more control over how stuff is shown on screen what makes performance better.

> I would say that getting this community more involved would be a great start. Conducting direct polls and really having a way for supporters to give feedback.

>

This has worked against us in the past. The multiplayer feature was massively voted for, but from the data we look at, very few people actually use it. So the hype effect is a big distorting factor in polls. I don't regret it, it was a super interesting project to work on, but it's something to bear in mind, and is the main reason I have avoided polls since then.

Having said that, we do have a feature-voting system planned anyway but I am going to strongly caveat it with warnings that "votes are not a guarantee of implementation", for exactly the reason we had with multiplayer. Also I can easily imagine things like 3D becoming #1 voted features, and there are a wide range of reasons why we're holding off on that.

There's a big difference between listening to all of your users - including those who haven't created a finished product in Construct - and those more "serious" (as the OP titled this thread) users who are looking for more quality-of-life features than anything new that will hardly be used by most users like multiplayer or unrealistic requests for 3D in a tool designed specifically for 2D. There's only a handful of more advanced C2 users because (I think) of some of the limitations in the engine that theoretically make features easier to use, but which annoy us more advanced users because we're hitting hard feature walls we can't work around like globally-shared images for tilemaps (if this was optional, it would be a heck of a lot easier to set up dynamically loading tilesheets and tilemaps), forced spritesheeting (which causes issues with seams, no matter how you spin in it, so it'd be nice to turn off for desktop builds where they provide little performance benefit), setting variable values without being forced to select the variable through a dropdown, real If statements (that also don't require using a dropdown for values or objects), etc.

> Do you want us to build native engines? I've covered that in this blog with our rationale around that, which nobody ever really directly argues against, there's just vague accusations of how HTML5 is "poorly optimised" or something, which really is not the case given the potency of modern JIT compilers and the native-equivalent performance of WebGL.

>

Actually I and others do have a problem with the arguments in that article, as well as the article on "HTML5 games faster than native"

Let's see:

> WebGL is close enough to OpenGL to be considered the same performance-wise. In other words, Construct 2 games render in practically the same manner a native engine would.

>

> ...

>

> We already cover Xbox One and Wii U - so that only leaves PS4. Currently we're blocked by Sony not providing an easy way to publish HTML5 games to the PS4. Given how well our Xbox One support worked - requiring no significant changes to our engine to work on a console - we are keen to see Sony supporting HTML5 on their console too.

>

>

There's a few arguments against those lines of thought:

> Listing GPU fillrate as the main cause of a games slowdown... and then stating that the WiiU is a viable export platform is quite funny. WiiU doesn't support WebGL, meaning not only regular GPU "fillrate issues", but no special FX and low performance.

>

> 5FPS after losing WebGL and FX is still not playable for a platformer. We didn't even make an HD title, just a retro 16bit platformer with 32x32 to 64x64 pixel sprites on average.

>

> As for fillrate being "the main culprit", there are many instances where CPU should be considered too (eg: most enemies and players using the platformer behavior) and, no matter the optimizations, aren't going to be able to combat the issues of JavaScript without emscripten. But, if you make a tool that exports to HTML5 through emscripten it might as well also export the actual C/Cpp (to port to the JS, best of both worlds).

>

> Even the mobile games developed with Unity and Unreal put C2 at the ground... How you can even compare?

>

> - Native games is WAY better in lower and mid hardwares, and this is AMAZING because more people will play your games.

> ->>Scirra depending on thirdy-partys for realese our game. Remember when you guys drop support to Cocoon as exporter? That's why I droped C2.

>

> ...

>

> By the way, The Next Penelope is being ported to C ...

>

> To me the main issue I had with html5 games is that on low-end devices (iPad 2) they perform not really well at all. The same simple app on iOS, even with the super accelerated safari, tends to have small hickups and feels not smooth compared to the same done in a native engine (love2d in this case).

> The situation seems a bit better on newer devices (iPhone6), but still showing those small jerks every now and then (are they GC related?).

>

> All of this scares me away from trying to do something serious with html5 engine.

>

> While it's true most devices support webgl it doesn't mean we get the same performance as native in that respect. In my experience it varies per device, and it's just not about the hardware capabilities. Case in point, for me in CC rendering is way faster than in C2. This goes against your benchmarks so that leads me to believe webgl gives native performance on only certain devices. The argument that the hardware is the limit doesn't fly when changing software and doing the same thing performs a lot better.

>

> The browser's hardware support is primarily about having everything work instead of having everything have good performance imo. Even things like the vsync jank is still there on some hardware. This is probably what causes the disparity between the issues users see and what is tested.

>

> I don't know if native support would fix this, and I realize doing so would cause a load of different issues and multiple code bases, but there seem to be core issues with how browsers do things that are not performant.

>

Now, in regards to "HTML5 faster than Native?":

> Construct 2's WebGL renderer is faster than our previous native C++ DirectX 9 based engine - the one we developed for Construct Classic.

>

This is a completely wrong comparison, because C2 is largely an improvement and optimization on CC, you already learned from past mistakes and found new ways to optimize. It's the software form of a "straw man" argument against native.

If you back-ported those optimizations back to C++ you'd find that the results suddenly return to native being the fastest and smoothest. We can tell this ourselves from simply our experience of porting to Unity in C# with our current game and seeing it run much faster and with more lighting, special effects, and enemies on-screen than our C2 prototype.

Then there's also the people who didn't see the results that are promised in that article with C2 vs CC:

> 97151 - WebGL

> 128458 - Native

> i3 - 3220 / GeForce GTX 550ti with small factory overclock / Win 7 64 / nvidia driver 306.97 / 8Gb RAM

>

> Intel E2180 2Ghz, 4GB RAM, Win7 64 bit, SP1, Geforce 210, Nvidia 306.97 driver

>

> Native/DX 25613

>

> WebGL:

> Chrome 22: 3801

> Chrome 23: 4482

> Chrome 24: 3901 (dev)

> Chrome 25: 3503 (chanary)

> FF16: 3254

>

> i7 9203.6ghz, 48gb, win7 64bit , amd7970 3gb, catalyst 12.11(beta)

>

> Native/dx: 118040

>

> WebGL:

> Firefox 16.0.2: 58712

> Chrome 22: 103761

>

> WebGL Performance (Google Chrome 23): about 10400 objects

> Native Performance: about 24000 objects

>

> My notebook: Processor Intel Core i5-2410M 2.3 Ghz, 8 GB Ram, Graphic card Intel HD Graphics 3000, OS Windows 7 Ultimate 64-Bits

>

I'd like to point out two things from all of this:

1.) Like the data above, some of the "still-Steam-average" hardware still sees native far out-performing WebGL, and desktop is currently the best supported platform for HTML5 + WebGL. The results may be 4 years old, but the average 2D gamer (based on customer support issues on Steam) hasn't updated their PC/laptop/even just the graphics card in a long time.

Even with an Intel i7 6700k and GTX 1070 which has much better WebGL support than most of my customers I get:

Sprites/objects >= 60fps with no drops below

Native/dx: 86k

Chrome: 95k

This may not be the number of sprites that will appear in a game, but it still reflects an underlying performance gap between Construct Classic (which could be argued to be almost as un-optimized as C2 is optimized) and WebGL. HTML5 is not faster than native. It can get close with WebGL + Emscripten, but it inherently is just not capable of being as fast as native, and I wish that Scirra would stop trying to compare the two this way.

2.) You can't just ignore comments/evidence/arguments against your company/public statements about your engine and then claim "nobody ever really directly argues against" them!

Bonus: That multiplayer plugin would probably have been used a lot more if people were able to export their games and "publish everywhere". It's also possible the users are waiting for more helper functions/plugins/behaviours that make tracking objects much easier (Eg: a behaviour for syncing objects). I know multiplayer is generally a hard feature, but it's a great one to have even if it doesn't get used as often as other plugins.

Like others are saying, yes, export matters 100% more, but I still am glad Construct got multiplayer.

Although, it seems some other users had a better time using their own multiplayer solutions:

> Using Electron instead of nw.js made my games smaller and better working, using my own networking solution with central socket.io based server destroyed weird, random connection problems that disallowed me from even testing my game. And made multiplayer a lot smoother. Being able to write my own rendering code allowed me for much more control over how stuff is shown on screen what makes performance better.

>

+1 to all of this, especially the "we're just as fast/faster than native" claims which are so completely beyond the pale in terms of just outright fabrications of HTML5's current abilities, using C2 or not. This is something I knew going in to C2, and I understand the performance difference (though it is greater than it should be with C2), so when I see this claim pushed over and over despite gallons of real-world evidence otherwise - and sorry, but your internal tests with tiny little games or demos mean nothing when compared to thousands of copies of commercial games out in the real world that show the opposite, and PLEASE don't try to blame the game's developers for this as you've done in the past - it's very hard to swallow after the 100th time when all evidence points to the opposite being true.

...

so when I see this claim pushed over and over despite gallons of real-world evidence otherwise - and sorry, but your internal tests with tiny little games or demos mean nothing when compared to thousands of copies of commercial games out in the real world that show the opposite, and PLEASE don't try to blame the game's developers for this as you've done in the past - it's very hard to swallow after the 100th time when all evidence points to the opposite being true.

+1000

> ...

> so when I see this claim pushed over and over despite gallons of real-world evidence otherwise - and sorry, but your internal tests with tiny little games or demos mean nothing when compared to thousands of copies of commercial games out in the real world that show the opposite, and PLEASE don't try to blame the game's developers for this as you've done in the past - it's very hard to swallow after the 100th time when all evidence points to the opposite being true.

>

+1000

I know, right? I've optimized the hell out of Sombrero (which developers are also encouraged against in Scirra blog posts, while those developers then receive the blame for poor game performance) and I'm 99% sure there is absolutely nothing I can do to improve performance farther, and the performance is nowhere near far more complex games, including other 2D games, because of some limitations that seem endemic to C2 more than general HTML5/JS/WebGL performance limitations.

I know, right? I've optimized the hell out of Sombrero (which developers are also encouraged against in Scirra blog posts, while those developers then receive the blame for poor game performance) and I'm 99% sure there is absolutely nothing I can do to improve performance farther, and the performance is nowhere near far more complex games, including other 2D games, because of some limitations that seem endemic to C2 more than general HTML5/JS/WebGL performance limitations.

To be fair, advising against premature optimization or overzealous refactoring is pretty common practice even outside of construct, and generally good advice in most situations. The Scirra blogs also do clearly state the exceptions to this as well, and also give clear information about what to look out for for you to make your own basis for deciding about when and how to optimize.

The biggest thing missing is probably fine control of memory management, which is handled mostly through smart use of layouts.

Ashley after reading the many many comments on this and my thread I believe what people are asking for is this:

1- Go ahead with C3 as it may at least be useful to people using Mac and Unix even though most C2 users have said they do not want a Chrome browser based subscription engine.

2- Make an update or addon package of exporters and features for C2 that users have been asking for and fix the bugs you have been promising to fix for years. Put that new team of programmers to work on that along with C3.

We all understand Scirra has to make money and I believe you understand that if you lose your long time C2 users by not listening to us your chances of staying in business are pretty damn small.

So this is a reasonable request and you can charge your $99 for a great package of features and exporters for C2 and I will bet you will sell many more of those packages than you will C3 browser versions.

It also would prove you actually intend to honor your license and advertising that said those exporters would be included in C2 and would probably keep your base happy and maybe they would be interested in C3 later after you get all the bugs worked out.

It seems to me you would want those long time C2 users to hang around and support Scirra but reading through the comments on many threads they are dropping out and pretty disappointed in Scirra right now.

So what do you say?

Can we get a package of features and working exporters for the existing C2 engine at a reasonable price with no subscription Ashley?

In what world would any company agree to this?

C2 delivers what it promises - if you can provide a substantiated claim proving otherwise then I would present that rather this post that reads less like a reasonable request and more like a hostage negotiation.

To address the key points:

1) What exporters are missing from C2? They all work. Some work better than others; none of them are broken.

2) One off purchases simply do not work for Scirra's business model of supplying regular updates and constant services.

If you want the new exporters within C3 that incur a regular, constant cost to Scirra, you pay a regular, constant price (a subscription).

If you don't want to pay a regular fee, that's fine, C2 is a one off payment (for the software) and the export options are free, because they don't cost Scirra anything to update, host and maintain.

>

> Ashley after reading the many many comments on this and my thread I believe what people are asking for is this:

>

> 1- Go ahead with C3 as it may at least be useful to people using Mac and Unix even though most C2 users have said they do not want a Chrome browser based subscription engine.

>

> 2- Make an update or addon package of exporters and features for C2 that users have been asking for and fix the bugs you have been promising to fix for years. Put that new team of programmers to work on that along with C3.

>

> We all understand Scirra has to make money and I believe you understand that if you lose your long time C2 users by not listening to us your chances of staying in business are pretty damn small.

>

> So this is a reasonable request and you can charge your $99 for a great package of features and exporters for C2 and I will bet you will sell many more of those packages than you will C3 browser versions.

>

> It also would prove you actually intend to honor your license and advertising that said those exporters would be included in C2 and would probably keep your base happy and maybe they would be interested in C3 later after you get all the bugs worked out.

>

> It seems to me you would want those long time C2 users to hang around and support Scirra but reading through the comments on many threads they are dropping out and pretty disappointed in Scirra right now.

>

> So what do you say?

>

> Can we get a package of features and working exporters for the existing C2 engine at a reasonable price with no subscription Ashley?

>

I asked for a direct response from Ashley thanks!