Is C2/C3 good for large 2D desktop games?

Planning to make a semi-large 2D over-head view game for desktop and not mobile.

How good would the performance be compared to engines such as GameMaker Studio2 ?

Would it be a downside that Scirra is html?

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!

I was wondering the same thing two months ago when I researched various game engines for a new semi-complex 2d game project. I tested Godot and Construct 2/3 on my two laptops.

I went with Godot, because on lower spec'd machines (i5, 4gb) the performance just wasn't that great, and native export with Godot kept the games I tried running at a nice 60fps. With NW.js and Construct 2 I could not get the same level of performance. At least, not on the older laptop. But since a fairly large part of the Steam community still runs similar level hardware, I decided against Construct.

I read through the comments of other C2 developers who have published C2 PC desktop games to Steam, and I did not really like what I read. There are some issues, it seems. My experience during testing was also that putting Construct in debug mode while running the game would slow it down much more than running games in debug mode in Godot. That really clinched the deal for me, because far more complex games would run quite smooth in debug mode on my Linux Mint work laptop, and would slow down far too much in Construct 3 and the browser.

So, yes, in my opinion the browser wrapper may work against you. But you could always increase the minimum system requirements for your game, obviously. And your work machine may be much faster than mine, which is a run-off-the-mill laptop with 8gb and intel graphics (purchased last year).

I have no experience with GameMaker - but Godot works like a charm while developing and testing on my laptop. C3 does not. Your mileage may differ.

If you aren't making anything too complicated, Construct is good. If you intend on making something fairly complex or medium scale, I would shy away from Construct.

My reasoning is based on a few things:

As your project becomes larger it becomes increasingly difficult to organize and manage your events, assets, etc. You have to be sure to plan everything out- so you'll need to be very adapt at construct in order to perceive potential issues down the line in development so that you can avoid them. This is the case with any engine, but construct has a very unique framework that you have to deal with, and it is often not suited well for organizing aspects of your project.

Performance doesn't seem to be that great for older hardware. I haven't tested anything on any new hardware, so I am suspicious of that too.

There may be a lot of gotchas or limitations, or bugs that you might come across that you may not normally have with other engines- and this is due primarily to the way Construct was designed, so you won't have any way of solving them. Or you may have to wait a long time for fixes.

On the other hand, there are a lot of good qualities that Construct has, with good reasons for using it. If you have lower expectations, you can find comfort in the ease of use the editor has, and be capable of creating a lot of different stuff fairly quickly. If you become more adapt at it, and understand what to avoid, you can realistically create a small to mid-size game that runs fairly okay. I've never seen a game made with construct that I would consider "large."

This question has been asked and asked and asked so many times

At the end of the time, regardless of whatever the IDE is, C2 is an HTML5 Javascript Engine, so go look for performance articles related to those environments, at this point in development, I truly doubt their runtime is the bottleneck for any big project

The short answer is "HTML5 and Node-Webkit (which is our only source of creating an executable) is not the best combination for a medium to large-scale game". I know this because I've released 1 on steam and have 4 more titles pretty far into development (from FULL blown high-res vector art to pixel art).

That being said, C2 IS the best editor in game development, period. You will never find something as intuitive and easy to learn while requiring no code, and for that I completely commend them. However, if you already are familiar with C# or any other languages, it's worth using a different editor and engine.

During testing of my first project, most users with bad laptops could run games like Ori and the Blind Forest on high, yet my simple vector art or pixel art game with very few assets could get a max of around 30 fps.

HTML5 isn't really the limit at this point, This game uses HTML5 and packs the desktop games with electron https://duelyst.com/,I experience no performance losses with it even on high settings, This is also another html5 game http://www.cross-code.com/en/home ,At this point in time. I would just assume that the extra overhead of catering to a visual scripting language has taken its toll when it comes to construct 2 desktop games

As a point of comparison, I recently started building our 3D game in Construct 2 using the Q3D plugin just to see how it would compare to building the same game in Unity.

Originally, the game was set to match the resolution of the device. On a 2017 Surface Pro 4 with a hi-DPI screen, this brought frame rates down to below 30 fps, almost unplayable. I have found that by keeping the screen resolution lower (854x480) and disabling all effects, performance is a rock-solid 60 fps/50% CPU load on both a low-end 2013 MacBook Air and the Surface Pro 4, and is 58-60 fps on an iPhone 7 plus.

The game is physics-intensive. I built several prototypes of the game, first with a custom 2D physics engine (built using C2 behaviors) and 2D graphics, then using the standard C2 physics engine with Q3D graphics, and finally with the Q3D Oimo.js 3D physics engine and Q3D graphics. In the end, I found that the OIMO physics engine gave me the best game feel, and by limiting the number of physics bodies I could keep CPU load down. The standard C2 physics engine was a smooth 60 fps as well, but the game really needed the z-ordering and 3D torque of a full 3D engine.

