HTML5 is NOT right tool to make mobile games

I for one am VERY happy with my Construct 2 game on Android (.APK) working at 56 to 60-fps at 1920x1200px (low-res scaling OFF).

My tablet is almost 1-year old, came out July 2013. The thing is that in 1-2 years time my current tablet will be the average or below average. So as game developers you need to look to the future, games like Asphalt 8 require reasonably heavy specs to run smoothly, but by being that game that everyone wants to be able to play one day, they stay at the top of the lists for years. Whenever someone upgrades their device the first thing they do is download the games they couldn't play before on their previous device.

Another thing, I grew up playing games on a Commodore Amiga 500 with only 7-Mhz and 512KB RAM.

Would it be appropriate for me to be releasing games for that system today? NO! So as game developers u need to be testing on better than average devices, becos by the time you've finished your game many months later the public has caught up and your device might be below average.

To help you choose which device to buy you need to look at benchmarks like: http://www.androidbenchmark.net/

And you need to take note of all the specs especially GPU chip model name and number, CPU, amount of RAM, etc... Type in any Phone into this website to see it's full specs + thousands of comments:

http://www.gsmarena.com/

Finally, look at Youtube videos of people actually playing hardcore games with the device you want, and also checkout website reviews eg. google search "phone model review"

Good luck! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

[quote:ghwhsnb4]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!

Thanks. Have you got a blog, I'd like to see Captain Zero! <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

As for HTML5 and mobiles, just take care and keep testing on devices as you add new features. Make sure you did not fubar the code somewhere with an endless loop or heck, checks every tic when it doesn't need it.

I have about 400 to 500 objects on my layout, asteroids with rotate behaviour, blinking stars, space dust etc, along with all the objects generated by ship trails and during fights, particles from weapon hits. All up with particles, it would be >1,000 objects. On top of ship pathfind and AI. Runs great on even older not top of line devices.

I say to new C2 users do not be discouraged, it's possible to make big games run well on older devices not to mention newer ones, even big RPGs:

I've read some replies, in this moment, some replies were like "My mobile hardware is better than yours" it's a bad practice because when you release your game on store after trusting the results of performance with your own device. Then, you will hear the users will say good and bad comments, their were comments like "This game is too slow ..." also we can have similiar comments like that and we will have no idea how to update your game, possibly take a long wait. The devices are very different than ours, I wouldn't say them to buy new device, it's an insult. I personally believe the words aren't worth to consider the fact, the acts are worth. I already explained the big games with HTML5 for mobiles is too risky in this time.

Most HTML5 games for desktop is very acceptable. Anyway, I keep reading this thread.

I'm not stepping into the discussion, because I do not have enough knowledge... but...

katzin do not worry about the issue with mobile, you should be fine ... We have release over 20 games for windows phone which the performance is fine. The only issues we had experienced were related to the high usage of graphics (which tends to break low end phones with 512 MB or less). We also stayed away from particles, which slows down the game. We usually adapt and test on low end devices (and some high end), if the performance is not good/acceptable, then we looked into the details.

Like I said, the only issues have been related to particle systems (a lot of them), so we used sprites/static images and it worked perfectly fine.

Good luck with your game!

Joannesalfa Certainly agreed, never just test your game on the top of line device only..

My own cut-off point is devices with Tegra 3, which is quite slow in JS compared to Samsung S3, these are not unrealistic targets to meet because the bulk of Android are on S3 or better devices now. For Apple, iPhone 4S is the bulk of the market with iPhone 5 replacing it fast.

EddyDingDongs

The Nexus 7 is still the top of line device, since its Snapdragon S600 SoC is super fast compared to most things out there.

For Apple, iPhone 4S is the bulk of the market with iPhone 5 replacing it fast.

That's true. When you read the App Store descriptions it is clear that many developers have already dropped the iPhone 4 support and the pace is quickening.

It was for Joannesalfa.

I mean the idea of making a "big" game on a cell phone is kinda like Facebook buying out Occulus Rift.

Its not that it can't happen, it just doesn't make much sense.

newt Funny you mention that because Facebook have just bought Occulus Rift.

http://kotaku.com/facebook-buys-oculus-rift-for-2-billion-1551487939

today I have tested my very simple platformer (CocoonJS) on Thailand OTPC (One Tablet Per Child), it is 1 core Rockchip CPU with 1 GB Ram. Anyway: even if there was only 1 object (player) and some simple background, it has max. 15-20 fps. So for sure JavaScript is too slow for mobile games, but fortunetly our C2 apps are saved by Moore's law (so nowdays there are lots of quad core CPUs and octa core CPUs)

