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.

It's not just Chrome based, as Firefox will be compatible in the near future.

This issue of yours is two different issues

1) browser based

2) subscription

What's wrong with it being Browser Based? What technical issues are there that you are concerned about? You haven't answered that other than "But chrome updates" which is has an easy solution.

> 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.

While I didn't use the multiplayer plugin much it is a very interesting thing to play around with. I would say my only complaint is that you can't connect directly to another player without the signalling server. (Last I tried, unless it's been updated)

Glad to hear you're planning for a rating/voting system for suggestions. I have some unique ones that Tom might be interested in even if they're low priority

(IPFS, Ethereum)

[quote:10ppf3a2]Construct does indeed publish to the platforms that are named but it really isn't clear about the extent of each platform's capabilities.

Generally, it's as good as the browser engine is. Still I do appreciate prospective customers want to know what will and won't work. I think a lot of products have this problem where they support N platforms but X features only work across Y platforms, and can end up with pretty complicated support matrices. HTML5 is generally a good way to smooth over those gaps, but it's true that we probably ought to do more to highlight possibly problematic platforms which have several missing tickboxes. One problem though is it's really hard to have public messaging around that when you've signed an NDA...

[quote:10ppf3a2]But the biggest thing is exporters and getting the projects out to the masses.

Yes, lots on the way here, as announced.

Can't wait to hear the details. With your bigger staff and the major legwork on Construct 3 done I hope you can tackle the documentation issues with ease.

No. If they're advertising platform support, that means the features of those platforms should work. Period.

There's a difference between making them responsible for the wrapper itself and making them responsible for supporting the export process into the wrapper.

The ecosystem has improved greatly since the start of Construct 2 but not every platform is equal.

> 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.

>

I'd like to mention that in less than 48 hours, this post generated 17 pages. Let's you see that you indeed have a passionate community (with various reasons for using construct). 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. The forums are a good starting point but so many people don't use the forums so it's not always the best thing to use. I know I've lurked the forums for years and haven't really posted much outside of sharing my projects.

Giving roadmaps that are clear and also make sure the wording in your advertisement doesn't cause confusion or give people false hopes. Construct does indeed publish to the platforms that are named but it really isn't clear about the extent of each platform's capabilities. So build once, publish everywhere can seem very misleading to the consumer Scirra seems to market to (hobbyists, artists, designers, and overall non-coders who have no true knowledge of what's capable).

The browser IDE seems to be an issue for a lot. There are many posts regarding why. I personally don't see it as an issue as long as I can still make my games without compromise.

But the biggest thing is exporters and getting the projects out to the masses. Construct is used for a ton of reasons. Some people want to simply learn about game dev and make games to share with their friends. Some just want to fiddle around every now and then. And some want to create commercial games. Each group want and need particular things. For the most part, Construct has the game making portion of it nailed.

I have been waiting for Construct 3 and have been really putting in faith in what you and Tom says about the future of this technology. I'm not a programmer and I see this company as an entity that cares about creators such as myself who want to make games but don't necessarily care to learn coding.

I WANT to use construct 3. But I also want to be sure that what I create will be able to be published properly. The entirety of Construct 2 had me frustrated yet still around because of the ease of development. Maybe focus more on the post development stuff. I see that there are support options mentioned for Construct 3 but you have to understand that subscribing would be putting faith into what Scirra says again. It's a hard pill to swallow when a lot of the community has put faith for the past 5+ years.

Really show us what we're getting into with C3. Be more transparent with the future and upcoming features.

Thanks for taking the time to hear us out

+1 this.

lamar

1) You feel you were advertised the exporters instead of support of being able to publish to the platforms for Construct 2.

Just because it was advertised that it would work with the platform

*(with third party exporters)

doesn't mean they have to fully 100% support and make sure each platform's exporter works flawlessly with all features provided by Construct.

