Performance

[dmitsuki]

Hey everyone.

 

I want to make a HD tower defense game for mobile browsers, so I want to have a discussion about performance and the best solutions.

 

I am planning on using Phaser (2.0) to accomplish this task, but how many sprites can be drawn and collided against each other before the frame rate takes a steep hit on the mobile browser? Is it feasible to get 100^2 sprites at a good performance? What do you all think the theoretical upper limit is. I remember making my first game, when I had around 50 sprites on the screen updating and checking collisions, the game dropped to around 40 FPS on my mobile device and required optimization.

 

My other question would be what about asm.js? Do you think you could see a performance gain writing native C++ or C#/Java code and compiling it to asm.js? This would require a custom engine obviously, but theoretically would this give a massive performance gain? Also, what is the current state of webgl on mobile browsers? Is everything still basically canvas or are we seeing actual hardware acceleration in Chrome, Safari and Firefox mobile os's?

 

Obviously I will prototype the Phaser version later to see what amount of animating, colliding sprites I can get out of my HTC Evo 4g lte, but for now I just want some of your opinions and experiences with "larger" games on mobile.

 

Thanks.

[rich]

Do you mean 100 sprites that use ^2 textures? Or 100^2 sprites? (in which case 10,000 of them?!)

 

re: asm.js I don't see the point. If you're going to code in C anyway, why not just write it in Objective C? Or Unity and C#? As browser support for asm.js on mobile is close to non-existent so I can't see how it would dramatically speed anything up (yet).

[dmitsuki]

Ah, that's what I was looking for. asm.js support on mobile browsers, if it's not there I guess I can't use it.

 

And I meant 100^2 collision checks per frame, 100 sprites against 100 sprites. Not actually drawing that many sprites, just one sprite is checked against every other sprite.

[rich]

Would you need that many checks? You could use the built-in quadtree to eliminate loads of those, depending on the type of game.

[dmitsuki]

Wait, the collision detection doesn't use a quadtree by default?

 

For my first game I was seeing a performance hit with 100 bullets trying to collide against the player, but then again perhaps that was just updating them.

 

I'm curious about porting or making a version of my SHMUP for HTML5 that looks like this

]

 

Tons of objects on screen, but with my first game I wasn't really able to get anywhere near this without a massive performance hit.

[away168]

If you are talking about objects colliding to each other in 2D base, use quadtree algorithm.

 

If you are talking about that kind of bullet-hell/danmaku game, for me it is best to use layer-based collision detection. You only need to compare Player's ship and the enemy bullets (say 100 bullets in screen), which goes on 1 x 100, and a number of enemies (E) against the Player ship's bullets (100 as well), which is E x 100, it's far cheaper even compare to quad tree for that type of game.

 

About how many objects before it takes a performance hit on the browser, no matter what you are using, it all depends on the mobile browser, you code, and how you use the libraries (if any). You have to test it yourself.

 

About asm.js, I believe it only runs on Firefox for now, experimental in Chrome. It means so far I won't hope for mobile any sooner. Correct me if I'm wrong.

 

Larger games in mobile requires better management on how you handle your data. In web game you are not downloading the whole game, and not expected to have user to keep downloading the whole package every time people load the game, even if they have it cached in the device. You can create a big traditional RPG game with less than 50 - 100 sprites on screen, but you will suffer on managing so much data. For example of your SHMUP game, say you have 10 stages, and each stage has a lot of different assets, you may want to load the assets per stage before the mobile device is crashed due to overloaded memory handling big backgrounds and other assets.

[rich]

Wait, the collision detection doesn't use a quadtree by default?

 

Yes of course it does, but you simply cannot make a danmaku that will work well on a mobile web browser. It's an unrealistic expectation of what they're capable of, no matter what framework you use. Maybe when WebGL is more prevalent. Until then, go native.

[dmitsuki]

Ah, doing test the biggest bottleneck does seem to be drawing a lot of sprites. I guess instead of "throw tons of bullets" at the player I can just more effectively use bullets drawn on the screen to make interesting patterns and what have you. Fix it with design instead of technology!

 

Thanks for your time everyone who replied!