Super Jet Boy – a few thoughts on touch-screen control and sprite presentation
Jet Boy (or Super Jet Boy to give it its full title) is a game about a boy with a rocket pack who embarks on an adventure to recover some mystical golden statuettes. High above the kingdoms of his homeworld a series of enchanted sky temples play host to an array of weird monsters charged with one simple task - protect their master's golden treasure.
Jet Boy has no special powers. For once I resisted the urge to load my game character up with bombs & lasers and throw explosions around the screen. All I wanted with Jet Boy was a simple case of learning how to control a character with a rocket pack.
Much of the work in creating the game was already written thanks to my work on Crossfire.
In that game I defined a pretty neat way of designing challenges using my own tools that ultimately spat out some JavaScript with enough data to construct a level. The logic for actually assembling that level and its obstacles and entities is elsewhere within the game's core.
I pretty much lifted most of that logic when constructing Jet Boy and adapted it to respond to gravity and bi-directional movement.
The real challenge in developing the game was in the control of the main character.
I knew that I wanted movement in all directions and also the concept of thrust to lift the character higher up the level. When no thrust was applied (either through no screen press or lack of fuel) the character would simply fall until they reached the base of the level. At this point the player would be looking for bonus ballons carrying fuel to re-enable the rocket pack.
So how do you acheive all of this without using on-screen buttons in a touch screen environment?
The obvious conflict was in the distinction between simply touching the screen to move the character and touching the screen to apply thrust to the rocket pack. As soon as I tap the screen both would apply. I may only want to shift the character from left to right in a horizontal fashion but by virtue of the fact I'm touching the screen the rocket pack would fire and the character would raise.
I initially figured this would be acceptable but the moment I fired it up it was anything but. In fact it was maddening.
So I set a new attribute on the player object that essentially ticked down to zero. At zero the character would start to rise.
It's a kind of pre-thrust thrust if you like.
The player touches the screen, the ticker is set, the rocket pack engages, the ticker begins the count down, a second or so later the ticker hits zero and there is enough thrust to enable the character to rise. If the player releases the touch before the ticker hits zero the ticker is forced to zero.
This worked quite well as it allowed for a reasonable amount of horizontal movement before the character started to rise up the screen.
To aid this I deliberately set horizontal motion to be very loose. In other words when the player slides his finger quickly across the screen the character zips left to right (or vice versa) at speed.
As usual when you implement this kind of thing to solve a problem you are often treated to a few surprises. One such surprise was in how nice it felt to have the character free-falling down the level and gaining speed through gravity, only to have that descent cut short in a smooth fashion thanks to the application of thrust. There is no fancy physics engine beneath all of this it is simply a case of fine tuning the numbers until I'm happy with the results.
Finally I would like to mention here that to achieve the smooth motion I deal a lot in floating point values. i.e. 1.2345 rather than 1. This affords a decent amount of granularity. But when it comes to drawing on the screen using context.drawImage() I cannot apply those floating point values to the x/y co-ordinates of the sprite. The result is a blurry mess of a sprite.
To combat this I simply round the figures down to the nearest integer with Math.round() / Math.floor() -- round up and round down respectively.
All of my sprites contain an 'angle' attribute so rotation occurs on each sprite regardless of whether the angle is always zero.
/* g.ctx stores the 2D canvas context, o is the sprite object, the spritesheet property stores all the sprite image data */ g.ctx.save(); g.ctx.translate(Math.floor(o.x) + (Math.floor(o.w/2)),Math.floor(o.y) + (Math.floor(o.h/2))); g.ctx.rotate(o.angle * (Math.PI / 180)); g.ctx.drawImage(o.spritesheet.image, o.frame * o.spritesheet.framewidth, o.row * o.spritesheet.frameheight, o.spritesheet.framewidth, o.spritesheet.frameheight, Math.round(-o.w/2), Math.round(-o.h/2), Math.round(o.w), Math.round(o.h)); g.ctx.restore();
(I will document my approach to spritesheeting at some point in the near future)
Sprite without rounding:
With rounding:
So that's it. The game is still very much in development and I'm spending a healthy amount of time enjoying the process of designing levels. When the game is complete it will be available through the usual portals and of course Mozilla's MarketPlace.
Adding web fonts to an HTML5 game
I take a lot of things for granted when crafting HTML5 games and often neglect sharing the little things that can make life seem a lot nicer as a developer.
One such thing is adding web fonts to a game without going across domains to get the resources.
Here's the challenge I faced: to use a fancy comic-like font for a game without going to Google's web font API. In some circumstances this has been problematic for me. So I wanted to include all the font's resources and necessary CSS within the game package.
I looked over the web for an explanation and found something pretty spot on on Stack Overflow so I'd encourage you to go read it here: Is it possible to load webfonts through the offline storage cache manifest?
Of course the beauty of doing it this way is that you can localise your text data simply.
I recently converted a bunch of games to Japanese for a client with great ease. I store all text in an array in a single file called textdata.js. All I had to ensure was that the textdata.js file was saved in UTF-8 format.
Some more thoughts on an HTML5 mobile adventure game
I'm determined to make an HTML5 adventure game so here goes with some more thoughts on the potential design of such a game.
The games that work best for me are the ones that are instantly accesible. Load assets (acceptable delay) > splash screen (acceptable and expected delay as long as it's short) > title screen / menu > straight in to the action.
I employ this with all my games and simply offer a link on more recent titles to study a "how to play" screen.
For my adventure game I want to offer something similar that allows the player to simply pick up from where they left off with just a tap of the menu.
The game itself I would want to centre around the pursuit of experience (XP) and therefore higher levels.
Combat would be a huge feature in the game as would the collection of loot. All fairly standard for an adventure game so far.
Where I want the game to stand out is in its "randomness".
I enjoy crafting structure to arcade games such that the player's expectations for what he will see in each level are always met. Consistency is key in games where the player is chasing a high score.
But with my adventure game I want the experience to persist across multiple game sessions with the player finding himself in a new location / situation every time he comes to play.
In some circumstances that situation may be a confrontation and the player's options will be FIGHT or ATTEMPT TO FLEE.
In other circumstances the situation may be designed to progress the story, say an in-game character attempts to talk or barter with you. The player's options in such a scenario are varied.
In any scenario I would aim to present two buttons on the screen at any one time - the player's actions being limited to simple A, B decisions.
Example 1 - interaction
The Inn-Keeper wants to talk with you.
[ TALK ] [ IGNORE ]
TALK selected.
The Inn-Keeper tells you a story about the fabled treasures buried within the dark castle's dungeons and guarded by the spirits of the King's fallen soldiers. -more-
[ CONTINUE ] [ STOP ]
Example 2 - confrontation
A GRUE stands before you and demands that you surrender your weapons and gold.
[ FIGHT ] [ FLEE ]
FIGHT selected.
The combat screen appears and the player must fight the GRUE to the death.
All adversaries drop loot.
I call each of these scenarios STAGES.
Stitching each stage together in a way that captures the player's imagination and moves the story along is vital to the game's success.
After each stage I would save out to localStorage all of the game's data. Asking the player to save progress seems terribly out-dated to me.
Clearly this sort of a game experience works best when the player has limited time available to play.
Pick up the phone, launch the game, complete a stage, close the phone. Next time the player comes to play he finds himself that bit further on.
Indeed changing the location is very important to allow the player to feel that he is progressing through an adventure story.
What I haven't completely thought out is how to present these stages when the player has perhaps half an hour to kill.
Although half an hour is an extraordinary amount of time to play a mobile web game it must be considered.
My initial thoughts are to use a map and have the player attempt to move between locations to unravel the story.
Another variation on that theme would see the player progressing through a randomly generated map with towns, villages, citadels and places of interest all popping up at loosly defined intervals to give the impression of a realistic world.
In a town or village the options system would change. The player would be in a safe zone so there would be no need for combat decisions.
In a "place of interest" the player would have a different challenge. Perhaps a stealth mission where the player controls his character around a maze whilst trying to avoid monsters.
If successful the player is rewarded with treasure.
In places of interest there would always be the threat of combat regardless of the underlying challenge to the player.
Another slightly more radical idea I have had is to make the game completely open-ended. No fixed goals. Simply let the player explore the world and discover new things whilst advancing his XP and level.
Still very much at the "brain-storming" stage but I'm getting closer to actually laying some code down and fleshing out the game.
I have that many concepts on the shelf just now it's ridiculous. Hopefully one of these will see the light of day soon!
Viewports and the scaling & positioning of the canvas
Having just spent a couple of hours poring over my code for scaling & positioning the game canvas I thought I'd share the experience.
Despite having made several HTML5 games over the last couple of years I've never experienced any real issues with scaling or positioning. Just recently however I've started to notice inconsistencies between browsers and OS versions.
In some cases the canvas would scale perfectly but not position properly. In other cases the canvas would not scale properly yet position well in the centre of the screen.
My criteria is simple - I want the games to be played in any orientation and to fit consistently in the centre of the screen.
Where full screen is available in either width (landscape orientation games) or height (portrait) I will also aim for that.
It's 90% there. On Galaxy S2+ and iPhone4+ portrait games load and scale to fit fine in portrait and landscape games load fine and scale in landscape.
The problem arises on iOS when the games are loaded in the wrong orientation.
e.g. if the game is a portrait game and it loads up in portrait mode then it scales to fit just fine, as you would expect. (illustration 1)
illustration 1 - game loads in portrait mode
But if the player then decides to play it in landscape it scales fine but doesn't centre correctly. Just sits to the left of centre. (illustration 2)
illustration 2 - game loaded in portrait and rotated to landscape - note white space where HTML BODY is simply untouched.
If the game loads up in landscape then it centers beautifully and is playable (illustration 3)
illustration 3 - game loaded whilst tablet in landscape mode
If the player then rotates to portrait the game scales just fine on iPhone to fit the screen but on iPad it sits rather awkwardly to the right of the screen with about a third of the content out of sight. (illustration 4)
illustration 4 - loaded in landscape and rotated to portrait
This has an impact on my regional touchEvent code that I use for driving menus and other in-game features.
I no longer present a banner message instructing the player to rotate. It seems clunky and my clients hate it.
Of course it's far too easy to suggest that as long as the games load up in their preferred orientation then surely I'll be OK.
The reality is it needs to work and work properly.
So what's my code doing?
Well surprisingly little.
I certainly don't sniff the device. It's 2013. So I don't actually know I'm dealing with iOS any more than I know it's a desktop or mobile browser.
The first thing I do is record the screen's physical width less any scrollbars.
var w = window.innerWidth; var h = window.innerHeight;
I also record the game's intended canvas dimensions.
var rw =320; var rh = 480;
Then to accurately scale the canvas I use the Math.min() method to first determine how best to scale the canvas to preserve the aspect ratio.
multiplier = Math.min((h / rh), (w / rw)); var actualCanvasWidth = rw * multiplier; var actualCanvasHeight = rh * multiplier;
Fairly simple stuff there just to keep the aspect ratio of the game's canvas intact and as previously stipulated aim for full screen in the preferred orientation.
To actually position the canvas on the screen I use CSS.
So first I've already got a handle on the canvas and stored it within my global namespace (g):
HTML
<body> <div id="game"> <canvas class="canvas"></canvas> </div> </body>
JavaScript
g.gamecanvas = document.getElementById('game');
CSS
.canvas { width: 100%; height: 100%; }
I then make sure that the canvas parent is displaying as a block level element, assign a width to it and use the margin property to centre it. The canvas fits its parent to the pixel.
g.gamecanvas.style.display = "block"; g.gamecanvas.style.width = actualCanvasWidth + "px"; g.gamecanvas.style.height = actualCanvasHeight + "px"; g.gamecanvas.style.margin = "0px auto 0px auto";
My scaling function is called every time the onresize() or onorientationchange() events are fired. It is also called at the very top of the code before the assets are loaded.
So when we tie all this together we get a perfect presentation the first time the game is loaded.
The canvas scales to fit the orientation and centers perfectly in the centre of the screen.
So why on earth do I get that "dead" area when the tablet is rotated from portrait to landscape? (illustration 2 above)
Why does the canvas shift over to the right when the tablet is rotated from landscape to portrait? (illustration 4 above)
There has to be something else to look at.
The answer lay in the META description for the VIEWPORT.
Here's what I used to present in the index.html of every game:
<meta name="viewport" content="width=320, height=440, user-scalable=no, initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
What a mess. I'd never touched this in almost two years.
Understanding the viewport is essential to understanding mobile presentation. Generally speaking the rule is if you don't understand how it works don't use it. The results can be undesirable.
Rather than go to the trouble of fully understanding what the viewport definitions are and do I decided to look at what I actually want to achieve. The answer here is very simple - a) stretch content to screen dimensions, b) suppress ability to pinch / zoom.
There is no need to specify the physical width or height in pixels of the device screen. There is also no need to restrict user scaling with the user-scalable attribute. Finally there is no need to set a maximum-scale, which I must admit I found surprising.
The only code I need here is:
<meta name="viewport" content="width=device-width, initial-scale=1">
The scaling of the canvas and positioning of the parent element within the document body are now perfect. No more "dead" regions and no more strange horizontal positioning.
There appears to be more sympathy for my lousy meta code within Android browsers than there is with iOS and Safari.
Some thoughts on player interaction with HTML5 mobile games
I currently have a number of small side projects which are for all intents and purposes simple design tests. My current focus is with establishing new, reliable and aesthetically satisfying ways to have the player interact with the game.
Basic control - Touch, slide and first-touch free movement
Initially with Wizard Wars I stuck to the basics and the game centered around tapping the screen to direct the wizard.
Subsequent games have seen simple slide left and right controls implemented to steer cars and star ships.
More recent games have seen me register the first touch and allow free movement in all directions. I like this approach and generally find it to be the most satisfying to play. Games like Crossfire (my homage to the C64's shoot 'em up heyday) and Desert Rescue really benefit from this style.
So for the most part all of my games exclusively feature one of those three methods of controlling the on-screen character.
The only time I veered from this simplicity was with Dungeon Adventure. With hindsight I'd perhaps concede it didn't work out so well and the control system took a lot out of what was a potentially enjoyable game.
Feedback and limitations
With mobile game development - HTML5 or otherwise - it's vital that the game's design is wrapped around the limitations of the touch screen control. I have never implemented on-screen buttons and don't have any plans to. It just doesn't work for me. The whole point of pressing buttons to affect the action is in the touch > tactile response > on-screen action dynamic.
For example the process of a ships laser firing in response to a button being pressed is empty without that central bit - the tactile response to the player.
Feedback in games is important to me, as is the management of player expectation. In many cases it makes a lot of sense to automate basic actions. e.g. your on-screen character automatically runs and you simply tap the screen to have him jump.
With Danger Ranger I desperately wanted a platform game experience. To achieve this I placed a jump pad at the base of the screen. As the player's on-screen character walked in to the jump pad he was thrust high in to the air. The player's only control was in sliding their finger left and right to control the character's movement.
So there are several genres that can be achieved even with the limitations of a touch screen. We just need to consider these limitations and design the game around them.
Classically of course ports of great arcade games have failed to deliver since they were designed for different interfaces. Defender springs to mind. A proper spaghetti control system if ever there was one. Not a great game to try and play on a sheet of glass.
Fusing a couple of ideas together
So moving forward with some new design ideas I'd like to try and fuse some of these touch styles together.
Initially I considered Bomb Jack as a project.
I'd always loved the game in the arcades and figured it was colourful and lively enough to translate in to a good casual / mobile game. Better still it could quite easily be shoe-horned in to my Danger Ranger code base.
The issue of course was in the control of "Jack" (I assume that's his name).
Bomb Jack (Arcade version)
So what is Bomb Jack ?
Well essentially you play the game by directing Jack around the screen with the joystick. and hitting a button to have him jump in the air. He only jumps when he's on solid ground be it the base of the screen or one of the floating platforms.
This makes things quite easy in that I will always know when he's NOT flying or falling. So if the guy is on terra firma any tap above him on the screen could be an instruction to launch him skyward.
Of course whilst he's in flight the side swiping controls still work to control him albeit at a slower rate.
For this to work there would have to be a threshold set around the character since the simple act of tapping the screen with the intention of moving him left or right is also going to fire touchStart().
Jump vs movement
A B <-- Any touch here results in a jump
------------- <-- Slide control threshold
<-- Any touch in this region moves Jack left and right
J <-- Jack's position
============= <-- Solid ground
Hopefully the crude illustration above makes some sense.
J is relative to Jack's position and the dashed line above him marks the uppermost region for touch events that result in his walking left and right.
Tapping in the A or B region will send Jack skyward to the left or the right respectively. In reality I would aim Jack to the point that the touch was registered to give greater granularity of movement.
Whilst Jack is in flight the illustration isn't relevant and any touch on the screen will drift him left or right until he finds solid ground.
Pure theory right now but so far I'm happy with it. In fact if it works I'd be happy to consider more complex platform games.
Bubble Bust and HTML5 mobile casual gaming thoughts
I've been thinking a lot about some casual game ideas just lately.
In my notebook under future reference / potential game ideas I have so many things jotted down. Games such as:
- Beach Head
- Ballblazer
- Bomb Jack
- Jet Set Willy
- Joust
- Encounter!
- Zork
...the list is about 20 long !
Zork obviously stands out here since it is a pure text adventure game. I actually wrote quite a bit of a JavaScript adventure engine a few years back. With minimal tweaking I reckon I could craft it in to a fairly useful mobile web game.
But the point here is that regardless of this list the games that I've been playing a heck of a lot just lately are bubble popping affairs. Games such as Bubble Bust ! (above)
I've always resisted these games. Figured they were just mundane and far too repetitive for my tastes.
I was wrong. The challenges are clear and tough enough to keep me coming back for more on a pretty regular basis.
I'm a huge fan of any game that contains a strong core theme and with clever design presents numerous ways to challenge you around it.
For example, in Galaxians we shoot aliens. We also have to shoot them as they dive. Galaga expands on this and forces us to time our shots when the captured fighter is being flown around.
Bubble Bust! plays with its core design beautifully. Essentially we are in the business of matching colours (3 or more in contact pops the bubbles) but of course it doesn't end there. Different bubbles presented to the player have different abilities. Bombs destroy bubbles in a small area. Rainbow bubbles can be used as a generic colour. Steel balls tear through bubbles destroying everything in their path. So on and so forth.
At its heart Bubble Bust! is a race against the clock.
As the bubble pack descends you have less time to think about your next move. The game ends when you either fail to clear the bottom most bubble before it crosses the line or when you pop the "key" bubble.
The pace of the game is high and for a casual game it's perfect.
I know there's a glut of games in this genre but of the ones I've played this one captures the excitement best.
So now I'm thinking about the whole "lots of decisions in a short amount of time" scenario and trying to apply it to some ideas of my own. Soccer, Horse Racing, Bingo ... those types of things.
What's more I want to try and honour the idea that if you fail you're left with a sense of "with one more go I can crack it". To achieve that I need to make the process of actually playing the game equal parts fun and rewarding.
It's a new direction for me. To date I've pretty much made shooters in some guise or another. With my next project I'll most likely be stood outside of my comfort zone !
Testing the latest version of my HTML5 game framework across devices
I ran some simple tests this morning across a small range of devices. I selected the most popular devices according to figures gathered by Google's Analytics. The results are in some respects quite surprising. In others (iOS' dominance) they're not.
I don't like Android for making HTML5 arcade games. I find it to be a deeply troublesome platform with all kinds of issues surrounding performance and response. But as a developer I can't ignore it.
| Device | OS | Browser | Traffic % | Drawing | Touch Response | Touch.Move Response |
|---|---|---|---|---|---|---|
| iOS devices account for approx 50% of all traffic with iPad the standout device | ||||||
| iPhone 4S | iOS6 | Safari | - | Excellent | Excellent | Excellent |
| iPad 1 | iOS5 | Safari | - | Good | Excellent | Excellent |
| iPad 3 | iOS6 | Safari | - | Excellent | Excellent | Excellent |
| Samsung Galaxy Y is the standout Android device in terms of popularity but still minimal volumes | ||||||
| Kindle Fire HD | Android 4.0 (Ice Cream Sandwich - modified) | Stock | < 0.5 | OK | Good | Good |
| Samsung GT-I9300 Galaxy SIII | Android 4.1.1 (Jellybean) | Stock | 0.89 | Excellent | Excellent | Excellent |
| Samsung GT-I9100 Galaxy SII | Android 4.0.4 (Ice Cream Sandwich) | Stock | 1.36 | Good | Excellent | Excellent |
| Samsung GT-S5360 Galaxy Y | Android 2.3.6 (Gingerbread) | Stock | 1.55 | Good | Good | Fail ! |
| LG LG-E400 | Android 2.3.6 (Gingerbread) | Stock | 1 | Good | Good | Good |
| HTC Desire HD | Android 2.3.5 (Gingerbread) | Stock | < 0.5 | Good | Good | Good |
The Samsung Galaxy S3 is a temperamental device. In almost every respect it's a beautiful machine yet it seems to let itself down with the most basic of operations.
For example, I found that clearing the screen was an issue when using canvas.width = canvas.width (the screen remained either static or simply blank)
When I switched back to the context.clearRect() method it worked fine. I'm not sure if this a true reflection of the underlying error but it's certainly a "bug" I can consistently re-create.
In some respects the screen clearing is academic to me these days. I find performance is still very high when drawing an entire screen full of background graphics. Drawing a full screen as the first draw operation on each frame is a heavy handed method of clearing the previous screen state and possibly not a best practise but for now effective.
I clearly have some problems in my code regarding the touchMove event on the Galaxy Y. The same OS on a different phone fires and handles the event without any problems.
OS Relevance
An obvious question when reviewing figures like these is "just how relevant is the OS ?"
Are the early Android OS' really relevant ? Surely Gingerbread has long been superseded on these phones.
Alarmingly the answer (according to my own stats) is not. Android 2.3.x is still by a country mile the most popular version of Google's OS to play my games.
I had very much hoped that this wasn't the case and that I could just assume that gamers with newer phones are able to upgrade and in fact DO upgrade.
I should add that on a number of the above Android devices I have Chrome and in some cases Firefox installed. All the games work beautifully in those browsers although web audio is still unsupported.
Firefox reliably supports IndexedDB fully in that it supports the onupgradeneeded() event.
Web Audio
Currently in the above scenario only iOS6 fully supports the HTML5 audio API. Interestingly the Kindle Fire HD passes all the tests for web audio support yet fails to play any sounds ! I've asked the question at Amazon and am waiting for a response. I can't see any obvious glitches in my code but I will continue to pore over it.
Conclusions ?
I'm not sure it's fair to draw any real conclusions from this short test.
All in all it was quite a satisfying little test if only to reassure me that the fact that these games run well on iOS is providing a great experience for the largest section of my user base.
Given how far we've come in 12 months I'm pretty sure that the top 10 phones in my analytics this time next year will perform all of these features beautifully and as HTML5 game coders we can just get on with making great games ! :-)
New HTML5 game for Christmas – Rocket Santa
I've enjoyed playing with my game framework this past week or two since releasing Crossfire. A few bug fixes and tweaks and I'm once again in a pretty good position for making new and original games in a timely fashion.
Something I've always wanted to produce is a Christmas game. Something with snow, Christmas trees, pressies, snowmen, elves and of course Santa (Father Christmas to us English folk). I also wanted to produce it pretty pronto as I've at least 2 more projects that I want to undertake before 2013.
So I took a look at a previous game Danger Ranger and took to adapting it to fit the new framework.
It's amazing how satisfying and strangely warming it is to have snow tumbling down the screen !
The game is now complete and available to anyone wishing to licence a fun and colourful HTML5 Christmas game with a funky soundtrack and lots of other cool features :)
Initial thoughts on an HTML5 football (soccer) game
I'm looking at producing a football (soccer) game for my next project. Looking around at the world of football in computer games is a pretty interesting exercise.
Thanks to sites like YouTube it's not so difficult to perform quick comparisons between games from a variety of different platforms.
See for yourself what I found over a coffee break earlier today.
World Cup 90 Sega Megadrive
Versus Net Soccer Konami Arcade
Cyberball Not sure which platform - cool portrait view
American Football game - cool portrait view
Beautifully presented N64 J-league game
Excellent execution. Non-fluid game.
Neo Geo. Say no more. Beautifully presented.
I included some of the non-Soccer games to highlight their presentation. I typically like to produce games in a portrait orientation so the Cyberball game was particularly interesting to me.
As a huge fan of football myself I can say that the thrills of the game are in the attacks. The faster and more precise the counter-attacks in a game the more thrilling it is for the spectator.
I want to build a game that captures the very best parts of a football match. To that end I may well ditch the standard approach for making such a game in favour of purely concentrating on the arcade thrills of attacking football.
Throw-ins, corner kicks, offside.. they're all pretty dull to an arcade gamer.
One idea that I've had is to start each as a set piece where the player has to defend a free kick. If the attacking team scores then the set piece is reset and the player must defend again.
If the set piece breaks down and the ball goes out then the stage is reset and again the player must defend.
If however the set piece fails and the player obtains possession then the thrill of the counter attack ensues.
I like simple controls so initially my thoughts are to tap left, centre or right on the screen to direct the goalkeeper when in defensive mode.
In counter-attack mode the AI for the advancing players will be handled by the code such that the player simply taps the screen to pass the ball. The theory is that the player taps ANYWHERE on the screen and the code will select the nearest team mate to pass to.
Once the team player with the ball moves beyond the overlaid 20 - 25 yard line he automatically shoots.
This is very much a dumbed down approach but it currently works for me to think like this.
I'm a huge fan of simple controls and simple execution.
New HTML5 game – Crossfire
My latest project - the Commodore 64 inspired Crossfire - is complete.
I used the project to refine my HTML5 game framework and to also try out some new functionality.
I'm thrilled at the resulting game and look forward to adding to the framework with subsequent games.
Crossfire is set to a scrolling landscape that (loosely, very loosely) resembles a Death Star style trench as viewed from above.
You control 3 fighters and are tasked with blasting countless formations of alien fighters whilst dodging numerous obstacles, bombs and cannon blasts. (Extra lives are available with progress)
The game is played at a fairly slow speed to allow for some fine-tuned movement and to also add to the amount of on-screen action.
Every couple of waves you get to challenge your reflexes with a challenge stage. These stages are played at a much faster speed and are very very tricky !
If you survive the challenge you will be met with a much harder stage the next time around.
For the super starfighter there is the opportunity to have your name in lights as Crossfire stores high scores locally to your device.
Note: Currently on mobile I could only find support for the high score table (courtesy of IndexedDB) on Firefox for Android. But I am sure that this will be supported across the board very soon.
The game will be available to play shortly on PlayStar.mobi and also Mozilla's MarketPlace.
If you are interested in licencing the game and would like a closer look please don't hesitate to drop me a line at wilcom1970@gmail.com