In fact Scirra has worked together with many of the wrapper projects to improve the project so Construct games can work even better in the environment but for each console the wrapper devs have to recreate the wheel and that needs a lot of time/skill/money. (Which is why it's good MS is doing their Xbox browser support stuff)

People didn't dev for Linux and Mac due to lack of support and we'd have a more stagnant dev environment if not for Valve and other companies throwing their weight into OpenGL/Vulkan to destroy the reliance on DirectX, but with consoles instead of just 1 environment (Linux/Unix-likes) you get multiple proprietary environments with not as wide of range of operating system/coding environment support.

I bet Scirra probably has some interesting stories trying to work with Nintendo if they were not under a NDA.

---

Now I do agree that there was a lack of support in regards to the exporters in terms of documentation that lead to additional confusions, as well as hopes that the parties making the wrappers would improve them more than they were.

As we see with Construct 3's cloud based service they're obviously getting an automated flow working to compile them for mobile, but I doubt the majority of the technology involved is Scirra proprietary. This means that it's possible for them to document majority of the process and then share with everyone so people can follow the steps and go through the process with their exported project.

I am just hoping Scirra does not abandon C2

You could've said just this.

Which of course while they have answered individual posts about it, its sunsetting plan could be in a well placed FAQ somewhere as the communication problem isn't them not listening, more of the information about the concerns are not apparent/easily accessible enough.

I think pretty much everyone knows C2 and C3 are HTML5 based engines so I am not sure even what you are saying?

You did not answer the question?

There are many reasons people have said they do not want a browser based engine and #1 is it is browser based and relies on Chrome and Chrome has many issues.

Why do you want a Browser based subscription engine?

There are many reasons people do not want a subscription including you do not own the engine and if Scrra goes out of business or stops renewing subscriptions for any reason you will not be able to edit your games.

Rephrasing questions:

Are you not worried about bugs that pop up with Chrome and Chrome Updates?

I am not worried about Chrome issues as they are the same issues you would get with Construct 2 for your exported games. If you're worried you can get the Desktop wrapped version when it's out, or in the meantime download Chrome Portable and use that as an instance. I actually recommend it for testing exports too.

You could disable auto-updates on Chrome too.

With Construct 2, Scirra notified us and fixed many issues that did pop up so there is confidence in that happening. Plus if you look at Chrome versioning you will see that the canary and beta builds are far enough ahead of stable that any issues will be known well before they affect the general populous.

Why do you want an app that is a cloud based program with subscription for it's monetization?

I can't really say much about the monetization method but I do prefer my own fully featured offline client. But while I do prefer it, other methods may be more feasible for them as a company and it's their job to make sure it inconveniences me as little as possible like any other distribution method/DRM. Chromes Persistent App feature makes the cloud based nature less of an issue on both desktop and android in terms of offline access.

What if Scirra suddenly just disappears?

For the Scirra disappearing thing there's 2 scenarios:

1) Website offline due to outage // User takes computer offline

How long can they use all features? Is it 30 days like Steam Offline mode?

2) Scirra stops existing

In the end if Scirra has to disappear, what is their sunsetting plan? Do they even have one?

This is something that we should have Ashley answer and have them put into a FAQ since there is much uncertainty over it.

For the scenario if Scirra exists and your sub ends it's less complicated as you own the code, but due to the model you don't own the right to access the full features of the engine. I have no opinion on that myself as of yet.

No one is saying Scirra shouldn't produce C3 for people like you but that is a small minority of people and they appear to be moving to a browser subscription format the majority of people that have supported Scirra with our money, making plugins and promoting them in our games do not seem to want.

So how is it a good business decision for Scirra to ignore what the majority of their base wants to focus on a small group of people like you?

The problem is in any discussion like this both sides say they're the majority or the target for the software. You're turning it into an Us vs Them discussion and that's not productive at all. What I'm trying to do is to get the points articulated without that sort of divisiveness.

You have valid complaints and concerns, but your assumed solution to those complaints and concerns are not the cause itself.

Where did I say anything about HTML5?

What else do browser based programs run on?

We all know C2 and C3 are HTML5 based and if someone does not want that format why would they get an HTML5 based engine?

You are trying to put your words in my mouth and we are NOT asking for special features. We are asking for exporters that were advertised when we bought our licenses and the bugs to be fixed and the features Scirra has been promoting that now are only included in a C3 Browser subscription engine that very few C2 users seem to want.

Why do you want a Browser based subscription engine?

Are you a Mac or Unix user?

I have been following these thread for months now and I have heard from less than a handful of people that want a browser based subscription engine and many many C2 users that do not want that so I would like to know specifically why you want that format and how you think that is a solution for your game design?

It sounds more like that you have 2 issues

1) You feel you were advertised the exporters instead of support of being able to publish to the platforms for Construct 2

