I'm sorry if the title is a little aggressive. I don't know what came over me.
Had a little bit of time yesterday so I did another lecture on my Unity course. This one focused on if and else if statements. I have worked with these before when doing the Codecademy tutorials for JavaScript, but I was a bit rusty so it was a good refresher.
In fact I came across if and else if when working on Pet Me! the other day, writing probably my most complicated piece of code so far. I wanted to create a puzzle where the cats won't come to you until you have wiggled a wiggly stick (a cat toy, this is what I call them...) three times. Each time you wiggle it the cats respond in a different way. I had managed to find a script which specified that the first time you wiggled the stick a certain thing would happen, and then any wiggle after would make a different thing happen.
But I wanted the player to wiggle the stick three times before the cats would be pet-able. So this didn't work for me because the second and third wiggles produced the same outcome.
In my own very cack-handed style I thought I could circumvent this by adding in an if statement. So I already had code that said the second time the stick was wiggled that the cats would come out of their hiding place and therefore be visible. Then I told the game that if the cats were visible and the stick was wiggled then the cats should be pet-able.
I thought I was being all clever with my if statement.
But it didn't work! (This happens a lot!)
The way it was written, the game was resolving the if statement at the same time as the instruction before it because it became true. So as soon as I wiggled the stick the second time, the game printed the text for the second and third wiggles.
Pah.
So I must admit I got a little bit of help on this one, as my husband happened to come home at that moment. "What you need," he said, "is an else if statement".
Now I had seen if and else if statements and I hadn't understood the difference between them. On the face of it they seemed to do the same thing (in Quest at least) so I wasn't sure why this would make the difference.
So imagine I had a key which would unlock a door with one turn, and then open it with another turn. A simple (but incorrect) example of what I was trying to do would be:
If I ran this statement then both sets of text would print because as soon as the door is unlocked it would read the second line and carry out the command. This isn't what I want, because I wanted it to take two turns of the key to open the door.
So in this case an else if statement would be just the ticket, because then it would only carry out one of the two options.
This would result in either the first or the second statement to be printed, depending on whether the key had already been used on the door or not.
Else if statements solve the problem of having a series of if statements in a row, where more than one of them can resolve at the same time, and you want one thing OR another thing but never both or all.
Right! So I started to use else if statements instead. But else if what? I needed some kind of way of telling the game that the stick had been wiggled 1, 2 or 3 times. Again some husbandly help was useful here as he asked if there was an object counter function.
I found that and added it, so now I could base my else if statement on whether the stick has been wiggled 1, 2 or 3 times.
Basically -
if the door is locked and I use the key then unlock the door and print "The door is unlocked"
if the door is unlocked and I use the key then open the door and print "The door is opened"
If I ran this statement then both sets of text would print because as soon as the door is unlocked it would read the second line and carry out the command. This isn't what I want, because I wanted it to take two turns of the key to open the door.
So in this case an else if statement would be just the ticket, because then it would only carry out one of the two options.
1. if the door is locked and I use the key then unlock the door and print "The door is unlocked"
else
2. if the door is unlocked and I use the key then open the door and print "The door is opened"
This would result in either the first or the second statement to be printed, depending on whether the key had already been used on the door or not.
Else if statements solve the problem of having a series of if statements in a row, where more than one of them can resolve at the same time, and you want one thing OR another thing but never both or all.
Right! So I started to use else if statements instead. But else if what? I needed some kind of way of telling the game that the stick had been wiggled 1, 2 or 3 times. Again some husbandly help was useful here as he asked if there was an object counter function.
I found that and added it, so now I could base my else if statement on whether the stick has been wiggled 1, 2 or 3 times.
Basically -
If stick wiggled =0 then print text 1
elseif stick wiggled =1 then print text 2 and make cats visible
elseif stick wiggled =2 then print text 3 and make cats pet-able
elseif stick wiggled ≥3 then print text 3
Rather than what I had before which was-
So the beauty of else if is that it checks each statement starting at the top and working its way thorough until it finds one that matches the number of times wiggled, carries out the instruction, and then waits for further player input before it checks them all again. This avoids the issue I had where the game would resolve each instruction because the if statements were both true.
The last thing I had to implement was the object counter to increase after each pass, otherwise without it the game would still not know if the stick had been wiggled, 1, 2, 3 or 1,000000000 times.
In Number Wizard, my else if statement was actually a lot simpler, but nonetheless as necessary. You may remember that I was at the point where the game prompted the player to press the up arrow or down arrow to state whether the number they had thought of was higher or lower than 500. As it was written, you could accidentally press both up and down at the same time and it would resolve both. The else if statement here was used to make sure that only the very first key pressed would be resolved, and it would not log the second key unless it was pressed at the start of a new frame.
I realise that maybe this would all be a lot easier to explain if I had more screen shots to show the dodgy code as it was. I didn't think to screenshot them at the time, and there is no way I'm going to change it back, and then back again just for a screengrab! So I promise I will screen grab as I go along in future!
I hope your brain is intact after all that.
Bye for now!
if player wiggles the stick for the first time print text 1
if it is not the first time the player has wiggled the stick then print text 2 and make the cats visible
if the cats are visible then print statement 3 and make them pet-able straightaway
So the beauty of else if is that it checks each statement starting at the top and working its way thorough until it finds one that matches the number of times wiggled, carries out the instruction, and then waits for further player input before it checks them all again. This avoids the issue I had where the game would resolve each instruction because the if statements were both true.
The last thing I had to implement was the object counter to increase after each pass, otherwise without it the game would still not know if the stick had been wiggled, 1, 2, 3 or 1,000000000 times.
 |
| Here it is! |
In Number Wizard, my else if statement was actually a lot simpler, but nonetheless as necessary. You may remember that I was at the point where the game prompted the player to press the up arrow or down arrow to state whether the number they had thought of was higher or lower than 500. As it was written, you could accidentally press both up and down at the same time and it would resolve both. The else if statement here was used to make sure that only the very first key pressed would be resolved, and it would not log the second key unless it was pressed at the start of a new frame.
 |
| if, else if |
I realise that maybe this would all be a lot easier to explain if I had more screen shots to show the dodgy code as it was. I didn't think to screenshot them at the time, and there is no way I'm going to change it back, and then back again just for a screengrab! So I promise I will screen grab as I go along in future!
I hope your brain is intact after all that.
Bye for now!
