It's hard to adequately respond to a 6-page forum thread that springs up over the weekend, but I'll do my best. Also these threads often turn in to everyone throwing in their own different concerns and it's pretty exhausting to even try to address everything - often I reply to the OP and then everyone piles in afterwards with "what about X? Y? Z?", and this happens a lot even when I do try to address everything... so anyway, here we go, focused on the OP:
HTML5 on Wii U: the main problem here is Nintendo's weak support of HTML5. Technically we're under NDA so I don't think I can go in to too much detail on this, but I think by now it's common knowledge that the NWF doesn't support WebGL, and that's really just one of several aspects. It's possible to publish smaller scale games on the Wii U, but larger scale stuff will run in to these limitations. There are similarly-specced mobile devices that can far outperform the Wii U due to having better browser tech. Things like this are really frustrating because they unnecessarily make HTML5 look bad. If Nintendo used modern web support, it'd have been far better. Yes, this is a shortcoming of HTML5 that we get stuck with browser engines like that sometimes. Yes, users don't care whose fault it is and just want it to work. But I honestly think it would have been impossible for us to write a native engine with the size of team we are within the timeframe of the Wii U being replaced by the Switch. In other words, it was that or nothing, really.
he Wii U did have some pretty good HTML5 support at launch so I can see why there was hope it'd be pretty easy to have it work.
If you want a Native VS HTML5 example of the Wii U the YouTube app was garbage and ran slow, but using the Wii U Browser the website YouTube ran a lot smoother and faster.
I'm not sure about later on but I do know the Wii U browser didn't see too many updates/optimizations and custom wrappers always seem to end badly
Native isn't always faster than HTML5, but HTML5 isn't always fully supported or maintained once added.
Hopefully the Switch will get a good wrapper sometime, but time will tell.
Wider console support: it's an interesting time to complain about console support, because the only reason we don't already have Xbox One publishing (which does use a modern browser engine!) is we've been busy with the C3 launch. See this Microsoft announcement which specifically mentions Construct 2 from early March.
o we know if it'll have similar support for features as Edge/using Edge itself?
Edge is a bit behind even though Microsoft is at least attempting to support HTML5 with updates here and there.
Wider HTML5 reliance: I would actually credit Scirra's entire success to our reliance on HTML5. Sure, it has some downsides, but no technology is perfect. We've seen other competitors with native tech fade in to irrelevance with limited features and dragged down by difficult bugs and development inefficiencies. I'm actually really glad we went this way. Also HTML5 was laughably bad when we started in 2011 (and some people literally laughed at us for choosing it over Flash). Originally, we never even expected to support mobile at all. Things have come a long way and it's still going strong, so I think HTML5 still has a bright feature.
I also have to wearily point out again that graphics drivers are a concern everywhere, and we have direct experience of that given we've worked on native tech in CC and the C2 editor. It's actually worse in native than it is in HTML5. It's so bad, it has actually ruined AAA game launches in the past. Most indie game developer's post-mortems I read, when they used native tech, almost always involves some kind of section excoriating the woeful situation with graphics drivers, to the extent they say things like "I wish I just had never even tried to release on Mac because the OpenGL support is so bad". Big companies can usually (even then not always) muscle through it by putting several engineers permanently on the problem, but when you're small, HTML5 probably actually makes this better than it would be otherwise.
've seen HTML5 gotten a lot better and more optimized, but it does have the problem on relying on a notoriously unoptimized rendering platform (a web browser).
There are some desktop wrappers that work without a lot of the extra browser crap, but they are unintuitive to setup, or have some obscure issues. Thankfully those kinds of issues are getting rarer but they apparently still do happen.
I've heard fears of "What if my browser updates and breaks something" for the editor in HTML5, but one thing I do recommend for testing things is Chrome Portable but many might not think about this solution right off. I also use different Chrome Portable versions to test my projects as well.
Not listening to customers: this is pretty hard to take, as the original company founder with over 23,000 posts on this forum, as high as a constant 10 posts a day on average in some cases. How many companies can you go on the forum and talk about something directly with the original founder of the company? We try to make ourselves available to customers, and I do my best to read all the posts and feedback on the forum, but it's pretty tough to respond to everything with hundreds of posts a day. I do in fact hear everyone's concerns loud and clear. There's a lot of reasons why we can't always immediately do something, ranging from the technology to overall direction of the company, but I am here, and I do listen, even when that involves quite a lot of criticism. Sometimes even when I explain the case, it doesn't stop the criticism. For example some users hit graphics driver related issues and then say they wished we had native engines; these people would be in for a very nasty surprise if we actually did that! But it's never stopped the criticism, so I think to some extent I've just come to accept that some users are going to be unhappy and won't understand some things we do or the reasons behind it, and that's part of the nature of running a company.
While I don't think it's entirely the issue in terms of the 'not listening' issue, I believe there is some of a communication problem in regards to the engine's performance expectations and that there should be more published communication on the subjects for improvements and performance. Not just blog posts stating how good it's running now as many people are not gonna scroll through every blog post to see that kind of information.
For major projects like trying to push for a console export a status page listing the exporter and it's supported level (unsupported, in-progress, NDA, working) and a link to the project page would work wonders. It seems that from marketing it works great on many export options but they're not all viable for many projects so easy to access Construct relevant feature support lists and performance details would be very beneficial.
A page with Scirra tested benchmarks for each platform
(PC/Mac/Linux with PC specs, Android/iOS with model, wrapper vs browser
) with a Construct 2/3 version of the exported test file would work wonders in giving people an idea of how relative their current devices are to the test devices. If the benchmark demos even had an option to "submit your results to Scirra!" on it that would help aggregate consumer side data for a wider range of devices than the ones you can afford
(but I do recommend having an official list of test devices that you can have physically)
I will say that the debug mode added into Construct 2 years ago was a godsend in providing this kind of data for my projects, but having a standard repo of test projects with their performance ratings would provide a good guide on how fast something should run, and for the more advanced demos how fast the type of game should run (
since I assume all Construct templates and demos are optimized for best performance )
Now I understand why if you consider marketing it wouldn't be good to advertise sub-quality numbers, but from a developer point of view you would want all the resources you can get to judge each engine and to omit that can be a disservice to the community (even though the community could make a resource, it'd be more beneficial if there was an official resource.). Plus with HTML5 tech being a lot better now than when you initially started the technical details will be more flattering than years ago as many of your recent blog posts have been showing