Flash Monkey is moving to New York!

1 Comment 13 February 2012

Ever since I was a kid I’ve been drawn to the New York, probably because it’s so romanticised in American films. However, it wasn’t until the end of last year that I finally made a trip over to the Big Apple to visit some friends, one of which had recently started work at Fi.

I’ve known about Fi for many years due to the amount of awards they have won and the brilliant work they continuously produce. More recently they have started to focus on creating cool HTML5 stuff and have amazing clients like Google and HTC. So I thought while I was over in NY I’d send them my CV and see if I could wangle a position there. Much to my delight, they gave me a job! A big thanks must go to my mates Chris Sainsbury and Darcy Clarke for passing on my CV and getting me through the door for an interview.

I’m very excited about joining such a great company and working with some great developers. I’m due to fly out and start my new job in mid March so I have a few weeks to relax (and maybe do a bit of coding!) If you’re a reader of the site and live in the city please send over an email, it would be great to hear from you.

I also want to say a huge thanks to Specialmoves who I have left in pursuit of the American dream. It really is a great company and even though I was only there for a relatively short time I learnt loads and made some great friends. I’m sad to be leaving such a great company prematurely, but really excited about my new adventure with Fi in New York.


Posted in Employment

HTML5 Collage Creator Prototype

Leave a comment 9 February 2012

I’m still relatively new to using JavaScript and CSS extensively and I’m learning new stuff every day. The benefit is obvious – I’m getting better at it. The bad thing though is that every time I create something new it sort of makes me a little embarrassed of the last thing I made.

That is sort of the case with this one. I made this at the end of last year and intend, at some point in the future, to further develop it into a really nice little app that will dynamically take any image and create a collage with it, much like my original flash version I made a couple of years ago.

For now though this is just a prototype, a proof of concept if you like. The data is hard coded (generated from the flash version) but the images are loaded from Flickr and I have the interactive side of it working nicely (click an image to zoom into it).

All the transitions are done using CSS transforms and simple easing algorithms in JavaScript. It works pretty well on mobile devices too. I’ve had it running smoothly on an iPhone, iPad and a couple Android devices. Go ahead and play around with it here.

All the code is commented so check out the source, although like I said I’d probably do things very differently if I was to write it again.



Posted in CSS, Experiment, HTML5, JavaScript

SWFAddress not updating on a Mac

Leave a comment 4 February 2012

At Specialmoves we maintain a very large multi-lingual Flash site for a luxury brand. As part of a recent update we noticed that there appeared to be some issues with the url and title of the browser not updating. It was only certain pages and happened in most languages. The problem became even stranger when we realised that it was only happening on Macs.

After a little debugging I soon found the issue. SWFAddress actually does a check to detect the OS and calls JavaScript functions differently on a Mac. On Windows (and other Operating Systems) SWFAddress uses ExternalInterface to call JavaScript functions. However, on a Mac it sends a string of JavaScript to the browser by using NavigateToURL.

Why the difference? I’m not sure to be honest but I presume it may be something to do with making multiple calls in quick succession with ExternalInterface.call() not working in some browsers on a Mac? That’s just a guess though and I don’t have time to do tests and find out the definite reason. The difference is mentioned in this old blog post on the Asual site but there is no explanation given why.

Anyway, back to why it was not updating on certain pages for our site update. The issue was that some of the translators had accidentally added a carriage return to the title on some pages. Probably caused from copying and pasting from an Excel or Word document. This carriage return was fine when using ExternalInterface but using NavigateToURL it meant the JavaScript was not valid and therefore never gets called.

The fix was simple, I changed this line in our code:

SWFAddress.setTitle(browserUpdateVO.title);

to this:

SWFAddress.setTitle(encodeURI(decodeURI(browserUpdateVO.title)).split("%0D").join(""));

This removes any carriage returns and ensures the JavaScript will be called successfully.

I think this is perhaps a little flaw with SWFAddress. Sure we developers should ensure we’re sending a title or URL without a carriage return. However, there is no way that the JavaScript will work with NavigateToURL if it contains a carriage return, so I think it wouldn’t hurt for there to be a little check within SWFAddress. I have contacted Asual and suggested this for the next code release.


Posted in ActionScript

Some thoughts on the future of Flash

1 Comment 29 January 2012

It’s that time of the year again when people write off Flash saying this year really is the end of flash with HTML5* taking over the world. I’m not so sure and here are my thoughts why.

Regular readers may have noticed over the past year or so an increase in HTML5, JavaScript and CSS experiments on this site and a lot less Flash. In fact I will soon be officially changing my day to day role to work almost exclusively with these technologies and much less (if at all) with Flash. More on that sometime soon.

