Any programming language starts off looking like ancient Greek to the unaccustomed eye, and C# is no exception. The good news is that underneath the initial mystery, all programming languages are made up of the same essential building blocks. Variables, methods, and classes (or objects) make up the DNA of conventional programming; understanding these simple concepts opens up an entire world of diverse and complex applications. After all, there are only four different DNA nucleobases in every person on earth; yet, here we are, unique organisms to the last.

If you're new to programming, there's going to be a lot of information coming at you in this chapter, and this could mark the first lines of code that you've ever written. The point is not to overload your brain with facts and figures; it's to give you a holistic look at the building blocks of programming using examples from everyday life.

This chapter is all about the high-level view of the bits and pieces that make up a program. Getting the hang of how things work before getting into the code directly will not only help you new coders find your feet, it will also solidify the topics with easy-to-remember references. Ramblings aside, we'll focus on the following topics throughout this chapter:

• Defining what variables are and how to use them
• Understanding the purpose of methods
• Classes and their role as objects
• Turning C# scripts into Unity components
• Component communication and dot notation

Let's start with a simple question: what is a variable? Depending on your point of view, there are a few different ways of answering that question:

• Conceptually, a variable is the most basic unit of programming, as an atom is to the physical world (excepting string theory). Everything starts with variables, and programs can't exist without them.
• Technically, a variable is a tiny section of your computer's memory that holds an assigned value. Every variable keeps track of where its information is stored (this is called a memory address), its value, and its type (for instance, numbers, words, or lists). 
• Practically, a variable is a container. You can create new ones at will, fill them with stuff, move them around, change what they're holding, and reference them as needed. They can even be empty and still be useful.

A practical real-life example of a variable is a mailbox; remember those?

They can hold letters, bills, a picture from your aunt Mabel – anything. The point is that what's in a mailbox can vary: they can have names, hold information (physical mail), and their contents can even be changed if you have the right security clearance.

Referring to the preceding photo, if I asked you to go over and open the mailbox, the first thing you'd probably ask is: which one? If I said the Smith family mailbox, or the brown mailbox, or the round mailbox, then you'd have the necessary context to open the mailbox I was referencing. Similarly, when you are creating variables, you have to give them unique names that you can reference later. We'll get into the specifics of proper formatting and descriptive naming in Chapter 3, Diving into Variables, Types, and Methods.

When you create and name a variable, you're creating a placeholder for the value that you want to store. Let's take the following simple math equation as an example:

2 + 9 = 11

Okay, no mystery here, but what if we wanted the number 9 to be its variable? Consider the following code block:

myVariable = 9

Now we can use the variable name, myVariable, as a substitute for 9 anywhere we need it:

2 + myVariable = 11

Even though this example isn't real C# code, it illustrates the power of variables and their use as placeholder references. In the next section you'll start creating variables of your own, so keep on rolling!

Alright, enough theory; let's create a real variable in our LearningCurve script:

1. Double-click on LearningCurve to open it in Visual Studio and add lines 7, 12, and 14 (don't worry about the syntax right now – just make sure your script is the same as the script that is shown in the following screenshot):

2. Save the file using command + S on a Mac keyboard, or Ctrl + S on a Windows keyboard.

For scripts to run in Unity, they have to be attached to GameObjects in the scene. HeroBorn has a camera and directional light by default, which provides the lighting for the scene, so let's attach LearningCurve to the camera to keep things simple: 

1. Drag and drop LearningCurve.cs onto the Main Camera.
2. Select the Main Camera so that it appears in the Inspector panel, and verify that the LearningCurve.cs (Script) component is attached properly.

3. Click Play and watch for the output in the Console panel:

The Debug.Log() statements printed out the result of the simple math equations we put in between the parentheses. As you can see in the following Console screenshot, the equation that used our variable worked the same as if it was a real number:

We'll get into how Unity converts C# scripts into components at the end of this chapter, but first, let's work on changing the value of one of our variables.

Since currentAge was declared as a variable on line 7, the value it stores can be changed. The updated value will then trickle down to wherever the variable is used in code; let's see this in action:

1. Stop the game by clicking the Play button if the scene is still running.
2. Change Current Age to 18 in the Inspector panel and play the scene again, looking at the new output in the Console panel:

The first output will still be 31, but the second output is now 19 because we changed the value of our variable. 

Now that we know how to create variables in C# and assign them values, we're ready to dive into the next important programming building block: methods!

On their own, variables can't do much more than keep track of their assigned values. While this is vital, they are not very useful on their own in terms of creating meaningful applications. So, how do we go about creating actions and driving behavior in our code? The short answer is by using methods. 

Before we get to what methods are and how to use them, we should clarify a small point of terminology. In the world of programming, you'll commonly see the terms method and function used interchangeably, especially in regards to Unity. Since C# is an object-oriented language (this is something that we'll cover in Chapter 5, Working with Classes and Object-Oriented Programming), we'll be using the term method for the rest of the book to conform to standard C# guidelines.

Similarly to variables, defining programming methods can be tediously long-winded or dangerously brief; here's another three-pronged approach to consider:

