PC browser games only 5%,should Construct change?

Am I missing other markets?

You can export your game as a "normal" Windows program (an .exe) and sell it on Steam, that's a big market you didn't list.

Here's an example on web games having more income than mobile versions:

https://www.gamedev.net/blogs/entry/226 ... ebgl-game/

I realize this is not the market standard, but I just wanted to share this with you to prove that it works that way sometimes.

You say that, but there is an overwhelming amount of people who say otherwise. A lot of C2 developers have switched to Unity because of performance. Who should we believe?

Performance aside, I think C2 and C3's biggest problem is third party wrappers. I haven't found a wrapper that I haven't experienced some trouble with. If C3 was native, you wouldn't need to rely on HTML5 wrappers. Construct is fantastic for browser games, but it's a real pain trying to get it to work on other platforms.

Listen to the developers who end up having to move on. We're far more familiar with the real-world performance of C2 and the endless issues with getting it to run well on multiple desktop platforms, let alone mobile or console (which have no real support) where performance just isn't there for anything graphically intensive in C2. We also have less of a vested interest in sweeping the issues under the rug.

Plus one to what digitalsoapbox said.

Looking at the PROS only we saw:

Construct 2(/3) - Nice editor and events

Unity and custom coded C# - The game actually runs, plus consoles support, plus compatible with a lot more PC's

>

> Am I missing other markets?

>

>

You can export your game as a "normal" Windows program (an .exe) and sell it on Steam, that's a big market you didn't list.

Speaking of other markets, Construct 2 supported exports to Nintendo Wii U. I saw the same games on Nintendo 3DS (but they may not have been created in Construct 2). Does anyone know if the new Nintendo Switch supports games created in HTML5?

Could Construct 3 support games for the Nintendo Switch or 3DS? I assume no one is creating Wii U games.

Speaking of other markets, Construct 2 supported exports to Nintendo Wii U. I saw the same games on Nintendo 3DS (but they may not have been created in Construct 2). Does anyone know if the new Nintendo Switch supports games created in HTML5?

Could Construct 3 support games for the Nintendo Switch or 3DS? I assume no one is creating Wii U games.

Nintendo used "Nintendo Web Framework" (HTML5 games) in an attempt to bring more developers on Wii U.

While the Switch should be able to run HTML5 content and has a touchscreen, it already has a lot of developers (and support for Unity), so I think it will not get "Nintendo Web Framework" anytime soon (or at all).

Even the New 3DS is a no-go for HTML5 due to performance issues.

If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.

I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.

Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.

As someone with zero expertise in GPUs, bottlenecks etc. here what i always wonder when i see statements about hardware being maxed out, not specifically in Construct but other 2D engines as well

I have a hard time understanding how Asphalt 8, Modern Combat, Titan Quest etc. can all run on my device yet somehow a simple 2D game is maxing it out

So it does seem like not all engines are created equal here nor are game developers. I still wonder what went wrong when The binding of Isaac lags on my iPad Air as soon as there are more then 4 fires in a room while Real Racing 3 runs flawlessly. I know it started as a flash game but supposedly it's been rewritten twice yet it still suffers from poor framerate

So how are Gameloft, DotEMU, EA etc getting this extra power out of my device?

I'd imagine those 4 fires are spitting out hundreds of objects using a costly shader for only a minor effect that could be done by a few frames.

Then again, form over function is what sells. Many of the better selling games have simple game mechanics, but have highly polished graphics.

If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.

I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.

Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.

I wish I could spend the time to help find the source of slowdown, lag and jank in C2/C3 and all its Third Party wrappers, I really do, because I love what you and Tom have made on the editor side of things, both in layout and events.

