About paal.org

Lead developer at one Norway's top digital agency; Apt. Teamed snuggly with our best friend agency Try.

I’m speaking at Making Web 2013

I’m really happy to say I will be speaking with Knut Skåla at this years Making Web conference! We will be telling the story on the most amazing and challenging project I ever worked on – “Solo – The world’s largest message in a bottle”. The talk will reveal the technical solutions allowed the 8 meter bottle to report pictures and data onto the project’s webpage. The talk is named “From the Atlantic ocean to your browser“, which pretty much sums it up.

As this is the first time speaking on a conference, I’m really happy about seizing this opportunity and really hope there will be more to come. I will post a link to the talk as soon as it is published.


A real time strategy game with Socket.io, Backbone and Coffeescript

This article is “work in progres”, and is as much a future reference for myself as hopefully some useful information for you as a reader. One of the options for this article is turning it into a talk/presentation, I would like to hear your opinion on that!

From spring 2012 until November 2012 I worked in project team with the purpose of recruiting more students to become engineers in the energy sector. The project should both educate, inspire and ignite a curiosity about how Norway’s offshore oil industry works. With a target audience of young people looking into a higher education, we choose to make a game. A real time strategy game. The best player would be awarded a scholarship worth 50.000$, and hence the first challenge was created.

Cheating on the front end? Move it to the back end!

Creating games on the web where there are prices involved is challenging, as games run in the browser are notoriously easy to hack. Our first challenge was then to make sure that cheating would be too hard, keeping the competition aspect fair to all participants. Including those without any Javascript skills potentially being used for mischief.

As front end on the web is easy to manipulate, the back end is another story all together. There most is invisible from the outside, with wiring and logic being “eyes only” for us developers. Our solution was then to move all game logic and state to the server, with having the front end as lean as possible. However we wanted a game that would act quick and feel responsive. At the same time the server had to be able to contact the client, so posting forms and AJAX calls were out the question. With modest experience with Node.js and socket.io, we thought:
– Why not use just that technology, even though it’s a just single player game?

Game session on server, with backup

At game startup, we would create a game on the server and use websockets via socket.io to do real time communications between the client and server. Hence it would be impossible to directly manipulate any any state or logic on the client, eliminating obvious opportunities to cheat. Also the server was set up to save all state data to DB both at intervals and disconnect, making sure games were never lost. The user could just continue  whenever he/she would like to, being on the same PC or maybe on the phone riding the subway.

Start with responsive, continue with mobile first.

Today there is no way one can ignore the amount of mobile users on the web, with some of our campaigns reaching over 30% traffic from mobile devices. This was no exception, but building a complex RTS game was already a handful, so we had to think smart. As searching and producing petrolium was the objective in this game, it was obvious that we main part of the game would be based on a map. Luckily maps are per definition responsive, with bigger screens just displaying more of the map. But games cannot only be based on maps alone, other GUI elements must also exist for interaction with the user. So our designer came up with the idea that we would just use a board game metaphor, with playing cards as the base of the UI. Cards are small and fits neatly within a mobile display, they also have a natural border – making them also look good when there is more space available. Except for the intro page, and the HQ-menu we eluded the need for media queries in most of the game UI.

Game in development, stay at your post!

Most at the time when developing for the web, you want to work at a single part at the time until it’s done. When you have a game that’s progressing as you develop, that can be challenging, like working on a card that’s triggered from an event. You certainly don’t want use a lot of time searching for oil, just so that you can work on the card that tells that you found some. Luckily my colleague Anders came up with the idea of locking revisions of save games in the DB, so that every time I reloaded the game, it would start from the same exact spot! Brilliant, and a massive time-saver in the development process. We could also name save games, if we would like to start the game at those states later.

Debug screen, shortcuts to the developers delight

For all repetitive tasks as a developer, one should create tools that eliminate them. Some examples are:

  • Restarting the game from a save game, with automatic login
  • Keyboard shortcuts for saving a game and refresh the browser
  • Skipping to a specific view
  • Manipulating the model
  • Simulating data from the server
  • Simulating series clicks on UI elements to test a workflow
  • Displaying debug information

I really urge developers to use their imagination to create those little sweet tools, they are both extremely useful and lots of fun to create! As this project was built on Backbone, I just created a Backbone.View called Debugger, with references to the models so that it could listen for change events.

Interaction design crisis, not to be taken lightly!

Exploring, finding and pumping oil from a rig you have to build is not simple. There a lot of steps that has to be done before the “black gold” is ready to be sold by the barrel. Communicating and teaching the user that process was already a challenging task, making the user complete all those steps in a game, even harder. A complex concept dictated a complex interaction, with too many choices on each map tile for the user to comprehend.

