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:

to this:

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.

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…”

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.

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.

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

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.

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.

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.

The project I’m currently working on features a fair amount of particles (it’s a Christmas site, need I say more). For the vast majority of them I’ve used Richard Lord’s brilliant Flint library but there was a couple of loaders on the site where I used my own simple particle system. I’ve always enjoyed playing around with particles as you can see from the posts featured on this blog, e.g. ColorWall, WobbleWall and Simple JavaScript Physics.

So with yesterday being November 5th (bonfire night here in the UK) I started playing around with creating a sparkler effect using JavaScript and Canvas. It didn’t really look exactly how I hoped but in creating it I stumbled across some other cool effects, the best being the one below. Click here to view the particles in action, move your mouse around and click anywhere on the screen.

I’ve always enjoyed creating simple visual effects that are nice to interact with and fun to watch and I think this one is just that. It’s a simple effect but I found myself dragging the mouse around for ages playing with it.

I plan to write a simple particle tutorial soon (ambitious for me since I’m currently averaging 1 post every 4 or so months) where I’ll explain the basics of creating a simple particle effect. Many developers think particle effect are really hard to create but once you’ve got the basics down it’s easy peasy.

Below are some of the other particles experiments I made yesterday. The first is the sort of sparkler effect. The second a slower more mellow version of the above and finally the sparkler effect without the canvas being cleared.

I have a new job! Well, maybe not so new anymore as I have been here for 3 months. After returning from travelling I soon realised that I needed a fresh start at a new company to really get me excited about programming again. After deciding it was time to move on one company instantly sprang to mind as the sort of place I’d love to work… Specialmoves. Having worked with them on a Lynx project whilst at TMW I knew a few people at the company and thought I’d send my CV over and much to my delight - I got the job!

Specialmoves is very different to my previous jobs. The company is a studio rather than agency with little over 20 employees, and focuses primary on development. In my first week we had a Studio meeting and Darrell (one of the founders of the company) said that 10 years ago him and Pascal (you guessed it, the other founder) set the company up because they wanted to do “cool sh*t”, and it’s safe to say that is pretty much still the inspiration for all things Specialmoves. It’s an exciting place to work and the company are always trying to push the boundaries and be innovative. I hope to learn a lot working here.

Check out the video below for something I made in my first couple of weeks at Specialmoves. To read more about the project click here.

The other great thing about my new job is that it’s an Interactive Developer role, so not Flash/Actionscript specific. I like programming with Flash, it’s where I started out as a developer and I think AS3 is a fun language to write in. However, I’ve always believed as a developer it’s important not to get tied down to technologies and to remain open minded and keep learning/experimenting with new stuff. My role at Specialmoves will involve a lot of Flash, especially at the start, but I will also get an opportunity to work on other platforms like JavaScript and mobile development etc.

In other news my HTML5 version of ColorWall was recently added to the Chrome Experiments site. Check it out here and give it a 5 star rating!

I plan to re-ignite the website over the next few months so expect some more blog posts soon!

Click here to play and see if you can beat my high score of 44. I’ll probably update it with a scoreboard soon. Oh and don’t try and run it in IE as it won’t work (no canvas support).

PS. It probably won’t work on your Nokia either but a mobile version could be an option in the future.

You might play this game and think “this is just a copy of that iPhone game Doodle Jump”, and you’d be completely right. I was bored the other weekend and thought I’d make a game. I like Doodle Jump and there isn’t really any good online alternatives (google it, the top link is pretty poor, I’m not even going to link to it) so I thought I’d make one. I really enjoy programming physics and since it’s fairly simple for this game I did it all myself rather than using a library such as Box2D.

Normally I’d get the game to a certain level, like this early demo of Space Monkey, then move onto something else but I liked this one and thought I’d see it through to a properly finished game I’d be happy to post here. One thing I noticed was the game play is only a small part of a simple online game like this. It probably took roughly the same time to build the shell and score board etc.

Apart from the Monkey character (who I bought off iStock) I did all the graphics myself. I’m really pleased with the way this game turned out and I hope you have fun playing it.

I made ColorWall purely as an example of how to re-create Yugo Nakamura’s great wonderwall effect. It was really just to see if I could do it using particles rather than a 3D engine but I was so happy with the result I thought I’d post it here on FlashMonkey, along with an explanation of how I did it and some source code.

I got some nice comments here such as Sourav Bhargava’s - “great analysis man . I appreciate your work. thanx the work helped me a lot”, and I did some spin off work such as WobbleWall and ColorSnake, but eventually I moved onto the next thing and started to forget about ColorWall.

However, whilst away travelling in Latin America last year I decided to check my Google Analytics (as you do) and couldn’t believe my eyes! ColorWall was starting to get a lot of hits, one day alone it got over 20,000. A little further investigation in GA showed me that most of these hits came from StumbleUpon.com, and a fair few from other social media sites such as Twitter, Facebook and Tumblr. It seems ColorWall (not ColourWall - I’ve taken a fair bit of stick from my compatriots for spelling it the American/programming way) has entertained people in a way I never intended/expected. Although 250 of the hits came from shroomery.org so that might go some way to explaining things.

Anyway, I’ll leave you with some comments people have made on StumbleUpon, I’ll start with the nice stuff, and end with some comments from people who ‘didn’t get it’!

He should check out WobbleWall

No. It’s Flash. I have done a crappy HTML5 version though: HTML5 ColorWall

The client often like to change their minds (just a regular client then) and I know that the animation may change quite a bit. To fade the content in after the animation I am using addFrameScript.

However, a problem, I know the frame that the fading should take place on could change several (hundred) times before the project goes live. I could just tell the designers where in the code to change the frame number, but I thought of a nicer solution than that.

The code was a simple combo of addFrameScript and currentLabels. I got the designer to add a label on the frame they want the fading to take place and then used this simple code:

OK it’s not going to make you fall off your chair with wonder but could be useful in the future. I’ve chucked it in a utils Class so it can be used like this:

In the above example the frame label the designer adds is “animation-complete”.