Design, Technology

Hello World Open – A Story in the Visuals: The history

October 27, 2014

Read time 6 min

It was a simple idea that blew up into a worldwide competition in programming.

At Reaktor, we arrange internal retreats called Code Camps every year. It’s a way for us programmers to get together and relax while doing what we love. In 2012, we wanted to broaden the audience, and that idea developed into the Finnish Championships in coding – and it turned out to be a huge success. That’s when we wanted to make it even bigger.

The end result of all this was an epic event called Hello World Open, the first-ever Coding World Championships. Hello World Open took place this spring, and we had about 2500 teams participating from all around the world.

We knew we wanted to make a car game but there were two crucial constraints: the game had to be simple enough to easily get into, but hard to completely master. Slot car racing was the perfect match, because there are few controls, but the end result is complex enough for a coding competition.

First, we needed to test the concept internally: we called it the Reaktor Turbo Challenge. Not one but two Code Camps were held to put the slot-car racing concept it into a real-life test. Both were resounding successes, and emboldened by them we set out to create an international coding competition.

This is the story of how the visuals of the competition came to be: a team effort of gargantuan proportions and forays into bleeding edge technology, all done in the browser. But first, a little bit of history.

image00

When we set out to do the race visualisations for the qualifications and finals of the Hello World Open competition, our primary concern was the very limited time we had. With a hard deadline set for both the qualifications and the finals, we decided that we’d go with a simplified 2D visualisation for the qualifications and use that as a building block for the 3D visualisations that would then be used in the finals.

During our internal Code Camps we had made prototype 2D and 3D visualisations, and these prototypes were used as a basis for the new visualisations for Hello World Open. Our experiences with the Code Camp prototypes gave us a clear view on what worked well and what didn’t.

image10

One concept we brought over from the original visualisations was the configurability of the race track themes through JSON files. Themes allowed us to change the look and feel of the track; we had, for example, themes with a snowy feel, themes with desert tracks and even space races. Having the themes as separate files also allowed us to parallelize the work: some people could work on the engine, while others could tweak the textures and styles. Thus, we already had something to work with—a prototype, if you will.

The Code Camp visualisations were originally built on two different code bases (a 2D implementation and a 3D implementation), so we decided to combine them. In order to do that, we created abstractions in the code to enable handling either streaming live data in real time or load pre-recorded data. Another abstraction we added was that the visualisation could run in either 2D or 3D. This let us use common elements such as rankings, lap indicators, start lights and other hud elements in both visualisations.

image11

Another major change pertained to how the game messages were consumed. As may already have been apparent to some viewers, the qualifications of Hello World Open weren’t actually live: instead, recordings of the races were simply published on a schedule. All the races had been run earlier, and all the server messages had been recorded into a JSON list for each race. The server informed the clients of the current tick when they opened the race visualisation: the visualization could then seek to the correct position in the recording.

This, however, posed a few problems, because the protocol used in the messages did not contain the full state of the game. The protocol contained only individual actions such as crash or turbo events of certain players, in addition to the positions of the players. As a result, to accurately seek to a certain position in a recording, some types of events had to be searched all the way from the start until the seeked position, while some other events—such as car positions—could just be retrieved from the last occurrence of such message.

A typical race recording could easily be around 2 MB gzipped (roughly 25000 events), and in extreme cases, much larger. Once the recordings had been correctly replayed internally to the current state, the remaining game messages of the race recording were buffered to the visualizer in real time using the display refresh rate cycle (requestAnimationFrame call).

On a technical level, all the event handling was done using Bacon.js event streams. These streams were then filtered, combined, throttled and hooked up to handler functions which updated the visualisation or internal data state. This allowed us to neatly separate event sources from the actual handling logic and to produce streams with full data instead of individual events.

During the finals, when the races were actually running live, the game messages were sent to the visualizer using web sockets. Because the frequency of these messages was in no way guaranteed to coincide with the display refresh rate, the messages were immediately consumed on arrival. They would update the state of the game such as car positions and rankings, but were still rendered at the display refresh rate. In other words, we could have internally updated the car position multiple times before a single display refresh was done.

We also changed the 2D canvas implementation to use KineticJS for easier layering, faster development and easier implementation of various graphical effects. While the visual changes we made for the 2D visualisation used in the qualifications weren’t significant, we had changed the architecture of the visualisations to make it significantly easier to work on the 3D implementation. The goal was to use the 2D visualisation code to generate various textures, such as color and lighting, and track coordinates for the 3D visualisation.

image05

Other parts of Hello World Open – A Story in the Visuals series

  1. The History
  2. New Dimensions
  3. Art and Assets
  4. Lights, Camera, Action!
  5. In Retrospective

 

“Hello World Open – A Story in the Visuals” is the story of the game that was built for the Coding World Championships. The series consists of five parts and it was written by members of the HWO technical team: Harri Salokorpi, Niklas von Hertzen, Teijo Laine and Tuomas Hakkarainen. The text was proofread by Eero Säynätkari. 

Never miss a post