Developing a portal for free mobile games

Anyone who has ever glanced across my portfolio will notice that there isn’t anything in there that is particularly original. This is quite deliberate. A couple of years ago when I set out to create these JavaScript / Canvas games I set myself the simple task of recreating some of the games that I loved as a kid. Since I entered my teens the year Spy Hunter (below left) came out I hold a particular fondness for the game and set myself the task of crafting my own homage to it (below right).
I absolutely adored this game in the arcades nearly 30 years ago. The style, the feel, the music… it had it all. And I wasn’t alone. My friends and I stood like groupies around this cabinet for many an hour during the summer holidays.

spy hunter screenshot spy chase screenshot

The same can be said for other games like Defender, Galaxians, Galaga… the list goes on. So what you see in my portfolio right now is a direct reflection of my love for the arcade games of the early 1980s.

I suppose there will come a point where I move forward in time and focus on the SNES or something. I don’t know. But for now I want to bundle all these games together to present what is I suppose a bit of a nostalgia trip.
I always intended to create a place where people could play free mobile games at the tap of a button and I think I probably have enough games in the portfolio to make such a thing worthwhile.
free mobile web games banner
You can find the portal at Just now there is no sign-up or login of any kind it’s all just a tap ‘n go, free to play affair.

Ultimately I’d like to branch out a little an maybe embrace social gaming and have high score tables for each game that are stored on my server. It’s early days and I need to have a serious think about security and avoiding a spamming of my database. But that’s a challenge I enjoy :)

Touch control in a maze game ? Pac-Man has the answers.

I’ve been looking around the AppStore for games that implement the kind of touch control that I’m after for my maze game. There’s a thousand and one maze games on offer which is fantastic so I downloaded a few free trial versions to test them.

In many cases the controls felt OK but not great. The more I thought about it the more I liked the idea of a simple swipe gesture to change the direction of the player’s sprite.

Pac-Man has it all.
I really shouldn’t have been surprised. With the Pac-Man trial version you can set which style of control you prefer. So I picked swipe.

Pac-Man screen shot

The effect really is quite something. Your little Pac-Man chomps his way around the maze and you make your turns with elegant swipes. It just feels lovely. I really want this smooth feeling of control and am actually pretty much there.

I do have issues with the testdirection flag being unset after just one try but I will figure that out. Once I’m happy with the implementation I’ll write it up in a little more detail since I think it’s a useful thing to share to JavaScript game devs.

Talking of which here’s an interesting article called Analog thumb sticks for iOS using HTML5 from the creators of Onslaught! Arena which you may find interesting / useful.

Touch screen and player movement

Today I have spent a hopeless amount of time playing with the touch screen interface for a new game.
The game is a maze game, similar in many respects to Pac-Man in the way that it executes, but quite different in its content.

When I started to assemble the code for the player’s sprite behaviour I knew I was going to be faced with a tough decision regarding movement control.
In previous games this has never really been much of an issue since I’m generally dealing with movement in a fairly basic way. Galactians for example was a simple slide left and slide right affair. Wizard Wars was a touch-to-go-here game and Danger Ranger was a case of sliding your thumb or finger to turn the ranger to walk left or right. Everything else in that game was about jumping. In any case I’d taken the movement code from Dragons and not added much more to it.

But with this maze game it’s important to me that the whole thing feels natural. I really didn’t want the player to be concerned with where he has to put his finger in order to move. I really do loath the idea of semi-transparent virtual d-pads. It’s just that the touch screen interface can be used to great effect without them.

But, I had to explore all options.

Before I prattle on about the theory of implementing player movement let me show you how I set up and manage the touch code.