• Conceptually, methods are how work gets done in an application. 
• Technically, a method is a block of code containing executable statements that run when the method is called by name. Methods can take in arguments (also called parameters), which can be used inside the method's scope.
• Practically, a method is a container for a set of instructions that run every time it's executed. These containers can also take in variables as inputs, which can only be referenced inside the method itself. 

Taken all together, methods are the bones of any program – they connect everything and almost everything is built off of their structure.

Let's take an oversimplified example of adding two numbers together to drive the concept home. When writing a script, you're essentially laying down lines of code for the computer to execute in sequential order. The first time you need to add two numbers together, you could just brute-force it like in the following code block:

someNumber + anotherNumber

But then you conclude that these numbers need to be added together somewhere else. Instead of copying and pasting the same line of code, which results in sloppy or "spaghetti" code and should be avoided at all costs, you can create a named method that will take care of this action:

AddNumbers 
{
    someNumber + anotherNumber
}

Now AddNumbers is holding a place in memory, just like a variable; however, instead of a value, it holds a block of instructions. Using the name of the method (or calling it) anywhere in a script puts the stored instructions at your fingertips without having to repeat any code. 

As before, once we've seen a new concept in pseudocode, it's best if we implement it ourselves, which is what we'll do in the next section to drive it home.

Let's open up LearningCurve again and see how a method works in C#. Just like with the variables example, you'll want to copy the code into your script exactly as it appears in the following screenshot. I've deleted the previous example code to make things neater, but you can, of course, keep it in your script for reference: 

1. Open up LearningCurve in Visual Studio and add in lines 8, 13, and 16 - 19.
2. Save the file, and then go back and hit Play in Unity to see the new Console output:

You defined your first method on lines 16 to 19 and called it on line 13. Now, wherever AddNumbers() is called, the two variables will be added together and printed to the console, even if their values change:

Go ahead and try out different variable values in the Inspector panel to see this in action! More details on the actual code syntax of what you just wrote are coming up in the next chapter.

With a bird's-eye view of methods under our belts, we're ready to tackle the biggest topic in the programming landscape – classes!

We've seen how variables store information and how methods perform actions, but our programming toolkit is still somewhat limited. We need a way of creating a sort of super container that has its variables and methods that can be referenced from the container itself. Enter classes:

• Conceptually, a class holds related information, actions, and behaviors inside a single container. They can even communicate with each other.
• Technically, classes are data structures. They can contain variables, methods, and other programmatic information, all of which can be referenced when an object of the class is created.
• Practically, a class is a blueprint. It sets out the rules and regulations for any object (called an instance) created using the class blueprint.

You've probably realized that classes surround us not only in Unity but in the real world as well. Next, we'll take a look at the most common Unity class and how they function in the wild.

Before you wonder what a class looks like in C#, you should know that you've been working with a class this whole chapter. By default, every script created in Unity is a class, which you can see from the class keyword on line 5:

public class LearningCurve: MonoBehavior

MonoBehavior just means that this class can be attached to a GameObject in the Unity scene. In C#, classes can exist on their own, which we'll see when we create standalone classes in Chapter 5, Working with Classes and Object-Oriented Programming.

For our last example, let's think about a local post office. It's a separate, self-contained environment that has properties, such as a physical address (a variable), and the ability to execute actions, such as sending in your secret decoder ring voucher (methods). 

This makes a post office a great example of a potential class that we can outline in the following block of pseudocode:

PostOffice
{
    // Variables
    Address = "1234 Letter Opener Dr."

    // Methods
    DeliverMail()
    SendMail()
}

The main takeaway here is that when information and behaviors follow a predefined blueprint, complex actions and inter-class communication becomes possible.

For instance, if we had another class that wanted to send a letter through our PostOffice class, it wouldn't have to wonder where to go to fire this action. It could simply call the SendMail function from the PostOffice class, as follows:

PostOffice.SendMail()

Alternatively, you could use it to look up the address of the Post Office so you know where to post your letters:

PostOffice.Address

Your basic programming toolkit is now complete (well, the theory drawer, at least). We'll spend the rest of this section taking you deeper into the syntax and practical uses of variables, methods, and classes.

You might have noticed that LearningCurve has two odd lines of gray text (10 and 21 in the last screenshots) starting with two backslashes, which were created by default with the script. These are code comments, a very powerful, if simple, tool for programmers. 

In C#, there are a few ways that you can use to create comments, and Visual Studio (and other code editing applications) will often make it even easier with built-in shortcuts. 

Some professionals wouldn't call commenting an essential building block of programming, but I'll have to respectfully disagree. Correctly commenting out your code with meaningful information is one of the most fundamental habits a new programmer should have. 

The single-line comment is exactly what's already in LearningCurve: 

// This is a single-line comment

Visual Studio doesn't see lines starting with two backslashes (without empty space) as code, so you can use them as much as needed.

Since it's in the name, you'd be right to assume that single-line comments only apply to one line of code. If you want multi-line comments, you'll need to use a backslash and an asterisk as opening and closing characters around the comment text:

/* this is a 
      multi-line comment */ 

Seeing example comments is good, but putting them in your code is always better. It's never too early to start commenting!

