Thinking of returning to C2 - some questions

0 favourites
From the Asset Store
A cool way for kids to write and practice English Alphabets
  • Hi everyone,

    Before I start, I must say that Construct 2 is the reason why I'm a game developer today. Without it, I'd never have learnt the principals of game dev that I apply now. With that said, I moved over to Unity for a first-person 3D game that I've spent nearly the last two years on. I'm now thinking about taking on a side-project in the form of a side-scrolling 2D platformer. I looked at the many ways of doing this in Unity, and, being the non-technical developer that I am, thought that Construct 2 is probably a more suitable platform on which to develop.

    Bearing in mind I haven't touched C2 since r208 (June 2015), I've got a few questions that I'm hoping the community can answer for me:

    1) How is support these days? Still going well enough? On that note, is C2 stable?

    2) Is there any (speculated or otherwise) ETA on Construct 3?

    3) Are there are must-have premium addons/behaviours/etc. that I should look at for a side-scrolling platfomer?

    4) How is Steam integration on C2?

    5) How's performance looking for standalone(exe) builds? Are we still at the mercy of Chrome's wonky WebGL support?

    6) Anything else you can think of?

    Really hoping that you fine folks can give me the answers I'm looking for. I know that the forums were a huge part of my progression as a developer when I was most active with C2; I'm hoping that's still the case! Thanks!

  • 1) How is support these days? Still going well enough? On that note, is C2 stable?

    2) Is there any (speculated or otherwise) ETA on Construct 3?

    3) Are there are must-have premium addons/behaviours/etc. that I should look at for a side-scrolling platfomer?

    4) How is Steam integration on C2?

    5) How's performance looking for standalone(exe) builds? Are we still at the mercy of Chrome's wonky WebGL support?

    6) Anything else you can think of?

    Welcome back. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    1 - It's great as usual. Scirra answers the Community's questions on the forum like before. The only thing is that C2 don't get new features and has a slower release cycle due to the development of C3.

    2 - No, but we can expect some news in 2017.

    3 and 4 - The Experimental Greenworks Plugin is quite unreliable as far as I can tell, but there's MadSpy's premium Steam plugin that works great from what I hear:

    https://www.scirra.com/store/construct2 ... basic-2546

    https://www.scirra.com/store/construct2 ... am4c2-2545

    5 - Performance is not an issue on desktop platforms if you develop your game with optimizations in mind (just like you would in every engine). Keep this thread saved in your bookmarks if you want to target desktop: updated-22-12-2016-the-big-nw-js-roundup-tips-amp-tricks_t184449

    6 - C2 was awesome when you left for your 3D project and C2 is still awesome. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> Happy developing!

  • The basic problem with 5. is still the same, I'm afraid. Chromium still has its blacklist, and since the same people are running the same crappy hardware/driver combinations as back then you still get a lot of negative review flak from those and can't do anything about it.

  • yeah, the main problems for me seem to be 4 and 5, but mostly 5. There's always something amiss regarding the nw.js / chrome stuff, where you're expected to wait for an update to fix it, which could take months. and there's always a chance these updates can introduce new problems.

  • in the form of a side-scrolling 2D platformer

    2D platformers seems to be the weakest point of C2, especially if making a game where the enemies are also using platforming behaviors and if there are many (eg: 5+) enemies alive at a time/on screen. Eats up the JavaScript performance and leads to missing collisions on average or lesser machines (which feels like a large portion of audiences who purchase 2D games on the desktop/Steam).

    Also, screen capture software still tends to wreak total havoc in the games, causing further missed collisions and engine issues you won't easily avoid, so social spread of the game might be negatively impacted.

    But as a side project? I agree with glerikud that it should work alright on desktop aside from the above (Windows specifically, never had much luck with Mac/Linux for our game).

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • > in the form of a side-scrolling 2D platformer

    >

    2D platformers seems to be the weakest point of C2, especially if making a game where the enemies are also using platforming behaviors and if there are many (eg: 5+) enemies alive at a time/on screen. Eats up the JavaScript performance and leads to missing collisions on average or lesser machines (which feels like a large portion of audiences who purchase 2D games on the desktop/Steam).

    Also, screen capture software still tends to wreak total havoc in the games, causing further missed collisions and engine issues you won't easily avoid, so social spread of the game might be negatively impacted.

    But as a side project? I agree with glerikud that it should work alright on desktop aside from the above (Windows specifically, never had much luck with Mac/Linux for our game).

    I'll add to this and say high resolution platformers are definitely an issue in C2 and I haven't seen any real movement to look into why HD performance isn't all that great. Based on my experience, the issues come down to slowness due to C2's rendering capabilities more than the speed of any event/action execution (as in, other engines using WebGL don't have the same rendering performance issues). Pixel art platformers that run at lower resolutions perform much better. Maybe (hopefully?) these rendering improvements will come in C3. At the very least, fixing shaders so they run based on the layer/layout instead of screen coordinates and adding in addition shader feature support is long overdue. See: https://www.scirra.com/forum/webgl-effects-change-while-scrolling_t115751.

    Construct's event system is super solid and allows some pretty advanced programming-type stuff. In that sense, Construct being based on javascript/html5 tech has worked out well. But it's graphical capabilities are kind of sub-par. And of course there's also the issue of platform support, and regardless of how much someone may enjoy using C2's event system, lacking support for the platforms a game may do well on is a real concern.

  • Thanks for the honest feedback, everyone! I had completely forgotten about the platformer-based enemy performance limitations. Sure, there are ways around that, but since I'd be going into C2 as a way around doing the more finicky stuff in Unity, that issue and the others mentioned seem to cancel out the relative hassle of using Unity.

    I think I'm going to stick with Unity, and just figure out the stuff I need to, and/or grab some assets to make life easier. It's a pity, I was looking forward to using Construct again. I absolutely adore the event system, it makes total sense to me, but it doesn't make sense to use a framework that could hold back any success this game might have.

  • GeometriX About the desktop export, you can try Armaldio's Electron Export that is waay better than NW.js performancewise:

    https://github.com/C2Electron/template

  • I'll add to this and say high resolution platformers are definitely an issue in C2 and I haven't seen any real movement to look into why HD performance isn't all that great.

    This is a classic case of blaming GPU performance on Construct 2. If a game runs OK in SD, but is slow in HD, that's 100% down to the performance of the GPU hardware. A native engine would perform identically, because it's the same hardware. I have looked in to this in the past, and it usually comes down to crappy integrated Intel GPUs. There isn't much any game developer anywhere can do about that...

    I'm not aware of any performance issues relating to platform movements - collision cells should ensure that's fast. I'd be happy to review a .capx if someone made something demonstrating a performance problem.

    According to webglstats.com 95% of users have WebGL support now. Problems for the 5% may be tricky, but firstly it's a pretty small segment, and secondly there's still not much that can be done about it - Chrome does a lot to work around driver bugs, and if it can't run WebGL, it's likely that the drivers have severe stability issues. So those users are likely to be a problem anyhow.

    I've not seen any actual performance numbers comparing Electron and NW.js. They are both based on the same Chromium engine, so it would be a surprise if they performed differently. I'd have thought they are running identical code!

  • I always have issues running higher-resolution webgl(they run too slow and aren't playable), but I'm assuming it is due to my graphics card:

    Unmasked Renderer: ANGLE (NVIDIA GeForce 9600M GS Direct3D9Ex vs_3_0 ps_3_0)

    I also have experienced slow-downs due to events related to enemy ai, but I assume it is probably something I am doing wrong. It could be that my specs just aren't fast enough, considering my laptop is from 2008.

    I look forward to the day that I get a new one!

  • GeometriX Yeah, definitely stick to it if you want the game to grow (consoles, mobile ....someday Hololens? <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> ). We love the event system too but have learned to love C# a lot more based on what comes out the other side.

    This is a classic case of blaming GPU performance on Construct 2. If a game runs OK in SD, but is slow in HD, that's 100% down to the performance of the GPU hardware. A native engine would perform identically, because it's the same hardware. I have looked in to this in the past, and it usually comes down to crappy integrated Intel GPUs. There isn't much any game developer anywhere can do about that...

    In native-based engines you have much more control over resolution, so we can render the effects and things on a smaller screen space, then use one clean up-scale render-to-texture to make that "HD" using a simple one-pass shader. It's used in emulators and many other popular games to make things look nice on much more hardware than WebGL supports.

    I'm not aware of any performance issues relating to platform movements - collision cells should ensure that's fast. I'd be happy to review a .capx if someone made something demonstrating a performance problem.

    The problem here is that it's really more than just Construct 2 being so frame-dependent (despite use of dT like crazy), JavaScript is really terrible and things fall through the cracks on anything less than gamer-hardware (which becomes worse as you enter the Intel CPU market which just happens to be the biggest customers of 2D games).

    I really wish there was more free time/staff at Scirra to actually make a few full-sized games to prove the people who *are* making full-sized games wrong if everything is an event-only issue.

    According to webglstats.com 95% of users have WebGL support now. Problems for the 5% may be tricky, but firstly it's a pretty small segment, and secondly there's still not much that can be done about it - Chrome does a lot to work around driver bugs, and if it can't run WebGL, it's likely that the drivers have severe stability issues. So those users are likely to be a problem anyhow.

    Support doesn't mean it's fully working. A laptop from 2006 might have a version of Chrome that "supports" WebGL, but it'll run DirectX 9 faster than it every time.

    I love Construct, ever since CC's early buggy alphas/betas and even now I still love it, but I can't afford the negative reviews and hate caused by it when someone with low-end hardware pays their hard-earned cash to have a broken game that I paid my hard-earned cash (and time) to have an engine that's perpetually broken (due to JavaScript + Chromium + NodeWebkit issues + GPU blacklisting and WebGL issues) to make it with.

    Unity has the funds and staff to do extreme optimization on both native and WebGL, and here's their results:

    https://blogs.unity3d.com/2014/10/07/be ... -in-webgl/

    Native is nearly double Chrome overall, that's a big difference.

  • Just to add, I'm working on a puzzle/platformer game for almost two years now and I've never had any problem. However, I don't use the platform behavior, but a physic engine (Chipmunk physic). The result should be heavier than any work using platform behavior, but nope, it's smooth as hell. My computer is pretty recent, tho.

  • > I'll add to this and say high resolution platformers are definitely an issue in C2 and I haven't seen any real movement to look into why HD performance isn't all that great.

    >

    This is a classic case of blaming GPU performance on Construct 2. If a game runs OK in SD, but is slow in HD, that's 100% down to the performance of the GPU hardware. A native engine would perform identically, because it's the same hardware. I have looked in to this in the past, and it usually comes down to crappy integrated Intel GPUs. There isn't much any game developer anywhere can do about that...

    I didn't say Intel GPUs - I've had performance issues on a number of mid and high-range nVidia GPUs when running C2 games at 1080p or higher. While the "Intel GPUs are crappy" theory may have worked in the past - when they were very, very crappy indeed - more modern Intel GPUs tend to perform much better (including those in their new Skull Canyon NUCs), so I'm not sure that holds water any more. Even then, other games, both 2D and 3D, made in other engines, perform significantly better on Intel embedded GPUs than games made in C2. Whether that's due to usage of WebGL or not is debatable (I say probably not), but saying other games don't perform any better on the same hardware - call them "native" if you like, but that's somewhat irrelevant to overall rendering performance not affected by the overall CPU usage of the codebase - is provably untrue with absolutely no effort required to do so past picking out another 2D game made in something other than C2 on Steam and launching it.

    There's probably an argument to be made about whether they're "true" 2D engines or 3D engines that allow 2D games, but at a certain point that just becomes a distraction, and for developers & end users, performance is performance. The technicalities only matter to those to shrugging off such concerns. Frankly, the suggestion that it must all be the GPU's fault is as ludicrous as the idea that rendering performance shouldn't, doesn't need to, or can't be improved.

    >

    > I'm not aware of any performance issues relating to platform movements - collision cells should ensure that's fast. I'd be happy to review a .capx if someone made something demonstrating a performance problem.

    >

    Low res platformers are easier to get a steady, higher frame rate in than high res platformers. Fill rate isn't awesome in most C2 games if there's a lot going on, on multiple (say, 7 to 10) layers. Add a few shaders - even if just the included shaders, so that issues can't be blamed once again on 3rd parties - and performance is shot, exponentially decreasing as resolution increases. While this is an expected consequence of higher resolutions, the degree to which it happens in C2, on mid and high-end GPUs, cannot be overstated.

    Based on comparisons to other game engines, performance is much lower in C2. This cannot be blamed solely on the GPU, and based on the performance of other software which uses WebGL, it would be hard to blame WebGL for the performance issues either.

    As I said earlier in this thread, C2's event system is pretty nifty, and I think overall performance of it v more traditional programming is good with room to get better. On the rendering performance front, Construct is behind the curve. That's just the way it is. Whether that's to be blamed on WebGL, C2's implementation of it, Chromium, NW.js or anything else I'll leave to others, since placement of blame doesn't change the end experience - the part that matters most when making a product to sell.

    Fingers crossed there are continued improvements to Construct, in 2 or 3. But some of this passing the buck is a pretty dismissive response to issues repeated time and time again. Sometimes the users of a product DO know what they're talking about when it comes to more technical concerns, which may be something to keep in mind.

  • digitalsoapbox

    Dude, your game is clearly awesome and is a true showcase for Construct 2, so it is great to hear your views as one of the few are producing serious content.

    Looks like you are getting the bad reviews on steam because its a multiplayer and people are having issues with server connection or empty lobbies. Literally people cant play your game.

    I don't think steam is the right place for your game. there is just too much going on there.

    Personally with something like your game I would do free to play with adds and shove it all over the net through browsers.

    also I would wrap into an app (with cocoon for accelerated performance) and put it on NVidia Shield TV , those things are really powerful, you are dealing with consistent hardware , they come with 2 joypads mapped like xbox and there is a lot sold with people sat in front of their tvs desperate for content.

    not trying to be an ass , just giving my 2 cents....., just hate seeing good games not selling.......

    Anyway your game is inspiring me to continue with my lowly endeavours

    cheers..

  • Not to go off ops topic too much

    It's been awhile since there was a C2 game jam.

    Maybe a platformer jam would help figure out any issues.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)