The sad truth of Construct 2

I am not so foolish as to expect my games to run well on ALL platforms. I choose the target platforms and design for them. Making a game and then expecting it to run equally well on all available platforms... well, that's naivety. For one you have to consider the huge gaps in performance, limited features as well as different means of control (touch vs gamepad vs keyboard/mouse).

You need to rein your expectations in a bit. If you hunt two hares at the same time, you'll lose both.

As a consolation prize, HTML5 means that games will eventually run on all HTML5 platforms when it is fully supported.

I've also been having very promising results with the latest CocoonJS version and iPhone 4. I strongly feel that CocoonJS can and will be the solution for C2 mobile performance problems.

Konidias i think you want to much. Mobiles Devices have limitations its will be always like this. Every tool, SDK, Engine whatever has also advantages and disadvantages.

You will need to live with limitation. Ludei is doing a great job with the exporter.

There is a reason why big game companies still use flash or java for bigger online games. AS html/html5 is not ment to be a game-platform, there are borders, sure.

Im actually a bit unhappy about my plans for 1-2 games too, but its not html5 or c2 to blame. I know, that when i want best performance on my android device, i have to code as near on the base as possible, so for me its java than. But as im not such a super-talented programmer i also try to make my ideas with c2 coming true, and well,...this is awesome. So, i think, if you see, what html is originally made for and what c2 makes possible/gets out of it, c2 makes a fantastic job. If others like gamemaker do the export better...i dont know.

C2 IS a game-making tool. Powerful, yes, but every game maker (pun intended) out there has it's limitations. Scirra is doing great job for such a small company, especially with all the latest betas.

My advice to you Konidias - learn to code. It would solve all your problems. C2 is not for everyone - it has it's pros and cons.

I'd just like to support your opinion :) For me HTML5 works also better than Flash. And more - Flash causes my browser or computer to crash sometime, and HTML5 does still not.

Since most HTML5 platforms these days render on the GPU (including Safari for iOS), porting to a native app will probably not get you extra render performance. It will still render the same way on the GPU. (WebGL just helps reduce the CPU burden of rendering.)

Logic performance is all that's improved by native tech. On desktop usually the logic accounts for 20% of the frame time, and the rendering accounts for the rest. On mobile it's tighter because of a more limited CPU budget, but a well-designed game should be able to get by. Native mobile game developers probably have deeper technical knowledge of the platform, and use very clever design and tricks to ensure they can make the most of the limited computational resources available. I think part of the problem with C2 is it makes it so easy to give a mobile device too much to handle.

Think about render performance again. Consider leaving 'clear background' on, then creating two fullscreen tiled backgrounds laid over each other (or a screen-sized sprite for example). You have already reached 100% of the pixel pushing budget of some mobile GPUs (which can only write to every pixel on screen 3 times in 16 ms). A native app developer would know not to do that; set 'clear background' off, use one opaque tiled background to give the background texture (perhaps with an effect or artwork "baked in" to the image), and start building the game off that. Then you're starting with 66% of the GPU pixel pushing budget free, rather than 0%. I know this type of thing happens, because I have been sent .capx projects with users saying "it's horribly slow, C2 sucks" or whatever, and they've done something like overlay 3 full-screen sprites right off the bat, so a simple game seemingly runs slow. You just can't design games for mobile like that, not even with native technology.

I think another big part of it is bad methodology: users create an awesome game using tonnes of effects that runs perfectly on a desktop, and then suddenly find it works slowly on a mobile. What you need to do is use preview-on-LAN right from the start, literally after clicking 'new project', throw in the FPS and object count in a text object, and preview exclusively on mobile while keeping an eye on the FPS. If the FPS takes a dive after a change, backtrack and find a more efficient way to handle it. Your desktop computer could literally be 100x faster than your mobile, no exaggeration - so it's just not sensible to design mobile games any other way. I get the feeling not too many people take that approach!

HTML5 tech is still developing. I would encourage you to try Chrome Beta for Android, with WebGL enabled in chrome://flags. It's by far the best I've seen HTML5 games running on mobile. And I think it's clear Google's intent is to eventually have WebGL on by default and shipped with the stable version of Chrome (that is now pre-installed on new Androids). I think that's the best indication of what the future of HTML5 on mobile is.