Visual Studio also provides a handy auto-generated commenting feature; type in three backslashes on the line preceding any line of code (variables, methods, classes, and more) and a summary comment block will appear. Open up LearningCurve and add in three backslashes above the ComputeAge() method:

You should see a three-line comment with a description of the method generated by Visual Studio from the method's name, sandwiched between two <summary> tags. You can, of course, change the text, or add new lines by hitting Enter just as you would in a text document; just make sure not to touch the tags.

The useful part about these detailed comments is clear when you want to know something about a method you've written. If you've used a triple forward-slash comment, all you need to do is hover over the method name anywhere it's called and Visual Studio will pop your summary:

We still need to understand how everything we've learned in this chapter applies in the Unity game engine, which is what we'll be focusing on in the next section!

With the building blocks squared away, it's time to do a little Unity-specific housekeeping before wrapping up this chapter. Specifically, we need to know more about how Unity handles C# scripts attached to GameObjects. For this example, we'll keep using our LearningCurve script and Main Camera GameObject.

All GameObject components are scripts, whether you or the good people at Unity wrote them. Unity-specific components such as Transform, and their respective scripts, just aren't supposed to be edited by us.

The moment a script that you have created is dropped onto a GameObject, it becomes another component of that object, which is why it appears in the Inspector panel. To Unity, it walks, talks, and acts like any other component, complete with public variables underneath the component that can be changed at any time. Even though we aren't supposed to edit the components provided by Unity, we can still access their properties and methods, making them powerful development tools.

Part of a previous Time for action section already had you update a variable in the Inspector panel, but it's important to touch on how this works in more detail. There are two situations in which you can modify a property value:

• In Play mode
• In development mode

Changes made in Play mode take effect immediately in real-time, which is great for testing and fine-tuning gameplay. However, it's important to note that any changes made while in Play mode will be lost when you stop the game and return to development mode. 

When you're in development mode, any changes that you make to the variables will be saved by Unity. This means that if you were to quit Unity and then restart it, the changes would be retained.

If you need to undo any changes made in the Inspector panel, you can reset the script to its default (sometimes called initial) values. Click on the three vertical dots icon to the right of any component, and then select Reset, as shown in the following screenshot:

This should give you some peace of mind – if your variables get out of hand, there's always the hard reset. 

Since C# scripts are classes, how does Unity know to make some scripts components and not others? The short answer is that LearningCurve (and any script created in Unity) inherits from MonoBehavior (another class). This tells Unity that the C# class can be transformed into a component.

The topic of class inheritance is a bit advanced for this point of your programming journey; think of it as the MonoBehaviour class lending a few of its variables and methods to LearningCurve. Chapter 5, Working with Classes, Struct, and OOP, will cover class inheritance in practical detail.

The Start() and Update() methods that we've used belong to MonoBehavior, which Unity runs automatically on any script attached to a GameObject. The Start() method runs once when the scene starts playing, while the Update() method runs once per frame (depending on the frame rate of your machine). 

Now that you're familiarity with Unity's documentation has gotten a nice bump, I've put together a short optional challenge for you to tackle!

Now it's time for you to get comfortable using the Unity documentation on your own, and what better way than to look up some of the common MonoBehavior methods:

• Try searching for the Start() and Update() methods in the Scripting API to gain a better understanding of what they do in Unity, and when. 
• If you're feeling brave, go the extra step and have a look at the MonoBehavior class in the manual for a more detailed explanation.

Before jumping into our C# programming adventure too deeply, we need to address one final, crucial building block – communication between classes. 

Up until now, we've described classes and, by extension, Unity components, as separate standalone entities; in reality, they are deeply intertwined. You'd be hard-pressed to create any kind of meaningful software application without invoking some kind of interaction or communication between classes.

If you remember the post-office example from earlier, the example code made use of periods (or dots) to reference classes, variables, and methods. If you think of classes as directories of information, then dot notation is the indexing tool: 

PostOffice.Address

Any variables, methods, or other data types within a class can be accessed with dot notation. This applies to nested, or subclass information as well, but we'll tackle all those subjects when we get to Chapter 5, Working with Classes and Object-Oriented Programming. 

Dot notation is also what drives communication between classes. Whenever a class needs information about another class or wants to execute one of its methods, dot notation is used:

PostOffice.DeliverMail()

If dot notation doesn't quite click with you yet, don't worry, it will. It's the bloodstream of the entire programming body, carrying information and context wherever it's needed.

We've come a long way in a few short pages, but understanding the overarching theory of fundamental concepts such as variables, methods, and classes will give you a strong foundation to build on. Bear in mind that these building blocks have very real counterparts in the real world. Variables hold values like mailboxes hold letters; methods store instructions like recipes, to be followed for a predefined result; and classes are blueprints just like real blueprints. You can't build a house without a well thought out design to follow if you expect it to stay standing.

The rest of this book will take you on a deep dive into C# syntax from scratch, starting with more detail in the next chapter on how to create variables, manage value types, and work with simple and complex methods.

1. What is the main purpose of a variable?
2. What role do methods play in scripts?
3. How does a script become a component?
4. What's the purpose of dot notation?