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