Lesson 13 - If Statement Conditionals

Tutorial Series: Introduction to Unity with C# Series

Previous Article  |  Next Article


Transcript

Alright before we go into conditionals, which will be the main topic for this video and probably the next couple videos. Before we get in to that, what I want to do is a little bit of house cleaning on our project here and sort of show you how you can arrange things into folders and keep things neat and clean, because might as well do it now, because later on down the line it will be a little bit distracting and potentially unwieldy. Let's just get this out of the way.

What we will want to do first is create a folder here in the Assets pane. Right-click and select folder and let's call this script. We will put all of our scripts in that folder. Take all of our scripts... I am holding and clicking on all of our scripts and drag it to our scripts folder. You can also drag it here, on the left side of the pane as well. I will also want to create a folder for our images, put those in their own folder, and one for scenes, which as I mentioned earlier is kind of like the levels, in Unity when we create levels. That is pretty much that. What I want to do also is keep our Test script here, kind of separate and all the other test scripts that we write, which is basically dedicated to understanding the C# principles and isn't really meant to be in our final game project for our prototype game that we are developing. Let's just put that in its own folder, the Test script that we have right now. Label it something like Tests and put that there.

I also want to rename this to make it a little bit more specific. What did it contain? It contained our code for showing you how to create variables and operations. Let's call it VariablesAndOperations, kind of a big name there but it is at least descriptive. We will open this up in Visual Studio and change the name of our class to VariablesAndOperations. Because if you remember, I mentioned before, your class name has to be the same name as your script when it is attached to a game object, just remember that. It is an easy thing to forget. We will save that, and actually I will run it just to make sure I didn't make any mistakes, or just to show you that it shouldn't make any mistakes. Looks good. On to conditionals.

Conditionals are a key cornerstone to just about all forms of programming. They are called conditionals because they create a branch in your code that says something like, "On the condition of so and so being true, "then do this, execute this block of code." You get this kind of fork in the road or railroad track path thing that happens in your code that allows for more interesting and dynamic behavior. The code can respond to the changing states within it and behave differently depending on those different states. That behavior, ultimately, comes down to being whatever you determine it to be in those conditional code blocks. The most common conditional in C#, and certainly the most common that we will be using in Unity is the if statement, which takes the basic form of "if", and then parenthesis, this is true, this evaluates true, the stuff that you write in the parenthesis, then do this the code block that comes right after inside of those squiggly brackets. I am going to put a bit stronger emphasis on describing if conditionals, because you will be relying on them fairly heavily in your coding within Unity in order to produce this dynamic functionality within your code. It could just be the aspect of coding that you would do well to work extra hard to wrap your head around but conditionals at their heart are quite simple.

Let's demonstrate that by writing out a simple if statement. What we will want to do first is create a new script. Might as well put it in our Tests folder here. Right-click, Create, C# Script, and lets type in Conditionals. Double-click that and open it up in Visual Studio and here we go, we have a brand new script that we can use to demonstrate conditionals. What I want you to write is...we will take out Update() we don't need that. Actually I am going to rewrite that to a custom name, let's call it RunConditionals() and in start let's actually call that method that we have yet to actually yet to write the definition for. Well as before might as well, take this stuff out. Remember, declutter since we don't need it. We are not going to talk about these elements just yet. Now let's write in our first basic conditional. Type in int x = 100 and then that's our variable. We are going to evaluate it with conditional. if (x == 100) then... those squiggly brackets represent here underneath the if evaluation. We want to output that to the Debug.Log(). "Operands are equivalent." That is our basic conditional there. Let's save it, and if you remember, we are going to have to attach it to a game object in our game here, so we will click and drag it there. And we will disable the VariablesAndOperations script because we don't really care about its output any longer. Clear that. There we go, we got the output, "The operands are equivalent." There we get the output, "The operands are equivalent" because that evaluated as true, x is equivalent to 100.

Now lets see what happens to this evaluation if we alter the value of x, so it is not equivalent to 100. Let's make it 1000 and then go back to Unity. There you go. It is not outputting that code block anymore. It just ignores that entire code block that is responsible for outputting the message because the conditional evaluates as false. It has to evaluate as true in order to execute that code block or else it just ignores whatever comes after that evaluation. Conditionals evaluate top-down just like the rest of our code. Our first evaluation starts with "if," which is that part and what is being evaluated as either true or false is the statement within the parenthesis. The only rule here is that you have to have some statement that can, in principle, evaluate as true or false, you can't just stick a string in there or a mathematical operation. Here we are doing the equivalence operation. We use the double equals operator which isn't any kind of assignment operator, like equals operator, but rather a check for equivalence that checks if what is on the left of the operator, the double equals sign, is the same as what is on the right of that operator. We haven't really mentioned this yet but we know what the operator is here because we talked about operators, it is the double equals sign as I just mentioned but the things that the operator operates on, not just here but in all cases, are all the operands.