However, my reason for jumping the Flash ship like Captain Schettino is not because I think it is going to sink and this year everything will be done in HTML5. I’ve been working almost exclusively with Flash and ActionScript for over 7 years now and I feel like it’s the right time for a change. It will be nice to add some new feathers to my programming hat and I will definitely sit more comfortably at work knowing I have more languages to call on to solve problems.

I don’t think it’s all doom and gloom for Flash though, in fact I believe Flash leads where HTML follows. Sure you can do a lot of stuff now in JS/CSS that you used to only really be able to do effectively in the browser with Flash; but Flash is still moving forward and you only have to look at audio stuff to see that. AS3′s SoundMixer Class enables you to do all sorts of cool stuff with audio (for example this from trioptic) whereas HTML5’s audio tag still has some short comings. This article about the recent HTML5 Cut the Rope games explains more. Let’s not forget the HTML5 specification is still a working draft and 2014 is the target date for recommendation by the WC3.

HTML5 specs have to be agreed upon and implemented across many different browsers and platforms and even then there will always be some differences and quirks. Flash can move much faster as it’s only one platform, and in theory should work the same across all browsers.

Another big plus for Flash at the moment is the ability to compile for different devices such as iOS and Android using AIR. I recently had to give some rough costings for a Mobile app to run on multiple operating systems (despite having never built such an application) and recommended AIR as a potential platform to develop in. I’m sure there are some issues with using this technique, possibly like similar technologies such as appcelarator suffer from, but it seems like it could be a good option.

I think consumers don’t really care what technology is used as long as it works. The only people who are getting excited (or scared as some Flash Devs I know) about HTML5 are us Developers. Imagine Joe average Internet user viewing my recent Pacman demo – they would think it’s pretty crap really, and maybe rightly so. They have seen amazing 3D Flash games so why would they care about a rubbish 2D prototype just because it runs in the browser on an iPad.

Also, do we really need browser games on iOS with the app store already offering so many great games? Although, maybe that’s not the point. I think in the immediate future HTML5 will be mostly used for UI stuff, replacing Flash for user interaction stuff like the simple example I created below.

Anyway, I’m really having fun using JavaScript more and more. Sure it has it’s quirks, and can at times feel like a step back from AS3. But it’s interesting seeing what you can do in a browser without a plugin and overcoming new challenges JS throws up for me. Every JS project I work on I feel like I’m learning loads and it’s an exciting time.

It’s also nice not having to compile a SWF every time you want to make a little change, pressing cmd+R is so refreshing. I’ll leave it on that poor joke – all comments from Flash devs who are moving in the same direction as me, and also those not, are really welcomed as always.

* To quote Richard Davey from his recent blog post about HTML5 Games (well worth a read) – “When I talk about “HTML5” I’m doing so from the popular media use of the word, rather than the technical one. On a technical level HTML5 is of course just a specification for a mark-up language. But the media has chosen to use the term as an umbrella, spanning lots of browser related technologies…”


Posted in ActionScript, CSS, HTML5, JavaScript

CSS & JavaScript Pacman

12 Comments 29 November 2011

Anyone who has been on this site recently will know I’ve been playing around with a lot of little JavaScript and Canvas experiments. I’ve had fun porting some of my old Flash stuff over to Canvas and some of them have generated a fair bit of interest with my HTML5 ColorWall featured on Chrome Experiments (go and vote for it!) and my Simple JavaScript Physics post getting a lot of hits.

One thing I’ve found frustrating is how poorly these experiments run on iOS, especially before the recently released iOS5. Apple are against adding web plugins, such as Adobe Flash, to their devices claiming people should be using HTML5 tags such as Canvas. However, constantly clearing and re-drawing to a Canvas element on an iPhone running iOS4 gives you about 3 or 4 fps (it’s slightly better on iOS5 but still not good enough to write a game).

I then stumbled across this article on Seb Lee-Delisles site about a JavaScript hack day they held at Plugin Media where they made the infector game using CSS and JavaScript to see if they could get a fast browser game running on iOS. Inspired by this and wanting to learn a bit more CSS/JavaScript I decided to try putting my own game together using the same techniques. This post will explain how I went about it and stuff I learnt.

Before I continue I should mention that this isn’t a full version of Pacman, it’s merely a prototype to see if I could get a browser game working smoothly on an iPad and other touch devices. I never intended to finish it fully as I feel the world already has enough Pacman games floating about and we don’t really need another one. I am planning on creating a more original game with a Designer friend of mine early next year and will post about that when it’s ready.

First up click here to play the game. Right click and have a glance over the source code then read on below and I’ll explain the main talking points of the game structure.

Moving and animating the characters

The movement of the characters is fairly simple. The Player and Ghost Classes (I’m going to call them Classes even though they aren’t strictly Classes, not in the way AS3 Developers would be used to anyway) both contain an instance of the Animation Class. This Class was adapted from the Plugin Media experiment and basically uses CSS transforms to position the game characters as seen in the code below. I updated the Class so it also incorporated rotation, which I needed for my Pacman game.

