How To Quickly Build A Virtual Drinking Game During Quarantine

Jordan Theriault
The Startup
Published in
5 min readJun 10, 2020

Every good story starts with a wild night, and this one is no different. My former coworkers and I get together frequently online for socials. We loved working together and still try to see each other as much as we can over glasses of wine and cold beer. In lieu of trashy Toronto bars (which in fairness we seek out, RIP Croc Rock), we have been meeting virtually now for several months and have been discovering creative ways of playing games and spending our time.

Lears Cup

So what leads to a 1:00 AM requirement documentation session?

On a particular night after endless games of Jackbox (a not-necessarily-drinking video game where people can play together remotely), we shifted and tried some online drinking games to kick up the notch. We tried DrunkPirate, Drink Virtually, and Picolo among others.

The problem was, we weren’t satisfied with the features and rule sets of the games.

  1. What if someone needs to use the toilet and misses a turn?
  2. How do you remember who’s turn it is easily?
  3. Why can’t I add/remove players at will when someone goes to bed for the night?
  4. You can’t remotely do a lot of rules in these games like switching a piece of clothing.
  5. Why is this game so plain and unappealing?
  6. We keep repeating the same 50 cards.

These questions build the requirements, and playing all these online drinking games was our initial requirements gathering. By using Google Sheets we started drafting our concept, requirements, and card rules. We decided we would recreate the classic drinking game Kings, and make sure it was easy to play virtually. We wanted to get it done fast so we can start enjoying it.

Product Vision Statement: “For long quarantined friends to have social drinks seamlessly”

Organize Your Thoughts

We started off by organizing our ideas into two categories. Features, and King's rules. We listed every single idea from the first session and everything we could think of for the game once we sobered up. This gave us an unruly list but we’ll deal with that next. By categorizing these concepts into their own cells in Sheets, we could all collaborate quickly with our ideas asynchronously. During the day ideas slowly began to appear on the sheet, like wonderful, nerdy magic.

Google Sheet Requirements Document
Google Sheet Requirements Document

What is the Minimum Viable Product?

Minimum viable product (or MVP). That’s the key to launching a product in a reasonable time-frame. You will always have a long laundry list of features. But at the core, you need to ask yourself an important question. What truly belongs in the first iteration of an application? What can be cut? How do I start playing this with friends ASAP?

We started by determining what was technologically viable given our time constraints. For example, multiple users connecting to the same URL and flipping their own cards was complicated to do and didn’t add value to the game since our users would likely already be on a platform that allows screen sharing. Then, we looked at what features were core to the concept. What does this application need to function? Next, we decided on what features would have the most impact on our users.

User Stories and Atomize

Now you can create user stories. There are so many right ways to do this that are prescribed by some amazing agile books you should definitely read. We however broke all the rules. You could write a beautiful user story like so:

As a user, I want to be able to remove players so that going to bed doesn’t disrupt everyone else’s game.

Or you could just be generic and quick because it’s a small app, and nobody is perfect when they’re doing a side project. Aim for what will be descriptive enough to get the job done if you’re short on time.

Trello Kanban Board
Trello Kanban Board

Develop and Design

Yes, development and design can’t be done in parallel. The code should be flexible enough to handle design iteration. While the designer was creating wireframes, we began developing the application’s key features such as the rule display, card flipping, local storage, and players.

Design paralysis is a real thing, and often the nuance of design can get in the way of good programming. By separating these two concepts, it’s easier to forge forward.

We are primarily javascript web developers so we selected React as our front-end framework. We’ve programmed many apps using Angular, but we like the combined view and controller that JSX brings to the table. We began with the base project create-react-app. This allowed us to hit the ground running.

Since Github allows private repos for free, we also used that. Git is a critical tool for collaborating with other developers.

Soon into developing the app, we realized there was a need for storing the game state. What if someone accidentally closed the browser? What if they want to resume the session later? We swiftly added Redux to handle states.

We knew we wanted some minimal transitions but didn’t want bloat. We stuck to using CSS animations to make them quick to render. Redux states trigger these animations.

At this point, the application was shaping up, but separately. Neither was perfect. But once combined, the game took a beautiful shape.

For design working quickly is key. Using Sketch for rapid wireframing, Illustrator for icons, logos and illustrations, and InVision for presenting the designs so developers can easily see the exact pixels of the designs is incredible.

Test and Iterate

“Will this game get people drunk too fast?” — An actual question we asked

We needed to discover what works and what doesn’t. The fastest way to do this was to invite as many former coworkers as we could to help give us feedback. This gave us a wide range of people to test with and we received the most valuable feedback the first time we played.

In every case, we encouraged people to give us brutal feedback. We actually came across an interesting revelation: friends don’t want to hurt your feelings and will not give overly specific advice. Peers are brutally honest. Use that work network to build your bug backlog. Nothing is ever perfect on the first iteration.

Over the course of two weeks, the app was done, over the course of the next two weeks, we tweaked the app. By the end, we reached our MVP.

The result is Lear’s Cup, and you can play it here, it’s free.

--

--

Jordan Theriault
The Startup

Web software developer, leader, speaker and writer. Lover of horror games, craft beer, and rock climbing.