Targets and thinking like a casual mobile gamer

I have a number of targets for this year with Space Monster Games but crucially I have one goal that stands out above all others; grow traffic to Playstar.

Playstar logo

The current visitor count stands at around 250,000 a month. I’m happy with that but I want to double it by January 1st 2015. What’s more I want to double it organically. i.e. not spend money promoting the site.

I noted a few points down relating to my targets that I thought might be worth sharing here.

Get a better spread of traffic sources

Just now I take regular traffic from a few sites. Referral figures run at anywhere between 40% and 60% daily. I have always assumed that the remainder have the arcade bookmarked but I suppose that Google’s Analytics script simply doesn’t have enough information to determine a source. This could be for a number of reasons.
I’ve often wondered, for example, what the effect of launching the site from within an embedded browser inside an app might return. I’m guessing that it would be returned as direct or not set since there’s no referring URL.
Either way it won’t do any harm to promote the arcade organically and be visible on a broader range and number of related sites.
Which leads me nicely on to…

Improved Page Rank

Playstar is a new site. It’s been actively maintained for less than 6 months. In that time I’ve used all the expected methods of communicating its existence via social media including Facebook and Twitter. But predictably its ranking within Google is low. Around 1/10.

By the end of 2014 I’d like to see that up at around 4/10.

How will I do that? This is of course the million dollar question. How on earth do you increase your Google Page Ranking for a mobile web gaming site?

Well I’ve pondered this question over and over and ultimately I arrive right back at the beginning. There is no magic solution specific to promoting a mobile web gaming site. It is after all just a web site. So to succeed I simply promote it as I would any other web site.

Demographics

Where and how I promote it warrants a little more thought.
I sometimes try and visualise my audience. Right down to the person.

  • What do they look like?
  • Where do they live?
  • What is their employment / education status?
  • How old are they?
  • What budget do they have?
  • What are their interests?

In an attempt to flesh this out a bit I’ve attempted to become my target audience!

What does a mobile gamer (never mind the web bit for now) do to find games to play?
Well this really does depend upon an array of things (including but not at all limited to):

  • Handset used
  • Budget
  • Internet connection / reliability
  • Demographic

The analytics collected from Playstar thus far inform me that the majority (60%) of visitors are male and aged somewhere between 16 and 36.
They are also casual / hardcore gamers, savvy parents, photography enthusiasts and petrol heads!
OK, so good luck targetting that audience with a single strategy. Google’s assumptions based algorithms for determining this data are simply not reliable enough.

To get inside the head of a typical mobile gamer it’s probably more reliable to collect a few handsets and go looking for games. Free games. The word FREE is key here.

Freemium

Annoyingly In App Purchasing (the freemium model) has taken off in a big way. This essentially renders games free at the point of download and in many cases the gamer gets a satisfactory experience without spending any cash. This of course means that a gamer looking for a free game can simply head to an app store and sniff out a freemium game. Their first port of call being the app store means that they are potentially less inclined to use a search engine to find a free game.

Competing with the countless millions of app store games is not for me. Besides I want to crush the app stores and drive everyone toward browser gaming!

But am I missing a trick here? Why not use the app stores? Why not submit my games to the app store as a means of promoting the arcade. The “footfall” through the app stores is huge. Even 0.01% of daily app store traffic at least seeing a screenshot of my games might warrant further investigation.
I could offer the games for free such they they stand a better chance of download and then splash my branding all over them in the hope that the gamer will take the next step and go visit the arcade.

Why visit the arcade when they can just launch the app I hear you ask?
It’s a good point but the arcade is more than just a bunch of games. Its feature set is growing and is largely based around high scores and achievements. This functionality wouldn’t extend to the app store. It would be important to stress that point.

As positive as this sounds it still seems like fishing with a crude wooden stick and a piece of string in a lake the size of Australia.

I’m brought back to search engines; where the same analogy could of course be applied. I just feel there is a little more control with the search engines.

Search Engine Optimisation

Encouragingly there is obviously a hunger for free games.

