The sad truth of Construct 2

Wow, some really insightful posts.

Thubie, when I bought C2 the '*' wasn't part of the information on the main page. There was a very strong push that HTMl5 games will run at native performance. This isn't true and i didn't expect to really run near native performance. Just good enough. I would like to see a poll on this also.

purplelava, wow. I totally understand where you coming from, [snip due to post being removed] I do agree with this sentiment however

"C2 effectivly makes 'casual' games, yet is only effective making desktop games. Where as desktop games offer robust games which mobile is a harder"

Personally I don't believe the term casual and hardcore.

I will also chime in. I'm still good on a kickstarter program to support Scirra or another to create exporter or an effective native running of games.

kondisius, I still agree.

Ok going on to my own thing. i decided to take up Ashley's un worded challenge that we need to be better game developers. ie it's logic, sprites, poor performance options. So i wrote this while working on meeting Ash's challenge and came up with some serious surprises.

------------------------------

After repeatedly hearing from Ashley that our logic and games were at fault. I decided to take up the challenge that a minimal no event logic game will have poor performance on my Tegra 2 android device.

I started by searching for an android demo program to determine capable FPS on my tablet. I found the app FPS2D. The simple result was that the FPS was 60fps with a deviant of up to 8fps. FPS2D had an empty black background with what looked to be apx 8x8 ball. This would be the standards of my C2 test for UIWebView.

play.google.com/store/apps/details

So my demo was going to be a black background with an 8x8 bouncing green ball. The ball has the bullet behaviour and will be colliding with solid's that are just on the outside of the layout. This technically adds a little more overhead for collision. Here are my tests and I want to point out one of the results was outstanding. Also test results resizing was not clean due to browser. So some tests were not "fitting" screen right". I also err on the lower side of the deviant results(so if fps was 12-15, 12 would be the reported value)

*due to the header bar and resolution often the the view-port would be rendered off screen. This could be the the cause of many slowdowns.

*Pixel rounding on

*clear background with a single layer, black colour

*as a note interger scale would product a very small view of the game which is probably why speeds were goo(follow up commentary on this at the end)

*test capx dl.dropbox.com/u/14087254/ballbouncetest.capx this was often modified to suit the test resolutions. so it's not a straight go to use for multi res. But I'm sharing to show the simplicity of it. So that there is no question on our design logic.

*since most developers want to pack there game. using browsers is not ideal solution. however they were tested to have an idea how there canvas2d runs.

*2 Apple devices were added.

Here we begin--------------------------------

*fps format(no scale, crop, scale, letterbox, letterbox integer)

FireFox(webgl)

FF with WebGL by far had the worst results right across the board. Don't waste your time right now.

480p (12,5,5,5,12)

720p (5,5,5,5,15)

1080p (2,5,5,5,8)

FireFox(canvas 2d)

480p (65,22,20,22,45)

integer: There are dips as low as 30 fps, but this steadies out

720p (28,24,25,27,64) these were surprising results

1080p (12,25-50,23,27,64)

crop: was all over the place and never steady enough to report.

integer: starts slow but quickly reaches 60+

Chromebeta(webgl)

Better than FF WebGl, but overall not a better browser to use.

480p (33,27,27,30,36)

720p (29,28,28,29,38)

1080p (25,28,28,28,32)

Chrome(canvas2d)

Chrome overall had steady results

480p (33,25,25,23,35)

720p (25,25?,25,25,40)

1080p (15,25,25,25,30)

Stock Browser-------

I feel these are the key browsers as any embedded app will be

based on these

Android Stock jellybean(canvas2d)

480p (55,35,40,46,59) acceptable across the board. with rare dips

720p (35,35?,40,43,60)

integer: That came from no where

1080p (24,41,41,44,57)

integer: rendering is not smooth. it was flickering and steady

iPad2 Safari(IOS 6x, canvas2d)

as expected this performed solid right across the board. However this is running A5 Chip which is better than the Tegra2 and more comparable to Tegra 3(which is the current development chip). this offers a lot of good promise for Tegra 3 devices which I don't have at this time.

480p (60,60,60,60,60)

720p (60,60,60,60,60)

1080p (54,60,60,60,60) This is the first time it's dropping below a solid 60

iPod Touch 4g (IOS 5.1, Canvas2d)

This by far has the most strangest results. I also started testing at 720p when I thought about adding it to the test list for comparisons. Due to the strange results this by far has the most commentary.

720p (45,50,84,84,90) the results are steady and usable

1080p (39,85,80,80,105)

off: the ball was doing a lot of jumping. very far from smooth

crop: can't see much of the viewport at all, but the ball was a lot smoother

scale: 85fps with but with common dips to 75

