[Bernardo Heynemann] fightcodegame.com – a story of fun, iterative development and a boatload of javascript

fightcodegame.com is a game where you use your javascript skills to code a robot that goes into an arena against other robot.

It’s a project for the Github Game-Off 2012 contest. It’s a different kind of hacking contest, in that you have a month instead of a day, two or a week.

It might seem like a minor detail, but it makes all the difference. At least it did for our team. We worked it like we would any other iterative project we might work with at our daily jobs.

The team is composed by myself, Cezar Sá, Guilherme Souza, Fábio Costa and Rafael Carício as devs. The incredible designer Marcela Abbade did the layout for our product.

A small team set for building a product that we didn’t actually believe could be built in such a small timeframe.


fightcodegame.com was developed iteratively and uses Javascript for both client and server.

We run node.js at it’s serverside components and the code for the engine is EXACTLY the same running in the browser or the server.

This was the first time I actually benefitted from running the same Javascript in the server and the client, so I found it interesting enough to share. The code can be found at https://github.com/timehome/game-off-2012.

How did you come up with the idea for it?

As all such ideas begin: in a table with friends. Someone said: “What if we did an arena where robots fought each other and you did the robot coding with javascript?”.

We all laughed like “yeah like that’s possible”, but the idea started growing on us. A couple months later and here we are.

Some Stats

Before I start I’d like to share some stats with you, because I’m actually very impressed with them.

At the time of this post, we have in the database more than 1500 fights.

Since we launched the website at 4pm of the 28th of November (date of the first fight in the database), that means roughly 14 fights an hour. It’s A LOT more than we expected.

We also have more than 200 people registered and above 150 robots created. Amazing, right?

What REALLY got me, though, is our stats in Google Analytics:

  • About 1000 visits in just a couple days;
  • About 500 unique visitors;
  • More than 11 thousand page views;
  • An incredible average page duration of 11 minutes;
  • Bounce rate of 30%, which means that most people entering the website navigate through it.

I gotta say that again - 11 thousand page views. Even if that counts our own page views, it’s still amazing in a couple days.

You said iterative?

Yep, we worked VERY iteratively. First, we didn’t have anything. Then we had the engine. And then we had the animation.

We spent the whole month of the project iterating and improving over the previous iteration.

And you know what? Iterative development CAN be fun. People spoil all the fun with metrics, meetings and other useless bureaucracy.

What about the game?

Well, the game is pretty simple. Build you robot, we’ll run your code against the other person’s code and see who wins. The easiest way is to go there and play a little bit.

What’s really interesting about it is how we calculate things and how we render the fight in the browser.

The first peculiarity about our game is that it’s engine needs to be 100% deterministic, since we can’t have different results in the server and the browser.

What that means is that we DO NOT store the rounds of the fight. We calculate them in the server based solely in the code of both robots and some initial info (like robots positions).

The engine is 100% javascript. That helps us A LOT in running it in both the server and the client. We used Coffeescript for it and were very positively surprised. If you are wondering what the engine looks like, go take a look at it.

The Engine

fightcodegame.com‘s engine is a turn-based engine. It might seem realtime in the browser, but it’s not. I’ll cover how we do it’s animation below.

The engine loops on the robots codes, logging everything until one of the following happen:

  • Only one main robot (not a clone) is left alive;
  • The fight times out (after a fixed number of rounds), in which case it’s a draw.

The really interesting part of the engine is it’s code: collision detection, line of sight and a lot of interesting stuff there. The end result is an array of rounds that will get passed to the interface to be animated.

The code for the engine can be found at the engine.coffee file.

The Animation

The animation part was tricky for myself, since I didn’t have much experience with RequestAnimationFrame. I couldn’t be more pleased. It was so easy making animation that actually renders the same across different computers.

Other than animating, we calculate the fight (run the engine) in WebWorkers so that we can maintain a responsive UI even when hardcore CPU cycles are being demanded. If you haven’t tried them, I seriously advise you to play with this amazing browser technology.

The fight goes like this:

  1. WebWorkers calculate the entire fight;
  2. We animate the resulting rounds with RequestAnimationFrame.

The RequestAnimationFrame method takes a callback function as argument. The function should receive a timestamp that represents the time at which the animation you requested is scheduled to occur.

What this means is that you can easily find out how many milliseconds of animation you have to run in this “step”.

In our case, we just subtracted the timestamp from the last processed timestamp to find out how many rounds should be rendered by the browser.

The code for the main portion of the animation is in the  animation.coffee file.

What’s next?

I have an amazing robot and I want more! What’s next?

Glad you asked. I’m not sure what’s next. If you feel that there’s something missing, please feel free to create an issue at our github repository and we’ll consider it for our next release.

Right now we can’t do anything. We have to wait until the judges try the app for themselves.

Hope you guys have as much fun as we did.