Ashley - I agree with everything you said except the part about testing the performance using preview over LAN. Since that uses preview code with checks, it's far slower than the exported code, and really hits the frame rate on mobile. Any time I want to check the performance, I have to export, upload, and then open the link in the browser.

Could there be an option to use exported code for the preview? I know why you wouldn't want users using it all the time, as it would make it harder for you developing c2 if people used it exclusively and missed the error messages, but as a user developing for mobile I rarely get errors but frequently need to check performance.

Finding out what's causing performance problems on mobile (and desktop at times as well) is a tedious process of tweaking, exporting, uploading, reloading and repeating, whereas the process could be done with one click.

Maybe a right click of the preview button or something?

That note of 'rendering the screen only three times per tick' is interesting. I'm not interested in mobile development, but does a similar (albeit larger) limitation exist on desktop hardware? Does image size have a direct effect on rendering performance? I have heard it said that a GPU can draw any quad at the same speed but this statement seems to negate that.

It's called the pixel fill rate, how many pixels per second a gpu can draw. All gpus have pixel fill rate limits, though recent gpus are ridiculously faster. Older gpus will hit those limits more quickly the same way mobile hardware will.

So yes, drawing a big quad takes more work than drawing a small one.

I wish people would give it a rest on the HTML5 & C2 bashing. It's new. Since it's inception it has been picking up steam. Much like all of the technologies that are current. They were once new, and had limitations. You have to be creative to overcome some of these limitations. I for instance have been coming up with clever graphic tricks to emulate effects (which I feel are being to heavily relied on) I use effects during early stages of my prototyping, and swap them out for animations, and graphics. I try my best to not have to use WebGL, or effects that require it.

For mobile I understand the frustration but I feel it's being directed poorly, considering HTML5 is so new especially for mobile. PC browsers just recently started supporting it, and many still don't. Google's push of chrome/WebGL is a hint of things to come.

The market is calling for these types of games... OUYA, Steam, etc... So it's obvious that all of these current limitations will be a thing of the past. Just give it a bit more time.

Just my 2 cents

No one's bashing construct 2 or HTML5.

Construct 2 is the best game making tool out there, with the best workflow, which is not to say it's perfect.

HTML5 is really good now, and can deliver some impressive results, though we aren't there yet in terms of portability. There are many limitations to what can be accomplished, even in a beefy desktop running a modern browser.

Mobile, however, isn't there yet. You can't make anything but simple puzzle games in there - meanwhile, other engines with native exporters perform a lot better. Sure, they aren't as capable and working with them is a convoluted mess, but the end product is often more performant.

I don't know why people are getting all defensive. I love construct 2 and scirra, but we're not there yet in terms of multiplayer and semi-professional mobile development. Blame it all on HTML5 and phone manufacturers (especially apple - I mean, their stuff costs double the price of an android/htc/blackberry/whatever with HIGHER specs and even with all that money they still can't get their act together? I honestly don't know why people buy their stuff).

In regards to mobile HTML5, Blackberry is putting a lot more effort into it than everyone else, and I'd recommend developers stick with them - the environment they're creating for us seems far less toxic than apple or microsoft's alternatives. Android is pretty okay, Google is very competent and mobile chrome is great. Firefox mobile shows promise as well, especially if you want to focus corporate, low-end or edu.

