Let’s start with a brief overview of the user interface (UI) for the Unity Editor. For each chapter there’s a prepared Unity Project with C# files and scenes named after each chapter. The personal and professional versions of Unity interact with C# in the same way.
When you’re starting the Unity Hub for the first time, you may be asked to sign in with your Unity User account. If you got through the previous chapter, then you should already have your login and password. Hopefully you wrote down your login information.
Across the top you’ll see the menu tabs Projects, Learn, and Installs. These are the major tabs; on the right you’ll also find New, Open, a gears icon, and an account icon. The Projects icon shows you a list of any local project, or if you’re using the Unity Cloud project service, you’ll see the projects listed there. The Learn tab will show some of the official Unity tutorials instructing you on how to use different tools that have been added to the Unity Editor. The Installs tab shows installers for different versions of Unity.
To get started Click on the Open Project icon and navigate to BookContents/Chapters/Chapter2 and select the folder.
Upon opening a project, you may be asked if you want to upgrade. Specify the latest version of Unity and use the Current Build Target. Press Open and upgrade the project to the newer version of Unity. Unity updates the project and generates a few new directories with temp files used to build the game. Assets like textures, meshes, and sounds are all prepared for building a game. Once this is complete the main Editor view opens.
2.4.1 The Main Window
The default Unity Editor interface is divided into five major parts: (1) toolbar, (2) Hierarchy panel, (3) Scene and Game view, (4) Inspector panel, and (5) Project and Console panel.
The tabs for any view can be dragged out and re-arranged in the Editor. Pulling a tab off detaches it from the main UI. The free tabs can remain a separate window, or they can be re-attached or grouped with other tabs. To restore the default layout, select Windows→Layouts→Default.
2.4.1.1 Toolbar
Label 1 in figure shows us the toolbar. The icons to the left are the navigation and manipulation tools. Toward the center of the tool bar are the Play, Pause, and Step Forward buttons. We will be using the Play-in-Editor button to test our code. On the right are various logins and view filters to help identify specific objects in the scene.
When the Play-in-Editor button is pressed, the Game view panel automatically comes to the front. Scripts attached to game objects in the open scene are executed and output is written to the Console panel. The contents of this book depend on opening a scene, examining code in the scene, and pressing the Play button to see what the code does. This pattern persists throughout the content of this book.
2.4.1.2 Scene, Game View, and Asset Store
Label 2 shows us the Scene and Game view just mentioned. As the scene updates, the view from the Main Camera is shown through the Game view. The Scene tab falls to the background when the Game view comes forward. Clicking on the Scene tab allows us to see what’s going on behind the scenes as the game updates. You’re also able to move Game objects around using tools in the toolbar while the game is running. There are some exercises in this book which may require you to move game objects around as the game is being played.
The scene is more like a construction view of the game. The Game panel is the view of the game through the Main Camera. The difference here is that the Scene panel cannot be seen by the player, only you as the creator of the game can access the Scene view. With this view, you’ll be able to arrange any object, light, or zombie the way you want.
2.4.1.3 Hierarchy Panel
Label 3 shows us the Hierarchy panel. In a new scene, you’ll have a Main Camera and a Directional Light. The Hierarchy shows you all the Game objects that make your game scene. Any zombies, environments, cameras, lights, and sounds can be found in this panel after you add them. When any object is parented to another, it can be found by expanding the parent object with the triangle. In the following example, you’ll find a piggy parented to a house.
The hierarchy of the scene contains the Game objects in the currently open scene.
2.4.1.4 Inspector Panel
Label 4 shows us the Inspector panel. By selecting an object in either the Hierarchy or the Scene view, you’ll be able to look at their various properties such as a Transform, which shows the object’s position, rotation, and scale in the scene. Objects in the scene are updated with the Inspector.
Take note of the Add Component button in this panel. This is one of the many ways in which we can assign a C# file to an object in the scene. If this seems a bit confusing, don’t worry, we’ll get back to what Components and Game objects are in a moment.
2.4.1.5 Project and Console Panel
Finally, label 5 shows us the Project and Console panels. The Project view shows us all the assets in the project. When we save a scene, it then turns into an asset for us to open from the Project view. As new C# files are added, they are shown here. To read the names of the files in the Project window use the slider located to the lower right of the window. Move the slider to the left to make the file names clearly readable.
The last but most important part is the Console panel. By clicking on the Console tab, the Console view will be brought forward. This view displays the output text that is created by the C# code we write. Any problems, warnings, and errors will also be presented in the Console panel.
The Unity 3D installer also installed Visual Studio Community, the IDE used to edit code. We haven’t written any C# yet, so we haven’t gotten to Visual Studio, but that will come soon enough. Before that, we’ll want to make sure that we’re not too surprised by what we’re about to get into.
2.4.1.6 Assets Directory
A Unity Project is a collection of many files and directories that store settings and assets used to build a game. Programming projects are made of many small text files called source files. In addition to these files, Unity includes 3D models, textures, sounds, and other resources used to build a game.
The primary location for all your C# files and assets is in the Assets directory. If you add a file outside this directory, your game will not be able to access it. When a project gets bigger, subdirectories in the Assets directory help keep your game organized. How you organize is up to you and your team; however, when you move or rename files it’s best to do that from inside Unity 3D.
Living next to every file in the Assets directory is a .meta file. This meta file helps Unity 3D identify the file, as well as keep track of any settings related to that file. For instance, the SampleScene.unity generated with a new Unity Project has a neighboring .meta file that looks like the following:
Open that meta file in Visual Studio and you’ll see something like the following:
You should never need to directly edit a meta file, but it’s important to know why it’s there. When you share your game project, you’ll want to include all the generated .meta files. Otherwise, your settings for each object in the scene might get lost!
When starting your own projects double check that the Editor has the Visible Meta Files mode selected for Version Control in the Project Settings dialog. This will ensure that the files maintain their links between scenes and assets.
2.4.1.7 Project Settings Directory
The Editor itself has a lot of settings stored to prepare the environment to build to different platforms, Windows versus Android for instance. Global settings like those used by plugins, editor extensions, licenses, etc. are all stored in the Project Settings directory. Since many things like quality settings should be shared with your team, you should include the Project Settings directory when sharing your project.
2.4.1.8 Packages Directory
Next to the Assets directory in the computer’s file browser is the Library directory. This contains the glue which Unity 3D uses to tie assets and logic together behind the scenes. Your editor preferences, platform settings, and many other bits that game engines need are placed here. It is very rare any user will need to go in here to make any modifications, so it is best to avoid messing with the contents of this directory.
2.4.2 Git Ignore
Several directories are created when Unity opens a project. When using Git, the generated files need to be left out when checking for changes to add. Git uses a text file called .gitignore as a template to filter out files to ignore.
The file uses patterns in text, if a file name or directory matches a pattern in the .gitignore file then it’ll skip the file when searching for changes. If the .gitignore file contains log.txt then all files, anywhere, which the repo named log.txt will be ignored.
Thankfully, there are plenty of Unity users who also use Git and .gitignore examples are readily available. A quick search on the internet reveals something on GitHub called the Unity.gitignore. With a couple dozen contributors, it’s promising, and it’s also what I’ve included in the Git repo for the BookContents.
To inspect the .gitignore file use a text editor—Visual Studio would be good—and navigate to the root of the BookContents directory. Open the .gitignore and you’ll see about 40 lines of text.
2.4.3 What We’ve Learned
Unity 3D has a diverse set of tools, all of which are useful once you’ve decided to go ahead and build a game. The engine has been used to create everything from 2D side-scrolling games to 3D first-person shooters. Fantasy role-playing games and top-down strategy games have all been produced and published using the Unity 3D game engine.
It is best for you to look around online for additional information on the Editor itself. There’s plenty of cool stuff you can do once you follow some of the online tutorials that cover the basics of the Editor.
Topics on materials, particles, and animation will not be covered in this book. It’s a good idea to get into the different aspects of the Editor to understand the most out of Unity 3D, once you’ve gotten through a portion of this book.
The Unity Project is a directory. In this directory are a few subdirectories generated by Unity when it’s launched. Only the Assets, Project Settings, and Packages ever need to be backed up. New directories generated by Visual Studio and Unity when launched may include a hidden “.vs” directory, “.obj”, and various other files, but they’re updated when Unity or Visual Studio are launched, and these don’t need to be backed up.
To be an independent game developer, you’ll have to cover the breadth of skills that are usually taken on by different team members in a larger game production cycle. As a “lone-wolf” game developer, you must take on a variety of tasks, not just the code.
If you’re an artist looking to add programming on top of your current skill list, then the rest of the Editor’s functions will come more easily. It is still a good idea to know your way around Unity 3D if you’re new to this game engine.
2.5 Sample Code
Throughout this book, samples of code will be shown in what is called a code fragment. Fragments, as the word infers, are small parts of a whole code sample. Complete code samples will be given when it is necessary to show how a completed source file will look like. If only one or two lines change in a complete file, only the changed lines will be shown as a code fragment. Here’s an example of a complete source file:
The above example shows a new C# file generated by Unity 3D. We’ll observe how it is created in a moment. What’s important is that you could copy the text carefully into a new file named Example.cs and use it as is. First, let’s see what a fragment will look like and then we’ll go into how this is done.
2.5.1 Code Fragments
The following example shows a fragment of code taken from the completed source file:
You should be able to identify where the code was taken from, line numbers seen to the left of the code should help indicate where in the file to look. After identifying where its original is, you should be able to see what’s changed or added. This means you should make the same changes in your version of the source code.
A fragment is intended to showcase smaller, more important components of a complete code sample. Rather than reading through the completed source file and looking for the change, a fragment will help you find the important differences when a new concept is shown.
Not all examples in the book will start with a complete source file. Often, the code fragment will require only one line to represent the concept being explained. The context of the code sample and your ability to understand the context should be sufficient by the time you begin to see those examples.
Most of the programming fragments will not make a visual impact in the scene inside of Unity 3D. There isn’t a single command to make monsters appear or dragons breathe fire. Programming is the manipulation of data with logic, not magic.
If the changes are added correctly, your version will function the same way as described by the tutorial you’re reading. A code fragment cannot function on its own. The rest of the code is required by Unity 3D to run without errors.
Once a concept has been introduced, you’ll be required to remember how it is used. Later lessons will again reinforce the concept that learning how to program is a skill-building process. To program a complete game, you need to combine the different ideas taught here and write your own code. Building upon your own skill will not only expand your understanding of C#, but once concepts have been learned, you’ll be able to apply them to other programming languages.
Occasionally, I’ll refer to how C# differs from other programming languages. I’ll leave it up to you to investigate what the other languages look like on your own. This provides a context as to why C# looks or acts in a particular way and how other programming languages solve the same problem. In most cases, you may find that many programming languages look and behave quite similar.
2.5.2 Are Errors Bad?
No, errors and warnings are there to help you. Don’t be afraid to make mistakes. The code you write cannot break Unity 3D or your computer. At least nothing you’ll learn from this book will enable you to do so.
As a matter of fact, it is often good to produce errors. The errors tell us what we can and cannot do. Programmers often ask themselves, “Will the compiler let me do this?,” which may produce an error. If not, then the programmer will continue his thought with “Huh, I guess it will, so that means I can ….”
Creating and fixing errors tells us what the code expects from us. It is a sort of a conversation between the programmer and the computer; for example, the programmer asking questions in the form of a code statement and the computer replying with an error to the programmer who asks for things the computer can’t do.
Many years ago, programming magazines used to share code in print. This meant that you’d have to copy word for word what was written in an article to get a program to run. Back then the compiler wouldn’t tell you where the error was.
Hidden in your code could be a 1 (one) in place of an l (lower case L) and you’d have to find it yourself after typing in a few hundred lines of text. Be thankful for the modern IDE that tells you not only that there’s an error, but often where the error is.
2.5.2.1 Compile-Time and Run-Time Errors
There are two general cases of errors: compile-time and run-time errors. Compile-time errors often include syntactical errors that are usually found right away by Unity 3D before the code is even run. These are shown in the Console panel which we saw in a previous chapter.
An error where specific words may be misspelled, or an incorrect character is placed in the code will result in an error in the syntax in your code.
There are many cases in which compile-time errors can pop up, far too many to list here. However, compile-time errors (sometimes called parsers) occur when the code itself is written incorrectly.
Run-time errors happen while the game is running and the code is executed. These errors are usually created by a misunderstanding of what the code can do. When Unity 3D comes across a statement that contains unexpected data or tries to do something mathematically impossible, for example, divide by zero, we get a run-time error. Such errors are usually a bit harder to fix as they only show up when there are specific conditions in the game. For these, we can mark the statement in Visual Studio and tell Unity 3D to stop when it gets there. Once that happens, we can inspect every bit of data and its value. This will help find and fix any problems that exist.
Errors simply stop Unity 3D from running your code. Some properly written code may follow correct syntax, but might require you to force Unity 3D to close using the task manager. However, this is rare and often easy to fix. Read the code samples carefully as you enter them into Visual Studio.
To fix the error, you find what character was mistyped and replace it with a correction. To test if the error is fixed, go back to Unity 3D from Visual Studio. If no errors or warnings are produced, then your code is clear of syntactical errors.
2.5.3 How to Follow Along
Many examples will require that you use both Visual Studio and read Unity 3D’s console window. We’ll be switching back and forth often for each section. When working in Unity 3D, you might need to have the Editor take up a lot of screen space to have access to all the different parts of the Unity 3D interface. Primarily we’ll need to see both the Console and the Inspector panels. This is often why programmers like having multiple monitors. One monitor with their code and the other monitor with an editor open, showing them the resulting behaviors.
Each section may have a corresponding Unity 3D scene. Open the Unity Hub to open the different chapter exercises.
The Hub is a separate app from the Unity 3D Editor. It’s used to install new and beta releases of Unity as well as create and open projects. From here, select the Open icon to the top right of the Hub app.
Select the directory of the chapter you’re currently reading about and click on Select Folder. An additional window may open asking which version of Unity to use; select the latest version and continue. Select continue if any additional windows open asking about upgrading the project to the version of Unity you’re using.
In each project for each chapter are Unity Scenes, each named by section. I’d suggest taking in a single chapter at a time and then letting the information sink in a bit. You should also conduct experiments on your own to gain a better understanding of what you just learned. If you can make assumptions about something you’ve learned and step beyond what was taught in the chapter, then I’d say you have a usable grasp of the chapter.
Without following each chapter and skipping around, you might find yourself reading terms that are unfamiliar. I try my best to build up from one chapter to the next. So, try not to skip too far ahead of yourself, unless you find yourself being bored and unchallenged; in that case, you skim through each chapter until you find something you’re not already familiar with.
2.5.4 Comments: A First Look
In the code you’ll see some marks that precede text in the IDE. Usually you’ll see either // or /* with some text followed by */ at the end. These indicate what is called a Comment. A Comment makes the text invisible to the compiler.
If the compiler doesn’t know the text is there, then what is it good for? Throughout the examples provided for this book comments are placed in the project near the example code. It’s with the comments that additional help and information is presented.
Even the engineers at Unity leave helpful breadcrumbs in the code hinting at what the code in the file does. The image above shows the comment “// Use this for initialization” to indicate what the following code is used for. Comments are useful, and you should remember to use them to keep notes for yourself as you learn.
Comments are used like breadcrumbs in a deep forest. Comments help leave behind some of the thought process in why your code is written the way it is.
2.5.5 What We’ve Learned
We’re going to have to do a lot of reading and writing. Sorry, that’s just the case when it comes to code. If this doesn’t detract from the experience of learning, then great! Otherwise you’re going to have to just get over the fact that programming involves a lot of typing and thinking at the same time. If you’re used to doing that sort of thing, then great!
