Cloud cup: a multiplayer set of mini games for web and Android

I’m glad to present the work of a week-long hackathon I did last November with three other googlers.

I’ve been having for a long time the idea of a real time game using phones as controller and a big screen as the main game screen. You may recall a previous blog post about a first prototype. A few years later, I could pitch the idea at an internal hackathon and gather a team around the concept. While I initially wanted to build a dancing game, I realized that this was already done, so we decided to go towards mini games, an idea very compatible with a hackathon timeframe.

Realizing after a day that we would not be able to have a reliable and scalable real time architecture and a fun game after just five days using regular backend technologies, we decided to focus on the game itself and to use Firebase to handle the real time and backend parts of our system. It allowed us to get familiar with this very interesting technology. I already used Parse in the past, while they both fall into the Backend as a Service (MBaaS) category, I could notice with pleasure that Firebase was able to perform as well as Parse for the regular MBaaS features (and even better to my taste, by providing an Angukar SDK) but that it also provides impressive real time capabilities.

After a single day, we had a functional prototype of our game: Android phones were interacting in real time with an Angular application in a “Shake” game. The next three days were spent creating other mini games and streamlining the game mechanism.

And we won the Fun category!

While the hackathon was internal, it was not a problem at all for Google to let us open source and release our work to the public. You can find the sources on GitHub: Android and Web. Firebase showcased the project on its official blog.

Try it now: Install the Android app, and visit to start a game.

I hope you like it.


How to generate a maze?

We had with Anne a 5 hours train trip and took the time to think about how we would proceed if we had to generate a maze.

First, we had to think about our problem: there are plenty of types of mazes. We decided that we would only consider mazes on a cartesian grid (no circle or bended walls). It can be different to start with a fixed start and end or just to fix the start, we decided to only fix the starting point, and to consider that the end would be the point the farest from this starting point.

An example of generated maze.
An example of generated maze.

After quickly setting up the rendering using HTML canvas (it may have been smarter to use SVG by the way), I set up the data structure : matrices (double arrays) for holes, horizontal and vertical walls

Then we arrived to the interesting part: our algorithm. We decided to consider a growing strategy: We start with a filled black canvas, and “grow” tunnels starting from the start point.
We keep in memory a list of “tunnel ends”, which are the point we are currently continuing the tunnels from.
At each iteration, we determine, with some probabilities, for each “tunnel end”: if the tunnel should continue in only one direction, split in two or three (if possible), the direction the tunnel should to continue to.
If a tunnel end encounters a dead end, then we remove it from the list of tunnel ends to consider for the next iteration.
We may end up with no “tunnel end” left, in that case we pick a random point on the current maze that is next to a “black” square, and we start a new tunnel from this point. This last condition is here to make sure all the available space will be used.
For each “tunnel end”, we also keep in memory the distance from the starting point, and store this distance for all square of our maze. This allows us to select an end when the generation is done.

But what makes a maze interesting? As a human, a maze will be difficult if when you encounter an intersection, your brain cannot easily determine on which direction to go. For example if you clearly see that going left will end up in a dead end in a few blocks, then you will chose right.
To achieve this, we adjusted some parameters in order for the maze to generate long and not obvious branches. We had to set the probability to split to a low amount, and had to keep in memory the overall tunnel growing direction and to make it prevail when selecting a direction in order to prevent the tunnel to collapse on itself too often.

Screenshot of the maze generator app.
Screenshot of the maze generator app.

Because something is not done until it’s pushed and shipped, I took a few more hours to put the result online and in a Chrome Packaged application.

The application is very simple: it generate a maze of the size of the window. To control the difficulty (size) of the maze, just resize the window.
I may add in the future more interactions and printing features.

The code is separated in two files, a standalone maze generator and a maze renderer.

Try it now

Square of the Dead

or “28 check-ins later“…

This week-end, I participated to the foursquare global hackathon. I worked with Jean and Olivier on

I’ve been having an idea for a long time: imagine a virtual virus that is spreading due to our social interactions. Wouldn’t it be great to see it spread and to see how people react? Foursquare was the ideal product to build upon. So I pitched a crazy idea about virus and zombies, saying that a game mechanism was still to be defined.

Inspired by zombie movies, we worked a long time to define a simple game pluggable on foursquare. After a couple of iterations, we came up with a simple system:

Square of the Dead, rules

Players can either be survivors or zombies.

  • When you are a zombie, you contaminate every place you check into. Your goal is to spread the virus.
  • When you are a survivor, you get contaminated if you check into a contaminated place. Your goal is to survive, for this you can find guns in non-contaminated places. These guns will allow you to de-contaminate places and transform zombies from these places into survivors.

The game do not require so much actions from the players, they just have to keep using foursquare to play. We minimized the problems by adopting a cross-platform notification system that everyone is already using: emails.

Technically, we used the Play! framework deployed on App Engine using Siena. I ran into a bug that made us lost some precious hours.

We will polish the game and maybe come up with some nice other features (like a map to see the virus spreading all over the world!).
Try “Square of the Dead” now.

Olivier, designer, also blogged about his experience.

Working on the project, picture by Le Camping

I really enjoyed the hackathon. Other projects were really great. here are my favorites:

  • 4sqBox: receive files when you chek-in somewhere
  • fstalk2her: check the boy/girl ratio before going into a bar and see what you have in common with these people 😀
  • Check Me In: Check-in just by facing your smartphone in front of the venue’s iPad (use case: you have no network)
  • Gettogether: very slick mobile app to organize something with friends.


I’ve been hacking on a little project during the summer. The idea is to use the phone as a remote controller for a game displaying on a screen. I’m building a dance game, where the players’ goal is to follow a dance seen live in a video.

I’m using the accelerometers of the phone to record the movement of the players. Then I compare this to the reference movement of this video. If the movement match, the player earn points. The best dancer win at the end of the game.
Technically, the main challenges are the processing of the accelerometer data and communicating in real time.

Accelerometer data from the phone: I could use the native APIs and build a native app, but Phonegap is providing an accelerometer API, so I could build my app once and use it on many platforms.

Data comparison: I have to use well thinked descriptors to compare the recorded data to the reference. I will start by detecting the “bumps”, their direction and their amplitude.

Live communication: I’m using some real time technology to make all the device communicating with a server in real time: my choice is to use node.js and the library (and to ideally use web sockets).

Data store: the library of dances will be stored in a no-SQL database. My choice is to use mongoDB.

Record a dance: one last challenge is to record the reference dance for a given video. I will try to use some simple machine learning algorithms to extract the reference from a set of records.

You can follow the development on my github.