I would like to share my experiences how I worked a lot of mobile games for my customers also it has do to with HTML5 frameworks and Construct 2 IDE, you may consider this as my personal verdict:

• It’s slower than native code by about 70%
• It’s slower than x86 C/C++ by about 50%
• The most viable method for it to get faster is by using the hardware to desktop level performance. It could be viable long-term, but it’s looking like a pretty long wait.
• Garbage collection for mobile is WORSE. Actually, it's really way worse than it is in desktop level.
• The language itself doesn’t seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code.
• Every competent mobile developer would waste a great time thinking about the memory performance of the target device.
• asm.js may be another solution, but if they win you will be using native language or similar old language as a frontend, more than something high level like JavaScript.
• 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.

I believe we should develop the games for desktop, if you want to develop big games for mobile, please forget it and try to find another native language could work with your big game design.

you are right, but construct2 or similar software use programming by "event"...

and it is normal the low performance of the game, but depends how the person "program" de logic of the game.... the best method is to program by native script, but take a lot of time to make a simple game....

and depends what do you mean with a "big game"... 3d game? big map? a lot of object?

I think the problem is the method to export the game... we not have a perfect exporter for the mobile... but we have the third party and they also have some bugs....you can make a great game with construct2, the new flappy bird or the new game of the year, but if the export doesn't work very well, you will have everytime different problems... you don't have a perfect control like construct2...

szymek - that is surely software rendering. Either the device has no GPU or the driver is blacklisted so it's not being used anyway. Either way, it's not to do with Javascript performance.

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

But that is what many people do (according to my experience) - I can't understand it, but after 1-2 years they boast about their brandnew phone

I just have to say OP is going about this entirely the wrong way.

Native is not better than Html5 code. Nor is Html5 better than Native code.

The real question we as developers need to ask ourselves is WHEN it is appropriate to use one over the other or, perhaps use a hybrid.

The main advantage of native objective based languages is having access to a devices core features. Things that we cant access with Html5. Take Siri for example.

Is Native code going to be faster than Html5? Certainly. But at margins that we as developers can typically ignore.

Full fledged games honestly don't work or meet mobile demands. Oceanhorn was brought up. This is a console grade game. Tons of people bought it. But fewer took the time to sit down and complete it. Why? Because mobile users don't look for console grade games. When people want to play actual games or have the time for an actual game they go to the computer or consoles.

Mobile games for the most part are relatively simple, and don't have a ton going on. Html5 is perfect for this. Unless, like I mentioned you want access to some device specific functionality.

If you honestly need over 1000 sprites at any given moment . I think you are going about your game design poorly.

One of the key tricks to mobile development is faking things. If you want a living environment, don't create a few hundred sprites to bring the game alive. Create a background image, and animate a few places throughout. Use sprites to help in believing something but don't go all out in creating vast scenes of sprites.

The ONLY time I have had really bad lag issues with Html5 on mobile devices is when:

1. Testing on old outdated devices. These devices are generally not supported by even native developers so it is a non-issue

2. Testing over lan with debug mode. It kills the frame rate. I can go from playable smooth gameplay, turn on debug and BOOM game is stopped.

3. Thats actually about it.

I also have to mention this. You always hear developers having this conversation. Html5 or Native code. Which one is better?

But I think everyone reading this thread needs to realize is this:

The users, the people playing the games. They are not bringing this up.

Why?

Because they probably can't tell you the difference in Html5 apps vs Native.

I dont know about you. But My games are not targeted at developers who care if the game is Html5 or some objective based language.

My games are targeted to people that only care if the game works. And Html5 works just fine.

Tylermon Actually I disagree with you but there is no need to debate the issue.

If you are targeting strictly mobile then the question is why did you go with HTML5 to begin with? That is the real question for anyone that is developing games. HTML5 is great and flexible but it is not the ideal platform for mobile games. The fact that it can export to them (Via third party exporters and wrappers) does not make it ideal for mobile. I love C2 for what it does, but for larger mobile games there are frameworks like Unity which work great. But they also do not allow you to just drag and drop.

Knowing your target platform and the limitations of the different development options are very important before trying to start any project which has a goal of being published for money. I have C2 for some of my projects and Unity for others. C2 gives a great balance of price vs. value. If you want a platform that is more tailored toward mobile than C2 you will need to either learn to program, or spend more money. There is always a trade off. Pick your poison

BluePhaze That's why I'm done with that.

About Unity3D, it does have precomputed Occlusion Culling solution, graphic optimizations, level of detail support and bottleneck reducer as Unity3d features, these features are required for big games, one more thing, Unity3D is not a browser-dependence.

I know it's not allowed to just drag and drop, only raw text editor which it's old workflow, however there a third party extension is called uScript, it's helping a lot to make visual scripting.