For the past few months we have spent almost every lunch at WatchDox (by BlackBerry) playing “Fibbage”, a party game from JackBox Games. The concept of this type of game isn’t new, and is (probably) based on the 1984 Canadian game Balderdash.
The game is presented on a TV screen (via a connected laptop), and everyone joins in on their smartphone. Each turn a weird or funny fact is presented to everyone, but alas — the interesting bit is missing.
For example:
In March 2015 the Coachella and Lollapalooza festivals
decided to ban ________
Now this isn’t your regular boring trivia game where several answers are displayed and you need to select the truth.
In the spirit of crowdsourcing, all of the players input the fake answers (which they hope will fool the other players). In other words — they input bullshit.
Oh, and for you edge case aficionados, if you somehow manage to enter the truth (in the above example it’s “selfie sticks”), you will get an alert and asked to provide a different answer — an actual lie.
After everyone submitted their lies, all the different answers are displayed on the screen alongside the actual truth.
And now each player chooses what they believe is the truth.
Everyone’s goal is to fool as many players as possible, i.e — make them think their lie on the screen is the truth and select it, while finding the truth themselves (besides avoiding giving other players points, you obviously also earn points for finding the actual truth).
It can get pretty funny, and when you manage to fool all of the other players with your lie… well, it’s a deeply satisfying feeling :)
(Since today’s gamers want more than feelings: coming in a future release of Bullshit — achievements!)
Like a lot of projects, this one also started with the question “could we do it better?”
The first thing that bothered us (us being myself, @tomteman and @Radotzki) were the bugs in ‘Fibbage’. The game would often disconnect players mid-game, won’t let them reconnect, or would freeze when they tried to submit their lie or choose an answer. To be fair, they patched that up pretty well in Fibbage 2 which recently came out. But it drove us crazy. We kept saying — “how hard can it be to maintain a session?!”
The bigger problem however was with the actual content — the questions themselves. First of all, they’re in English and tailored for a US audience. Although most of us can manage, some people didn’t understand the cultural references, or even the questions themselves due to unfamiliar words. Spelling was also an issue for some players, since a typo was a dead giveaway that an answer was some player’s lie and not the actual truth (hence — no one would fall for it).
We even ran out of questions eventually! And once that happened, Fibbage simply recycled questions we already played, which was no fun at all.
To tackle all of that we built the “Questions CMS”. We want users to be able to not only add questions to the default categories (which we moderate), but also to create their own categories and questions and moderate them with their friends.
a CMS is like a modern web app’s ‘Hello World’
Given the nature of a CMS and the features it requires, it seemed like a solid approach for “kicking the tires” on all these new technologies we wanted to try out.
There were plenty of other features we felt Fibbage was missing, and most of them revolved around each player having a unique user which he will use every time he plays.
Having a unique user doesn’t only allow us to add things we all know and love from existing games such as leaderboards, achievements, etc. It would also solve an issue we ran into while playing at the office:
I would sometimes also play the game with my friends at home. However, that meant that the questions I answered with my friends would simply get skipped when we played at work (same steam account). If I were to use a different steam account, then Fibbage would replay questions I already saw, which gives me an unfair advantage.
By having unique users we’ll be able to mitigate that to some extent — when we initialize the questions for a game, we’ll try to maximize the number of questions that are new to all the players. And if we have to show a question already played by any of the players in the game, then he’ll only be able to submit a lie, but not to select an answer (since he already knows what the real answer is).
And thus, “Bullshit” was born.
obligatory link to the actual game
So what’s under the hood?
When we started out in June 2015, Angular 2 was still in alpha (alpha 38) and TypeScript was just starting to gain substantial momentum. Of course we could have implemented everything using ES5 and Angular 1.X, but where’s the fun in that?
We decided to try out Webpack (gulp was still king back then), and used the following github repo to bootstrap the project’s client side: https://github.com/AngularClass/angular2-webpack-starter
For our UI, the library of choice was Google’s Material Design. It still wasn’t ready for Angular 2, so we couldn’t use native MD elements, but only the css available through Material Design Lite.
Gotta keep that data fresh
Since this game provides a multiplayer experience, we need to constantly push game state changes to all connected users whenever any data changes.
So for example when one of the players enters his lie for a question, we need all other players to be notified of that, since each player should see who answered already.
Socket.io was an obvious choice, both client side and server side. If you are unfamiliar with socket.io, it allows you to utilize web sockets and easily push data to your clients (thus avoiding polling).
So our clients are listening for events on the socket, but how do we know when the data changed on the server? enter RethinkDB.
Besides using Node.js (written in TypeScript) on the server side, we have opted for RethinkDB as our DB engine.
RethinkDB resembles MongoDB since it also uses the document system (not an RDBMS), and the read/write queries are fairly similar. The big difference is that instead of polling for changes, the developer can tell RethinkDB to continuously push updated query results to applications in realtime.
We work with RethinkDB on our server using the rethinkdbdash npm package. It’s an advanced Node.js driver for RethinkDB with a connection pool, support for streams etc.
Authentication is pretty straightforward. We use Facebook as our OAuth provider, which takes care of all authentication related functionality. It also ties in nicely with our Questions CMS as users can easily invite their Facebook friends to moderate categories (become a category administrator). We intend to add more OAuth methods besides Facebook later on.
Modularization — the path to clean code
Through ES6's module system and webpack’s built in bundler, we were able to keep our code highly modularized, making sure all concerns are separated in an orderly fashion.
So now that we got an idea of what we’ve been working on in the past six months, let’s see some code in part 2!
Or … click here to play!
