LearnHow We Built Code Racer in 4 Days


writes on January 19, 2012

If you haven’t seen Code Racer, you should give it a try. Code Racer is the product of Idea Week at Treehouse. Idea Week is a tradition brought over from Carsonified to Treehouse where the entire team drops what they are doing to work on a completely new project for one week.

This is my recounting of the Idea Week when we created Code Racer. This won’t be a full story as a lot of people worked on this project and I wasn’t in a position to keep track of what everyone was doing. Fortunately our video professionals at Treehouse had cameras rolling, so much of this is documented on video. I can only tell you about what I was involved in, which was the server and client side development.

I had been involved with one Idea Week before, when we created Brickify. This actually wasn’t an official Idea Week, it was a project we decided to build late on a Tuesday, but then became an Idea (half) Week.

We decided to do an Idea Week when Ryan told us he would be gathering the whole team together in Orlando this January. Since we had recently hired several new teachers and video pros, and Idea Week was a great way to get everybody working together as a team.

Treehouse CodeRacer Launch Video from Treehouse on Vimeo.

The idea for what we were going to build wasn’t decided until the Monday morning of our Idea Week. In the time leading up to the project, we figured our product would likely be a Ruby on Rails application with a great UI, design, API, and hopefully an iOS app. This seemed ideal because Alan and Jason work with Rails every day, and I have several years of experience with Rails as well. I was thinking Alan and Jason would lead the server side development, and I would focus on front-end interaction. It didn’t quite end up working out like that.

When Ryan presented his idea of creating a real-time code-challenge game, it became clear that our assumptions of responsibility were pretty far off. Since we needed to use Web Sockets (or their available fallbacks), Node.js became the clear decision for the Code Racer server. This changed the dynamic of the team a bit since I’m the resident Node.js guy, as well as the front-end JavaScript guy. Fortunately Alan, Jason, and Amit have experience with Node.js and JavaScript, so they were able to kick ass on Code Racer.

Besides not knowing the project idea until Idea Week begins, there is another challenge: a hard deadline. One week seems reasonable for a project that has 5 developers and 4 designers. That’s 5 days, right? Well, Treehouse works the four day work week, so it’s really 4. Also, Alan, Ryan, and Tyson had to fly out mid-day Thursday, so we had to launch Thursday morning. So Idea Week is really a little over 3 days. Better get started!

Tech Decisions

The first thing we did was discuss tech. Because the game required near real-time interaction between the players we chose Socket.io, which is a great server and client library for working with web sockets. This is what allows us to communicate quickly between the players and the server.

Socket.io is built on Node.js, which made Node.js the natural choice for our server. The event based architecture allows us to hold many socket connections open concurrently on one server.

As a group we also decided to use CoffeeScript for our server and client code. I found it to be very useful when I worked on Code Challenges for Treehouse, and Alan and Jason were interested in trying it out on a non-trivial project. It ended up working really well.

For the front-end, we chose to use Spine for our application library with jQuery powering our DOM interactions. There is a lot of information shooting around that needs to be reflected in the UI. Events from the user like typing inside the code editor, and events from the server like information about the game state all need to be handled so the models and views can be updated. Spine’s models, views, and controllers handled the interaction extremely well. Information from the server is received via socket.io, which will update our models. The various controllers on our page listen for changes to the model and update the views as needed.

We also utilized Facebook for authentication and MySQL for storing our users and game logs. I can’t talk much about those decisions because Jason lead that effort.

Day One – Planning and Server

On Monday morning, after our first meeting, the whole team swung into action. The designers and developers split up to talk about their plans and responsibilities. This is where we the developers began making the tech decisions that I described above.

While we were doing that, the design team was coming up with UI sketches as quickly as possible, so our whole team was on the same page. These sketches were extremely valuable to the dev team, because we needed to start building the UI almost immediately.

After that, the dev team split up and began working. Fortunately I had some side projects that utilized Node, CoffeeScript, and Less, so we were able to strip out the guts of that project and use it as a starting point. In less than an hour we had a running server and a github repo that everyone could start working on.

Code Racer: Day One from Treehouse on Vimeo.

I spent most of Day 1 setting up the project and then building a game matchmaking system where when you start a game, you join a lobby until that game reaches capacity. When the game reaches capacity it begins, and a new game is created for the next set of players.

Day Two – Interface

The second day for me was all about the front-end. By Tuesday we were able to connect to a lobby and start multiple games on the same server. Next on the list was creating the interface. There are a lot of moving parts in the game that must react to information sent from the server and the player.

When a new player joins, we have to add them to the page, which includes an editor, a tab in the players bar, and an entry in the lobby screen. When a player updates their code, it must be sent to the server, which will notify all the players in the game. Each player must take these notifications and update the code for the other player’s editor. Being able to watch someone else code was one of our top priority features.

Getting all of the information moving around the different client models and controllers, through the sockets to the server and back down to the clients was the most difficult problem to tackle. By Tuesday night we were able to see other players’ code as they typed it. Many of the other game elements like the timer, player list, and scores were also being displayed.

Code Racer: Day Two from Treehouse on Vimeo.

It was about this time I had to step away from the code for a while. Trying to hold all of the server and client interactions in my head was causing me to mentally fatigue, and I could tell I was becoming less effective. Fortunately Alan jumped in and spent Tuesday night working on getting the game logic up and running. I was amazed at how quickly it turned from a small prototype of live-coding into something that really looked like a game.