This challenge really manifested itself when I just had completed all major parts of the game and was ready to try it. A bit excited I started from the beginning, creating a new company “Snake Oil” and started the game from the top.

There was just one problem, I could not understand how to play the game which UI I had created myself!

An interaction crisis was a fact, and I rallied the troops for a whole day meeting, loaded with Post-Its, whiteboards and markers. We first tried to map all steps the user had to visit before making money on oil production, and from there we looked into solutions that would help him on his way. It was a long process, but in the end we came up with a solution that in my opinion really saved the whole game and project in whole.

A stitch of the result post-its. Showing all steps for the user to take before pumping oil.

From a solution where the user had all options available at all times for a map tile, we drastically simplified the workflow by forcing the user into a “wizard” mode for each tile. So the only choice the user had, was clicking a map tile, and the next action for the tile be presented. So instead of having a massive hierarchical menu, we just sat a logic order on all steps available. When exploring a map tile, instead of the user having to select from “2D seismic”, “3D seismic”, “environmental inquiry” and “geological research”. A click on the tile would just trigger purchasing the one action after the other. This also saved us the massive design challenge of pushing abbreviations of all those choices on a menu that would fit into a mobile display.

Result and statistics

Some statistics of the game in it’s competition phase. More to come later:

  • In the most intense weeks, average time on site was 40 minutes. On our other typical campaigns, the average is closer to 4 minutes.
  • 100 000 games were played. That’s the number equal to 2% of the Norwegian population
  • 75% of the visitors was returning, they wanted to play more

In short, we were extremely pleased with the response we got from the users and in the numbers above. The users really enjoyed the game we had created, and some even begged us to keep it running after the competition ended.

The game is still playable at it’s original link, albeit only in Norwegian:

Project team

Art Director Sebastian Rasch
Copywriter Anders Holm
Copywriter Sigurd Solberg
Consultant Ole Hustad
Project management Mona Larsen
Developer Anders Stalheim Øfsdahl
Developer Emil Jönsson
Developer Pål Smitt-Amundsen
Developer Knut Skåla
Project Music Dedmau5

Running Box2D on server with Node.js via Socket.io

I was kinda bored from the TV this friday and decided that learning a little more on Node.js was more fun. Once able to run a “Hello World” example, I wanted to advance into working on websockets using Socket.IO. Socket.IO is a library for both browser and server which simplifies working with websockets, and at the same time provides fallbacks for older browsers. It was really easy to get started, sending messages between browser and server after short peek into the docs & examples.

Next step was mixing it all up and adding my favorite js library – Box2D.js! I took the code from my Box2D DOM demo in to the main file and created a module from Box2D, exposed  via module.exports. And shockingly the backend-to-frontend-port worked on (almost) the first run! So now instead of the browser animates it’s own DOM objects via JS, it receives CSS for all objects at 30fps from server!

4 browsers, 2 iPhones and 1 iPad, with a lot of boxes animated in sync:

You can download the source here. . All needed libs are embedded, just run ‘node box2dserver.js’ and host the same folder on your localhost. Also remember to change the ‘host’ address in index.html to the one running Node:

window.socket = io.connect('http://<node-server-IP-or-name-here>:8080');

Animating a webpage with Box2d physics

Now this is what I call responsive design :-)

Now this is what I call responsive design!

You may have seen fun projects/demoes where a webpage is demolished using lifelike physics animations. Wario Land Shake It is a good example of that and it’s also allows the user to drag page elements around after the video is done playing. This however is created as a full page Flash, trying to look like a HTML page. Similar cases has also been done just by pre-rendering all into a video. So I wanted to have a go at doing this in HTML, as I haven’t seen that done before.

