iPad only, gamedev — week #5 — Coding and Debugging

Zendrael
4 min readOct 17, 2016

--

You should know that, as a web game, we’ll have a lot of players out there (hopefully) with the more diverse types of devices and screens and resolutions. Our game must be prepared for each of these users and not let us crazy on development, thinking on each size that our game must contemplate. There is a solution for that as showed in our main.js file:

(Type the code, don’t be lazy!)

This way I’m assuming our default game size to have the minimum height of 160 pixels and an width variable, accordingly to the device screen. Be we creating a retro styled game or not, this will expand the game area vertically and take all the available width. The important part here is that if you are working with a different default size, change the 160 value for the value you prefer for your default resolution.

Another trick for this game is to set up our canvas to be rendered as a pixel perfect area, without antialiasing. Our CSS can help on that:

Good so far, but we are not seeing nothing until now, how do I know if this is working? I’m assuming you know how to code using Phaser, but if you don’t, we need to make a few more lines of code. Start by our Boot.js state:

States are like "screens" of your game in Phaser. We can have our loading screen, menu screen, play screen… You can have as much as you want or your game needs. In fact you could make an entire game with a single file but we are going to let things a little organized here.

Before we can start to draw things in the screen we must preload all of our assets, like images, audio files and so on. That’s the reason for our Preloader.js state:

We are almost there! While our game is loading the assets, a beautiful and nice "Loading…" will stay in the screen and, when finished loading, we’ll call the Play state. In this case, we are just loading our sprite and telling Phaser that each frame of the spritesheet has a size of 16x16 pixels. If you don’t understand the concepts of spritesheets and tilesets, drop a comment so I can explain more in another post.

Finally we will show something in the screen, coding our Play.js file as follows:

Ok, we can now test what it is looking like by opening the index.html file and touching the eye icon on Koder app. If you are seeing nothing (the green square should be on the top left of the screen), this is time to deal with the possibility of a bug in the code. There are two ways to get bugs on this mobile-only approach: use the Koder’s Firebug button which is not working on iOS 10 (are you on 9? Is it working?) or use the great Mark Knol’s "Console Log Viewer" at https://github.com/markknol/console-log-viewer . Just put the next line inside the <head></head> of the index.html file:

<script src=”http://markknol.github.io/console-log-viewer/console-log-viewer.js?log_enabled=true”></script>

Now, when you load the game (in Koder or any browser, mobile or not), a console will appear on top of the game and will show the errors and logs helping to debug the code. Yeah, this is really good and you can even use any other way to edit your code, even remotely and accessing your server thru Safari for testing. The easy way to debug on mobile! A big thanks to Mark!

That’s good for this week, on the next we can create the other elements, make the interact with the scenario. See you there!

--

--

Zendrael

Minimalist, Game Developer, Writer, Tai Chi Chuan practitioner