Prior to my previous post where I was looking into using Perlin Noise in a game I was developing a game for my recently acquired Playbook. (The Playbook itself in my opinion is a very underrated little tablet and I am thoroughly enjoying using it.) You have a set of 5 by 5 lights and the goal is to switch off all of the lights, when a light is clicked the two vertical and the two horizontal lights adjacent to the light will switch on/off depending on whether the light was lit, I’ve called it OutLikeA (original, I know). I chose to develop the game using Webworks, Coffeescript and HTML5, I’ll outline the reasons and design below.
Why?
I’ve chosen to use coffeescript mainly as a learning exercise for myself, and I also wanted to use the provided class system so that I can easily have base classes that implement some of the default methods such as update and draw. (I know you can do this in javascript, as I said learning exercise) As reference material these books: The Litte Book on Coffeescript and Smooth Coffeescript really helped me ge to grips with the language.
Now I could have developed the game using the NDK for Playbook or any of the other development options but I wanted to see what all the HTML5 canvas fuss was about. There is one reason why I might not use HTML5 to produce games on the Playbook again, however I’ll go into that later.
How?
UI
OutLikeA uses a number of different screens, the start screen, level select, game screen and a few others. There are a few ways to move between screens and there also back buttons and menu buttons to go back a screen or show a menu. The way I have implemented this is that each displayable item in the game extends a simple class that defines an update, draw and subscribeclick function. For each iteration of the main game loop the update function is called and then the draw function; the subscribeclick function allows an item to listen if the screen is clicked and respond.
To track history and allow easy movement between screens I use a stack, when a screen is to be displayed it is pushed on to the stack and then in the game loop the top of the stack is displayed. When a user goes back to a previous screen the item on the top of the stack is popped and so the previous screen is displayed.
Levels
Each level is stored in an array in a json file and has the following attributes: name, board, locked and moves. The name is simply the name of the level, the board stores a 2D array of 1s and 0s where a 1 represents a light that is switched on and the 0 represents a light that is switched off. The locked key stores a boolean of whether the level is initally locked the first time a user starts the game and finally the moves key stores the minimum number of moves that are required to complete the game. When a level is completed a value in local storage is set, this keeps a record of which levels a user and allows the level select screen to block access to locked levels.
JS
I’m using a few helpful javascript libraries in the game: modernizr, zepto and radio. Modernzr is a neat little library that detects what features are available on the client platform, I’m using this to detect whetehr the device supports touch. This is so that if the game is running on a Playbook I can catch the touch events and remove the delay when clicking, if the game is running on a device without a touch screen it will just use standard touch events. Zepto is being used in place of jQuery, it provides most of the capability in a fraction of the size. Finally Radio.js is being used to implement the observer pattern, when a touch or click event is thrown any items that want to respond to this simply stated when they are initialised that they would like to subscribe to these events.
Is it complete?
To the all important question, the game is very nearly complete I just need to add a few more levels and then it’ll be ready to upload to the app store.
Issues
Now I said earlier that I might not use HTML5 to produce games for the Playbook again, the main reason is that there seems to be a bug with the HTML5 audio implementation whereby small sounds will either not play or play at random times. This is a tad annoying, and for now I think I’ll just realease the game anyway without sound and hopefully when the 2.1 OS update comes out this will fix the issue. (According to crackberry this might just be afew days away)
Source
I’m not releasing the source just yet, but it will be available when the game is released and the game itself will be free.
And of course I can’t finish without the required screenshot, my fanatastic skills with Paint shines though.
Update 17/06/2012
I’ve updated to the beta 2.1 playbook OS, and annoyingly it looks like there is still a bug with HTML5 web audio, the sound plays twice. Close but no cigar. So for this version I’ll disable sound by default and allow it later when it’s fixed. All that’s left to do now is to add the final levels and it’s ready for the wide world.
Update 3/07/2012
The game has now been released on the app world, and it’s immediately got one scathing review: “This game is the worst game I’ve EVER played>>>>>It doesn’t make ANY SENSE!!!”. Now, I know the game isn’t a tour de force, and it’s still an early phase, but really this is the worst game ever? Guess someone has never played Superman 64. Saying that I don’t particular mind that it’s a bad review, it’d just be nice to be able to contact the user to see what issues he was facing and see if they can be fixed for the next version as far as I can tell there’s no way for me to do that. Oh well it’s out there and that’s something.