Surely these gamers are willing to play anything. And that must include mobile web games.
Naturally therefore there must be a significant volume of gamers using Google to search for “free mobile games” or “free online games”. Not necessarily “free mobile web games” but that will change with time.
The challenge here is in making my “free mobile web game” site stand up alongside the “free mobile game” options returned in Google.

SEO best practices essentially point to a couple of strategies:

  • Keep talking about your site (via all means)
  • Share your site with as many people as you can

It’s certainly not going to do any harm and to this end I have a blog and social media accounts. I’m less inclined to litter forums and blog comments with drivel purely to get links as I think it devalues the brand. But is this the right approach?

If I were a gamer looking for free games what would drive me toward a mobile web gaming site? Who might I be?

  • A disillusioned iOS gamer used to Flash gaming in my PC’s browser?
  • The frustrated owner of a cheap handset with an assumption that nothing will run because it’s so terrible?
  • A novice who simply taps “free games” in to the Google box that sits on the home screen of Android devices?

This kind of thing intrigues me. To properly reach out to a potential mobile web gaming audience I need to think and behave like a mobile gamer.

Education

There is of course another approach.
Rather than waiting for the world to catch up with the notion of mobile web gaming, tell them about it.
Stand out from the crowd as somebody who is an authority on mobile web gaming. Not just a gaming portal but an innovator. A designer, developer and arcade owner.
There’s some merit in this but what would concern me is that it places a direct relationship between the developer and the arcade; the technology and the fun.

I would really want the arcade to stand out as a pure means of escape without linking it directly to the nuts and bolts that go in to its production. As a boy playing Space Invaders et al I couldn’t have cared less about who designed the games and how they made it in to the arcade.
But in this age of maximising web exposure it’s important to play to your strengths. This blog is as much of a weapon in that sense as the arcade and its games.

Conclusion

Drawing conclusions from all of this is tough but one thing has emerged that I will take on board.
I need to be the gamer. I need to actually become the audience.
To this end I need to ditch using an iPhone 5s as my daily phone and walk around with a Samsung Galaxy model for a week or so. Samsung devices are by far the most popular handsets visiting the arcade.
I’d probably pick a low to mid-range Galaxy phone running a minimum of Ice Cream Sandwich (4.0). An SII perhaps.
I’ll treat it as my main phone and source of all mobile gaming. I’ll set my budget to zero and at every point I want to play a game of some kind I’ll shun the iOS devices in favour of the Samsung.
It will be hugely frustrating initially I’m sure but hopefully will yield some interesting results.

All comments, suggestions and opinions welcomed.

Road Rage – New HTML5 arcade game

Road RageRoad Rage is finally complete.

I put a lot of work in to this one in terms of balancing the action versus rewarding the player with plenty of on-screen action.

I’m not really in to doing post-mortems on my games but for this one I’d say it’s come out pretty close to how I envisaged it. I made a decision early on to keep the pace up and allow the player a fair amount of freedom to move and blast things. To that end I litter the screen with explosions, bombs, bullets and debris.
I’m hoping that it’s well received enough to justify the extra effort :)

Ultimately the question of “is it fun?” has to be answered and I’d have to say that the feedback from testing that I’ve had is extremely positive. Most of the comments returned highlight the soundtrack, audio fx and big colourful sprites. I’m thrilled to read such encouraging comments since it pretty much underpins my ethos for making games. It’s certainly something that will carry over in to my book.

Road Rage

You can play the game over at the arcade. Sign up, sign in and shoot for the top spot. Let’s see how good you are!

Analysing the Playstar Arcade – Gingerbread (Android v2.3.6) visits

As the month draws to a close I’m enjoying poring over the visitor statistics collected through my Playstar arcade courtesy of Google’s Analytics.

The figures are interesting in terms of growth but a little depressing when I see that under closer inspection there’s a significant percentage of traffic who don’t get the full experience.

Take a look at these charts.

November 2013 - 171,462 visits

November 2013 – 171,462 visits