From now on I will try to refer to them as operands, here the x is the left operand, and the 100 is the right operand, that the operator, the double equals sign operates on. Just a little bit of extra information there but it might help you keep that clear in your mind. Again, we start from the top. In the first if statement evaluates whether or not the value stored in operand x is equivalent to the value in operand 100. If that is true, it executes this block code immediately after, the code in the curly braces. If it is not true, it just ignores that code block entirely, as if it doesn't exist, and it moves on down to the next line of code, which here there is nothing, but if there was some code here, it would start looking at the next line, that is if it evaluates false. Sometimes however, we want to evaluate other possibilities, in the case that it evaluates as false. You can do this with Else statements. If the first "if" evaluates as false, instead of going on to the rest of your code, it can go fall down to an "else if" statement. Let me demonstrate this with writing in this code. We will add in an else clause in case the if evaluates as false. Type in Debug.Log(“The operands ARE NOT equivalent.”) Save that. Run our game. The operands are not equivalent, so there you go. It evaluates the first if, finds that is false then it immediately goes to else, that evaluates as true because, of course, x is not equivalent to 100, so it goes on to the else and that becomes a default that then does execute.

If we have lots of cascading possibilities, we sandwich in between the if and the else, else-if statements. Let's add in a simple else-if. Let's go else if ( x == 100/2 ) which will be 50. Type in “x is equivalent to half of 100.” Let's just do this all again. Let's put x back to 100 and then see the output. "The operands ARE equivalent," yep that is what we were expecting. And now lets make it 50 which is going to as true, here, after it evaluates as false here, it will fall down to this. Let's try that out and show that in action. That evaluates. Now it doesn't have to be 1000, it could be anything other than 100. We will expect it to fall through the final else clause if we now run it. There you go. "The operands ARE NOT equivalent," it falls down to the final else. If that first if evaluates as true, it skips entirely the next evaluations, the else-if and the else. If it evaluates as false, then it moves down to the first else-if, and then if that fails the next else-if.

If you have more than one, you can certainly put in as many as you want, this continues so on and so forth. If all of those else-if's fail, then and only then does it execute that last clause, the final else. It is sort of like a fail safe or default which says, "Failing all of those possibilities, do this." That is what we get there. It should be pretty clear that this is the only logical order that these conditionals can be ordered in. If at the very top, followed by else-if, if you want, at the very bottom a final else, just one. No other ordering makes logical sense, keep that in mind. You of course don't have to have an else-if, as you have seen. You can just have an if or an 'if and an else, and then of course you should have a final else. You could just use if's but you have to be very careful, because if you just have if's, more than one might evaluate as true, you can get some kind of funky, conflicting code. And in most cases, it will be apparent that you probably made an error, when some weird things are happening in your game.

That is just a simple first look at if conditionals. This whole behavior of falling down to the next possibility. If the first if evaluates as false, it falls down to the else-if, if its there, otherwise it falls to the else. The way I would illustrate this behavior to give you a little bit of a way of visualizing it is, imagine you poof into existence in a room at the top of a multi-story building, called Shato-conditional or perhaps Shato-conditionalle or conditionelle. I am not really great with French. You could say that if you want, if you prefer fancier things. In that room at the top of Shato-conditional is a toll operator named “Mr. If”, and you are allowed to say exactly one statement to Mr. If, and Mr. If will simply reply telling you whether or not that statement is true or false. If he says true, great. You are allowed to go to the back of the room and open up this chest that executes that level's block of code and then immediately leave the building. You are done with Shato-conditional and Mr. If.

However, if Mr. If says false, immediately under your feet a trap door opens, forcing you down to the next level, that chest on the top level will remain unopened. If this building is three stories or more, then you meet on this next level Mr. Else-If. Mr. Else-If looks exactly like Mr. If, and both he and room and the chest function exactly the same as on Mr If's level. If Mr. Else-If replies true, you open that chest and leave the building immediately thereafter. If he says false, again you drop down through another trap door, down to the next level where you will be greeted by another Mr. Else-If to repeat this process. If it is mercifully the bottom floor, you finally get to Mr. Else, who is the exact same as all the other guys except, congratulations, you finally get to get out of this crazy building. He finally lets you out no matter what, even if evaluates true or false. If it is true, you get to open that chest. But no matter what, you get to finally leave this nutty little building that we made up in our minds.

