Warming up to browser apps

I recenty did a really fun game for my friends at Last Friday in Stavanger. The game itself was a typical fly-in-space-and-shoot-asteroids-type of game. A simple, but easy to understand concept. However - what was special was how you controlled the game and the size of the screen!

The display was projected on a 8x12 meters screen located right in the middle of the Stavanger town square. People walking by could just pick up their smartphone, open a URL and then play the game. I did the code for client, server and game/display while Last Friday delivered the graphics, the physical installation and helped out on bits and pieces.

This is the solution that we came up with:

• JS/HTML5 game controller that works on any smartphone / pad / desktop
• Node.js on the server with socket.io as the transport
• AIR app for the game and display

Node.js kept a queue of clients waiting to play the game. This was sent back to the clients so they could see what position they had in the queue. The info was also sent to the huge game display that showed the game-queue in between games along with instructions on how to join. Once it was your turn, your phone displayed a “Get ready”-message and the game controls faded in so you could play.

Sounds simple? It wasn’t all smooth sailing and here’s some lessons learned along the way.

The original idea

The original idea was to use a local socket server and a native game controller-application that people would have to install. I wanted a challenge and thought this was a good project for testing the maturity of mobile browsers and node.js/socket.io that I had heard so much hype about. Last Friday liked the idea and I started making a “proof of concept” browser-app. This turned out to work really well and Last Friday could sit in Stavanger and play the game running on a display and server in Oslo without serious lag. Not shabby? I hacked together the concept in just one day, including learning node.js… Maybe the hype around node.js could have some substance?

As the game progressed we realized that there was no need for making a custom app and there was also no need to set up a special access point for the players. They simply connected through their 3G connection and that provided sufficient speed. Users with iPhone’s got the best experience since they can use WebSockets. For Android the default Webkit browser can’t do websockets, so socket.io (the transport used with Node.js) falls back to using HTTP-calls. We initially thought that this would prove to be a problem, but it worked rather well.

The solutions

I initially spent 2 days on the server, 2 days on the game/display and initially just 2 days on the mobile client. This is before some minor game tweaks and starting the dreadful job of fixing browser bugs and incompatibilities. That part took another 3 days and then some. Here’s some lessons learned:

• When making a game-controller, it’s important that you can hold the button to repeat the action. The problem with this is that if you tap and hold an image in a mobile browser, the Save-as dialogue will appear. This prevents controller input and crashes spaceships… Mobile Safari has a super-neat css property called “-webkit-touch-callout: none !important”. Adding this line in your CSS prevents the dialogue from showing, but - oh joy - this is a proprietary CSS tag so it only works on iOS devices.
  
  For Android, you’ll have to hijack all possible events (ontouchstart, ontouchmove, ontouchend, ontouchcancel) for the image and then kill any default responses to this (preventDefault, stopPropagation, cancelBubble, returnValue AND return false).
  
• Another problem with mobile clients and game-controller input is that if you drag your finger on an image, the browser thinks you’re dragging it. As before - mobile Safari has a proprietary CSS-tag for this as well: -webkit-user-drag: none;
  Mobile browsers will also try to highlight selected objects. This can be also be turned off using webkit magic: -webkit-tap-highlight-color: rgba(0,0,0,0);
  
• Using jQuery Mobile accelerated development overall, but it also caused some extra debugging when it “killed” the first fix for the above problem. I’m guessing jQuery Mobile comes with its own set of hacks and that we did something that cancelled something that our app need? Not sure how it resolved, but Edvard at Last Friday got it working again.
  
• Calling “window.scrollTo(0, 1)” is the clue to remove the address bar in mobile apps. Works well, but not fault free.
  
• Mobile clients don’t really tell that they’ve closed a connection. To solve this we implemented a polling from the server that cleaned out clients that didn’t reply within a reasonable time - indicating that the browser was wither closed or fully disconnected.

The game was made only for the annual ONS conference so unfortunately you can no longer play it. While having a short lifespan, the project was a great learning experience. I have to say that overall, I’m not impressed by the current state of mobile browsers. However - node.js really is a beautiful piece of Open Source software!

Node.js

Working with Node has more or less changed my mind about making apps based on Javascript. A library that allow you to learn, implement and run a custom server in just hours is nothing less than stunning. If you’re a Flash developer reluctant to move into Javascript - I urge you to go check out node.js and work through this tutorial. It’s fun to play with, you can easily use it with your Flash / AIR projects and you’ll probably learn something new about Javascript along the way 😊

Oh - did I mention the coolest part? As you can see from the screenshot above - the client was IRIS & NASA. I’ve actually made a space game for NASA! How cool is that?

The game in all it’s 100m2 glory in Stavanger