I wouldn't call all those years with Construct wasted just yet. Construct was started as a free open source clone of Clickteam products and their newest one in development looks like its returning the favour (minus the HTML5-only export).

Might be a very viable alternative for you.

it's the graphics drivers, which are native technology. As I repeatedly have to say to people who don't seem to believe this, graphics drivers are widely accepted to be terrible and can even completely ruin game launches. Here's two links to back this up:

Batman: Arkham Knight had such poor PC performance it virtually ruined the launch - it ran fine on console, where the drivers are good quality and predictable

"How to delay your indie game" specifically calls out struggling with GPU drivers: "Despite claiming to, their drivers just don’t properly implement the OpenGL specifications... Then a new OSX update will hit and everything will change again, yet at the same time I will need to still cater for the previous releases and older machines... it’s unbearable... Would I support Mac again? No."

I always laugh at this argument. "Graphics card drivers are bad!" so you decided to use possibly the most unsupported and experimental platform (other than Vulkan, which seems to have better performance already), I.E. Web GL ?

That still runs on graphics card drivers! You're still facing the same issue, just hiding it as "not my fault now!" when it's Chrome or Node-Webkit/NodeJS that's blacklisted it instead.

The simple bottom-line is:

1.) Most desktop graphics cards today are optimized specifically for DirectX (at least to 9.0c), and have varying degrees of OpenGL support, both integrated and dedicated

2.) The same graphics card issues that occur in a native engine will still occur in HTML5 + WebGL, because you're still using the GPU to render graphics unless you're blacklisted and running software I guess?

3.) Aside from a few neat tricks to convert native C++ to JavaScript like ASM.JS, JavaScript will always be slower than a majority native code by some amount. Sometimes by a very large amount, as we have noticed with collision and physics.

3b(onus).) If you're someday going to be using ASM.JS why not also export actual C++ code that could be used in another game engine that supports lots more platforms and actually allows people to make viable/sellable commercial desktop and console games? It could be charged per export and still make plenty of cash for Scirra!

To the people saying "You just event bad!" well if the engine is designed that way and I optimize my events as best I can to still have the functionality I need, and it's slow, but I code fairly averagely in some C# and Unity and it runs blazingly fast + with better compatibility on Steam than our previous Construct 2 title, is that not proof enough? It wasn't even a GPU limitation because we added MORE effects to our game!

It's nice when that last argument is made by people who don't have titles selling commercially on Steam, who don't see the issues that occur and have to hear "Give me your source code and/or report it to Chrome or NodeJS !" every time they have an issue in the engine they purchased to make commercial games.

Personally, I'd rather pay $100/year for Scirra to make a commercially sold large 2D pixel-perfect retro platformer in their own engine and then release and troubleshoot it on Steam, than to further invest in HTML5 with C3, and it sucks, because I really like the way Construct does game making (it still has an editor I love very much, which is what keeps me still fairly interested in the developments of Scirra ahead). I just need C2/C3's export to be a lot better for playing, and preferably sooner than "the future" where PC's drop in price to the point where everyone runs basically an Intel i7 CPU + NVIDIA GTX 960+ GPU and the problems "suddenly disappear now" magically.

Triforce The arguments made above have been my experience, and the experience I have seen from other prominent Construct 2 games on Steam. You can listen to the people who haven't made large games if you want, but we have all roughly come to the same conclusions: C2 is great for hobbyists, educators, and personal or small games. But when you need to get larger, make some prototypes and test a LOT before deciding to stick with it.

With C3 you can get on Steam and iOS. That's more than enough exporting features for you to make money and get exposure with. I think the major problem with developers is phycological. There's a mindset that "if you are not coding you won't ever get the flexibility you need".

You need to minimize your game development problems and C3 does that.

While Steam alone is okay for sales (but not really "enough" to run an indie studio on without being extremely popular), I would say iOS / Android are both very hard to make any commercial success on without falling back to in-app-ads or token-purchase systems and free-to-play models.