While I stepped back from the game logic and architecture, I was finally able to go around the office and see what everyone else was up to. It was awesome to see what was getting done. Amit had a working system for creating challenges and verifying answers from the players. Kevin had built a bunch of awesome weapons you can use on other players that will play sounds and manipulate your screen in some way. Jason had Facebook integration up and running. The design team was doing awesome creating amazing designs and interfaces.

Day Three – Integration and Testing

By Wednesday morning we had something that resembled a game. The html layouts the design team had built had not yet been integrated into the game and there was a lot of work to do on the game logic itself. Wednesday was all about getting the game done. We had to be ready to launch by Thursday. We spent the whole day working on the game logic, testing, tweaking, and testing again.

We played our first game on Wednesday after lunch and the competitive taunts and gasps of excitement and defeat from the players were quite loud. For the first time we were able to see that Code Racer is actually fun to play. A huge wave or relief rolled over the whole office. It actually looks like this idea may work.

Day Four – Launch!

Finally it was launch day. We spent the morning squashing bugs, polishing the UI and game play, and deploying the application. It was pretty stressful. We had a lot of things we needed to get done and almost no time to do it.

We sent out links to our friends to test Code Racer before the official launch. Of course this brought us a lot of feedback on improvements we could make and bugs we need to eliminate, which is how we spent Thursday.

As Ryan and Alan were getting ready to leave for their flights, we were able to launch Code Racer officially. We did it!. Articles from TechCrunch and Venture Beat went live, and tweets started flowing in. It was unreal. On Monday morning I wasn’t sure this idea was possible, but now here it was, online, with thousands of people playing it. In the first 3 days after launch over 6,800 players had played a total of over 4,500 games.

In less than 4 days, the team at Treehouse went from idea to product. I’m incredibly proud of all of the people who worked on Code Racer and count myself very lucky to have the opportunity to work with them.

The Libraries and Tools We Used

Finally, I wanted to share the (hopefully) complete list of tools we used to make Code Racer. Thanks to Jason for putting this list together!


Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Get Started

22 Responses to “How We Built Code Racer in 4 Days”

  1. I’d be down with one of the modnation codes, I really wanna play. I’ll also trade ya.

  2. Mikael Örtenheim on January 23, 2012 at 10:53 pm said:

    Very interesting and good article! Why did you choose to work with spine.js? and not for example backbone.js?

    • After building several projects in Backbone and Spine, I prefer many of the design decisions made in Spine versus Backbone. Spine is a bit more lightweight, and the way models persist, I find to be better. Spine is also written for CoffeeScript first (but also usable in JS like Backbone). One of the advantages to this is by using CoffeeScript extend, you can easily leverage the CoffeeScript super keyword. 

      Backbone is also awesome, but Spine definitely deserves a lot more attention.

  3. This is what makes Think Vitamin awesome. Behind the scenes of how something went from start to finish on a specific project gives everyone good context. 

    I can’t imagine how well organized and on task everyone had to be. I suppose “let’s get this done in only 4 days” was a big push/motivation. 

  4. Michael Calkins on January 23, 2012 at 6:31 am said:

    This was an awesome idea and the environment of launching an application is amazing.  I want to see more languages getting into it!  Put me on the list for future idea week beta testers 😉

  5. Anonymous on January 23, 2012 at 4:25 am said:

    This looked awesome….I was excited to try it. Then it asked me to login with facebook and that’s the only way it looks like you can login. So I closed the tab without trying it unfortunately, never to return…

  6. Hi Jim,

    As a project manager I am interested in knowing more about the Project Management of this project. What kind of project management methodology you used to manage this project? Agile? And do you think that following a certain PM methodology was instrumental in finishing the project in such a short time span?

    • We didn’t use any particular PM techniques on Code Racer. Alan was tasked with keeping track of the project as well as doing development. We had daily stand-ups, which helped the team get an idea of where everyone was at. There was only 3 meetings, so they were pretty course in given how short the timeline of the project was.

      For the most part we just jumped in to coding. Since we only had the week to work on it, we really only had time to get the essential functionality built. This means we didn’t have to spend too much time deciding on features, we just worked to get something that worked at all.

  7. Guys, check the 2nd video at 1:14! So hilarious! 🙂 

  8. Alejandro Ñáñez Ortiz on January 22, 2012 at 4:10 am said:

    Great project! Hope to see more like this!

  9. Alejandro Ñáñez Ortiz on January 22, 2012 at 4:09 am said:

    This is such a great article!

  10. Very informative and inspiring!

  11. No offense, but it sucks. Plus you can’t deal with non US keyboard layouts, nice. Also, click handling is screwed up, dialogs for bombs can’t be closed, why can I bomb myself? Why can I do it twice if I have just one bomb? Why isn’t the dialog closing the first time I do it? Oh, there wheren’t any players, either.

    • Sorry you don’t like it. Most of the things you listed would are bugs. We’d be interested in hearing more about them. Given the short timeline, we couldn’t shake out all the bugs as we would have liked to. We just had to launch.

      If you do have a moment to send use a little more info about the problems you encountered, we would really appreciate the feedback. jim@teamtreehouse.com 

      Thanks for taking a look, and for your feedback!

  12. Anonymous on January 19, 2012 at 10:52 pm said:

    Good explanation of the tech used.  Very interesting, thank you!

  13. Štěpán Hruda on January 19, 2012 at 10:21 pm said:

    Brilliant idea and execution. I love it, keep it up!

Leave a Reply

You must be logged in to post a comment.

man working on his laptop

Are you ready to start learning?

Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Start a Free Trial
woman working on her laptop