2) You do not like the monetization model (subscription) Construct 3 is going towards.

I already addressed my opinion on #1 in my prior post.

For #2 because you're getting the cloud based automated wrapping as part of the sub is still cheaper for many people than the other engines, and it addresses you concerns with Construct 2's process due to the issue with #1 (at least for mobile exports, which is a large demographic)

Is this correct? You keep repeating Browser Based Sub Model when the browser based part seems like a non-issue from you very own statements, so I hope you can forgive me for trying to clarify the issues rather than relying on the monolith of "HTML5 isn't good enough yet" as the reason to not even use HTML5. I'm not trying to put words in your mouth as I do understand the pains, but wish the core issues can be better communicated.

Pretty much misses the point completely!

If Scirra is listening you would have heard most of the C2 users do not want a browser based subscription engine.

ome of us like that the direction they chose is HTML5.

"Some don't like a browser based engine" is not a problem on the developer listening, but more of what you the consumer wants and is demanding they go towards. Scirra has made it clear for many many years that HTML5 is the direction they're going.

From your further complaints you even admit that you don't care what kind of engine it uses, only that you want specific features:

We paid for a C2 license based on the expectation those exporters worked and they don't and you have been making promises to fix bugs and exporters for how many years now?

Instead you spend lots of time and get a new team to develop features and fix the bugs and make exporters for a subscription engine that very few C2 users even seem to want.

Your complaint is really that the options provided did not meet a standard you wish that they would have. This is independent of the engine itself and more about the ecosystem.

Yes, there is an ecosystem problem with HTML5 games in regards of compatibility/accessibility as it's a new ecosystem compared to Windows/Mac/Linux native libraries that link to already existing solutions/dependencies. Back when Construct 2 was first started it was seen as a fools errand, just like before Valve put into the effort to support Vulkan and Linux making a cross platform game for linux was also a fool's errand.

(and Linux is a native platform)

If you look at the state of HTML5 technology now as well as their offer of cloud-packaging C3 apps for mobile export what can be done now it has vastly improved. Games run faster on the same PC using more recent versions of Chrome. I'm on a Phenom II X4 925 which isn't the greatest CPU but I've had little issue outside of browser/driver support, which thanks to Vulkan we have better Open/WebGL support now than ever.

(kinda like linux!)

I do agree that with the confusion surrounding the best way to export for a platform and the issues that the Construct 2 side of things should've been a simple process, but I don't agree that Scirra should be ultimately responsible for optimizing every platform wrapper. They should provide a flow that allows a simple export process, even if it involves just shoving an exported zip file into a third party compiler/wrapper program. They seem to have an automated flow setup on their end for C3 projects, so documentation on that could be adequate.

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

The public beta will be available to everyone, and we're aiming to have it out by April. We're not charging anyone for earlier access!

That's fantastic news. How long do you expect the public beta to last?

> I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative.

>

I don't remember exactly which behaviors use it, but definitely the platform behavior does even better than pixel precision - it goes down to 1/16th of a pixel, IIRC. So it's actually kind of sub-pixel-perfect.

Well from what I remember and was able to test using grid placement in the platformer template, it still requires a 32x32 player to be either slight smaller than 32x32 for it's collision box to fit in a 32x32 hole or have the hole be slightly bigger. You can adjust the player size to 31.9x31.9 or so to have it smaller but relatively the same size so it can fit in.

It's just a limitation on how the polygon collision system is designed when focusing on lower resolution projects and it has great benefits for high resolution games where traditional bitmap collision masks would be too cumbersome.

I've had collision issues before and even played around with making a custom 8move to fit some needs of mine due more control over it and how it handles pushing it out of the blocking object, but it's more of a hazard of how it actually does collision vs ticks with polygons rather than pixel-perfect collision. I can't say how many times i had to make an object slightly smaller to fit into a gap that in a pixel-perfect environment would fit perfectly (gap of 8 pixels wide, object of 8 pixels wide, polygons of 7.96 or so) or make sure it's sprite stops perfectly against the wall rather than going over the edge slightly.

Most of the time it's only an issue depending on tickspeed and movespeed of the object it's tracking. There's always room for optimization and isolating edge cases so they don't drag down the system, but it's just a limitation of the engine.

I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative. The pixel rounding they do in the optional settings for it simulates it visually but the collision box itself is still a polygon.