Another thing about if statements, and that is you saw a mathematical equivalence being evaluated in those if statements. But what about other common evaluations, such as greater than and less than and other common mathematical concepts? There are handy operators for those as well. We will show you them, really simple stuff. Let's put this back to 100 and we will comment out this code so we can preserve it in case we want to back to it for whatever reason. And what we will do is we will write in another if statement. if (x > 100), that is the greater sign, we will write this. Pretty logical. Else... Let's save that and run it.

x IS LESS than 100. Does that make sense? Is that correct? No it is not. We see that the evaluation occurred correctly. It checks if it is greater than 100. If it is not, then it goes to the else statement. What is wrong here? It is simple, if a value is not greater than a certain number, then it isn't safe to say it is less than that number, because it might actually be that number. For that, we have to write in the >= operator, which checks for if it is greater than or equivalent to the operands. I will type in or equal to. Save that. There you go. We could of course use the < sign,="" operates="" the="" exact="" same="" way.="" it="" is="" just="" the="" opposite="" of="" the=""> sign. A few more things to say about if statements, including how in tandem with bools, they allow you to hold states in your code. It is a functionality that is particularly useful for developing games.
You are doing great, keep following along and I will see you in the next video. Thanks


Related Articles in this Tutorial:

Lesson 1 - Who This Course is For

Lesson 2 - What to Expect from this Course

Lesson 3 - Installation and Getting Started

Lesson 4 - Starting the First Project

Lesson 5 - Prototype Workflow

Lesson 6 - Basic Code Review

Lesson 7 - Game Loop Primer

Lesson 8 - Prototyping Continued

Lesson 9 - C# Fundamentals and Hello World

Lesson 10 - Variables and Operations

Lesson 11 - Variables and Operations Continued

Lesson 12 - Floats, Bools and Casting

Lesson 13 - If Statement Conditionals

Lesson 14 - If Statements Continued

Lesson 15 - Complex Evaluations and States

Lesson 16 - Code Syntax vs. Style

Lesson 17 - Variable Scope

Lesson 18 - Object-Oriented Programming Intro

Lesson 19 - OOP, Access Modifiers, Instantiation

Lesson 20 - Object Containment and Method Returns

Lesson 21 - "Has-A" Object Containment

Lesson 22 - "Is-A" Inheritance Containment

Lesson 23 - Static Fields and Methods

Lesson 24 - Method Inputs and Returns

Lesson 25 - Reference vs. Value Types

Lesson 26 - Introduction to Polymorphism

Lesson 27 - Navigating the Unity API

Lesson 28 - Applying What You've Learned and Refactoring

Lesson 29 - Constructors, Local Variables in the Update Method

Lesson 30 - Collecting Collectibles, Items and Powerups

Lesson 31 - Spawning and Managing Prefab Powerups

Lesson 32 - Implementing Powerup State Logic

Lesson 33 - Displaying Text, OnGUI, Method Overloading

Lesson 34 - Referencing Instantiated GameObjects, Parenting

Lesson 35 - Understanding the Lerp Method

Lesson 36 - Creating Pseudo Animations in Code

Lesson 37 - Understanding Generic Classes and Methods

Lesson 38 - Animations Using SpriteSheets and Animator

Lesson 39 - Working with Arrays and Loops

Lesson 40 - Debugging Unity Projects with Visual Studio

Lesson 41 - Camera Movement and LateUpdate

Lesson 42 - Playing Audio Clips

Lesson 43 - Routing Audio, Mixers and Effects

Lesson 44 - Adding Scoring Mechanics and Enhancements

Lesson 45 - Scene Loading and Game Over Manager

Lesson 46 - Understanding Properties

Lesson 47 - Controller Mapping and Input Manager

Lesson 48 - Understanding Enums

Lesson 49 - Dealing with Null References

Lesson 50 - Handling Variable Framerates with time.DeltaTime

Lesson 51 - Preparing the Project for Final Build

Lesson 52 - Final Build and Project Settings

Lesson 53 - Introduction to the Unity Physics Engine

Lesson 54 - Understanding FixedUpdate vs. Update

Lesson 55 - Movement Using Physics

Lesson 56 - Attack Script and Collision Events with OnCollisionEnter2D

Lesson 57 - Projectiles and Stomping Attack

Lesson 58 - Parallax Background and Scrolling Camera

Lesson 59 - Infinitely Tiling Background Sprites

Lesson 60 - OOP Enemy Classes

Lesson 61 - OOP Enemy Classes Continued

Lesson 62 - Trigger Colliders and Causing Damage

Lesson 63 - Multi-Dimensional Arrays and Procedural Platforms

Lesson 64 - Finishing Touches

Lesson 65 - Series Wrap


Comments

Please login or register to add a comment