We at Axure HQ have brought to you a carnival’s worth of “Random” games-- from Kip’s Magic 8 Ball to Rachel’s Slot Machine, from A Game of Cards / Adding to the Fun with Random! to Deal or No Deal / Even More Fun with Random(-ish)! and back to Threes! / More Fun, More Random!! Just when you thought we were done, I’ve brought along another little “Random” game for you to try that is a twist on a classic decision-making game; Rock, Paper, Scissors, Lizard, Spock, invented by Sam Kass and Karen Bryla and made famous on The Big Bang Theory.
The rules are simple: to win a game, you must win 5 rounds against the computer, though you can play as many games as you’d like. The scores for the rounds are displayed beneath the player’s and computer’s display panels, and the scores for the games are kept at the top next to the rules.
As far as the strengths and weaknesses of each weapon, the standard rules of Rock Paper Scissors still apply, with the addition of Lizard and Spock. Spock pulverizes Scissors and Rock with his mighty half-Vulcan muscles, but he can be poisoned by Lizard and have his logic disproved by paper. Lizard eats paper in addition to poisoning Spock, but can be defeated by Scissors and crushed by Rock. The rules of the game are posted within the file for you to reference, so don’t feel the need to commit them all to memory!
To set up the game, you have to program the computer’s choice to be the result of a randomly generated function. To achieve this, I used the “Math.Random” function to generate a number between 1 and 5, (since there are 5 different weapons to choose from) and then assign that value to a variable named “ComputerVariable”.
Here’s what the completed function looks like:
[[(((Math.random()) * 100).tofixed(0)%5) + 1]]
The first part of the function, “(Math.random()) * 100).tofixed(0)” will give you a number between 0 and 99. The “%5” in the next section will divide the randomly generated number by 5, and then spit out the remainder. However, since the function currently spits out a value between 0 and 4, I added a “+1” so that it instead spits out a value between 1 and 5.
Next, I set up the conditions that would determine the winner and loser of each round. There are a couple of ways this could have been done; if I wanted to, I could have set the OnClick events for the player choices to set a value for a “PlayerVariable”, then use a condition to compare that variable to the “ComputerVariable” in order to determine a winner. However, it’s also possible to do it the way I did it by setting up a condition on each of the buttons that just determines whether the player wins or loses, based on which weapon they chose and which value was generated for “ComputerVariable”. If you were to work on a bigger project that requires more than 5 comparisons, then it would be better to use the variables rather than setting everything up manually.
Using the manual conditions method, I set up a condition that takes the value of the computer variable and checks which number it matches between 1 and 5; numbers 1 through 5 correspond to the weapons Rock through Spock, in clockwise order. For the round to work, I set it up so that the OnClick action by the player on a weapon choice generates a random value for the computer, and then depending on the player’s choice and the value that the computer has, the player either wins or loses. For example, if you click “Rock” and the computer randomly generates a value of 5, you lose because 5 (Spock) defeats Rock (1).
If you win a round, the “Win” shape shows; similarly, if you lose or get a draw, the “Lose” and “Draw” signs show, respectively. Every time the round ends, the “Play Again” button shows up. When one party has reached 5 points, the “Champion” or “Loser” signs appear, along with a “Reset Game” button.
Now that’s all good and dandy, but the fun part of this game was the semi-dramatic animations. Instead of just having dynamic panel states change instantly after the player selects their choice, I delved a little deeper and figured out the timing that would make the game a bit more videogame-y. That part got a bit tricky because of the timing, so I’ll show that below.
Some of you may have occasionally encountered issues with the timing of animated events and found that certain actions may occur seemingly out of order. This was the case with this project.
The order of operations that I expected (and eventually achieved) when building this game was as follows:
Player picks weapon, and the dynamic panels and center background fade out.
Player’s choice slides in, the “VS” sign appears, and then the computer’s choice slides in.
The “VS” sign fades out to “Win”/”Lose”/”Draw”, and the “Play Again” button appears.
The issue that I encountered when I started adding the timing of the animations was that the computer’s choice kept showing up prematurely. It is supposed to wait to show until after the “VS” sign, however almost as soon as the player picked a choice, the computer’s choice was already sliding in. I thought to resolve this by setting the Math.Random action down to the bottom of the first case, but this resulted in the computer’s variable not being set at all. Because of this, I had to move the “Math.Random” function back to the top.
You’ll notice that at the start of each condition that evaluates the ComputerVariable, there is a 2200ms wait; this allows enough time for animations in Case 1 on each button to execute the “Hide”, “Show”, and “is Selected” animations in order before the ComputerChoice kicks in and shows the dynamic panel state corresponding to the weapon chosen by the computer.
The math that determined the 2200 ms wait at the start of Cases 2-4 is as follows:
500 ms to show the “DramaticRectangle” (the blue background that covers the game picture) and hide the “PlayerChoice” and “ComputerChoice(Random)” dynamic panels.
1000 ms wait to build drama (drumroll please)
800 ms wait between the setting of the “PlayerChoice” panel state and the setting of the DramaticRectangle’s “is Selected” style to “true”.
I shaved off 100 ms from the wait time (hence 2200 ms) to speed things up ever so slightly, since the player already has enough drama at the start of the animation.
The moral of this story is this; if you set the value of a variable to a certain value, and have a case that sets off some actions based on the value of that variable (even if there are other actions to complete between the first and second cases), the actions in the following case will begin to fire off once their condition is met, regardless of whether the first case is complete. For this reason, you’ll want to establish a “wait” to make sure that all of your animations complete in the first case. Otherwise the actions will try to fire in a (seemingly) simultaneous manner.
I’ve attached the .rp file for this project onto this post for anyone who is interested in taking a look. Hopefully this was a helpful and/or fun post for you all to read!
RPSLS_Random_Project.rp (1.07 MB)