In the previous articles (Intoduction, Calculation, Game Screen) we went through the basic steps required for mobile game creation and looked at calculating and adding responsive behaviour to our game. The same concept applies to the game screen as well. Here is the main game screen The game is a classic dominoes game where players are required to throw their dominoes on their personal train or a special public train, or any other player’s personal train when it becomes public during the play. A lot of tweeing effects are used in the game which is turning out to be the main area to focus. The first step to optimize the game was to reduce the resolution for mobile which I chose to be 960×640 for devices with low processing power and 1350×900 for devices with high processing power. In order to do some benchmarking I integrated some code to measure FPS in[…]

In previous article I fixed the resolutions I wanted to use for my game, the next step was to set up the game screen and placing the controls on the screen. This is very similar to how it was done for RESIZE mode but for the continuation of this article I will demonstrate the first screen of the game which will give good idea about other screens as well. Then I will focus on the optimization which I am going to try to improve the overall performance of the game on mobile devices. First thing I do is to fix the area for individual controls so that we can calculate its size and give maximum space available on mobile device. The layout I chose for first screen of my game is something like below Look at the percentage values. The selected orientation for my game is going to be Landscape. Top 30% area heightwise is[…]

In my introductory article on this series I talked about using SHOW_ALL scale mode for my game which fits perfectly for need to be responsive. It will resize the game to fit into available space using the original aspect ratio which was used to develop the game. The only issue I saw was the “letter-boxing” effect so if device’s aspect ratio was different than the game’s aspect ratio, there will be blank space around either horizontal edges or vertical edges. We can account for that extra available space when loading new game and positioning of all ui controls can then be done relative to available space which is similar to how we handled RESIZE scale mode. The only difference here is that it can only be done once in SHOW_ALL scale mode when the game is initialized. In mobile app this is not going to be a problem and we can[…]

In my previous posts on responsive Phaser game (part1, part2, part3) I used RESIZE scale mode for making game reponsive. RESIZE mode needed quite some handling whenever screen was resized. For example position of individual controls were required to be recalculated. Moving tweens were also something which required special handling on resize. It serves better for desktop games in which you can support different aspect ratios. I planned to compile and publish my next game to Android play store which made me also look into SHOW_ALL scale mode. SHOW_ALL handles resizing automatically and does not have a resize method for moving controls around on resize. The only limitation is that it fixes the aspect ratio of the game canvas and when game screen is resized, it resizes game canvas in the same aspect ratio. It might be a problem for desktop games where browser window can be resized to any proportion but mobile[…]