Flash vs. HTML5 – how we did it!

Now that many of you have had chance to play around with our Pong game , we decided to ask Branny and Jono, the creators of the game, to tell us how it came about.

First of all, what do you do at Code?

Branny: I'm a Senior User Experience Developer -- that's a bit of a mouthful, but basically I do HTML, CSS, JavaScript and Flash.

Jono: I am a Flash and AS3 Developer.

What made you think of doing a Flash vs. HTML5 game, and why did you choose Pong?

Branny: I'll let Jono explain why we decided to do a game with the two technologies, but I guess I can answer why we chose Pong... it was kind of an accident, to be honest. Once we'd decided we were going to embark on a mission to put the two technologies together, it was a case of sitting down and talking about what we could do. We wanted to keep it simple and initially see how effectively it would work. We started by getting the two technologies talking to each other on a simple horizontal line. The thought process that took us from a horizontal line to the game Pong was pretty natural, as you can imagine!

Jono: After attending a very inspiring 'What the Flux' presentation by Seb Lee-Delisle at this year's Flash on the Beach, I felt like there was a definite feeling of animosity towards the two technologies pretty much everywhere. I wanted to convey some of the concerns that were being voiced, as many seemed to feel that Flash should be getting along with HTML5 and the two 'different' technologies should be playing to their individual strengths. I thought it might be a good idea to literally play them off each other -- simple as that, really. Street Fighter was my first thought, but thankfully Branny reigned me back in!

What was the brief?

Branny: There wasn't an official brief, really. As this was an R&D project, we kind of came up with a loose brief -- create a simple game using Flash and HTML5 as the platform.

Once you had your (loose) brief, how did you go about the project?

Branny: Well, firstly we sat down and talked about how we were going to tackle it, and how we would work together. We decided to initially work individually to set up our environments. I was going to build the HTML5 side of the game, so naturally I would set up the web page for the game to sit in. I firstly created it locally, but would have to set up a central location for testing. Initially, I just created a share on my local machine for Jono to drop his Flash file in.

Jono: Using a combination of Flash Builder Plug-in for Eclipse and Flash CS5, I began to create the core classes -- pong, ball, paddle and environment classes, etc., fairly simple stuff and some basic game logic. Then we went about hooking up the Flash and HTML. Flash's ExternalInteraface classes seemed like the best way to proceed, so I began to set up function calls that would be triggered when my ball reached a certain point on the x axis.

Did everything run smoothly?

Jono: 'Smooth' was really the keyword in this project, as there were a few obstacles in getting the game to render as smoothly as possible. One of the most obvious problems was which application was going to wear the trousers (having keyboard focus and saving score data), and manage the other platform.

Branny: I think smooth enough! There were obviously some issues that we came across that we hadn't foreseen, but for the most part it was pretty trouble-free.

What issues came up that you didn't expect to be a problem?

Branny: Focus was something I knew would be a problem with Flash, but it never crossed my mind that Canvas would have the same issue.

What do you mean by 'focus'?

Branny: When you come to interact with any flash element in a web page, the Flash object needs to have the focus of the cursor to enable any kind of interaction with mouse, keyboard, etc. This, to my surprise, was -- and is -- exactly the same with the Canvas object. This caused us a massive issue when it came to controlling the two sides of the game -- how would we control both sides with one keyboard when both sides required focus? We used the same method to control the two sides as we used to cross the ball from one side to the other -- the good old JavaScript call to Flash's ExternalInterface. We kept the focus in Canvas and sent calls to the Flash to move the Flash paddle.

Did you find many performance issues?

Branny: Yes, we came across lots of performance issues, some of which we tackled to a degree, and some we left for people to see. The main performance issue was having the two technologies running side by side in the same web page. The HTML5 side of the game is basically run on JavaScript's setInterval. In order to move the paddle before starting the game (to allow you to position the ball before you released it) we had to run two set intervals, one to control the ball and one for the paddle. This alone had an impact on the processor. Jono then applied the same logic to the Flash side, replacing setInterval with Flash's onEnterFrame. Again he used two instances. Having four processes all running at the same time was in itself really hard on the processor. This, coupled with the ExternalInterface calls to move the Flash paddle, really killed the game.

Jono: I think Branny has pretty much covered the reasons for the game being a 'little' CPU hungry. Perhaps, on reflection, if Flash had been controlling the application it could have been running one EnterFrame event and listening for all keyboard events, then the Javascript could have been running one setInterval and listening for all of its keyboard events which could have all been dispatched from the Flash.

Branny: The other major issue was keeping the ball on an even keel as it crossed over from one technology to the other. To keep things simple, (and you have to remember this was an experiment) we didn't use true collision detection; we just went for ball position, x and y. This caused issues due to the speed of the ball. If you've ever done anything like this you'll appreciate that this isn't the most accurate way of detecting two things hitting. Basically, you check if the co-ordinate is less (or greater) or equal to a desired position, then do something if that argument returns true or false. Depending on how fast the ball was travelling it would reach a further (or less) position depending on when the setInterval would next check.

How did you get around the difference in position?

Branny: We were constantly checking the balls x and y position and passed those co-ordinates from one side to the other, so it didn't matter how far the ball had gone. When the trigger was fired, the x and y position on the ball was taken and passed over to the other side.

What was the most challenging part of the game?

Branny: Keeping Jono's crazy particle physics off the paddles ;). No seriously, I think we came across a lot of issues that were fixed relatively quickly, but the issue of the ball crossover was probably the most time consuming.

Jono: Yes, the ball crossover was a little time consuming. Converting the balls x distance and y distance with acceleration from milliseconds into frames per second should have been a fairly simple calculation, yet when implemented into the game it became tricky to make the transition look seamless, especially at speed.

Anything else to add?

Jono: In the end, the HTML/JavaScript was controlling the application and keeping score; instead of using Flash SharedObject class to store data about latest scores in the Flash Player, we opted to use HTMLs local storage facility. This could have easily been switched so focus was given to the Flash, and not the HTML -- perhaps a v2...

Branny: Many people have mentioned the Flash performance issues and the fact that setting wMode="window" would solve some issues. This is true; however, in this experiment, we controlled the scores with JavaScript and HTML using the local storage facility. Using "window" would have hidden the Flash Score. Yes, we could have put the score in the Flash and used the Flash storage, but, like I say, this was an experiment and these are all learnings for next time.

So now you have created a little stir in the digital community, what's next?

Jono: It is a very exciting time to be a Flash developer -- regardless of whichever round we're up to in the HTML5 vs. Flash bout -- with the release of Flash player 10.2 beta, Molehill, Air 2.5, iPhone packager. It is our job as Flash Developers to create rich and exciting media for the web, using Flash for what it was designed for -- to push the limits of the browser. So R&D, basically.

Branny: I think R&D is a valuable commodity in this business, so we will continue to experiment on ideas and new technologies. Watch this space.

Cheers guys -- we hope to hear from you again soon with your next R&D project.

If anyone has any further questions on this topic, then please feel free to leave feedback and we will try and get the guys to answer your questions.


Beginners guide to Arduino Physcial Computing