#switchonyms

Switchonyms is not the first of these games I've made. Ever since Diamond Checkers, I've used a 4-character game id as a join mechanism:

With 26 letters and 10 numbers, that's 36 ** 4 possible combinations, all but guaranteeing no overlap between active games.

In my database, or in this case, the local memory's database object, these game ids become parameters that reference the entire game object. In the url, this route becomes a database lookup.

My friend Max told me all the way back with Diamond Checkers that I should stick to letters, to avoid questions about Os and 0s, Is and 1s, etc. - especially with the fancy fonts I find. But I was sure I needed that extra space just in case I got a lot of users...

Listen. ... Okay? Okay, I might have made a mistake. So... for the obvious user experience improvement, I'll go back to my old apps and update them - so enjoy those letters next time you play!

tl;dr: the experience of actual users is more important than the functionality for potential ones; CoColors' 8-character <canvas> ids were even worse; but in general, this Jackbox-esque game id idea is awesome

This is a big one: a real-time, in-person, multiplayer mobile word game. I call it Switchonyms.

There's a lot to talk about, more than I can put in these three posts, so I'm going to focus on the core components that make this project unique. But for those interested: this code is raw nodeJS, with web socket(s) powering the real-time back-and-forth of a fast-paced party game about guessing words. 

Let's say your friends are trying to guess the word on your screen. You can't say it, but you can give clues that hopefully spur someone else to say it... but what if you get stuck? Well, check out this switch <button> (top-right):

This triggers a socket.send() that requests a new word from the server, where I've got a big dictionary of nouns, verbs, and adjectives - for rounds 1, 2, and 3, of course.

Since each list is just a giant array, I can write a function to select a random word out of it:

Then update the global game object (making sure that word isn't already there)...

...and send that word back to the player...

...which updates the view, by both changing what word is visible and setting the style of the switch <button>:

Originally, switching meant swapping words between players - but that just meant someone else was stuck with it! After lots of play-testing, this is much, much better. Code-wise, a similar process happens when a word is successfully guessed... but more on that in part 2!

tl;dr: websockets allow for instant two-way communication between client and server; build helper functions, like chooseRandom(), for things you do often; use arbitrary attributes as CSS selectors

In Switchonyms, you get points by guessing a word, and you lose points the longer you take to get someone to guess your word. Chaos is achieved by giving two people words to get rid of. But who gets ‘em?

Before that "guessing" phase, there's this "matching" phase (above), which produces, as its output, two players - each of whom gets some points!

Everybody gets a word - a word shared by some other player. Actually, in order to make it work, everyone needs two words - the logic ends up looking a lot like the matchmaking code I used for Secret Santa last Christmas.

If you touch a player's name (on the front-end)...

...the server stores that info in the game object (on the back-end)...

...and, if the right opponent selects you back...

...then you both get points! The rest of the game is a modified version of this - you touch the name of whoever guessed your word, and they can CONFIRM if they actually did.

What are you waiting for? Go guess some words!

tl;dr: you can create a continuous chain of matches between players in a group of any size; “click-to-confirm” was a necessary v2 feature; keep track of who selects who as you go to know when they've found each other