TL; DR: I made a game, play now: Name, Place, Animal, Thing!

There are two things I’ve done quite a bit in this time of social isolation — catch up with old friends and play a ridiculous amount of Skribbl.io and Ludo King with said old friends.

During one of these late night catch-ups, someone suggested that we play “Name, Place, Animal, Thing” — a multiplayer game we used to play in our middle school notebooks. For those unfamiliar with the rules, here’s a watered down version — the game lasts over multiple rounds, and at the beginning of each round, you get an alphabet. You then have 60 seconds to think of a “Name”, a “Place”, an “Animal” and a “Thing” — and note down words for each of those categories, but only words that begin with that letter. The person who gets the most correct answers over the course of the game wins. Easy enough!

Except, I couldn’t find an online version! Now what do we do? Wouldn’t not building my own online version of the game be an insult to my craft?

But what does making a game even entail?

I have no idea. Game design? UI design? Icons? Graphics? Avatars? Writing the actual code? Let’s organise our thoughts a little bit.

Defining Requirements

The first thing I needed to do was define gameplay and outline a set of bare minimum requirements for the game to be playable. Let’s break it down.

Game Setup

• The game has to be multiplayer and sync between people real-time across different geographies (Hello, sockets!)
• For starters, I only want the game to be playable in small private game rooms.
• A player (the admin) would be able to create a new game room, which would generate the game code that could be shared with up to 10 people who will be able to join the game and play against each other
• The admin would be able to define the number of rounds per game and the additional categories (besides name, place, animal and thing) in each game

Game Play

• At the beginning of each round, a random alphabet needs to be selected — Once an alphabet is picked, it cannot be picked again
• The rounds need to be timed at 60 seconds, but the timer stops as soon as the first person submits their response
• Once all responses (or really, the first response) is submitted, we move to scoring
• For starters, the game would be self scored — players are able to give themselves either 0, 5 or 10 points. 10 for every correct answer, and 5 for every answer they share with someone (I went back and forth on this. I think there is value in people scoring each other instead of themselves, but I didn’t want to add that complexity just yet — I also toyed with the idea of automatic scoring, but again — too much complexity for version 1)
• Once all scores were collated, each player would be able to see everyone else’s score and then start the next round (I think having the ability to reject someone’s inputted score could be a possible update for future versions, but we’re keeping it simple)
• and repeat! Once all the rounds are over, the game ends and the person with the highest score wins the game

Designs

Now, I am most definitely not a designer, but I wanted the game UI to have a notebook-y feel. I also am not a fan of (but mostly don’t know how to design) big and complex UIs. Let’s take the minimalistic approach (can you sense a pattern?):

• I wanted the game to look careless — like it was handwritten on a sheet of paper
• Fonts are important! I searched long and hard(ish) on Google Fonts, and went with Schoolbell. Since the game UI is not very complex, the font really would have to take centre stage
• Time for some icons and graphics; I found some hand-drawn icon packs on FlatIcon that I could use for buttons and user avatars Et voila!

Tech Stack

Real-Time Communication with WebSockets

I am primarily a front-end engineer (with some back-end exposure), but this mini project would require a server that would enable players (we’re going to call each player a ‘socket’) to real-time communicate with each other. I was aware of the WebSockets protocol as a bi-directional communication solution, but had never implemented my own. I decided to go with Socket.io, a library that uses the WebSockets protocol to enable communication between the browser and the server, and also adds some additional features (like fallbacks, automatic reconnects and broadcasting to multiple “sockets”).
JavaScript always has been my language of choice and I didn’t want to make the learning curve steeper than it already was. The back-end would be a Node.js server using socket.io.
The internet has a plethora of resources written by competent backend engineers, so I will not go into the details of Node.js, WebSockets and Socket.io.

Front-End Implementation

I used create-react-app to bootstrap the project, but once I was done with the basic functionality, moved it over to Next.js because of the supposed improved SEO performance (my game did start indexing higher on google after this, but this was not a controlled experiment so I can’t really say).

I’ve also become a big fan of styled components, and having my CSS scoped to single components has really improved the developer experience for me. I don’t think I will be going back to the world of chaotic stylesheets anytime soon.
A couple of weeks in, and I managed to actually produce a playable v1 which I have been testing with friends and co-workers. Testing with actual people instead of repeatedly playing the game against myself has been a very insightful experience — I could write an entire post on that in itself — and I’ve got some really thoughtful, constructive and actionable feedback that I would like to take into future versions of the game, but for now, the first version is online and playable here.

Thoughts and feedback are always welcome and appreciated. Happy playing!