Creating a multiplayer game in less than two days: Tempest
Tempest is a real-time, multiplayer strategy game where you pilot a rover in search of valuable resources on a distant, mineral-rich planet.
Three competing factions race to collect as many minerals as possible, while out-maneuvering severe storms, stealing from enemy collection stations, and confronting enemy rovers.
Of course, keeping your rover safe is your first priority. After searching the red planet for minerals and returning with a full load, your rover is rewarded with increased capacity and speed.
And no realtime strategy game would be complete without some powerups and defense, so we added medkits, speedboosts, and a blast shield to increase your chances of success!
It’s also worth noting that all of the music and sounds in Tempest were designed specifically for the game and composed in the same key to make for a harmonious, ambient adventure (thanks Jonathan Bell Wolfe!).
We’re a bit dumfounded at how quickly this project came together. Even though we’re used to moving from idea to implementation super fast, it never gets old to see an abstract “what if” turn into something you can actually play. Sure, it’s a bit heavy code/library wise (NowJS for realtime websockets and CAAT for handling drawing and animation on an HTML Canvas element), but it works!
Tempest is more fun with friends, or with multiple tabs :) Give it a try and let us know what you think!
HOW IT CAME TOGETHER
To work on lots of things in parallel, we collaborated on all of the code and design for Tempest using Space. It’s incredible how quickly things resolve (or break, and get immediately fixed) when we’re all working at the same time without checking things in and applying patches. A missed semicolon or quote can break things (as it always can), but when that does happen, everyone is focused on tracking down the bug and bringing the application back online. Of course in production, the workaround to this problem is simple: edit a working version collaboratively and only push to production when it’s stable.
The other advantage of working synchronously and simultaneously on a project is that it can evolve much more quickly. The whole architecture is free to change as it’s being built, and when a change goes too far, everyone can chime in on how to do what’s needed without breaking too much code.
Our first day started with a one-hour brainstorm via a Google Hangout about the kind of game to make (read: NOT a specification-writing dev session). We all just started building the components we were most excited about and skilled to create, and by the end of day 1 the key elements were already up and running (realtime websockets for communication, a large interactive canvas for the game map, a strong design direction, basic styles, a soundtrack, and matching sound effects).
After a good night’s sleep and some basic observations about what seemed most fun and/or experientially flat, we spent most of day 2 building out Tempest (with health kits, speed boosts, and defensive blast shields) and smoothing out kinks so that the game could scale up to lots of users competing at once.
We’re not saying that every project can happen quite as organically or quickly as Tempest did, but who knows? The short version is that we just moved out of head-space and into action-space where we could really see what worked and was most exciting. It’s almost too simple, and something we’re sure to keep in mind for some of our other backburner projects that need a swift kick in the pants to get off the ground — let’s stop talking about the awesome things we’re going to make and see what we actually can.