This chart stands out for the high percentage of visits from devices loaded with the Android Gingerbread OS version 2.3.6. Gingerbread, the 2.3 range OS from Google, is notoriously clunky for HTML5 game execution. It’s not without its functional issues and is typically the OS that comes bundled with popular lower spec models such as the Samsung Galaxy Y or Galaxy Ace.

28.6% of 171k visits is a lot. Too much. It pains me that so many people would come to the arcade and not get the experience that I want to deliver.

99% of my traffic is mobile.

The 21.1% listed as other is a mix of Android, iOS and Firefox. iPad emerges as a popular device.

December 2013 - 235,758 visits

December 2013 – 235,758 visits

December is a month that traditionally skews the figures since it contains the Christmas holiday season. I have over the last few years experienced a marked spike in traffic to my games in the two weeks that typically constitute the Christmas break. This Christmas was no different.

Although the figure of 23.6% is a reduction on the previous month for Gingerbread users, it’s still high.

As mentioned in a previous post iPad increases in strength but still falls under the category of other.

January 2014 - 255,601 visits

January 2014 – 255,601 visits

So on to this month. Obviously I’m posting this with a full day’s worth of data to collect. I imagine the total # of visits will be closer to 262,000 based on the pattern over the last 30 days.

Gingerbread’s presence is still a little ominous although less so than it might have been. 22.2% of total visits is still a reduction but a small one. Moore’s law has to kick in at some point and the public will surely all be holding a minimum of Galaxy S3 in their hands soon!

It’s thrilling to be at a quarter of a million visits per month. It’s also thrilling to see so many high end devices visiting the arcade. The purist in me really does care for the owners of those low end handsets but at some point I know I have to let go.
I’m not such a purist that I’ll invest countless hours of time and money ensuring that my games work perfectly across the board. I am after all always keen to continue producing fast paced, action packed arcade games.

 

 

Some Friday data from the Playstar arcade

Over the last six months I’ve paid a lot of attention to the visitors statistics generated by my HTML5 game portal. Particularly interesting are the figures for iPad.

The rise in popularity of the iPad as a mobile web gaming device is wonderful news. iPad is an HTML5 game developer’s dream in many respects. Super fast performance and a beautiful display. I have in the past had issues with the way that my spritesheets were rendered on iPad. Specifically pixels from neighbouring frames glitching intermittently in the animation loop. The same code on other iOS devices didn’t present the same anomaly. On later models this is fixed.

iPad is not the leading device to visit the arcade. That honour (of the identifiable devices in Google Analytics) goes to Samsung’s Galaxy Y handset. By contrast a fairly terrible device to develop for.

Here are the figures for iPad traffic.

Month (2013) % of portal traffic # iPad visits
July 1.82% 4,031
August 1.8% 4,492
September 4.1% 9,062
October 4.3% 11,985
November 7.56% 25,539
December 11.48% 48,885

Christmas certainly helps. I imagine that iPads have been a popular gift globally. As you can see the holiday season also presents a significant increase in traffic.

Adding dynamic tweet functionality to HTML5 games

My current focus is with the PlayStar Arcade. I’m keen to push it as a platform for playing my HTML5 games. A lot of work has been carried out “under the bonnet” as we say in the UK and now I’m in to the slightly more entertaining areas of adding bells and whistles.

Something I was always keen to pursue was the ability for players to share their scores via social media. Twitter was my first port of call.
Thanks to their Tweet button script placing a button inside the game was a fairly simple exercise.
The flow that I wanted would see the player complete the game and reach the “GAMEOVER” status. At this point I would present the <div> containing the Twitter code.
The player would then be prompted to share their score and tap the Twitter “Tweet” button. All I had to do at this point was switch the text inside of the code that Twitter gave me with my own text. This replaced text would be what appears in the dialogue box for the player to tweet.

tweet score from html5 game

But there was a problem.

The attribute that I need to change to achieve this is the data-text attribute of the <a> tag in the Twitter script. But dynamically changing this attribute proves useless. 

When the Twitter script executes it converts the <a> tag in to a <div>. Any subsequent calls that I make to amend the tag fail.

I appreciate that this is largely theory so rather than post my own code solutions I’m going to link a site that covers it neatly with code examples.

