NOTE: You might want to try out the game we’ll be building today before you start reading. Go ahead, we’ll wait for you!
While many Qualtrics novices rely heavily on Display Logic and Skip Logic to customize their survey design, the path to Qualtrics mastery involves getting very comfortable with the Survey Flow window, that pop-up window that looks like this:
All those boxes and colors and unfamiliar tools can be daunting at first blush, particularly when you see a finished survey flow that seems to go on for pages. This is where Qualtrics begins to look an awful lot like computer programming, and that’s no accident, because some of what you’re going to do in the survey flow window is not so different from what you’d do with code if you were writing a program.
Fortunately, Survey Flow is a lot easier to pick up and learn than Python, Javascript or SQL queries, and and one of the best ways to learn any new skill when you’re programming is to create a game. One of the simplest games you could possibly create is Paper, Rock, Scissors, and as it happens, teaching Qualtrics how to play this game with you can also teach you how to use several different functions within the Survey Flow window!
But if we’re going to do this, we first need to design our game. That means we need to first create a design document that includes the following:
- Our list of mechanics that determine how the game is played
- Our list of rules that determine our victory conditions (who wins or loses)
- A diagram that shows us what a typical game should look like
The mechanics are pretty simple for Paper, Rock, Scissors – each player is going to select one of the three choices and throw it on the count of three. In this case, the human player is going to select his or her choice through a survey question. The computer player (Qualtrics) is going to select its choice through a random process. The program will then compare the results and determine the winner.
But how do we know who will win? We need to have some rules. The very simple rules of this game are:
Paper beats rock. Rock beats scissors. Scissors beat paper. Throwing the same on both sides results in a tie.
That covers all legal moves that can be made by both players and provides our victory conditions.
Now, we just need to develop a design diagram to understand the flow of the game. This is also pretty simple:
We’ve got our design process completed. From here, all we need to do is program the game!
But before we get started, we’re going to do something that might not come naturally to you if you’re not super-experienced in Qualtrics, and that’s dividing our survey into blocks. Think of blocks as being like the individual pages of a paper survey, between which we can insert things that change the way the next pages of the survey will display. But blocks can contain any number of questions, and you can (and probably have) program your entire survey into a single block if you want to.
Blocks are useful in survey flow because they allow us to set advanced instructions like branch logic, interstitial embedded data, randomizers or the end of a survey. This can save us a lot of time and trouble if we want to design a survey that only displays certain questions to certain people based on their initial answers. In our game, blocks will be helpful for transporting our players to the right section (win, lose or tie) depending upon the outcome.
Let’s begin by programming a survey that includes the following:
- An introductory block
- A block for allowing the Human Player to make his or her choice of what to throw
- A block that will show up to let the Human Player know if he/she is the winner
- A block that will show up to let the Human Player know if he/she is the loser
- A block that will show up to let the Human Player know if the result is a tie
- A block that will ask the Human Player if he/she wants to play again.
(You’ll notice right away that the survey itself is not programmed to determine what move Qualtrics will throw or to evaluate who won. We’ll do that in Survey Flow later on.)
In our introductory block, we just need two things: A starting message that explains the rules (I also added in a graphic to make things more visually appealing) and then a query to see if the player is ready.
Next, I built a block that simulates the throw. The player is given a countdown and then asked to select a move:
We’ll use the answer from the move that’s thrown in our Survey Flow a little bit later.
Next up, we need to create three blocks that will tell us what was thrown and what the outcome was. One needs to display what happens if the human player is the winner, one needs to display what happens if the human player is the loser, and one needs to display what happens if the match results in a tie.
We’ll use piped text to determine what our human player threw by clicking on “Survey Question / Q2 Which would you like to throw? / Selected Choices”. This will give us a string of funky-looking text starting with a dollar sign $ and enclosed in brackets {} that tell Qualtrics what result to display.
We will also need to have Qualtrics display what the computer player has thrown. We haven’t created this outcome yet, but we can go ahead and set it up to display now. Let’s assume we’ll be calling the result “cpu_throw” (CPU is shorthand for computer) and tell Qualtrics to display what the computer player will be throwing using “Piped Text / Embedded Data Field / cpu_throw”:
Qualtrics will spit out some more funky text to tell the survey what to display. If you have trouble keeping track of things, open up a document window and paste the piped text code for each of our outcomes and make a note as to what they pertain to. One is going to refer to our human player’s “SelectedChoices” and the other to our computer player’s “cpu_throw”.
Now, we just need to put this all into plain language the player can understand. I first wrote a line that informs the player what both sides threw and which then reports which move beats which and the outcome of the game:
That’s my winner block. Here are my loser and tie blocks:
Now, I need to include one more block, which asks the player if he/she wants to play again. This is a simple yes/no question which we’ll later program to either take the player back to the start of the game or to redirect to another webpage. Here’s what it looks like for now:
With that, we’ve finished our survey, which includes all the player mechanics of the game! We now need to go into our survey flow and tell the survey how to apply the computer player mechanics and the rules for the game.
Let’s begin by instructing the computer player how to make its choice. We could do some tricky things here to make the computer player win more or less of the time based on what the player selects, but the easiest thing to do here is to have the computer select one of the three moves at random. Since the computer player can’t take a survey, we need to use embedded data to accomplish this, and the survey flow tool gives us a chance to set up something called a randomizer to decide how that embedded data move will be assigned.
We want the decision of what the computer selects to happen after the introduction but before the player selects a move, so we’ll insert our randomizer in between the intro and throw blocks by clicking “add below” in our intro block in the survey flow window:
We want to set the randomizer to select one of the following outcomes for setting our embedded data field “cpu_throw”:
- Set cpu_throw to “Scissors”
- Set cpu_throw to “Paper”
- Set cpu_throw to “Rock”
This is what the resulting survey flow will look like:
With that, we’ve told the computer player how to make a move! But we haven’t yet programmed in how the software can determine if the game is won, lost or tied. To do that, we’ll need to insert three pieces of branch logic after our player makes a choice in the throw block.
Branch logic is quite similar to display logic in the survey editor – you set a conditional statement and the survey will do what you say if that condition is met. Here we’re going to use it to display blocks that will only show up if the right conditions are present. We don’t want to tell someone who won that they lost, or vice versa. We also don’t want to say there’s a tie when there’s not. This is why we need to have a clear understanding of our rules, because we need our conditions to be exclusive and exhaustive.
After the throw block, click “add below” and select “branch”:
In our branch window, we’ll have some logic we can program. We need to tell Qualtrics to make three comparisons, any of which is valid to display our winner block. These comparisons will be in the form of “IF…AND…” statements, such as “IF Paper is selected in Q2 AND cpu_throw is equal to Rock”. There are three victory conditions for the human player, so we’ll program them here. (Be sure each pair is part of a new logic set and that you’ve set OR, not AND for each new logic set.) Here’s the end result:
We’ll do the same for the Loser and Tie blocks by setting their conditions.
(SHORTCUT TIP: Try using the “Duplicate” choice to use the previous logic as a template and then change around what you need to suit your new condition. It’s much easier than starting from scratch!)
Now our survey logic is programmed to evaluate whether the player won, lost or tied. Our game is nearly complete! But we have one final task, which is to ask the player if he/she wants to try another round. We’ll accomplish this by using branch logic once again after our “Play Again?” block displays. If the player selects yes, we want to redirect them to the survey link. If the player selects no, we want to send them somewhere else.
We set our branches to correspond to their answer and then select “End of Survey.”
But since we want the survey to redirect the player to a new link, we need to click “Customize” and then, in the new window that pops up, select “Override Survey Options” and select “Redirect to a URL”, which gives us a box where we can place our web link.
We have one extremely important final step: we have to save what we just did! Don’t forget to do this, because it can be easy to forget! Look in the bottom right hand corner and click “Save Flow”:
Now our game is ready to play! You can try it here if you didn’t already. Have fun, and once you get it programmed, try to change things up a little bit with some of the following challenges!
- Can you replace the text with icons or graphics for both the player AND the computer moves?
- Can you add in colored backgrounds for WIN, LOSE and TIE which communicate the outcome more visually to the player?
- Can you make the computer select its move based on the player’s and create an EASY mode (where the computer usually loses) and a HARD mode (where the computer usually wins), and can you allow the player to select which mode they’d like and then have all three modes (EASY, NORMAL and HARD) available in the same game?
- Can you create a cheat code that allows the player to somehow manipulate the game?
I hope you enjoyed this article. Here’s a link to the Survey Preview and to the QSF file if you’d like to refer to either. If you’d like to discover more Qualtrics tips and tricks, be sure to check out other articles in our series, and if we can help you or someone you know with a Qualtrics question or problem, please contact us!