Do notice that Ashley can't do anything about any of this. The strategy of integrating third party exporters worked to some extent (in that we now know which technologies suck and which show some promise), and shows the goodwill Ashley has in supporting us in that area, and how he'll do everything he can to make it better (compare that to other game making tools, which just don't care, and spend years with updates that amount to little more than bug fixes. Konidias will know which one I have in mind specifically). The most recent versions appear to be focusing more on the core product, with new features to help the core engine, and that's a relief for me.

It says a lot that, even when working in large projects, ALL THE ROADBLOCKS I've encountered so far, NO EXCEPTIONS, have been in regards to HTML5. It was NEVER construct2's fault, and on the few times construct didn't do something I wanted it to do, I fired up my development kit and made a plugin/extension to fix it.

I'll end up by agreeing with Konidias, though I'll disagree with the title - this is not "the sad truth of construct 2", but "the sorry state of HTML5 right now, especially in mobile".

That note of 'rendering the screen only three times per tick' is interesting. I'm not interested in mobile development, but does a similar (albeit larger) limitation exist on desktop hardware?

Generally modern desktop GPUs have such a ludicrous fill rate that they can fill a window-sized texture faster than the CPU can issue the command to draw. But mobile devices are a lot weaker, mainly due to being battery powered.

Personally, I love Construct 2 and find it to be an amazing tool, especially given its price point. That being said, I really do not think Scirra should advertise support for mobile platforms until stable frame rates are achievable for the average game. I understand it is, in many ways, the consumers responsibility to research the technologies themselves, but I feel like many purchase construct expecting to make mobile games, as it is advertised on the homepage.

would encourage you to try Chrome Beta for Android, with WebGL enabled in chrome://flags.

The fact is that when you publish a game on the PlayStore for example, there is not Chrome Beta and WebGL, just an apk. At the same as services like CocoonJs have a great technology, we don't have the same performances that a native application has.

For making mobile game, I'm not sure that C2 is the best tool. For Html 5, it is the best for sure !

hat being said, I really do not think Scirra should advertise support for mobile platforms until stable frame rates are achievable for the average game.

Agree with you.

Fimbul hit the nail on the head. I'm not bashing Construct 2 at all. In fact I stated many times in my posts that I think it's a fantastic piece of software... which is why I think it's a shame that it's limited strictly to HTML5 exporting (or wrapping the HTML5)

It just sucks to me that I have to weigh different software in each hand to see the upsides and downsides... I want that perfect piece of game development software to exist... Construct 2 basically gives me nearly everything I want in a dev tool, it just hurts with the exporting. Other game dev software is a pain to work with, but gives me the exporting options I need.

I suppose one day I will get the best of both worlds... but for now I can only dream of that day and rant about it here. :P

It's good to see that some other people agree with me. I see a few people in this thread who just seem to be blindly defending Construct 2 and blaming ME for not being able to design games within some ridiculous limitations.

How about the classic "flashing an enemy or player when they are hurt"? With a simple effect I could just flash the sprite to white... but I can't do that for mobile games since iOS won't support webGL. Which means the only alternative I can think of would be to create separate white versions of each frame of the sprite... which can get ridiculous if the sprite has 4 directions and many animations. We're talking near doubling the amount of sprites needed just to create a flash effect? Totally inefficient. Could I design around it? Yeah. But should I really have to do that? Is there a simpler way to do this? If so please let me know. I'm sure there are some things that can be done with workarounds that I'm just not aware of... But there are other things that you just simply can't do.

I'm not expecting to create Halo for an iPhone 3 or anything, but I would expect more from mobile exporting than Construct 2 can deliver at the moment. Maybe by the end of this year my opinion will change... Maybe it won't. I can't really just cross my fingers and hope that things work out with HTML5.

Apple looks like they will NEVER fully support it, because it's direct competition with their app store. Why buy games through the app store when you can just play them through a browser? Because the games currently just can't compete with native apps in terms of performance and features. I don't see Apple letting that change and losing their 30% cut of sales.

What I see from Ashley is a lot of wishful thinking and predictions. But there is nothing solid to say that HTML5 is really the future. For people who want to release high quality mobile games within the next 6 months, I don't see HTML5 or Construct 2 being good enough. Maybe in 2014? Maybe? I'm sure eventually mobile devices will be so powerful that you'll rarely have to worry about browser limitations at all. But that isn't going to happen tomorrow.

Also it's a bit silly to say "well if you use this specific phone with this specific version of this specific browser, you get really good results!" because you aren't going to convince everyone to use that exact setup. Everyone has their own different phones and their own preference of browser, and you have to work with what you get. I just see it as another headache to deal with for mobile devices that we really shouldn't bother with.

Not only do you have to deal with the huge variety of mobile devices, but with HTML5 you also have to deal with the huge variety of browsers and options available. At least with native apps you know it's going to look and perform the same across multiple devices. I don't have to worry about a user running the "wrong" browser for my game and getting poor performance. They just pop open their native app and it's good to go.