http://tumblr.christophercamps.com/post/4072517874/dynamic-tweet-button-text-using-jquery

This guy had the exact same problem and solved it beautifully. 
I now have the ability to let the player complete a game, rack up a score and then share it with the world courtesy of Twitter. Facebook is next.

Road Rage development update

In wrapping up the development of Road Rage I hit one or two snags. This annoys the hell out of me since it is largely due to big holes in the game’s design.

I’m a designer who likes to have the core stuff ironed out long before I get my hands dirty with code and graphics. The central mechanics of the game are the first thing I figure out and everything else gets built around it.
For Road Rage the central theme is the winding road that shifts at pace beneath the action and provides a rapidly changing restriction to the player’s movement. If the car veers off-road it incurs significant damage.

HTML5 arcade game screenshot

This all worked out well initially. I’d used the code base for Spy Chase as a foundation and built upon it with layers of activity. The problem was that the game was actually far too easy to play and I wasn’t willing to compromise any of the design features. 
The road movement look neat, the laser fire from the player’s car worked well, the missile fire from the enemy looked great and the explosions and special effects all added a wonderful depth to the game. But it was just too easy.
The player’s movement was limited but fairly swift in the x axis and his laser fire was rapid. This I liked. Everything played out smooth and it felt like the most complete arcade game I’d ever made. 
Injecting the time limit was a late addition and it really intensified the challenge. 

Then it occured to me that the fundamental issue was with the player’s ability to shield damage from bombs, cars and the off-road. This increased the player’s chance of survival through to the health regenerating Checkpoint between stages. 
I played with a few different means of punishing the player and settled on a single hit from a bullet or missile destroying the car. Bumping other cars and trucks took a small amount off the player’s “health” (pretty vital as bumping is a key feature in the game and a fair bit of fun) and running off-road added larger amounts of damage. I didn’t want to destroy the car for veering off road as in some cases it’s unavoidable. Better to add damage and encourage the player to return to the road at the earliest opportunity.

So the game dynamics are now set such that the player avoids enemy fire at all costs and shifts left and right to collect, dodge and shoot. So much so that you could pretty much remove the road and backdrop and it’d play out like an old school shoot ’em up. 

I think the game is a huge amount of fun and faithful to the arcade game designer’s ethos of short, challenging and intense fun for your coin. Hopefully it will encourage a high percentage of replays!

Road Rage will find its way to the PlayStar Arcade in the next week or so.

Using Google Trends to gauge the popularity of mobile gaming related search terms

Google offers a pretty neat trends service that attempts to illustrate the popularity of search phrases over a given period. I’ve been having a little play.

Here’s a few quick charts using some reasonably obvious mobile gaming related search phrases illustrated over the past 12 months. The use of the word Free is my own assumption that the world at large wants everything for nothing!

1. Free Mobile Games, Free Online Games, Free Arcade Games, Free Online Arcade Games

Google Trends

I removed the word “Free”:

2. Mobile Games, Online Games, Arcade Games, Online Arcade Games

Google Trends chart

Hardly a dramatic change.

3. Mobile Games, Online Games, Arcade Games, Online Arcade Games, Free Games (link)

google trends chart

Just for a bit of fun I added the straight forward search phrase “free games” in to the mix. A popular search phrase. No real surprises there.
Hardly scientific but an interesting way to spend a coffee break.

A selection of screens from my new HTML5 arcade game – Road Rage

I intend to complete this game very soon. I confess I’ve got a little carried away adding some special effects with sprites. The shards of metal that fly away from the damaged vehicles when struck with a missile or gun fire were just too tempting to resist.
I spawn them in the game with random trajectory, speed and spin rate. The effect is pretty neat. For the most part the metal shards whizz off the screen but occasionally you get a slower shard that just ambles off screen with a slow spin. It really adds to the impression of blasting everything to pieces. Hope to have the game completed over the Christmas break in time for new year.

9HTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshot

The importance of quickly proving a game concept with JavaScript

