By Marianne Maisonneuve

It all began when a peer at Moove-it asked me if I would be keen to participate in the Rails Rumble. The title rang a bell but I was not familiarized with most of the competition’s specifics. However, I was eager to join a programming contest, so, without a shadow of a doubt, I said yes.

What is a Rails Rumble?

Rails Rumble is a two-day programming competition where participants (generally teams comprised of anything in between 1 to 4 members) from all of the world are to deliver a compelling and catchy app.
The two paramount premises are:

  1. it has to be developed leveraging a Rack-based framework, and
  2. it is expected to be implemented in Ruby.

Once the 48-hours effort is over, jury is to vote for the app that impressed them the most. Finally, the ballot’s results are to be published in the form of a web ranking.

The process

A couple of weeks before the competition kicked off, we organized the team and debated the available options, dividing them into areas of interest. We evaluated the pros and cons of each one. We identified diverse target markets, e.g. Health, Society, Software Development, Work Productivity, etc.

At the beginning some of us would lean toward Health, nevertheless, in order to deliver something useful and appealing in the Health sector (as any other humongous and complex industry), one should be truly immersed into the subject in question. None of our teammates joining this year’s edition really owned such deep grasp of the Health context, though; therefore we rapidly discarded that idea.

Kick-off meeting discussing alternatives
Kick-off meeting discussing alternatives

We also thought about giving our project a social purpose by putting together something that could ultimately support the needs of the general public. Even though most of us were very enthusiastic about this approach, figuring out something meaningful to us in such short time was kind of unrealistic.

Another approach was to build something in line with the methodology and the processes that we promote here at Moove-it. Perhaps something in line with what was conceived in the ’14 Rails Rumble: Kaigi, a web app aimed to streamline remote retrospectives’ execution. Kaigi is indeed popular within Moove-it, since part of our team is scattered across Argentina. Moreover, the great majority of our customer base resides in the US.

With our eyes set on improving our process, the experience and the communication we keep with our clients, we had originally decided to implement an app for tracking our daily meetings. It mainly consisted of a Hangouts and GoToMeeting integration app, where we could write e.g. action items, sidebars; very much every aspects tied to the event itself, for every organizer and attendees to have. This one was our best shot for a while, nevertheless, it didn’t last long…

A sudden change in plans

A few days afterwards we had a follow-up meetup to finalize the idea and turn it into a tangible project. However, new views were thrown out to the table, making us realized we were not as enthusiastic as we were before, which then led us to scrap out our original idea and take a whole new direction. We were now all seeking for something, not only innovative and challenging, but also something that thrills us, something we could fall in love with and made us feel proud of.
We decided then to lean towards Entertainment. That was indeed the choice that suited us best, as we got rapidly flooded with clever ideas coming from everywhere; “Let’s do an arcade game…”, “It would be cool to bring zombies in…”, “Yes, a runner…”.

At the end of the meetup, we had entirely flipped the subject and agreed to build a Ruby-on-Rails “Zombie Runner” arcade, entirely operated from our mobile phones.

The preparation

It was now time to dive into the nitty gritty of the product we were about to build. We held a kick-off meeting with the UX/UI designer, so that we could shape the game’s workflow and overall behavior. We all reached to a common ground on the game’s modality: it will need to support single and multi-player. Besides this, the whole scope still remained to be nebulous.

By the time the kick-off was over, we had finalised the views, UI components and a draft version of the game’s interaction design. Moreover, we had reached an agreement on where and how buttons and transitions were intended to behave. In the end, a rough whiteboard diagram was our only asset, serving as our single input for our later identification and organization of user stories and tasks.

With only one week to go, we held a new gathering aimed to ensure everything was clear and ready for us to only stick to coding during those two intense days. We agreed to have two of us doing the backend, and the other two, the frontend piece. We also shared our views about the technologies to be used, how we were going to make the mobile phone behave as a joystick, and get everything seamlessly integrated with our Ruby-on-Rails app.

And the day finally came in…

I guess it was a mix of anxiety, enthusiasm and, at the same time, profound commitment towards this cause, what I could felt by only staring at each others that day. We were thrilled to be working together on something we truly liked.

When you only have two days to achieve such an ambitious goal of building from the ground an app, you need to be, more than ever, self-directed and proactive. Besides, you should pick your tools and process right at the very start. An over-structured approach may lead to unnecessary overhead on coordination and planning, making your entire project to fail. On the other hand, lack of a framework and consistent practices may also wind up in a wreck.

The team in action
The team in action

As a consequence, we decided to follow a Kanban-ish approach as a minimum viable process. Basically, we set up a whiteboard and divided it in two columns where we would place sticky notes. Left-side column for the TODO tasks, and the right-side area for the DONE ones. Since the four of us were physically based in the same room, we perfectly knew who was doing what, so we didn’t really need a IN PROGRESS column.

We strived to set achievable short-term objectives to keep us on track and make us feel as we were progressing at a good and steady pace. That helped us keep team’s morale where it had to.

Every now or then, our peers from Moove-it showed up to cheer us up -e.g. delivering pizza, burgers and other treats- making us feel extremely supported and comfortable; an instrumental factor in keeping us engaged and motivated.

These were two intense days of hard work and all-nighters. The first night, two of us did not get any sleep at all, while the two others passed out for just an hour. However, knowing that the whole team was behind us really payed off for all that lack of sleep.

As we got closer to an actual usable version, things suddenly become more and more exciting and fun. The first few test-runs were extremely encouraging. In fact, everyone who stopped by for a quick visit ended up playing with it along with bringing up suggestions.

The Grand Finale

We wrapped up 10 minutes before the official deadline. We rapidly delivered a fully-functional game which inevitably has lots of stuff to be polished, but, at the same time, looks good and entertains its audience.

We faced several issues closed to the end, though. Three hours to run and we still did not have the multiplayer modality ready. Essentially, we could not get to come up with a proper way to create the routes in order to sync the players. Anyways, in the end we were able to pull it off and proudly deployed, at last!

We also learned a lot. Understanding the key role of aesthetics in the Entertainment world was new for some of us. Furthermore, we got to explore the Pixi.js library (a 2D webGL renderer) to generate animations. I was even able to get a deeper understanding on how websockets work.

Even though we knew it entailed an ambitious endeavor, when completed, we felt very happy and proud to behold the result.

We were able to meet all of our set goals in less than 48 hours, because of hard work and, most importantly, teamwork, discipline and commitment. Overall, it was a great experience which I would certainly repeat.

Testimonials

This was my second time on the Rails Rumble. You know… when they say ‘Second parts were never as good as first ones’, well that’s not true in this case. I had a blast! On the first, I was more concerned about finishing the product than having fun and enjoying the ride. Also, the team decided to build a product a lot more compelling and more enjoyable than the first one, IMO. So if the question is: will you do it again? I’ll most definitely will.— Adrian Gomez, participant.

It was a great experience where we were able to work under pressure to release a great product. Given the nature of our app—a game—, it was even more enjoyable to develop and test. I will definitely do it again. — José María Aguerre, participant.

My experience in the Rails Rumble was very rewarding from all points of views. Sometimes, it is difficult to assemble a team to diligently work for a common goal, but in this case we could. Communication was key, due to the fact that we didn’t have much time and it also required a full time dedication. As a consequence, commitment was essential. To conclude, I can stress that it was indeed an enriching experience I would like to be part of again — Maximiliano Arcia, participant.

Play the game!

Zombie Runner is available online. I encourage you to write down your comments, ideas and questions.

Snapshot of Zombie Runner
Snapshot of Zombie Runner