Now that I am a few months into development, I am planning to stick with C2 rather than switching to Unity. I haven't found any technical roadblocks to completion, and I expect the finished game to fall into the "medium-sized" category. I have been a heavy C2 user for the past three years, so I am very careful with the way I structure my event sheets for maintainability. There have been several times that I wished that C2 had true object inheritance, but most of the time I am happy that to work with event sheets rather than C#.

So will C3 make a big or small difference over C2 in performance on a PC desktop? Or is that too early to tell?

So will C3 make a big or small difference over C2 in performance on a PC desktop? Or is that too early to tell?

Probably too early to tell.

When they update the C3 runtime, there will likely be some improvements.

As far as I've ever been able to tell, every case of significant performance issues in a browser, NW.js or on mobile, is GPU blacklisting. That is approximately 4% of devices in the world which have such terrible GPU drivers the browser won't use it (since it causes crashes/severe glitches) and reverts to software rendering.

I have seen scant evidence of any other significant performance issues for a long time now, despite always asking and investigating.

The irony is graphics drivers are native technology. Using different technologies just makes you vulnerable to the crashes/severe glitches on those 4% of devices with poor quality drivers.

For the 96% of devices, WebGL is native performance. It's bottlenecked on the hardware.

For the 96% of devices, WebGL is native performance. It's bottlenecked on the hardware.

This is 100% untrue blaming-shifting nonsense. Performance on even powerful desktop GPUs is around half of what native provides for larger desktop games, and saying half is being generous, and reaching only around 50% of native performance involved a LOT more work than it would using other game development tools; hell, there's not even a way to set the canvas resolution easily in a way that takes into account object positioning, because you've somehow convinced yourself it isn't necessary (even though native apps support this with switching monitor resolution out of the box), and only offer "low" or "high" settings. Blame drivers all you'd like, but it's what literally every PC uses, so complaining about and/or blaming them is pointless navel-gazing. Blaming the only ways to export games for poor performance is highly disingenuous, since they're the only way to export and sell C2 games. I can't even imagine the gaps in logic that allow someone to arrive at your performance comparison conclusions.

You've hitched Scirra's wagon to HTML5, and that's fine. But let's not pretend it's even close to a mature technology, from a software/development standpoint all the way through hardware support, for the creation of medium-large games. The performance simply isn't there, and you're flat-out wrong to suggest it's remotely close to performance of native with anything more than a very, very simple game with absolutely no bells & whistles.

Blaming the only ways to export games for poor performance is highly disingenuous, since they're the only way to export and sell C2 games. I can't even imagine the gaps in logic that allow someone to arrive at your performance comparison conclusions.

You've hitched Scirra's wagon to HTML5, and that's fine. But let's not pretend it's even close to a mature technology, from a software/development standpoint all the way through hardware support, for the creation of medium-large games. The performance simply isn't there, and you're flat-out wrong to suggest it's remotely close to performance of native with anything more than a very, very simple game with absolutely no bells & whistles.

This response seems pretty harsh. So you think Ashley is being purposefully deceitful in order to sell more product? If so, to what end?

Ashley has a point, investing to a young technology which has potential to improve in time. But currently, within this decade, I'm with digitalsoapbox on this one, HTML5 is too young, javascript so slow... Even making a small Flappy Bird game is far more stable making in Unity for an Android Jellybean phone from 2012 than making on C2.

As far as I remember, my tests back then has a performance of 60fps stable no significant spike for the game made on Unity and 24fps unstable, frequent lag spikes and unplayable for the one made on Construct 2.

Theoretical FPSs or hypothetical speeds between native and html5 doesn't matter anymore when real life benchmarks are so significantly bad.

In conclusion: Ashley you're so wrong ...

Ashley has a point, investing to a young technology which has potential to improve in time. But currently, within this decade, I'm with digitalsoapbox on this one, HTML5 is too young, javascript so slow... Even making a small Flappy Bird game is far more stable making in Unity for an Android Jellybean phone from 2012 than making on C2. ...

Could one of your guys please provide something which actually has some sort of valuable information in it?

I mean I'm always biased towards native but these sorts of claims are what Ashley has been criticizing several times in this forum already.

...As far as I remember, my tests back then has a performance of 60fps stable no significant spike for the game made on Unity and 24fps unstable, frequent lag spikes and unplayable for the one made on Construct 2.

Theoretical FPSs or hypothetical speeds between native and html5 doesn't matter anymore when real life benchmarks are so significantly bad.

In conclusion: Ashley you're so wrong ...

This is simply not enough and can in my opinion, also easily be faked.

I would be nice if either you, — or digitalsoapbox could provide the following to prove your claims:

• Re-created C2 in-house example with export + source files (e.g. in Unity)
• Description of your benchmark test (details on how you did it and on what kind of machine)
• Precise performance comparison (FPS, CPU and Memory Use)

Upload all those files and provide all the necessary information so that everyone is able to reproduce and do performance comparisons by themselves.

Please keep in mind that this has nothing to do with me, desperately trying to defend web technology or Ashley.

I just think that every claim needs, clear and reproducible evidence to go with it (just like when reporting a bug).