I have what I’m sure is probably considered a primitive style of coding JavaScript. It’s never really evolved in to anything that a purist would adopt over the years. To be frank it doesn’t concern me. What’s most important to me is that I understand my code and more importantly perhaps; it works.

The benefits of knowing my own code and the intimate relationship that I have developed with it have time and again proven useful. Not least when I’m approached by clients and 3rd parties to implement their own code and / or extract data from the game. Simple modifications and tweaks are simpler because I know my code inside out and the upside to all of that is of course that such changes are quick. Or at least quicker than they would have been if I’d had to first figure out how the code works.

There’s another huge benefit to writing and understanding my own code which for me comes in to its own when I’m considering a new game. I often daydream about a game or take inspiration from the most random things. I’ve got sketch books full of ideas and documents on my computer full of code snippets and high concepts.

HTML5 arcade game screenshot

To try and explain I’ll briefly explain the process of developing one game.

Some time last year I was driving home after a long journey across country. Not too far from home I remember pulling off the motorway and as I approached the traffic lights on the slip road I watched the striped yellow lines on the road. As I slowed to stop I remember clearly thinking how cool it would be to create a game in which the player controls a jet fighter that flies low over a striped landscape. Inspired by the illusion of the lines cascading beneath the car I turned over in my mind how the code might look. It didn’t take much to figure it out and that game turned out to be Distant Orbit (pictured).
I could prove the concept quickly because I knew how to adapt my code base to implement the stripe objects that form the planet floor. Better yet I visualised the game loop and could understand how to scale the alien bugs as they emerged over the horizon. There was nothing overly complicated in it and using the same approach I could quickly implement the tower that forms the player’s primary target in the game. The thought processes in understanding scale rates and how to manipulate such events per game “tick” came to me pretty quickly and because I understood the underlying code that handles the drawing and moving / scaling of objects I knew pretty much how the code would look.

What’s valuable to me is being able to take a concept, process it in my mind (and therefore visualise it on screen) and then move quickly in to code. It’s only by being able to do this that I can quickly dismiss an idea or take it to the next step – design. I like to have one quirky feature per game:  striped floors, scrolling terrain, 3D trench, starfield; and it’s generally this feature that I’m focusing on at the concept stage.

Much of this is always done using “defaults” for sprite art and defaults for audio. All objects have default behaviours as sprites in my code and adapting them to behave differently is 5 minutes work. At least to prove the concept. Fine-tuning can happen much later on as part of a balancing process.

So in short it’s crucial for me to be able to very quickly get in to coding. When I have a vision for something I spend a short amount of time poring over the approach that I’ll take and then it’s all about cutting code.

In future posts I’m going to break with my own tradition of not sharing my code. You can see for yourself just how ugly code can render some pretty cool looking arcade games :)

Balancing the action and using a classic for inspiration

Designing HTML5 arcade games with JavaScript has become something of a theraputic exercise. The combined thrills of pixelling, coding and designing the various elements of the action are proving to be quite useful in the stressful run up to Christmas.
Yet despite this I now find myself in that unavoidable “crunch” mode on two projects. I also set a target to finish these two projects by the new year.

A laugh at it now but I shelved my first project as it approached completion to pursue a fresh project. It was of course a diversion. I was deliberately avoiding the pain of that final 10% that takes an agonising amount of time to complete. Now I have doubled the pain!

It’s not all bad.
The discipline of developing arcade games has evolved and tightened over the years to become almost formulaic. This in itself isn’t always a good thing but it can be useful to have a blueprint for design when it comes to balancing, testing and code fixing.

For the most part at this stage I find that the raw code is cut and I’m largely playing with numbers. I play the games A LOT and talk to myself as I’m running through them – always making notes. Here’s such a conversation :)

There’s just not enough to challenge me here. The player character moves too quickly to be threatened by the bad guys. The bad guys need to target the player more. There’s too much room to move. The player isn’t developing any skills in his movement and bullet / entity dodging!