letterbox integer: WTF????????? this actually dips as low as 95fps. however the animation was never as smooth as the ipad2. I think the iPod Touch was just blazing out the canvas renders, but logic took longer creating this less smooth effect.

Observation

After spending hours doing these tests I feel this explains a lot of the communication problems between Ashley and the vocal native part community. UIWebView does seem capable, but only under certain conditions. These conditions however strict and makes it a lot more work.

Scaling options

OFF: The results of this are across the board. I suspect the dips in performance has more to do with rendering the canvas offscreen. A canvas size that does not exceed the the window will probably have good performance.

CROP: not worth using

SCALE: Is not worth using. yet it's the primary suggested path to mobile and easiest to implement cross platform. But this get's the worst set of performance :(

Letterbox: Not worth using

Letterbox integer: This is by far the best average and reliable performance across all resolutions.

Not always the best, but never the worst. The problem is that none of my tests ever had this scale fit the screen. often it produced significantly smaller screen sizes. ideally it would be best to create games based on this scale and find a way to get games to fit.(addendum below)

WebGL

WebGL universally had poor performance. This is where Ashley is 100% correct. WebGL would not solve the speed issues for simple rendering. Advance rendering may end up with different results.

Letterbox Integer testing follow up

I spent some extra time just playing with this scale option on my tegra 2, iPod T4g, iPad2 at 720p. resolution had impact, but not as much as expected.

Android: 80 bouncing balls produces 25-35 fps

iPad2: 80 bouncing balls produces 50+ fps

iPod: 80 bouncing balls produces 50+ fps

Android+CocoonJS: 80 bouncing balls produces 50fps

This produced overall very promising results and for me acceptable for my more minimal games. 80 bouncing balls is far jump from just 1 ball from all the tests previously done. Also the results are fantastic in comparison.

However with all that goodness there seems to be a big BUT. After the promising results I decided to test out my Ouya game to the new options.

Draoust with letterbox integer

I required to do some tinkering with what I had in the game. I was able to manage to go from 20fps to 32fps in the stock browser. Which is about a 30% improvement in performance.

It looks like the end performance results to all of these testing is that there is some kind of critical problem with scaling with Android UIWebView. Performance is best on a 1:1 scaling ratio. Also make sure that the canvas does not extend past the available screen size.

Draoust with CocoonJS

Main menu runs at a solid 60fps. However there isn't much happening

Gameplay runs at a steady 50 fps with common dips as low as 45.

These results are super acceptable for my Ouya game. it's just to bad CocoonJS crashes on the Ouya. But hey come March maybe Ludie will have one to test and fix to run :)

About 80 bouncing balls

While 80 bouncing balls is a fine for common performance of I think simpler games with out lot's of effects. It by no means will compare to a native app. However it's fine for me.

When designing your game. Get your best FPS with just a simple bouncing ball. Then work up form there. Test constantly on your mobile device. If there is a sudden drop then check the recent changes you made.

I still support native exporter or an official Scirra C2 Wrapper that's community driven extensions, but for now I think I can settle where C2 is. I look forward to getting my Ouya and testing Draoust on the Tegra 3 that has similar to the A5. And maybe Ashley can check on the scaling and see if there is anything that could be done to get "SCALE" to work better. On that scaling note. I'm not sure how C2 handles scaling, but I recall reading a post last month on straktrace. The indivudual found that using CSS3 transforms on a canvas2d produced far better performance results when scaling. This might be some angle to look at :)

Grats to Apple for creating an incredible performance rendering even on the A4 chip :)

WOW, thanks for all the testing, that hopefully will show some of the nay sayers where the limitations actually are. Construct is not the issue here, it is the browser and platforms being so disimilar and even those that support similar features not implementing them the same way.... Now I just need to see IE10 on Windows 8 and Windows Phone 8 so I can see how my targeted platforms perform...

This tests are interesting <img src="smileys/smiley1.gif" border="0" align="middle" />

theubie

I'm personally not complaining about my purchase, I'm an early adopter and I would buy it again. My point is that it's simply a shame having such a powerful tool tied to a (and you are right this is purely my personal opinion) failed technology and I'm not the only one to think this way.

I think it's apparent that creating a native exporter for C2,is not just running a few lines of code off over the weekend,and even if it was then you have the extra burden of support and updates for said exporter.

This would take development away from the core program,and there would be a list of topics venting anger at that...

If you respect what Ashley/Scirra have done with C2,maybe respect their word and put some faith in the decisions they have made...

I think concentrating on the IDE is definately the best way for Scirra to go...with hardware manufacturers climbing over themselves to get the fastest,shiniest products to the market,it's just a matter of time to see the performance of HTML 5 increase accross all platforms.

