• Jeroen Savat

  • Frontend Software Engineer

The CurveFever project is a multiplayer "snake" game that uses some of the latest webtechnology. Smartphones are used as controllers, while a big, projected "main screen" serves as the playing ground.

The idea(s)

When thinking about what kind of project we could come up with for the Foreach Ship It Day, I figured making a web game could be a very fun way to learn some new things.

I started by doing some research about what's already out there.
Specifically, I already knew about a cool Chrome experiment called super sync sports, which uses the smartphone as a controller. Loved that idea. Stole it. (*)
I wanted to base (*) the gameplay off of a game I already knew and loved to play at LAN parties, called Achtung, die kurve!


Turns out even the code (*) for this already exists in HTML5:

(*) Disclaimer: Good Artists Copy; Great Artists Steal

In the original game, the goal of the game is to survive as long as possible. You and your friends share the keyboard to control the line. The lines are constantly moving forward. The players can only adjust the direction of the line. A player loses if his line touches a line or the border of the game. He then has to wait for the start of the next round to play again. For every player you outlive you earn a point.

The challenge

We already had (the basis for) a game and some ideas to make it cooler:

  • Using smartphones as controllers: If the device has a gyro sensor (we automatically detect this), we use that to control left or right, failing that we just provide buttons to press.
  • Making it multiplayer (not just one device): "serve" the game on one big screen, and let people connect with their device as a "client" (so they don't render the actual gamefield, just a controller interface) 
  • We wanted to make multiple sessions (lobbies) possible as well.

We had lots of other ideas for gameplay improvements as well, but our main goal was to learn. 
So here's what we wanted to learn (and how we'd apply it to our idea):

Service Workers

A Service Worker is a script that is run by your browser in the background, separate from a web page, opening the door to features which don't need a web page or user interaction. 
The reason this is such an exciting API is that it allows you to support offline experiences, giving developers complete control over what exactly that experience is. 
(source: html5rocks

The idea was to use Service Workers to cache all our static resources to increase performance & to make our game "installable" as an app from the homescreen (instant loading for repeat visitors!).


At the 2015 edition of fronteers I learned that webpack was a very interesting and flexible JavaScript module loader - and I wanted to see if there would be any merit to start using it instead of requireJS (which we use on a daily basis in all of our projects).
This would of course mean getting some practical experience with it first, so that we could make an educated decision. 

nodeJS, socket.io, express

The bare bones of the "javascript backend" - nodeJS as a server, express to serve the resources, and socket.io to manage the game's client-server communication.

Reading device sensors

We obviously need to be able to read them to determine if our snake's supposed to go left or right, depending on the orientation of your smartphone.

What we learned

1) Webpack

  • This did take some getting used to. Nonetheless our experience was positive enough that we decided to start using this in our workflow instead of requireJS!

2) socket.io & nodeJS with express

  • Very educational: making a game like this required a different way of thinking...  javascript "backend code" as a proces versus traditional web-based server(s) is a very different beast indeed.
  • How to (efficiently) debug node code was - and still is - a bit of a mystery to us (whereas that's very easy to do in the browser)

3) device orientation:

  • this website provided us with some very nice snippets on how to access some native smartphone capabilities: what the web can do today  (specifically the accelerometer API)

Aside from the technical topics, our team was comprised of 7-8 people at it's peak - which meant we had to coordinate very closely on who's doing what on such a relatively small project (and prevent people working on the same code as much as possible). This was very challenging to say the least (at the very start even impossible, since the project setup needs to happen first and everybody would be working on the same files).

Short "technical standups" to coordinate were key here - we split up into 2 teams at the start, and as the codebase progressed we even split up into 3 teams (which would have been too much at the start, but proved ideal in the later stages of development).

The end result

Intro (YOUTUBE video)

Gameplay (YOUTUBE video)

A "nice to have/TO DO" list of what we didn't get to implement:

  • gracefully close connections (when a user disconnects that color is still 'reserved')
  • serviceworkers (we did learn a bit about this, but your website NEEDS https for serviceworkers to work - and we didnt have the time to set all of that up. So we weren't able to implement any of it into our game)
  • node restart (forever): when the server process crashes or errors occur, everything just stops working.
  • more hotpink unicorns (at the moment we only show these at our "lobby full" page - for shame)


A bit more work than we had anticipated, but our mission was definitely a success: learn a lot and make a fun game, all while having a blast!