var xp = Math.round(this.x + this.offsetX);
var yp = Math.round(this.y + this.offsetY);
styleStr = "translate(" + xp + "px, " + yp + "px)";
dom.style.webkitTransform = styleStr;
dom.style.MozTransform = styleStr;
dom.style.OTransform = styleStr;
dom.style.transform = styleStr;

styleStr = "rotate(" + this.rotation + "deg)";
dom.style.webkitTransform += styleStr;
dom.style.MozTransform += styleStr;
dom.style.OTransform += styleStr;
dom.style.transform += styleStr;

The character animations are done using simple Sprite sheets as seen below.

I liked the way Plugin Media wrote their Animation Class so the API worked in a similar way to ActionScript with play(), stop() and gotoAndStop() functions. View my adapted version of the Class here.

Collision Detection / Level Generator

The hit detection for when Pacman touches a wall is actually very simple. The level background is a transparent png as shown below.

I create a Canvas element and give it a green background. I then load the image on top of it, divide the image up into a grid and loop through to check if the pixel color is green using “getImageData” with the canvas tag. If it is I know it’s a space, otherwise it’s a wall. From this I can create an Array with info on the level and I use this throughout the game.

To see the full Level Class where this Array is generated click here. You may remember me criticising the performance of the Canvas tag and be wondering why I am using it. It only performs badly when you are constantly clearing it and writing to it. Once graphics have been written to Canvas it’s performance is no better or worse than simply loading an image.

If you have downloaded the source and are running it locally you may find that it doesn’t work and you get a security error. That is due to the line of code below – “getImageData”. You won’t get this if you install and run a local webserver such as Apache – this post on stackoverflow will explain further.

cellData[w][h] = (context.getImageData(xp, yp, 1, 1).data[1] == 255) ? 1 : 0;

The second bit of collision detection is between Pacman and the Ghost. This was much simpler and is done using a distance calculation.

var dx = Math.abs(player.xp - ghost.xp);
var dy = Math.abs(player.yp - ghost.yp);
var dist = Math.sqrt(dx * dx + dy * dy);

if(dist < CELL_SIZE)
{
  onGameOver(false);
}

For the Ghost AI I have written a simple implementation of the good old A* algorithm. Keith Peters wrote a great chapter on pathfinding in his ActionScript 3.0 Advanced Animation book, which is well worth a read if you’re completely new to pathfinding. A* is by far the most used pathfinding algorithm. You’ll find it being used from simple games like Pacman right up to complex PS3/Xbox games. You can see my implementation in the updateGhost function within the index.html source.

Touch screen devices

For the touch screen controls I used Modernizr to detect if the device supports touch.

if(Modernizr.touch)
{
  isTouch = true;
  makeControls();
}

Then I create onscreen controls using divs and the HTML touch events. I combined the event listener for key presses and touches as shown below.

function onKeyPress(e)
{
  if(!isPlaying && !isKeyDown) onClicked();
  isKeyDown = (isTouch) ? (e.type == "touchstart") : (e.type == "keydown");  
 
  switch((isTouch) ? e.target : e.keyCode)
  {
    case KEY_LEFT :
    case leftButton :
      leftDown = isKeyDown;
      break;
       
    case KEY_RIGHT :
    case rightButton :
      rightDown = isKeyDown;
      break;
       
    case KEY_UP :
    case upButton :
      upDown = isKeyDown;
      break;
       
    case KEY_DOWN :
    case downButton :
      downDown = isKeyDown;
      break;
  }
}

Fixed timestep

The final issue I experienced was a noticeable difference in frame rate between certain browsers and devices. This is an expected issue when running game physics on an interval and there is a simple solution: fix your timestep! I won’t go too much into this as you can read all you need to know in this great article from Glenn Fiedler. I have written an implementation of what is described in Glenn’s article in JavaScript and the game now runs at pretty much the same speed across all browsers and devices, it’s just smoother on some.

So with a fixed timestep and using CSS transformations on divs rather than constantly writing to Canvas I have succeeded in creating a simple browser based game that runs at an optimum speed on an iPhone/iPad and across other devices such as Android phones.

Conclusion

I really enjoyed creating this and learnt a lot about JavaScript and CSS. Reading books/online articles is a great way to learn but sometimes you just need to get stuck into code, and what better way than to make a simple game.

I want to say a little thanks to Seb and the guys at Plugin Media whose code I used a bit of. Also, my current employers Specialmoves, who were happy for me to do a bit of work on the game during my downtime. Finally, thanks to Richard Hallows who gave me some advice on CSS and best practises (check out my alphabetically ordered CSS style sheet).

Go ahead and try it out on your phone and let me know if you have any issues. As always advice and comments are welcome so let me know what you think.


Posted in CSS, Experiment, HTML5, JavaScript
← Older posts Newer posts →