The console export options that became available to us after switching engines had made a substantial difference in both the success of our crowdfunding campaign, and the global press that our game has received so far.

For other benefits that switching to code gave us check out my post here:

However, Scirra can't control when and where a 3rd party wrapper will be available, so it's best to assume that the only true export of Construct 3 is HTML5. Console support so far has been unsuitable for commercial titles to rely on, and that might continue on indefinitely if console makers don't wish to enable full HTML5 + WebGL.

Basically: Don't try to minimize the other options available, they are tools for a purpose, and if you want to make large and/or commercial games for consoles and mobile they're a safer bet.

Construct 2/3 is great for hobbyists, web games, educators, and freeware, but having released our previous Construct 2 game on Steam we have learned the hard way that most computers buying 2D games are still not ready for HTML5 + WebGL.

Scirra is sticking to their plans on Construct 2 and Construct 3: All exporters will be HTML5 + wrapper based for the long-term ahead.

There was talk very early in the development of Construct 2 for other exporters way back when it was starting (which is why HTML5 is in a folder called "exporters" in your Construct 2 folder), but that was cancelled equally long ago.

After the many posts and the locked thread, it seems the best option for Construct users now is to wait and see how the subscription turns out. Scirra really wants to try it, and if it works out then that's great for them (and us) !

If not, they'll hopefully have a backup plan ready in time

But, I would say it will be one or two years from now before we know for sure (eg: many people might try one or two years before trying something else, so it's still pretty risky for Scirra if big/long-term projects aren't being made).

That's okay though, we've all been waiting many years already for HTML5 to be the high performance multi-platform export format of choice for 2D gaming anyway, what's the harm of waiting a few more?

Top-down games seem to work pretty will in Construct 2/Construct 3, but I would say it comes down to this:

1.) Is your game CPU heavy? (eg: lots of line-of-sight, and maybe physics stuff going on?)

2.) Is your game targeting a wide variety of desktops, and is it commercial (eg: do you want to release on Steam?)

3.) Do you want console export? (eg: anything beyond "Wii U and Xbox One", which are themselves in quotes because they don't have full performance on the hardware that a native engine would)

If you answered yes to any of those three questions, especially the commercial one, and you really are making a "large" game, I would advise looking elsewhere.

There are many who are happy to say there's "virtually no" difference between native and HTML5, but having made the switch ourselves we can say:

-We gained FPS after re-coding in C#, this makes sense since JavaScript is inherently slower in most cases

-We could use fancy effects that didn't seem to slow down as much as WebGL did, even if we used more of them

-We now support consoles, and for that matter, a much greater variety of desktops

-The game in general "feels smoother", it's hard to explain but as a long-time Construct Classic user I can say that (to me) C2 never felt as smooth as CC did, and switching to native again with our latest title seems to re-confirm those suspicions.

Otherwise? Construct 2 / Construct 3 should be a great option

Hope that helps!

Didn't you finally want to leave the good people here alone?

Tom we really need a Block function in the new forums.

But how would a block function work?

Does the owner of a thread have the ability to block someone from posting in their thread?

Does it just hide the other users' posts from you? Or have a button to see it when you want to know what they said?

Does it stop them from being able to reply to you / quote you / tag you?

Being able to choose what information to see or ignore is yet another reason why arguments start, I don't think it would make things better.

However, for hateful posts you can surely report them.

Whatever I, and other developers here, may have said about Construct. It doesn't mean that Scirra's team isn't working hard, just maybe not towards the outcome that we would like (again, I'd like for Scirra to take a stance on that moving forward with C3) and the mods are also great at responding quickly.

Construct has a great community, these arguments are growing pains as Construct morphs into its next evolution. Right now, to me, it's looking like it's going more the way of "Scratch" with hobbyists and web and educators having the best time with it, and some mobile/"light console" as optional bonus features.

If Scirra advertised the tool that way, I would never have a problem with it, although I would see partially missed potential for console export from Construct's awesome editor, that's just personal opinion.