function initTouch()
	if(checkForTouch()) {
		if (document.body.addEventListener)
			document.body.addEventListener('touchmove', touchMove, false);
			document.body.addEventListener('touchstart', touchStart, false);
			document.body.addEventListener('touchend', touchEnd, false);
		} else {
			window.addEventListener('touchmove', touchMove, false);
			window.addEventListener('touchstart', touchStart, false);
			window.addEventListener('touchend', touchEnd, false);
	} else {
		window.addEventListener('mousedown', mouseDown, false);
		window.addEventListener('mousemove', mouseMove, false);
		window.addEventListener('mouseup', mouseUp, false);
		write("No touch capability.");

function checkForTouch() {		
	var d = document.createElement("div");
	d.setAttribute("ontouchmove", "return;");
	return typeof d.ontouchmove == "function" ? true : false;

As you can see I perform a fairly basic test to see whether touch is supported as a function and if not fall back to mouse control. If you were to play any of my games on the desktop with diags switched on you’d see the line “No touch capability.” every time.
The point here is the level of control that we have over touch start, move and end. It’s pretty powerful and gives us a ton of options for controlling our games.

So how do we do anything with touch ?
It’s quite simple. Every time a touch event fires I store the co-ords in the touch object. Something like this..

var touch = {};
function touchStart(event)
	var xy = getXY(event.touches[0]);
	touch.startx = xy.x;
	touch.starty = xy.y;

function getXY(event)
		var xy = {};
		xy.x = (event.pageX - (g.canvas.offsetParent ? g.canvas.parentNode.offsetLeft : 0));
		xy.y = (event.pageY - (g.canvas.offsetParent ? g.canvas.parentNode.offsetTop : 0));
		return xy;
	catch (e)
		write("getXY: " + e.message);

I generally wrap most functions in try / catch. Just pretend I did that with the touchStart() function ;-)
So again it’s all fairly straight forward. Returning an object with just the x and y parameters I get some control over how to handle my player movement. Notice that I use the offsets to determine the true position since I’m positioning my game canvas in the centre of the document with margin: 0px auto and a width of 320px; On the desktop this is an issue. Generally on mobile it isn’t since I’m handling the display with the viewport.

So now I’ve got some co-ordinates and I can start to explore options for controlling the player.

The game itself is a maze crawling affair. I want my character to walk the maze avoid monsters and collecting goodies. There will be a little more to it than that but essentially this gives me something to go on when considering the player’s control of his character.

Option 1 is all about a virtual overlaid d-pad. You will have seen them. God awful things that just don’t feel natural at all. They’re generally plonked in the lower corner of the screen and you are forced to control your game in a small space.
I created a simple d-pad graphic and placed it in the lower right corner.
I then wrote some code to track which edge of the d-pad had been pressed, uploaded the game and hit the refresh on the phone.
( Note: my X/Y detection code is primitive. I’m checking the screen to see if the touch event was recorded at the same location as the location of the d-pad graphic. )
To cut a long story short I must have spent 50% of my time looking at the blessed d-pad and not even enjoying watching my character march around the maze.
I ditched this idea swiftly.

Option 2 saw me drawing thin arrow graphics at the top, right, bottom and left most edges of the game screen.
The theory was sound. I’d just let the player touch some fairly large areas of the screen in order to move the player up, right, down or left.
Again I uploaded and refreshed on the phone.
Initially it felt OK. I was able to smoothly move the character around and it felt pretty good having more than a couple of cm flexibility in the movement.
But I soon tired of having my hand obscuring the lower corners of the screen when the player character was down there and I was in need of some finer movement.
I ditched the idea.

Option 3 was actually fairly similar to option 1 but with greater scope.
I switched the phone off and just touched the screen. I played the imaginary game and tried to feel for what was right.
As I moved my thumb around I realised that the kind of control I was after was in fact quite similar to option 1. But I wanted the d-pad to be positioned based upon where I first tapped the screen. A kind of user-definable d-pad location.
So I set about creating a sequence that went something like:
touchStart: record the centre of the d-pad co-ordinates
touchMove: throw the event at a d-pad handler and update touch x and y

With the centre of the d-pad recorded as my origin I then needed to figure out how the co-ordinates of touchMove translated in to a new direction for the player.
Something like..

if (touch.newx > touch.startx) moveright; 

There are some complications here.
Imagine that the finger is swiping to the right from an origin of say 128,128.
As the touchMove event continues to fire the x is incrementing through 129, 130, 131 and this is great. I’m clearly looking to move to the right.
But then my thumb flicks up or down the slightest amount.
My y value is also incrementing 128,129,130,131…
So which is true ?
Does the player want to move right or down ?

I’m actually still working this bit out and will blog about it once I’ve got it working.

Overall the movement is fairly smooth just now and I’m working hard to make it as smooth as possible.
User feedback and a logical touch interface is vital in these games. If you mess this bit up you kill the entire game and your player will just go looking for something else to play.

Other things that I’m curious about are walking DOWN a corridor, effectively “hugging” the wall to turn RIGHT or LEFT at the next available exit.
To this end I’ve played Pac-Man quite a bit just lately and learned some valuable design lessons.
I’m also mucking about setting touch.testx and touch.testy in an attempt to sniff the wall for available exits.
Actually this code works pretty good right now.

When there is more to see I will return to this subject.
Thanks for listening to me waffle ;)
Please feel free to share your own thoughts, ideas words of wisdom on the subject.

