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.
A small team set for building a product that we didn’t actually believe could be built in such a small timeframe.
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.
How did you come up with the idea for it?
We all laughed like “yeah like that’s possible”, but the idea started growing on us. A couple months later and here we are.
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).
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 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:
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.
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.