At the same time, threads like these serve as a "canary in the coal mine" for other developers, so they know when it's time to move on from their prototypes and free games to other engines if they seek commercial and console content (or to let them know if they even have to change engines at all, which currently the consensus from showcased and other "serious" devs seems to be: yes)

Yeah, I think the response Lamar is looking for belongs in his other thread which was locked. Lock this one and unlock that one maybe?

How would you like us to deal with bug reports that don't meet the minimum requirements to investigate? Do you have a link to some of them that concern you?

Ideally I'd like for Scirra to try recreating the described situation, work with the paying customers to reproduce what it is they assume they are trying to do, and spread knowledge about how to do that properly, rather than closing as won't fix.

For example, here's some in the past 6 months:

Graphical issues NW.js: Closed for using a third-party addon and not being "minimal" (how do you do that when you have a full sized game and might not know if it's merely a size-of-the-game issue?)

Platform jump height variation: Closed as won't fix (so no pixel perfect games allowed eh? too bad Retro is the most common 2D game people like to make)

Issue with platform behavior: Closed as won't fix (A jump command should be received that tells the platformer to only check for being on ground once the velocity Y is below 0 again)

Pin behavior position lag: Closed as can't fix (why not give the user some means of control over the order in which behaviors will be executed?)

Choppy/Jerky Frame Skips: Closed as another Google issue / "can't fix" (Great, says every customer expecting decent mobile export)

Also R0J0hound I think it's safe to say that those passmark results are comparing against other users who are into "passmarking"/benchmarking. The Steam HW survey is even slightly biased as it is probably has more gamers who play 3D games than 2D.

For a strictly-2D sense, the average hardware we're seeing does dip down into Windows XP and Vista users, and they do still get very vocal when our game doesn't work (and we told them in requirements that it wouldn't, not even marketing to them as possible or "functional" on their OS !).

Which threads were unjustly locked that you are referring to?

Good point, I unfairly lumped locked and closed together in one there.

I am more so concerned about closed bugs (which I mistakenly believed were locked) which were closed simply for not fitting within the tight guidelines on bug submissions.

I'm not going to defend a 4 year old blog post. Yes, it's probably wrong. It was just an interesting benchmark result. I haven't spent the past 4 years claiming HTML5 games are faster than native. Just that they're fast enough. It is basically fair and correct to say WebGL has identical GPU rendering performance to native code.

Hehe, I don't think you need to say it's faster, but for your target audience that last sentence is going to sound the same to them and they'll be upset when they find out what that actually means.

Again, I do think it's a pretty unique thing that you actually can talk directly to the founder, but I'm starting to see the appeal in disappearing behind a corporate team page...

We talk to our customers too, it's part of our charm as a small indie team. The same applies for Scirra, not participating in the discussions just proves everyone who says Scirra doesn't listen is right, although I guess ignoring their concerns and locking their threads / bug reports does the same too

tunepunk Q3D is awesome, built on ThreeJS, so you're only seeing the C2 event system and 2D collisions/physics and audio subsystems at work there. Shows more WebGL's strength than Construct's performance.

Also, Unity does have different eventing types: plyGame is quite a bit like event sheets, but there's also PlayMaker and a few other visual scripting tools available for it. It's probably just a matter of time before "I stay with C2 for the event sheet" becomes "I switched to Unity for the event sheet" and it'd be a massive shame if that wasn't an event sheet plugin made by Scirra.

To be fair, since my post that jayjay quoted me with I have since got a replacement for my 10 year old computer so the graphics are no longer a bottleneck on my system. Also the few times I tried mobile export the performance was much better than my old system.

Great point R0J0, although the Steam hardware survey says that's not the norm with only half the systems running Win 10+ (almost 30% still running Win7 systems) and only half are quad-cores on all of Steam.

From a commercial perspective, a 2D game that requires a quad-core CPU and latest line of NVIDIA or AMD or *maybe* Intel isn't very acceptable to the developers or their customers, and it reflects in Steam reviews and comments across other forums.