2020
Project & Technical Lead
Figment Labs
In mid 2020, Stage 4 lockdown in Melbourne meant that people were separated from their friends and their loved ones. While brainstorming fun activities for our friend group to participate in for our weekly Zoom catch ups, I proposed an idea to create a virtual escape room – and it all snowballed from there.
Space Race needed to be a digitial experience nothing like what was already out there. We wanted players to work in teams to complete a series of challenges strung together by a central narrative, yet the puzzles themselves needed to be scattered across the vast expanse of the internet. We wanted interactions to be real-time, and needed it to feel as if you were participating in this event as a team of up to six friends, but also along with dozens of other teams across Australia.
This came down to three key features that made Space Race unique:
As the co-project lead and technical lead for the event, I was responsible for bringing the vision for this project to life, while creating the platform and relevant infrastructure to enable the event to run with hundreds of concurrent users in real time.
With a tight turnaround of just three weeks, myself and co-project lead May Ou assembled a small team of puzzle makers, designers and marketers within 24 hours to help bring this project to life. Below are some of our marketing posts featuring Astra – our Space Ship inhabitant which participants were helping escape from its ship.
With this short of a time frame to build out the entire platform, I knew I didn’t want to worry about complicated load balancing and ensuring services wouldn’t go down at scale. I had previously worked with the Firebase ecosystem and thought it would be a perfect solution for managing Auth, Database and API services due to their serverless scaling, great documentation and fully featured SDK.
Vercel helped a lot with the one-click CI/CD with Github integrations. We ended up having several frontend SPAs for the challenge (for pre-release puzzles, for the platform itself, for the pop-up log system) and all of these were seamless to set up and point to subdomains through Vercel. You can see all of our separate frontend instances in the attached gif.
I separated these requirements out into separate tasks which could be worked on incrementally and upgraded iteratively throughout development. I wanted to showcase some cool features below.
We needed the registration flow to be as simple and frictionless as possible. Once participants purchased a ticket through Eventbrite, we would add their details on to the game platform database. Participants could easily log in by entering their email address which they used to purchase their ticket and clicking a single-use sign in URL which would be sent to them. This was super simple thanks to Firebase Auth and their amazing SDK.
Once logged in, they would be prompted to either create or join a team. Teams were identified with a unique ID which could be copied and shared with fellow team mates. By either creating or joining a team, the client would immediately start a subscription to the relevant group Firestore document. This meant that any changes to the group (members joining/leaving, changing the group name, completing a challenge) would immediately propagate to all subscribed clients and refresh the UI without reloading the webpage.
After teams have formed groups, at exactly 7:30 PM they would be able to access the console and begin the mission. The mission was separated into three stages, with each team having to complete all the compulsory challenges in each stage to progress to the next stage.
These challenges needed to be updated real-time so each member of the team could immediately see which challenges were being worked on and which have been completed. This was made easy through additional Firestore subscriptions based on which challenge document the player was viewing.
A key requirement of the Space Race platform is that you should be able to work together with your team on challenges. By entering a challenge view page, players immediately subscribe to the group-specific challenge document /groups/<groupId>/challenges/<challengeId>
. This means that any actions (submitting a solution or releasing a hint) would propagate to all other users currently viewing the page.
A single attempt by a teammate would lock submissions for all team members for 10 seconds. This lock/release system was also used for hints. Each challenge has a number of clues to help teams progress through puzzles which release on a time delay. These hints are locked from teams on a database level through Firestore database rules – no complicated logic to restrict access from sneaky hackers!
Early on I realised that it would be a huge pain to manually enter and edit puzzles every time someone wanted to make a change. Throughout the puzzle development process we iterated multiple times on puzzles. From wording, to the hint release times, to the layout of the text itself, if I had to manually make all these changes on the platform, I would lose valuable development time necessary to work on all the other features.
Thankfully I was able to spot that this might be a pain point early, and spent a couple of days creating a puzzle management system to allow the puzzle team to quickly edit all aspects of the puzzle document. The puzzle team could now edit the title and description of each puzzle, manage all the formatting of the puzzle content through editing their content in markdown (powered by Remarkable), and also create and edit hints for the players and the amount of time they had to wait before the hint was released.
Initially, no one really knew what we wanted to do with the livestream. Other than showing a leaderboard and occasionally announcing teams who have progressed between stages, all the cards were on the table as to what we should do to create a sense of community for the event.
An idea that was being thrown around was to allow teams to submit drawings to the livestream, some of which would be assessed and bonus points would be awarded. This ended up being far more successful that we originally imagined, and we received hundreds of submissions from teams throughout the night, which were showcased and commented on by the stream presenters.
By using the react-canvas-draw library we were able to capture the canvas drawing history and recreate the drawing process on stream, which added an extra element of anticipation and interactivity in comparison to sending static images of the complete drawings.
I’m super proud of this system. On the backend, every time a team sends an attempt to our submit
cloud function, it publishes a message with their attempt data to a GCP PubSub topic. An additional cloud function listens to submissions to this topic, and sends a notification to the Discord webhook.
This decoupling of the notification service meant that we could easily add/remove/mute notification systems on the fly by updating the notification handler and not touch the critical submission system code. We wanted to make a Stream Labs integration for this as well to show progression directly on the stream, but we unfortunately ran out of time before the event.
The event was a huge success. Thanks to the reliability of Firebase and Vercel, as well as their out of the box scalability features, the event ran without any technical hiccups! I’m super proud of what the team was able to pull off in just three weeks.
To wrap it all up, I hope that I can continue to work on projects like this in the future. Bringing fun and unique visions to life to increase the net good in the world is what’s most important to me in any project. I hope I can carry through this ethos in both in my future side projects and professional work.
Here’s a little screenshot of a zoom call with (some) of the Figment Labs team! View a list of all of us here.
Play