Words With Friends 2 & How We Built Lightning Round

Words With Friends Engineering
Zynga Engineering
Published in
7 min readSep 4, 2018

--

Brian Liang | Architect

Peter Turner | Principal Software Engineer

John Bacon | Principal Software Engineer

In 2018, we’ll be celebrating our 9 year anniversary since launching Words With Friends on mobile. Since then, we’ve had 250M+ million downloads and have processed 70B+ moves. Since our initial launch, we’ve had a few sequels: New Words With Friends in 2014 and most recently Words With Friends 2 in 2017.

Today, we’re excited to share our journey of building one of the features for our recent launch of Words With Friends 2, Lightning Round. This was one of our most ambitious features to build since our game was largely asynchronous between two players. We’ll walk you through how we arrived at the idea from the early brainstorming stage to building and shipping the feature in our sequel.

The Sequel

We had a dedicated team early in 2016 exploring what our players would want in a new version of Words With Friends. We wanted to provide old and new players a new way of playing words. We had a hypothesis at the beginning:

“A fast-paced, multiplayer game mode will excite and engage new and lapsed players.”

We wanted the mode to cater to our competitive players as well as provide something new for our lapsed players to try out.

Brainstorming

On our team, we’re constantly sharing ideas with each other, often through our internal, team-wide distribution mailing list.

One activity we all like to participate in is our brainstorming sessions. We gather people from all disciplines and walk through a few exercises to generate ideas for the team to vote on. From our brainstorming sessions we arrived at two ideas:

Multiplayer with up to 4 players

  • Free for all match of up to 4 players
  • Game ends when a player plays all their available tiles
  • Player with highest score wins

Lightning Round

  • A 5v5 team versus team battle where 5 players on each team play words on multiple boards together
  • Each team has 5 boards plus one additional board for a total of 6 boards
  • The game boards are shared only with the team
  • First team to cumulatively reach the target score wins the match

Prototyping

To get a sense of how “fun” the ideas were, we initially tried them out in the form of “paper prototypes”. Paper prototyping is the process in which you find the easiest and cheapest way to test an idea; it can be as simple as a piece of paper with sketches of the interface or in our case, we used our actual Words With Friends board game to simulate game play.

4 Player Words

To test free for all mode, we recorded members of our team making moves and kept track of the score for each move. The board was in our common area and a notepad was used to keep track of the score and whose turn it was next.

The match took a long time to complete. Often times when a single player wasn’t playing their move it would hold up everyone else. While we can mitigate this by auto-passing the player after a period of time, it ultimately took longer to complete a game.

Lightning Round

For lightning round, we played on our old Pass and Play feature on our Classic Words game. We had members shout out the score for them to be tallied. First team to reach a target would win the match.

It was chaotic keeping track of the scores as the game progressed; shouting out scores for each move made got pretty wild to manage. We felt pretty good about this new mode and decided to invest some time in building a prototype for Lightning Round.

Engineering Challenges

  1. How do we quickly build a playable prototype of Lightning Round to gain conviction?
  2. How do we support a synchronous game on a largely asynchronous tech stack?

Playable Prototype

One of the challenges of building the playable prototype was the real-time nature of the mode. Words With Friends was traditionally an asynchronous turn-based game where players made a single move at a time; we had to build a synchronous real-time mode to handle many moves at once.

Without spending too much time architecting and building a new service, we decided to build the playable prototype on Firebase.

Firebase

Firebase is a development platform that provides a variety of services like databases, analytics, messaging and crash reporting for mobile applications. One service we were really interested in was the Firebase Realtime Database service which provided real-time syncing of JSON data.

With the realtime database service, we were able to quickly devise a schema that would store the match, team, player, board and move data. Due to the team versus team nature of the game, each client would simply listen for changes on its own team’s game boards and the total score of the opposing team. With each update, each client would have the full snapshot of the team’s moves and the opponent’s progress. When the progress reaches the target score, all clients would end the match and display the results.

The most challenging aspect of this approach was synchronizing the board states since there was high contention for boards that were made available when moves were made. To help alleviate this problem, we added a mechanism to reserve access to game boards and used transactional operations when reserving an available board. While this didn’t eliminate the problem, we felt that it was good enough for our internal playtesting needs.

Overall, we found that this worked for the small amount of players we were testing with as it was a cheap and scrappy way to prove out our idea. We spent the next few days refactoring our client to use this service and had a working prototype of Lightning Round with 10 players (5 versus 5) for our team playtest.

Supporting Synchronous Gameplay

Our game service was largely supporting asynchronous play through REST APIs. We wanted to avoid investing in a new synchronous tech stack until we gained enough conviction for the feature. This presented a challenge for supporting synchronous gameplay on existing asynchronous APIs. To address this issue, we decided to build on top of our asynchronous tech stack by leveraging an existing persistent socket connection that was being used for real-time chat updates. In addition to powering chat, we leveraged the persistent connection to provide updates for:

  • Latest scores as a result of moves played by teammates and opponents
  • Player presence updates (playing, joining and leaving matches)
  • Providing game state changes (match begin, match end)

This allowed us to still leverage our existing REST APIs while also providing real time updates.

To mitigate reliability issues with our persistent socket connection, we had the client fallback on polling for data using the REST APIs when the socket connection was dropped for whatever reason.

With this hybrid approach, we were happy with what we built as it allowed us to support synchronous gameplay without risking a larger refactor of our existing asynchronous stack.

Release

Through a few iterations with the team and players, we were happy with the initial results.

In general, Lightning Round:

  • Added a new dimension to playing Words With Friends; it’s not just how great of a word you play but also how quickly you can play words
  • Was a bite-sized game of Words With Friends that can be completed in less than 3 minutes
  • Allowed you to play cooperatively with other players

We released Lightning Round with the Words With Friends 2 launch in November of 2017 and since then our players have created over 50M+ Lightning Round matches. The game was heavily featured on the Apple App Store and Google Play Store, including a full day’s worth of featuring on Lightning Round. We look forward to adding new features to this mode as we look to support selecting and playing with your close friends in a Lightning Round match.

Contributors

Andrzej Buszko | Principal Software Engineer

Chris Zelenak | Architect

--

--