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.
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.
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):
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.
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!).
This would of course mean getting some practical experience with it first, so that we could make an educated decision.
nodeJS, socket.io, express
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
- 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
- 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!