It's a bit like running for a bus,that is coming towards you...

You can respect the team / works of the team, and not be agree with some decisions.

I am an early adopter, that's because I have always believed in Construct 2 and the Scirra's Team. And that's always the same.

But we can have different opinions about some decisions that has been made.

The fact is may be we are wrong, or...may be not. Future will tell us the story :)

At the end of the day C2 is the easiest way to develop your game. Native exporters would be nice but that would take so much work especially for the mac devices.

Remember that most engines get venture capital in the millions and do a worse job than Scirra.

Back when we were just getting started - the first "public preview" was in February 2011, almost exactly two years ago - we had threads like this, but arguing the same point for desktop games! Everyone was saying we should develop a Flash exporter, HTML5 was a fad, it performed terribly, it didn't even run anywhere (this was before IE9, IE8 was the latest IE and had no HTML5 support at all!). We also received a lot of pressure to write a DirectX or OpenGL native desktop exporter, similar to what we had for Classic. And they had a point: no browsers had hardware-accelerated canvases, so you were lucky to get 30 FPS even on a powerful desktop computer that could run the top 3D games. None of the games ran in IE at all, because IE9 wasn't even out yet at that time. Mobile was hardly even mentioned. It looked like a joke.

IE9 launched with a hardware accelerated canvas. Not to be out-done by IE, Chrome and Firefox followed up with hardware-accelerated canvases, and then exceeded IE with their WebGL support. The platform matured, bugs were fixed, performance was tuned, and now even the strongest HTML5 critics seem to admit it runs great on desktop, it's just mobile is the problem. So in two years it went from virtually unsupported to working fantastically on all desktop systems. And boy am I glad we didn't write separate exporters! We would be a long way behind where we are today if we had, because we would be having to maintain multiple codebases. Writing two codebases isn't twice as hard, it's more like squared (to the power two) as hard, because of all the extra effort to make sure both codebases are functionally identical in all circumstances, and that extra work never goes away if you keep adding features like we do.

The problem I have in threads like these is trying to persuade people where things are going. Just like the threads about desktop support two years ago, you have a point, there are lots of problems: crappy performance in PhoneGap, a Firefox bug that slows down WebGL on Android, the general browser mess on Android, whether iOS will support WebGL, and so on. What I am trying to say is we are repeating the desktop situation. These are real problems, but they will be solved with time. I would go so far as to say in two years HTML5 will be working great on mobile. In the mean time there are workarounds like directCanvas and cocoonJS, which are not themselves perfect either, but a lot better in many ways.

I know two years is a long time, and many of you have projects you need to be done before then. But I don't think it's an exaggeration to say it could take 12 months to get native exporters that are better than what directCanvas and CocoonJS already provide. Browsers do a *lot* for you: things like XML parsing and XPath support on mobile can be tricky, and that's potentially a whole project for one feature. Web Audio API equivalent features is another. If we just say we don't support things like that, then we're not going to do much better than solutions like CocoonJS already do. If we do support things like that, it will take a great deal of time to get every last tiny feature in Construct 2 working equally well as in a browser, because the project amounts to partially implementing a real browser (and Chromium is ~6,600,000 lines of code and over a thousand contributors). If your game is renderer bottlenecked, it probably won't be faster with a native engine anyway. And then we have the ongoing problem of multiple codebases, which will slow down the rate of updates considerably. (Perhaps this is why many of our competitors release updates a lot more infrequently than us.) In the same amount of time, HTML5 on mobile would be half way to great, possibly even already working great by then. Which means our small startup just wasted a whole year's worth of development time. Comparing that to the amount of progress we could make with our HTML5 support in that time, I think it's fair to say it's just not worth it. So yes, we're stuck with some difficulties in the mean time, but I am totally sure given time everything will be much better, and for right now today, there are workarounds like directCanvas and CocoonJS, as well as things like the Safari for iOS browser working very nicely, especially with iOS 6+.

"A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be." This is what we do, and I feel it has proven to work with the desktop support. There's an awkward wait while we get to where the puck is going to be, but I don't think there's anything we can practically do to get there quicker. But we will get there!

Well said Ashley !

I hope everyone gets to read your post. Truly something there.

You are a developer that makes me proud to say, I utilize and support that software.

Ashley - Keep it up.

Ashley : My thinking about Html 5 is great. I prefer Html 5 than flash, performances are better and we can see that with C2 of course. How you said the problem isn't really the desktop or html 5, because we know that C2 is made arround this technology, this more mobiles, how you said in your post.

You said :

