Phaser Strengths and Weaknesses on Mobile

[Thepian]

I'm not trying to imply anything, just want to avoid a lengthy evaluation.

 

It seems that Phaser has a large chunk of demos, and very well covers the ability to develop 2D arcade style games for desktop keyboard/mouse interaction.

 

I'm looking to make mobile phone web games that are closer to puzzles than arcade games. I would want to use SVG and webfont symbols rather than png sprites.

 

To me those requirements should be easy to overcome, but there could be catches.

 

I also try to be pragmatic and only go for popular frameworks. According to

 

https://html5gameengine.com

 

Phaser is doing pretty well. I find Construct interesting for the editor, but I don't develop on Windows, so that is out. Impacts price tag is no issue, so that seems like the other option.

 

Has anyone worked with both Phaser and Impact, and is able to weigh the two?

 

Are there any missing pieces for touch screen navigation ?

 

How would you do responsive layouts ?

 

How are CPU/Memory requirements on mobile ?

 

Is it realistic to load scenes as independent modules with a Canvas element each that can be enabled within 100 ms ?

 

Any comments are welcome

[rich]

I'll let others pick-up the points you raise, but I want to add that I don't know of any game frameworks that support SVG (even slightly). Impact certainly doesn't. Some of them may let you load SVG as if you were loading an image, but it will still render as a bitmap with all the trappings that entails. I guess the primary reason is that most frameworks like to use WebGL where possible, and you simply can't render SVG with WebGL, so it has to be rasterised to a texture at some point. Given how browsers differ significantly in how they approach this most devs like to do it themselves, hence PNGs, texture atlases, etc.

[drhayes]

The Impact community has these discussions all the time.

 

I'm still a Phaser newbie but I'm in the process of converting a game I'm working on over to Phaser for all the benefits I listed in that thread. Ultimately, I'm confident about where Phaser is going to be in a year (about how long it's going to take me at my current pace to finish my game) over where Impact is going to be in a year.

 

I don't have a lot of experience writing games for mobile but I will say that pure SVG requires a helluva lot more CPU to decode than raster which makes it a bad fit for mobile when used heavily. Along with all the other reasons Rich gave. It's probably the main reason why even desktop web pages aren't built with tons of SVG despite its prettier appearance and more sane presentation options compared to CSS.

 

From reading the docs, I think Phaser has a more complete touch input story than Impact. No "native" touch support in Impact, for example, versus all the touch-related properties and methods in Phaser. Impact doesn't "natively" support GUIs, either. Most Impacters write custom GUI code or use Impact++. Definitely check that out as it's the unofficial Impact 2.0.

 

That said, Phaser's API is pretty sprawling compared to Impact's. If you're new to JS, or new to gamedev, Impact might be a better bet since it gives you fewer options for how to structure things vs Phaser – states or no states, multiple states, derive my own custom Sprite class or not, which physics system WebGL vs not, etc. The API docs for both are great (nice update to the Phaser docs, BTW! I'm a huge fan of the new format!) and are worth a deep read to see what you're getting into.

 

Overall, Impact feels a little "batteries not included" compared to Phaser. Plus, from an engineering perspective, a team of people work on Phaser open-source while Dom, the author of Impact, is working by himself closed-source whose last official release was in July of 2014. Nothing against Dom; I've gotten a lot of value from Impact after buying it in 2010 and think the world of the framework.

 

Why the specific requirement to have separate canvases with that timing?

[Thepian]

Thanks for the feedback. It sounds like Phaser is a pretty good choice for me. I guess I will have to render the pieces as PNG in a build step. A shame since the graphics will be really simple with little or no background tiling.

 

I'm not making a game in the traditional sense, but a story that switches between scenes which are sometimes mini-games, so I want to chop the game into parts that can be sequenced dynamically based on the progress. I'd like to make it so a non-programmer can do that with a visual tool. Hence it should be possible to launch a game scene with parameters determining the game details and start that game with no noticeable delay. The actual figure what arbitrary within the range that most users wouldn't notice.