However, I don't have that time. I can only tell you that I experienced much better performance and compatibility in Unity when remaking the same game we had prototyped in C2 (actually, with better special FX and a higher output resolution thanks to upscaling a deferred renderer/render texture), and that I also find both Unity and Construct Classic make "smoother" running games that don't feel janky (even if the native runs at maybe 30fps, it doesn't jerk like C2 can at 59fps).

I'd really like to recommend again that you use your own tool to make (and release/troubleshoot) a full sized platformer game (on at least Steam for Windows) and experience the issues that others like myself have reported here. I'd even subscribe/pay for a C3 subscription just to see some work on that happening/it release over the next 2-3 years.

And if you prove me wrong? Great! Share your knowledge with us on how to best make large games!

If I prove you wrong? That's still good, because now you know best how to debug and optimize C2/C3.

> Speaking of other markets, Construct 2 supported exports to Nintendo Wii U. I saw the same games on Nintendo 3DS (but they may not have been created in Construct 2). Does anyone know if the new Nintendo Switch supports games created in HTML5?

>

> Could Construct 3 support games for the Nintendo Switch or 3DS? I assume no one is creating Wii U games.

>

Nintendo used "Nintendo Web Framework" (HTML5 games) in an attempt to bring more developers on Wii U.

While the Switch should be able to run HTML5 content and has a touchscreen, it already has a lot of developers (and support for Unity), so I think it will not get "Nintendo Web Framework" anytime soon (or at all).

Even the New 3DS is a no-go for HTML5 due to performance issues.

I'm not entirely surprised that Nintendo Web Frameworks was not carried over to N3DS or NS. Bummer!

Of course, even if someone could use NWF, jumping through the hoops to get the game accepted is another story. Sounds like Unity is the way to go for Nintendo games.

Speaking of Nintendo, Ever Oasis just came out for the 3DS, proving that the 3DS is not dead. And next week RPG Maker FES comes out for the 3DS. Awesome stuff.

Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented)

I have a hard time understanding how Asphalt 8, Modern Combat, Titan Quest etc. can all run on my device yet somehow a simple 2D game is maxing it out

3D games in particular have a very different rendering approach. Many GPUs have limited bandwidth, and the fact 3D games have depth allow them to use a front-to-back approach that more or less ensures every pixel is only drawn to once, at least for the basic color pass. Many Construct users naively create a stack of 14 force-own-texture layers, causing every pixel to be written to at least 14 times, which absolutely hammers the GPU bandwidth for all it's worth. Then traditionally they blame HTML5, Construct, browsers etc. without recognising what they've done.

Part of this is the game design aspect: AAA games are built by experts who know this GPU performance stuff inside-out. If you're an indie dev just starting out with Construct, things like fillrate limitations are often things you learn about the hard way.

I'd really like to recommend again that you use your own tool to make (and release/troubleshoot) a full sized platformer game (on at least Steam for Windows) and experience the issues that others like myself have reported here.

I do work with very large projects. Thanks to the developers sharing them, I do privately have C2 projects for games like Airscape and The Next Penelope. On the whole, they seemed to work fine, and the C2 engine was holding up great. The Next Penelope in particular had some issues with using too much fillrate early on, but Aurelien made some game design changes to reduce excessive layers, effects etc. and then it fit much better within GPU hardware limitations. That is exactly what I was talking about above. So my view here is not due to naivety, it's actually based on working with these very large projects.

> I have a hard time understanding how Asphalt 8, Modern Combat, Titan Quest etc. can all run on my device yet somehow a simple 2D game is maxing it out

>

3D games in particular have a very different rendering approach. Many GPUs have limited bandwidth, and the fact 3D games have depth allow them to use a front-to-back approach that more or less ensures every pixel is only drawn to once, at least for the basic color pass. Many Construct users naively create a stack of 14 force-own-texture layers, causing every pixel to be written to at least 14 times, which absolutely hammers the GPU bandwidth for all it's worth. Then traditionally they blame HTML5, Construct, browsers etc. without recognising what they've done.

Part of this is the game design aspect: AAA games are built by experts who know this GPU performance stuff inside-out. If you're an indie dev just starting out with Construct, things like fillrate limitations are often things you learn about the hard way.

> I'd really like to recommend again that you use your own tool to make (and release/troubleshoot) a full sized platformer game (on at least Steam for Windows) and experience the issues that others like myself have reported here.

>

I do work with very large projects. Thanks to the developers sharing them, I do privately have C2 projects for games like Airscape and The Next Penelope. On the whole, they seemed to work fine, and the C2 engine was holding up great. The Next Penelope in particular had some issues with using too much fillrate early on, but Aurelien made some game design changes to reduce excessive layers, effects etc. and then it fit much better within GPU hardware limitations. That is exactly what I was talking about above. So my view here is not due to naivety, it's actually based on working with these very large projects.

Thanks for the explanation

As i said, it was not a dig at Construct, it's just something i've wondered about due to my own ignorance on the subject

Many Construct users naively create a stack of 14 force-own-texture layers, causing every pixel to be written to at least 14 times, which absolutely hammers the GPU bandwidth for all it's worth.

Can you explain this a little more? Just want to make sure i'm not doing the exact same thing already too.