Continuing on what I learned creating my previous post about Box2d for JavaScript, I wanted to take it a step further replacing the debug renderer with elements from a webpage. The elements should be working as a blue print for the Box2d objects, and the transformation into the physics world should be transparent. I created a quick webpage using <div> elements with some mockup content and started on the steps to make it work:

  1. Scan the appropriate part of a webpage for <div> elements, creating the corresponding counterparts in the Box2d world. This turned out to be pretty straight forward, using a jQuery selector with the each() method looping through and creating boxes in Box2D. Positions and dimensions were extracted from CSS, being absolute positioned for the sake of simplicity. After they where reset to a 0,0 position, ready for letting the animation engine handle the positions later. A reference to the <div> was injected into the m_userdata of each of the Box2d bodies.
  2. Animating is done by looping through all fixtures within the bodies in the Box2d world, retrieving the position and rotation of the objects. Thus having rotation of the boxes, just using god ol’ top & left for positioning and animating had to be forfeit. Instead we use the transform property on CSS3, offsetting the position from 0,0 and setting the correct rotation. An added super bonus is setting transform: translateZ(0) in the parent element, we get super fast GPU accelerated animation. Using the -webkit vendor prefix, we even get pretty decent performance on iOS devices.
  3. Checking that all was in a 1:1 relationship between the browser rendering of the <div> elements and it’s Box2d counterparts also had to be done. I did this by using the debug renderer on a canvas, being displayed behind the elements. In the example you can turn it on and off, also making the <div> elements transparent to see both “worlds” at the same time.
  4. Handling both mouse and touch events is always a bit of a chore when you just want to focus at the task at hand. So I wrote my first Javascript tool ever, MouseAndTouch.js that handles both types of input in your typical “press-draw-up-end” manner. The code setup is probably not quite kosher, but writing it helped me along the way of learning JavaScript.

Ok, thats quite enough talk already. Go ahead and take it for a spin! Make sure that you drag the elements after they have been dropped :-) And please comment, esp. on my novice setup on the MouseAndTouch.js as a standalone tool.

For those of you that like more technical details, here are some things I found in the development process:

  • The rotate() method of CSS3 transform does not like negative values or infinite number of decimals. So you need to normalize the angle and fix the number of decimals. I ended up specifying the angle with degrees and setting the number of decimals to two.
  • Creating some shorthand methods for creating Box2d items helps speed up the development process.

A quick snapshot of the mobile friendly internet

You need the patience of a sniper to read thisI’m just home from my daily commute on the train, which also happens to be my favorite type of transport. It’s also a place where I can take some time to catch up on my never ending list of posts to read on Reeder, Twitter and Instapaper. The latter I have promised myself to have all articles read a couple years into my retirement.

Today my Twitter feed was full of references to the upcoming OSX Mountain Lion which is due for release this summer. Tech interested bloke as I am, I had to get information directly from the source itself; the new pages put on on the Apple website. However it was a sharp contrast coming from the sweet mobile apps with readable text, to a static “old school” 980px website rendered on a iPhone display. Retina display makes the text sharper, but the 4S not being bundled with a magnifying glass it’s still impossible to read the text. Zoom you say? Double tapping the 700px text columns still didn’t do the trick, forcing me to to the go in to “Sniper mode” reading the text. An experience reminding me more scouting for enemies (camping) in Battlefield with a 8x ballistic scope, than a good reading experience.

For marked a leading player on mobile like Apple, you ought to think that zooming webpages should be a thing of the past. But but for the sake of being fair here, I have taken some photos and created a photo gallery titled “A quick snapshot of the mobile friendly internet”:

Playing with Box2D in Javascript

Box2D is probably one of my favorite libraries in whole of the programming world, simulating physics in a realistic manner. Actually you may already have played with it without knowing, just by playing Angry BIrds. There it handles collisions between flying birds and their nemesis; the pigs and their fragile buildings.

I’ve used Box2D for a scene in my last project at Apt; the Norwegian site for the Volkswagen Beetle. As one of the scenes is a “tribute” to Line Rider (a classic Flash game with physics simulation), I choose to use the renowned Box2D on this occasion.

Click to play!This particular evening I focused on testing a js port of Box2D, namely the Box2D-Web as it was recommended on the Creative JS blog. This port is actually an automatic conversion of the Actionscript one, so I also expected that reuse of my code from the Flash VW project would be a trival. This turned out to be a truth with some modifications, as some adjustment was needed. I also used the bundled “debug renderer” which is really handy in development when you create Box2D objects and need to look at how they act. In a normal development process of games and such, you normally exchange the debug renderer with animation of your own graphics. But in this lab experiment I choose to keep it for simplicity and its clean appearance.

Enough talk, take a look at it here and play with it. First draw/touch a hill from top left corner towards the bottom right, then drop a circle (or twenty).

PS. If you are a developer and a would like to learn more about Box2D, start with reading the manual regardless of your desired programming language. You should at least need to learn some of the basic terms and the theory, before getting down and dirty with the code. The next vise step is to pick a port for your chosen programming language, and find some tutorials and examples to get you started.



A shot at installing WordPress

I’m not really sure if this is to be a start of my blog, or me just being curious on WordPress. Either way it will be a place where I post more permanent links to stuff that I’m working on than just using Twitter. I would also like to get some more experience writing, as it is an area I’m less confident in.