o yes, we're stuck with some difficulties in the mean time, but I am totally sure given time everything will be much better, and for right now today, there are workarounds like directCanvas and CocoonJS, as well as things like the Safari for iOS browser working very nicely, especially with iOS 6+.

That means that all is not completly stucked :) and with time and patience, we could have better performances for mobiles with Cocoon or AppMobi etc...just take time to technology to be completly ready may be :)

I prefer an answer like this, that is for me, more understandable.

And I have always supported C2 ^^

Ashley

A superb explanation of Scirra's smart decisions! What about making it a blog post? It really deserves more visibility than it gets in this thread.

Let more people know how much they're benefitting from the greatest hockey players in the business ;)

Ashley

I had a long conversation last night with a friend of mine who has worked as a Designer in the game industry for a long time (Games like: RIFT, Stargate Worlds, World of Warcraft). We were discussing the changes that the Game industry is going through and how that is affecting the big game companies and the little ones alike.

Basically the shape of games is polarizing to REALLY BIG BLOCKBUSTERS and small casual games, without a whole lot of good games in the middle.

Some of the things that he said that really rang true for me are very pertinent to this thread:

1) Flash is DEAD. It is going away. Even Adobe has an exit strategy. The big game houses are writing their own now and migrating away form Flash. It will take a few years, but there will be few attendees at the funeral of Flash from the Game industry.

2) Game companies are moving towards smaller games that have continued revenues instead of the big purchase up front. Games like Farmville (Facebook) and Pandemic (Android and iOS). The important thing about these games is that they have in-game purchases. You can play along and get in game points to spend, but for 99 cents we can give you that plant, genetic upgrade, new race car, etc... RIGHT NOW! This is where we are seeing little games that start out as FREE end up making 6 million a month due to add on purchases. This too, is the niche I am entering with my game making.

3) The game consumer is getting very smart. They want to be entertained and challenged and have it all presented in a pretty package (great art, music, effects). Fortunately, they are willing to pay - a little bit anyway - for games that meet their expectations. What they are being smart about is when a company disappoints them too many times they will no longer buy from that game company. WOW! Consumers have a memory?!?!? Some of the inscrutable "frustrating" game makers have even gone to the extent of changing their company names every year or so, just so they can slap on some new graphics over the same LAME game and sell to a whole new batch of unsuspecting rubes.

All-in-all I am very happy with your choices for Construct 2. I think you are focusing on the right things and getting a lot done. I only wish you had more help with the coding.

-Jim

Great post ASHLEY.

I think this thread has been fabulous a lot has come out of it :) As an example I'm still a naysayer, but I drove me to do the performance testing with different settings. Result was that i was able to increase performance by a lot. Also I went about going through different websites and found some interesting facts.

Canvas rending SUCKS. Even Cocos-x on android isn't all that good. While we are annoyed with 20fps issues they are having troubles with 30fps issues with the same sprite circumstances. There are gaming blogs that report game design considerations once you hit more than 30 sprites. With that part of the problems lay in the Tegra 1 and 2 where any transparent rendering has flaws which also drops performance.

What however changes is oddly enough OpenGL 3d based rendering. Strangly enough a full on 3d engine doing 2d can render 250 sprites animated at 30fps on a Tegra 2. I'm not sure why the difference or what's going on. but it is insightful. None of this would come to light if discussions aren't there.

Now to something important which I don't think the HTML5 choice will ever get over. Which is the other problem. Let's remove the entire performance speed issue. let's assume we are in happy land :) heres the problem

hydra.agoragames.com

devs.ouya.tv/developers/odk

anything that is native code access

even the day HTML5 becomes this great at gaming. We can't access Steam Achievements. So there we go. Completly reliant on CoocoonJS which is closed platform at this time. Though apparently CoocoonJS has an extension manager in the works. Till that day :(

I have no idea how to monetize my Ouya game for a sale. I can't access the Ouya store. If I use Clay.io and am allowed to sell the game. this will require users to enter in the pay system by another method and well people don't like that :(.

I'm still a naysayer, but I'm willing to put performance to rest for now. I feel I can pull enough performance out what there is right now for my games. Though that doesn't change other factors :(

Anyways I thank everyone for speaking there minds and having an opportunity to speak my mind. Also Ashley participating and giving us a lot of company making decisions :)

as a final note on that however. I still think Scirra should do a kickstarter to gain funding for a 1 year staff to make the Exporter Development Kit. Once that's done. just let the community do the rest and Scirra can stay hands off towards maintaining. As Ashley pointed out Chrome was a communal developed project from many different code snippets and improvements. The EDK's exporters and plugins could operate under the same standards. Scirra can stay hands off past that entry point. But hey. That's it for me.

I hope many of you have learned as much s I have :)