Playing with sprites, walls and new game concepts

I’m always looking at new game designs and cool ways to implement them. I also have my own system for creating HTML5 games that has evolved over the last 12 months.
I don’t use frameworks or libraries or such, I just enjoy getting my hands dirty with my own code.
But if you’ve read this blog before you’ll know that.

I wanted to have a crack at building my own maze game.
I’ve created similar games in the past and enjoyed making them very much so the idea of bringing one to mobile web is quite exciting.

Initially I took the decision that I wasn’t going to build a level editor. I just don’t have the inclination right now. Perhaps that will change if this game works out pretty well.
For now I wanted to just hack around in JavaScript in such a way that I could visualise the level as I key in each element in to the level data array.

Something like this..

var leveldata = [];
leveldata[0] = [
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+, ,+,+,+,+,+,+, ,+",
		"+, , , , , , , , ,+",
		"+,+,+, ,+,+, ,+,+,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+,+,+,+, , ,+,+,+,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",

As you can see I have defined an array to contain all the level data in and then populated each element with another array. It is this second array that will store the level specific data.
What you see above is a representation of tiles. Each tile on screen is 32 x 32. So a level array with 14 elements equates to 14 rows of 32 pixel height = 448 pixels. This in turn equates to a total tile height of 480pixels. Perfect for my prefered game resolution of 320 x 480.
You can also see that I’ve left the last few rows full of tiles. This is due to the iPhone leaving its status bars in place by default and therefore chewing up far too many screen pixels.

In my code I iterate through each element in the array and parse the string for the comma “,”.
You can see this below.

function setWalls()
		var l = leveldata[g.level];
		for (var y=0;y < l.length;y++)
			var s = new String(l[y]);
			var a = s.split(",");
			for (var x=0;x < a.length;x++)
				switch (a[x])
					case "+":
		g.mode = "pregame";
		g.resetting = 50;
	catch (e)
		write("Set walls: " + e.message);

g is my global namespace. Quite a lot goes in there that is game specific as opposed to player or sprite specific.
spawnWall() is my function for pulling a wall sprite out of the sprite collection and assigning it a set of co-ordinates.
Something like this..

function spawnWall(x,y,row)
		for (var a=0;a < NUM.WALLS;a++)
			var o = m.walls[a];
			if (!o.visible)
				o.visible = true;
				o.targetx = x;
				o.targety = y;
				o.x = x;
				o.y = g.canvasheight + y;
				o.row = row;
	catch (e)
		write("Spawn wall: " + e.message);

I am positioning the wall tiles below the canvas height. This is deliberate since I want them to scroll in to view in between levels. In my move() function I have code to shift a sprite from its x co-ordinate to its targetx co-ordinate. Same for the y.

So back to the leveldata array and where you see a white space no tile will be drawn.
Where you currently see a “+” a wall tile will be drawn.
Eventually the + will be replaced by single characters that represent the type of wall tile I want to display.
For now it simply translates to my default wall tile.

wall graphic
You can see that this wall tile is 64 x 32 in size and contains 2 frames of 32×32. I am going to animate my wall tiles.

When I run the game in test mode I see the following screen layout.

castle screenshot

I have deliberately defined the wall tiles as sprites.
This gives me a tremendous amount of flexibility since the sprite class and methods allow for a lot of animation and movement. It also makes life a lot easier when I come to consider collision. Rather than “overlaying” a collision map I simply test for position based on a ton of sprites.
It also gives me the freedom to move walls should my design require it.

So just now I’m playing with ideas but ultimately I’d like to plant entity starting points in to the leveldata array.
Perhaps try a PacMan approach to a game where the whitespaces are taken up with “o” which will be translated by the game in to small coins that the player must collect.
I don’t know. It’s early days.
The most important thing is that my codebase allowed me to create this proof of concept in around 15 minutes.
Exciting times.

The market for HTML5 gaming

As I’ve recently blogged I am convinced that 2012 will be an enormous year for HTML5 gaming on mobile phones.
So much so that I am staking a fair bit on it. Not least the creation of my own game development studio.
But like every startup I need to do my homework and right now there are some fairly obvious questions to be answered.

Just how big IS the HTML5 gaming market ?

… and how big can I expect it to be in 12 months, 2 years, 5 years …

When I first asked these questions I drew a blank. It occurred to me that I just don’t have those kinds of figures. Sure I have some contacts that could help me but I really need some broader statistics not just the figures of a handful of portal operators – as big as they may be.
The right place to start is of course the sales figures for mobile smartphones over the last couple of years. I need to get a snapshot of today’s market size and an idea for its growth over recent years.

Here’s a quote from to get things rolling:

“Sales of mobile technology continue to soar as the worldwide mobile handset market grew another 16.5 per cent year on year this quarter.
The number of units sold totalled 428.7 million in the second quarter of 2011, a 16.5 per cent increase on the same period last year, when it stood at 367.9 units, according to research firm Gartner.
Sales of smartphones were up 74 per cent year on year, accounting for 25 per cent of worldwide mobile phone sales in second-quarter 2011. They accounted for 17 per cent of overall sales in the same period last year.
Google and Apple are leading the smartphone market; the combined share of iOS and Android in the smartphone operating system market doubled to nearly 62 per cent in the second quarter of 2011, up from just over 31 per cent a year ago.”

Of course it’s the sales of smart phones that I’m particularly interested in and we can see that they are up 74% year on year.
In 2nd quarter 2011 that is 25% of ALL mobile phone sales worldwide. For the same period last year that figure was just 17%.
Right now I’m willing to bet that smartphone has a greater than 25% share of all mobile phones sold. Possibly as much as 35%. We’ll need to wait for the figures.

To get an idea for growth we can go back to 2009. I see that for that year an estimated 172.4 million smartphones were sold and the year before 139.2 million.
Bearing in mind that approximately 107 million smartphones were sold in the 2nd quarter of 2011 alone compared to a total of 172.4 million for the year 2009 we can see that in just a couple of years we have some marked growth.

What’s interesting of course is that it is the “big screen” devices that now dominate. Blackberry, the pure smartphone developer, has seen some decline in its market share while Apple and Google continue to steam ahead. No doubt due to the marketing prestige of iPhone and the fact that Google simply gives its OS away for free to manufacturers and hence is available on phones everywhere.

I’ve made an assumption here that everyone who owns a smartphone will want to be playing games on it. Of course this isn’t true.
So further questions need to be answered:

  • How many people are playing smartphone games ?
  • Exactly WHO is playing games on their smartphone ?
  • What genres are people lapping up more than others ?
  • Indeed is it as easy as that. Are people of a certain age / sex gravitating toward the kind of games that we think they are ?

What do my Google stats tell me ?

A reasonable starting point is my own statistical data. Courtesy of Google I can not only capture user volumes I can also see just how many of those users are coming back to play my games again.

Last month (November 2011) I recorded 33,207 visits to my game site. Of those 24,628 were unique visitors. So 8,579 (or approximately 25%) had returned to take another look. This is better than I expected but the skeptic in me wants to understand a bit more so I dug a little deeper.

According to Google the average amount of pages viewed was around 2. This perhaps is what I might expect. One view to pull up the game list and another to go off and play a selected game. Perhaps my visitors had in some cases bookmarked the game list ( I don’t know.
Digging a little further I also notice that the average time on the site is around 2 minutes. I’m fairly confident I can evaluate this to the visitor simply “having a go” on a game. I’d like to think that’s as simple as the time available to somebody waiting in the bus queue or using the bathroom !

Who is playing my games ?

So what information can I glean for the actual visitor himself ?
What can Google tell me about the way that the visitor has consumed my web site. This information is pretty valuable and is of course restricted to the way in which the browser declares itself. To find richer information such as age groups I need to investigate other sources. More on that shortly.

Operating System

A quick look at the data collected for operating systems offers very few surprises.
55% of visitors are using an Android based OS. 16% are on iPhone, 15% on iPad, 12% on iPod and the rest are a mishmash of Symbian, Samsung, Nokia etc.

What is perhaps surprising is the percentage of Android users compared with iOS. 55% is a huge portion and surely can’t be indicative of the global takeup for the operating system. Can it ?
Well it didn’t take too many clicks to put me straight on that one. For the 3rd quarter of 2011 Android has an astonishing 52.5% share of the smartphone OS market. So my own figures are clearly reflecting what is happening in the real world. Better still I appear to have a suitably large amount of data to play with.
Source: Business Insider

For a little balance I also asked Jean-Philippe at Kimia for a snapshot of his stats for their mobile portal

From a total of 1.5 million clicks on all platforms (Android, Iphone, J2ME, Symbian, Blackberry):

  • 29.5% Java
  • 22% Android
  • 21.5% Blackberry
  • 14% Symbian
  • 13% iPhone

From this number 19% of clicks account for HTML5 games. Roughly 285,000 clicks of which 55% are apparently being served to iPhone or Android devices.
The time period isn’t really of any concern. I see it as far more significant that 1/5 of visitors are requesting HTML5 content. Very encouraging.


In terms of geography most of my visitors are from Europe with a fair scattering from the US and a handful from Asia. Perhaps if the US featured more prominently in my results I’d see a greater percentage of iOS users. I don’t know. What all of this tells me is that the two operating systems that I’m targetting with my developments are happily running the games. As iOS5 gets a foothold I’d very much like to see more iPhone/iPad users coming my way.
Before iOS5 I guess I may have been a little more focused on what Android is doing worldwide but to be frank the two OS perform my games at lightning pace right now so the dominance of Android is largely inconsequential.

So what are my visitors playing ?

What games do I make and is this in any way indicative of what mobile gamers want to play on their phones ?

Well most of my games are fairly traditional arcade games from a bygone era. Hypergunner and Galactians inparticular are old-school shoot ’em ups. As is Galactians 2, of course. Danger Ranger is a simple platform game and Spy Chase is essentially Spy Hunter; a classic driving game from over 25 years ago.
I think anyone playing my games repeatedly probably has a little nostalgia in them for that golden era of gaming. I’d like to think that my games have enough quality about them to honour that period so perhaps I have converted a few younger gamers to the “good old days” :)

The most “popular” of my games in terms of visitors is Galactians.

What games are being played elsewhere ?

To get a true picture of what people are playing I need to look further afield. There are numerous high profile game portals around today and more and more will be popping up over the next 12 months as HTML5 offers a more cost effective route to market. Anything that doesn’t actually install itself on your phone or require a plug-in of any kind has to be a safe bet for the future of gaming and several mature game portals are understanding this.

Of course understanding this data is key to my success. I need to tap in to what the gamer wants in order to appeal to potential clients.

So initially I approached Netherlands based Spil games. A company whom I have licenced games to previously and who certainly understand the potential for HTML5 gaming.

Spil operates a number of portals globally not all of which are specifically HTML5. This is a good thing. I really wanted to understand what games are being played not strictly what technology is being used. The end user – the player – after all probably doesn’t care too much how he or she is going to play the game. For them it is a tap on the screen and straight in to the action.

So which games are people playing ? What are the key age groups and what can we learn from them ?

Here is some initial data from Spil for the popularity of HTML5 games on its portals:

Girls (age: 8 to 12)

  • Dress Up Games
  • Quizzes
  • Puzzle Games
  • Board & Card
  • Skill Games

Teens (age: 10 to 15)

  • Action Games
  • Racing
  • Sports
  • Girls Games
  • Adventure

Family (age: 8 to 88)

  • Puzzle Games
  • Girls Games
  • Skill Games
  • Racing
  • Board & Card
  • Quizzes
  • Time Management Games

What I glean from this is that my own particular brand of game is largely going to appeal to the 10 – 15 age bracket.
It is of course early days in HTML5 game development and much of what we see here is the kind of games that we typically saw in the early days of Flash game development before the designers got to grips with the tools and the potential of the platform.

According to Spil’s home page they enjoy an incredible 140 million players each month. This is of course spread across their entire offering which includes desktop gaming. If we rather crudly suggest that 1/3 of Spil’s traffic is coming from a mobile device and then apply Kimia’s ratio of 19% to Spil’s figures that’s an impressive 8.8 million HTML5 gamers per month. In reality I suspect this percentage is much lower but even so with those volumes that’s still a large portion of people playing games in their web browser.

85 million visitors to Spil’s portals every month are female. More than half their monthly traffic. It looks like the games that are working best for Spil are the more cerebral games where we ask players to think a little rather than simply blasting aliens to pieces !

To conclude

I see nothing but growth. As more of us have smartphones in our pockets and as the technology and standard mature in to something really quite rich as a platform I can only see a bright future for the HTML5 game developer.
I would also suspect that browser vendors will seriously consider a binary serving of JavaScript source files to get around security issues. I think the more that the game development community applies the pressure the more we will see browsers adapt to the demand.

The market for mobile gaming with open web technologies is expanding at an incredible rate. In just the last 5 or 6 months I have seen the number of mobile game portals triple as they recognise the value of circumventing the app stores. What money they save in store publishing and marketing they can invest in to their own infrastructures which can only mean strengthening their ability to monetise their games.
For you the HTML5 game developer this is of course great news.

All those enthusiasts that predicted that the future of IT was in mobile technology can feel quite smug that their predictions have indeed come true. Where technology grows gaming and entertainment in general inevitably follow.
Again, for you the HTML5 game developer there couldn’t be a better time to carve a living for yourself.

You have the technology, you have the skills, you have the support of the standards and the growing reliability of the browsers on all platforms. If we can just solve the issues surrounding audio and security we will have at our fingertips a truly wonderful platform for not only making but publishing our games.

Mobile phones are here to stay.
The future of HTML5 gaming is in your hands. Literally !

New HTML5 arcade game – Rebel Rescue

I’ve spent a fair bit of time lately trying to iron out all sorts of issues with Rebel Rescue. On the whole I’ve enjoyed making the game but like any reasonably lengthy (2 months) project you get a bit tired of it all whilst you push it over the line. Most games for me take around a month from the first pixel drawn in Photoshop and the first byte keyed in to EditPlus to completion.

Rebel Rescue screen shot

Rebel Rescue - HTML5 arcade game

For the most part in the last few days I was playing with numbers.
Balancing the speed of rockets, frequency of bombs and accuracy of laser shots is a pretty fine art. Making something worth playing takes a bit of patience.
I think the game is pretty cool to play.
To help the process I took two days away from it last week. The intention was to look on it again with fresh eyes.
It worked ! I instantly found new and better ways to challenge the player.

As with all my HTML5 games the game can be played on a mobile phone as well as the desktop. If anything this game lends itself much more to the touch screen since it allows for slightly more refined movement.

I took my lead from several sources with Rebel Rescue. My inspiration strangely enough wasn’t Star Wars. I merely used some assets that I had created from a previous game and created a simple arcade shooter. My inspiration was really the classic games of the 1990s such as Blazing Star. Yes the visuals don’t compare but then I am a one man band. I would love to create the visual beautifullness of the great NeoGeo titles. But now is not the time and I am under resourced.
For now I look more at the instant appeal of such games. I tried to identify what it was about such modern classic shooters that appealed on such a gut level.
The rapid lasers coupled with the predictable movement of the enemy and resulting explosion of bonuses and powerups fell right in to my lap and straight in to the game. HTML5 across most mobile devices (the ones that count) is pretty performant these days so littering the screen with sprites is a breeze.

I hope you enjoy what I came up with. If you’ve any bugs to report please mail me ( the address is on the ‘about’ page ) and I will look at them.

You can play the game at

Use the arrow keys and Ctrl or Z to fire lasers and start the game.
On mobile devices just touch / drag on the screen.

Have fun !

HTML5 Star Wars game – bullets, bombs, explosions and chaos


Rebel Rescue screen shot

Rebel Rescue screen shot

More lasers, more bombs, more bad guys and more explosions. I’m absolutely LOVING developing this game. And the best bit ? It runs like a dream across all major devices. Now if we can just get audio sorted.
There’s a very bright future for HTML5 arcade game designers.

Galactians 2 – a few minor changes

It always happens. I test a game to death and call it done then the first time I go back to it I find stuff that really should have been fixed.

So I’ve made a couple of changes.

  • Pause mode now really does pause ALL the action
  • Improved spritesheet for bonus / bombs to try and remove pixel flickering (Appears to happen on Apple devices exclusively)
  • Threw in a few more text sprites to reflect bonus item scoring

That’s it. Nothing major.
Oh and I scored just over 2,000,000. At that point it gets pretty chaotic.

Galactians 2 – New HTML5 arcade game

I’ve had this game kicking about for several weeks. I’ve been trying to find some time to get it finished and playable and a challenge and, well, a bit prettier than it was before.
I finally found some time to polish it up a bit.

The game itself is Galactians with a few extra bits. I always loved the diving alien thing and wanted to add a bit to it so you’ll find weird alien blob explosive jelly and a painful black homing missile to contend with. That combined with bombs, bullets and diving aliens.

I hope it’s as enjoyable for you to play as it has been for me to create.

You can play Galactians 2 here.

You can play in your browser with arrow keys and Z or CTRL to shoot, or mouse or, if you prefer, on your mobile phone / tablet.

My high score is around 1,400,000. If you beat it let me know :-)

