HTML5 is NOT right tool to make mobile games

— Yes, you make reasonable facts, gameplay is more important than graphics but without a lot of graphics as content doesn't offer higher replay value, you're talking about simple games that no one would like to replay... until it's totally innovative (No, it's not like flappy bird.)

No, I'm NOT talking about simple games that no one would like to replay... what makes you assume such a thing?

Having 1,000 sprites on the screen as a limit to developing a game goes a bloody long way. Think of a good RPG, how many objects are on screen at any one time? 300 is more than enough. RPGs and RTS are generally regarded as the most complex genres.

Have a look at these examples,

https://play.google.com/store/apps/deta ... ikeyshorts

https://play.google.com/store/apps/deta ... ox.android

Is there a reason why you think Construct 2 won't be able to make such a game? There's so many hit games I look on the Google Play store and think immediate "gee, that could be made with C2 for sure!".

Edit: Here's my current project, a sandbox space RTS! Of all things to make with "simple" C2, making a sandbox RTS I wouldn't consider it simple or lacking in replay-ability.

Alpha footage of game mechanics, lots of particles used, independent turrets, faction AI and pathfind, game runs very well on older devices, tegra 3, samsung s3 etc.

i'm still making games for mobile with C2, most newer device should have no problem handle it(iphone4s onwards), even if the performance is fine, i notice games made with C2 drains more battery power than others, probably it requires extra cpu power to run? felt like running some heavy load 3d game when playing my simple C2 game on mobile :/

anyways, i'm not making any huge game at the moment, so there are probably more shortage in C2 i haven't come across yet.

hollowthreat Yes it strains the CPU more especially, since the code is less efficient, it takes more compute power to get it to run at 60 fps. Thus it drains battery faster.

My C2 game runs great on Android, and it's quite an intensive 2D physics game with hires textures and 1080p graphics.

I'm getting 56 to 60 fps on a Google Nexus 7" (2013) 2nd Gen... It's very smooth like silky butter!

I added the CocoonJS object to my project, and exported as CocoonJS, then Ludei compiled the .APK file, i installed the file on my android tablet and i was surprised just how smooth it was.

So much for all that ranting i've been hearing on these forums about performance not being good enough, maybe stop testing on a 5-year old phone and buy a newer one, my tablet was $288 at Officeworks brand new.

In my experience, there are some things that just don't work consistently on mobiles in HTML5 - with or without the use of cocoonjs, crosswalk, chrome or whatever. This is some of my experience using C2 for mobile (which was what I bought it for, discussion about viability of 3rd party wrappers aside):

1. Physics. Collisions cause browser hesitations even in my quad core super mobile (I have an LG G, a Samsung S2, iPhone 4 and Toshiba Excite for testing). These hesitations change the characteristics of the physics objects (how high they bounce etc) enough that a player A could do or see things that a player B on a different phone might not. Games using physics on mobile are not viable unless you don't care that different players might see or do different things. I do if it changes the game play...

2. Platform. Same as 1 but to a lesser extent. Any browser slowdowns cause changes in how the behavior appears so that the player's experience ultimately depends on something I have no control over - what type of phone they bought.

C2 and HTML5 do other things well, but these are the weakest ares I think. Even my flappy bird clone runs differently on each of my test devices and that only uses custom movement! If I test anything made using Unity then these problems of handset performance and compatibility don't seem apparent...

Edit:

EddyDingDongs, not everyone owns a top of the range android / iOS device like yours and I can't ask my potential customers to go and buy one before downloading a game. If everyone did have one already then there would be no need for this thread...

[quote:1c1bfeiq]Alpha footage of game mechanics, lots of particles used, independent turrets, faction AI and pathfind, game runs very well on older devices, tegra 3, samsung s3 etc.

Holy crap that's awesome! I've been working on a game kind of like that called Captain Zero for a long time but it's on the back burner... Time to put it on the front burner I guess!

So much for all that ranting i've been hearing on these forums about performance not being good enough, maybe stop testing on a 5-year old phone and buy a newer one, my tablet was $288 at Officeworks brand new.

Don't you think this is a little obnoxious?

Just why should people throw out perfectly working phones every year or so, just to make you happy?

Lots of mobile games are bottlenecked on GPU performance, so faster logic (e.g. using C++ instead of Javascript) would not improve the framerate. With the WebGL renderer, the GPU is used pretty much identically to how a native engine would use it.

Ashley

did you test Airscape demo on your computer? On mine, 1.5 years old dual core AMD (+ AMD GPU, actual drivers) it's not 100% smooth

also what is actual Scirra suggestion for iOS?

• It’s slower than native code by about 70%
• It’s slower than x86 C/C++ by about 50%
• Every competent mobile developer would waste a great time thinking about the memory performance of the target device.
• Javascript is too slow for mobile app use in 2013. If we get new devices were built in 2014, it may be better but Javascript looks "faster as native" in 2020.

• Of course native code will be always faster than other codes, but do you have the time and resources to develop and optimize you app for different operating systems ? Also there will always be some compatibility issues (since is not a standard like HTML5 wants to be).
• With devices these days having over 1GB RAM , I don't think it will be a big problem.
• Even LowEnd smartphones (DualCore Cortex-A9, 512MB RAM) can run most of the HTML5 games constant at over 45 FPS. The user doesn't care how the game was made if it works good.

The only real issue that I see is that HTML5 eat more battery (and resources) then native code.

Ashley:

Interesting to see how the discourse changed over the years.

Now people are complaining about "unplayable framerates" with 1000 sprites, webGL effects and physics enabled on two year old phones.

Used to be that the mobile situation was:

• In 2011: try to keep under 50 objects
• Early 2012 (also here):"no mobiles support WebGL yet"
• in mid 2012: avoid using physics

and those limits counted even for state-of-the art phones

I for one am glad no time was wasted making native exporters.

Edit: changed "don't use webGL" to "no mobiles support WebGL yet"

I never said "don't use WebGL", my advice has always been to leave it enabled!

Hopefully asm.js physics runs well on modern mobiles too.

Sorry guys im very very new on this.

I bought personal edition of construct because i wanted to create a game for mobile phones and now im reading this?

I read the complete post and i understand that html5 for mobiles is not the best if the game have tons of processing, but if the game is simple it works fine even for a 3 year old phone right?

I was afraid when i read the tittle, if like i said before is right could someone edit the first post to clarify this important thing so the new people reading don't get afraid?

Thanks and regards,

good read about javascript performance and its probable near future

katzin Yes, I've made simple games that play nicely on my old phone... I think OP is taking about bigger games, such as RTSs and RPGs ...

The market for mobile games, in my opinion, if very different from the PC or console one. Games on mobile tend to be a bit more simple. This is not an absolute rule, but you know...

I'd say, with your personal license you're good to go. I'm not expert, but this is what I can tell from my experience.

One thing, though, there seems to be a problem when game starts. It takes it 2-3 seconds to get to full speed. But I think this might be an old Crosswalk issue, not related to CS.