I kid you not. This was a recent note I took.
The beauty of all of this is that everything in the game is defined by numerics. The player’s movement is defined as a speed parameter that allows his co-ordinates to increment each tick. Similarly the other objects in the game perform against the same calculations. In the driving / shooting game (which I currently call Road Rage) the room in which the player has for movement is defined by the road object’s width and height. I applied a .nextthink attribute to the road container which ticks down every game tick. At zero I make another decision on how to scale and move the road.
With this method I can shrink or expand the road with ease after an elapsed amount of time. As a result of my testing and observations above I could see that the road needed to narrow more frequently. The player’s car going “offroad” results in a lot of damage and consequently Game Over so a shrinking road is a real challenge to the player.

HTML5 arcade game

As you can see in the screenshot the road is divided up in to slices. Each “slice” is an object that contains parameters for the ground texture, the road, the road’s verge and the lines that run down the middle.
The only artwork on display per slice is the ground and verge. The other two elements are solid colour blocks.

The tree decorations that overlay the ground are sprite objects and behave in a default sprite behaviour. i.e. emerge off screen, run the length and disappear without any collision detection.

Developing the shifting road wasn’t really much of a challenge. You could almost imagine the process as a series of around a dozen rectangular cards placed in order. By altering the x position of each road object as it is spawned off the top of the canvas (and subsequently allowing the object to increment its co-ordinate) you can create a satisfactory rippling effect that simulates the shifting road. The road width (the solid colour area) is known and therefore I can plot x co-ordinates for the overlayed verges.
Similarly any sprite object that sits on the road can be tested to see whether it has over-run the verge in which case I apply damage to it. Too much damage and it is destroyed. The impact on the random military vehicles in the game is a key part of the appeal as the player’s gleaming red sports car (modelled on a Ferrari 458!) can bump them off the road with a few well timed swerves in the right direction :)

For a long time in the early days of development I was playing the game and struggling to find a core mechanic for it. That vital element of the game that forms the player’s goal or goals. I knew that arming a sports car with rockets and allowing it to shunt other vehicles off the road would be fun, but as always I wanted an intensity to the action that meant there would be a ton of rockets and bombs on the screen. This can cause design problems in terms of setting a challenge since firing a huge amount of rockets and lasers only works if the stuff you’re aiming at is destroyed! It’s no good if the targets just bounce around a bit and are unaffected by your gunfire.

So I dabbled with all sorts of mechanics including collecting valuable items and avoiding oil slicks. They just didn’t work. The thrill of the game is in its pace and causing the car to spin or forcing the player to swerve and collect items just didn’t add up to very much fun. It needed to be a high octane experience with shooting, dodging, turboing and explosions set against an underlying need for speed.

So I fired up Out Run for a little inspiration. A wonderful game from the 1980s in which you drive a car at speed across an undulating terrain whilst avoiding other road users. The game is divided in to stages such that when you cross a checkpoint you are rewarded with a little more time to play.
This did it for me. It was obvious. A game in which you drive a car has to be a challenge of beating the clock.

I could still get away with blasting the bad guys I just needed to ensure that the core goal was to complete each stage in a set amount of time. Adding a timer was simple. I set it to 30 seconds initially and ticked down every second. At zero the car exploded and the game was over.

So the next question was how do I speed the car up and slow it down without having specific controls overlaid on the touchscreen.
This was a no-brainer. I implemented a turbo accumulator. The destruction of cars and military vehicles spawned turbo collectables that bounced around the screen. By collecting several of these the player built up their turbo bar sufficiently to engage a short (10 second) turbo mode in which the car’s speed doubled. The faster the car the quicker the player zoomed through each stage. So there was plenty of incentive for the player to destroy the other vehicles and go collecting the turbo shards.

But this wasn’t enough of a challenge. I wanted to add an element of dodging to the game so I stuck with the idea of the other vehicles launching missiles at the player. One hit and the car was destroyed! Unlike off-road damage or bumping the other cars, missile damage didn’t reduce the player’s “health”. It just wiped them out.

So I’m now confident that I have the game that I was after. As I play it now it’s pretty close to the original design and with the injection of the pulsating soundtrack and over-the-top sound effects I think it’s easily the best arcade game I’ve made to date.

I look forward to sharing it within the PlayStar Arcade shortly.