iOS5 and mobile game performance with HTML5

When I first started creating these HTML5 arcade games I confess I had nothing to test them on. So I created my games and just tested them in a desktop web browser. Normally Chrome.
It soon became apparent that the best way to reach out to people and monetise my work was to adapt the games to run within a mobile browser.

I soon became bored of pestering friends to test my games so I scraped together some cash and bought an HTC Desire HD. A wonderful smartphone in every respect but perhaps not the best handset to choose for testing.
You see the handset is so capable it can run CANVAS based games at lightning speed. I was really no better off than when I was using the desktop.

My wife has an iPod Touch first generation. I tested my games with this for a while and assumed that the games would work first time on all iOS devices.
How wrong could I be ?

iPhone 4 is a dog. I soon realised that the CANVAS performance on iPhone 4 was considerably less than desirable. There are probably several reasons for this and generally they’re not without their fair share of conspiracy theories.
Apple throttling JavaScript performance on iPhone 4 deliberately to encourage more business through their App Store ?
Surely not.

Whether it was true or not I was left with a huge hole in my portfolio. I had these cool looking games that really only worked on anything that wasn’t an iPhone 4. Trouble is of course that iPhone 4 is one of the most popular handsets in the world. My market was a fraction of the size it could be.

To make things worse I’m really not a hacker. I guess I hold this daft old fashioned view that I shouldn’t have to hack. I’d rather the vendors sort their devices out than me hack around trying to scrape some FPS together. I’m really just terrible at that kind of thing.

So yesterday we saw iOS5 arrive. Plenty of hype about a number of cool features but not much of a fanfayre for the performance of JavaScript in the browser. A few rumours surfaced that the performance was up to 3 or 4x the performance of the current hardware but I really needed to see it for myself.

To my amazement the performance exceeded my expectations. My “slower” games; Dragons and Danger Ranger are whizzing along. All games now perform beautifully in the mobile Safari browser.
iOS5 changes everything.

I decided to put together some tests to compare raw CANVAS performance against old school DIVs and IMGs.

If you have a mobile phone point it to the two following links.
Take a look at the FPS count in the top corner. If you like comment your findings below. I’d be interested to see your thoughts and experiences.

CANVAS based animation:
DIV based animation:


%d bloggers like this: