Abstraction in object-oriented programming

Inheritance and polymorphism in object-oriented programming

Encapsulation in object-oriented programming

Profile code to identify issues

Job preparation: Junior Programmer

Quiz: Apply object-oriented principles

Submission: Programming theory in action

Deep-dive into the pillars of object-oriented programming and their application, then learn how to profile and optimize code.

In this mission, you’ll refactor the inventory project you completed in the previous mission using the pillars of object-oriented programming as a guide. You’ll deep dive into the inner workings of each pillar individually, so you can better understand its value in developing applications. Next, you’ll learn how to profile your code to identify any optimization bottlenecks that would slow down the final build of your application. To close out this mission, you’ll develop a small application for your portfolio that uses fully optimized code built on OOP principles. 

When you complete this mission you will complete the Junior Programmer pathway - CONGRATULATIONS!

Apply Object-Oriented Principles

Unity Junior Programmer

Kickstart your programming career with Unity's Junior Programmer Pathway. Learn coding fundamentals, C#, and game development to create your first interactive projects. Start learning for free!

Junior Programmer Pathway - Learn Coding & Game Development | Unity Learn

We recommend that you have basic knowledge of Unity or complete 

Ready to code? This guided learning Pathway will take you from zero to job-ready!

Welcome to Junior Programmer! Designed for anyone interested in learning to code or obtaining an entry-level Unity role, this pathway assumes a basic knowledge of Unity and has no math prerequisites. Junior Programmer prepares you to get Unity Certified so that you can demonstrate your job-readiness to employers.

Junior Programmer

Course Introduction

Install Unity Software

Unit 1 - Introduction

Lesson 1.1 - Start your 3D Engines

Lesson 1.2 - Pedal to the Metal

Lesson 1.3 - High Speed Chase

Lesson 1.4 - Step into the Driver's Seat

Challenge 1 - Plane Programming

Lab 1 - Project Design Document

Introduction to project management and teamwork

Quiz 1

Learn how to create new C# scripts, call basic functions, and use variables to modify the results of those functions.

In this first mission in the Junior Programmer pathway, you will program a car moving side-to-side on a floating road, trying to avoid (or hit) obstacles in the way. In addition to becoming familiar with the Unity editor and workflow, you will learn how to create new C# scripts and do some simple programming. By the end of the Unit, you will be able to call basic functions, then declare and tweak new variables to modify the results of those functions.

Player Control

Unit 2 - Introduction

Lesson 2.1 - Player Positioning

Lesson 2.2 - Food Flight

Lesson 2.3 - Random Animal Stampede

Lesson 2.4 - Collision Decisions

Challenge 2 - Play Fetch

Lab 2 - New Project with Primitives

Quiz 2

Mod the Cube

Quiz: Create with Code 1

Gain familiarity with some of the most important programming and Unity concepts, including if-then statements, random value generation, arrays, collision detection, prefabs, and instantiation.

In this Mission, you will program a top-down game with the objective of throwing food to hungry animals - who are stampeding towards you - before they can run past you. In order to do this, you will become much more familiar with some of the most important programming and Unity concepts, including if-then statements, random value generation, arrays, collision detection, prefabs, and instantiation. In completing this Unit, you will learn how to program a basic game with the ability to launch projectiles and maneuver the player to keep the game alive.

Basic Gameplay

Unit 3 - Introduction

Lesson 3.1 - Jump Force

Lesson 3.2 - Make the World Whiz By

Lesson 3.3 - Don't Just Stand There

Lesson 3.4 - Particles and Sound Effects

Challenge 3 - Balloons, Bombs, & Booleans

Lab 3 - Player Control

Quiz 3

Learn how to add music, sound effects, and visual particle effects to transform the experience of your project.

In this Mission, you will program a fast-paced endless side-scrolling runner game where the player needs to time jumps over oncoming obstacles to avoid crashing. In creating this prototype, you will learn how to add music and sound effects, completely transforming the experience of your projects. You will also learn how to create dynamic endless repeating backgrounds, which are critical for any side-scrolling games. Finally, you will learn to incorporate particle effects like splatters and explosions, which make your games so much more satisfying to play.

Sound and Effects

Unit 4 - Introduction

Lesson 4.1 - Watch Where You’re Going

Lesson 4.2 - Follow the Player

Lesson 4.3 - PowerUp and CountDown

Lesson 4.4 - For-Loops For Waves

Challenge 4 - Soccer Scripting

Lab 4 - Basic Gameplay

Quiz 4

Learn how to implement new gameplay mechanics including powerups and increasing difficulty.

In this Mission, you will program an arcade-style Sumo battle with the objective of knocking increasingly difficult waves of enemies off of a floating island, using power ups to help defeat them. In creating this prototype, you will learn how to implement new gameplay mechanics into your projects, which are new rules or systems that make the game more interesting to play. On one hand, you will learn to program a powerup, which give the player a temporary advantage. On the other hand, you will learn to program increasingly difficult enemy waves, which make survival more challenging for the player. A good balance of powerups and increasing difficulty make for a much more interesting gameplay experience.

Gameplay Mechanics

Unit 5 - Introduction

Lesson 5.1 - Clicky Mouse

Lesson 5.2 - Keeping Score

Lesson 5.3 - Game Over

Lesson 5.4 - What’s the Difficulty?

Challenge 5 - Whack-a-Food

Lab 5 - Swap out your Assets

Quiz 5

Introduction to user feedback and testing

Learn how to implement a User Interface - or UI - into your projects, such as a title screen and score display.

In this Mission, you will program a game to test the player’s reflexes, where the goal is to click and destroy objects randomly tossed in the air before they can fall off the screen. In creating this prototype, you will learn how to implement a User Interface - or UI - into your projects. You will add a title screen with a difficulty select menu that will control how challenging the gameplay is, you will add a score display that will track how many points the player has earned, and you will add a Game Over screen, which will allow the player to restart and try again. In learning these skills, you will be able to create a fully “playable” experience that the user can enjoy from start to finish without having to restart the application to try it again.

User Interface

Next Steps - Introduction

Lesson 6.1 - Project Optimization

Lesson 6.2 - Research and Troubleshooting

Lesson 6.3 - Sharing your Projects

ECS Survival Guide

Career research and preparation

Introduction to portfolios

Debug the App

Counting Prototype

Quiz: Create with Code 2

Prepare to continue developing your Unity and C# skills independently, including learning how to complete your personal project.

In this Mission, you'll prepare to continue developing your Unity and C# skills independently, including learning how to complete your personal project and how to prepare for the Unity Certified User: Programming exam, which you can take through your school program, if available.

Publishing Your Project

Introduction to real-time 3D experience design

Set up version control

Explore the sample project

Principles of object-oriented programming

Create a scene flow

Implement data persistence between scenes

Implement data persistence between sessions

Quiz: Manage scene flow and data

Submission: Data persistence in a new repo

Learn about data persistence and an introduction to the core pillars of object-oriented programming.

In this mission, you’ll learn about data persistence, or how to manage the loading and unloading of data between both scenes and sessions. Along the way, you will be introduced to the core pillars of object-oriented programming, which will help you structure your code throughout the mission. There will only be one practical example throughout the mission, which will build on the new functionality you create with each tutorial. At the end of this mission, you’ll take everything you learned and apply it to a new project by building a persistent score system for a small game.

Manage Scene Flow and Data

9c472a98-98b7-42f3-896f-909ad64b3aa4:f74a5b9686ce

Overview

Explore the scene

Gather profiling data

Establish a millisecond budget 

Explore the Profiler Timeline

Add Profiler sample methods

Optimize the Code

Summary

In this tutorial, you’ll learn how to use the Profiler to analyze a scene and identify where optimization bottlenecks are occurring.


By the end of this tutorial, you will be able to:

Deduce the script method that uses the most CPU time (vs. a script method that does not) by using the CPU profiler in the Profiler window

Differentiate a loop that efficiently goes through a collection once in an Update() call from many loops that go through the same collection in an Update() call

Recognize possible issues that might cause performance problems (e.g., too many RigidBody components, too many Colliders, too many shadows, etc.), given a scenario

Investigate performance issues caused by poly count, texture sizes, or too many objects on the screen by using Unity's Stats window

Identify unnecessary nested if statements

Designed for post-secondary and K-12 educators at accredited academic institutions teaching Unity in the classroom, the Unity Educator plan provides you with free access to the same real-time 3D development tools used by professionals to support your students.

Included in this plan are Unity Pro, cloud-based collaboration, cloud build, free Unity assets, and much more!

Junior Programmer Pathway Facilitator Kit.zip

Junior Programmer Pathway Facilitator Kit (Google Drive)

Unity Educator Hub

The Unity Junior Programmer Pathway Facilitator Kit includes everything you need to successfully bring this Pathway into your learning context including a syllabus, complete lesson plans, standards alignment, teacher preparation guide, and more. 

Junior Programmer: Apply object-oriented principles

As you work toward finalizing your project and preparing it for publishing, it’s important to identify and resolve, either during or after refactoring, any bottlenecks that remain in your code. Unity’s Profiling tool is ideal for locating hard to find issues that may be driving down your frame rate. The Profiler produces a detailed report of precisely what is occurring in an application frame by frame, including what scripts are called, how memory is being allocated, how visuals are rendered on the screen, and more. You can see anything that affects your project’s performance in the Profiler.

Your project’s performance depends largely on the computer it runs on, which is why it’s important to profile your project on your specific target device, or, if your target has a range of supported hardware, such as desktop, to profile on multiple devices with different specifications. If you run this project on a new high-end gaming PC, you’re likely to get very high frame rates, while the experience might be completely different on a five-year-old laptop with onboard graphics. 

To make it easier to identify common optimization issues, we created a highly unoptimized scene for you to review as you explore the Profiler for the first time. With this in mind, be aware that the numbers you see in this tutorial will likely not be exactly the same as those on your own computer. However, regardless of your frame rate, you will be able to see measurable results when you optimize the scripts.

Let’s look at an example of a performance issue we can examine with the Profiler. As previously mentioned, we will be using a custom scene created just for this tutorial, which is found in a dedicated optimization folder in your project.

1.  Locate the Optimization folder in the project, and open the Optimization scene in the Scenes folder. 

2. When you first open the scene, you’ll only see a gray plane. In the Hierarchy, you’ll also see a Manager GameObject with an OptimManager script attached.

4. In Play mode, thousands of forklifts appear on the plane, all rotating and moving around within a set boundary. Open the Stats tab and make note of the current frames per second (FPS) for your computer. 

5. Exit Play mode and look at the OptimManager script in the inspector. This script is responsible for the generation of the field of forklifts. Note the variable for the forklift prefab, an instance count, and the size of the boundary.    

6. Select the Manager object in the Hierarchy, then in the Optim Manager component, change the instance count to 200. Reenter Play mode and observe the change to your FPS. 

The reduction in the number of forklifts in the scene increases the overall FPS. In a situation where frame rate matters over anything else in an application, this might be a viable optimization solution. However, what if the application required both 2000 forklifts and a frame rate of 60 FPS? 

With these requirements in mind, it’s important to figure out precisely where the bottleneck is occurring. Was the frame rate lower in the first example simply because there were 10 times as many meshes on the screen? Is it because they’re all moving? Is it something else? Finding the answer will tell you exactly what to address.

Profiling will give you a snapshot of everything that’s occurring and exactly how long each operation is taking, so you can make an informed decision as to how to improve your frame rate.

Game view from the Optimization scene, which has 2000 forklifts moving in random directions. The Game Stats window is open in the top-right corner with the frame rate of 11.6 FPS highlighted.

Game view from the Optimization scene, which now has only 200 forklifts moving in random directions. The Game Stats window is open in the top-right corner with the improved frame rate of 90.6 FPS highlighted.

Let’s look under the hood and figure out what Unity is processing in this scene.

1. Set the Instance Count on the OptimManager back to 2000.

2. Open the Profiler by selecting Window > Analysis > Profiler.

3. Dock the Profiler window next to your Project window. 

4. Currently, the Profiler is completely blank, because no data about the scene has been gathered yet. The Profiler begins working when you start Play mode. Ensure that the Profiler’s record button (the red dot) is active, and then press Play.  

5. The Profiler will begin to log a color-coded chart of performance data.  After a second or two, exit Play mode. You now have a detailed outline of everything occurring in the application during that time period. 

The top half of the Profiler is divided into modules, starting with CPU Usage. This will be the only module we’ll use in this tutorial. 

The module contains a chart of various categories of operations and how they are making use of the CPU. On the left side of the module, there is a color key for these categories. Spikes show when one of these categories of operations, such as Rendering, takes up more time to work on a specific frame. 

Notice that the blue background isn’t a background at all, but a representation of scripts running! Even from this very high level, we can tell that something is very likely going wrong with our scripts, since they’re taking up orders of magnitude more processing power than even rendering the scene itself. We will inspect the scripts shortly.

Profiler window with the “Record Profiling Information” button highlighted.

Profiler window showing CPU usage, with almost the entire window filled with a light blue color, indicating that each frame is taking a very long time to render. There is a vertical white line in the window, indicating a particular frame, with the tag “94.57ms”, which means that frame took 94.57ms to render.

The bottom half of the Profiler shows a visual breakdown of exactly what’s occurring in each frame. If you don’t see the bar graph visualization on the bottom half of the Profiler, select Timeline in the dropdown directly below the Profiler Module section. 

The white vertical line on the CPU Usage graph represents one frame that was played in the application. Left-click and drag this line in the CPU Usage module to see how usage changes from frame to frame. Select a frame where there’s a spike in CPU usage. 

In the above example, you can see the notation CPU: 117.26ms (highlighted). This represents the total amount of time, in milliseconds, that everything in this frame took to complete. 

When profiling, we want to pay specific attention to this millisecond completion rate, as it's the key to achieving the final frame rate goal. Depending on the target frame rate, you will have a specific millisecond budget per frame. The way to calculate this is:

1000 ms / target frames per second = ms budget

So, to reach a target of 60 FPS, each frame has a millisecond budget of 16. This means that the frame currently being profiled is more than seven times what it needs to be!

Halfway down the left side of the Profiler window, a dropdown item is highlighted with the “Timeline” option selected.

A single frame is selected in the Profiler window. In the Timeline panel, the CPU render time is highlighted and displaying “CPU: 117.26ms”.

At the top of the Profiler Timeline there are two alternating labels: PlayerLoop and EditorLoop. If you don’t see these, you may have to use your scroll wheel or trackpad to zoom in. The PlayerLoop represents everything that’s running in the game itself, whereas the EditorLoop represents everything that’s happening to run the application in the Editor. In this case, since our end user won’t be using the app in the Unity Editor, it's safe to ignore the EditorLoop and focus only on what’s happening in the PlayerLoop.

The bars listed below the PlayerLoop represent everything that’s happening in the application during that frame, in descending order by length of time. The Profiler Timeline is color coordinated to match the CPU Usage graph. The large blue bar indicates that there is a specific script-related action occurring in this frame that is taking up a large chunk of time.

Click on the bar to see that the source of this action is the OptimUnit script, specifically its Update method. It takes 81.55 ms to complete, which by itself goes over our milliseconds budget many times over. Also note that there are 2,000 instances of this script running in this frame, which is significant because we know that we’re generating 2,000 forklifts in the OptimManager script. Somehow, these two factors must be related. 

Why would the script run 2,000 times? There must be one instance for each forklift. If we select the OptimUnit Prefab on the OptimManager, we discover that the OptimUnit script is attached to the Prefab itself — which means that there are indeed 2,000 copies of this script running.

Next, we can use the Profiler to help us identify the exact lines of code that are slowing down this project.

In the Timeline of the Profiler window, a light blue bar is selected. Next to the blue bar is a pop-up interface, displaying info for “OptimUnit.Update()”.

There’s a lot going on in the OptimUnit script Update method, so let’s get a little bit more help from the Profiler. We can profile specific sections of code by adding Profiler.BeginSample and Profiler.EndSample methods.

1. In the Optimization folder, locate the Scripts folder, and open the OptimUnit script.

The Update method is handling four discrete tasks: handling time, rotating the forklift prefab, moving the forklift prefab, and checking for the Manager’s boundary. Let’s flag these tasks for the Profiler to track. 

2. Add the BeginSample and EndSample methods directly above and below the HandleTime method at the top of Update: 

Profiler.BeginSample("Handling Time"); // begin profiling a piece of code with a custom label
HandleTime();
Profiler.EndSample(); // ends the current profiling sample

Notice that Profiler.BeginSample has a parameter to declare a custom tag name. This label will appear in the Profiler in the same way that “OptimUnit.Update” does.

3. Directly after the Profiler.EndSample method, add a new BeginSample for Rotating: 

Profiler.BeginSample("Rotating"); // begin profiling

var t = transform;
float xRotation = currentAngularVelocity * Time.deltaTime;
float zRotation = currentAngularVelocity * Time.deltaTime;
	
if (transform.position.x > 0)
    xRotation *= -1;
	
if (transform.position.z < 0)
    zRotation *= -1;
	
transform.Rotate(xRotation, 0, zRotation);

Profiler.EndSample(); // end profiling

4. Again, directly below the last EndSample, add a new BeginSample, this time for Moving: 

Profiler.BeginSample("Moving"); // begin profiling
        
Move();
        
Profiler.EndSample(); // end profiling

5. Finally, add one last BeginSample beneath your previous EndSample, this time for Boundary Check: 

Profiler.BeginSample("Boundary Check"); // begin profiling

//check if we are moving away from the zone and invert velocity if this is the case
if ((transform.position.x > areaSize.x && currentVelocity.x > 0)
    || (transform.position.x < -areaSize.x && currentVelocity.x < 0))
{
    currentVelocity.x *= -1;
    PickNewVelocityChangeTime(); //we pick a new change time as we changed velocity
}

if ((transform.position.z > areaSize.z && currentVelocity.z > 0)
    || (transform.position.z < -areaSize.z && currentVelocity.z < 0))
{
    currentVelocity.z *= -1;
    PickNewVelocityChangeTime(); //we pick a new change time as we changed velocity
}

Profiler.EndSample(); // end profiling

6. Save the script and return to the Editor.

7. In the Profiler, press the Clear button to clear the currently captured data. 

8. Capture new data by pressing Play and letting the application run for a few seconds, then exit Play mode.

9. In the CPU Usage module of the Profiler window, select another frame with a spike on CPU Usage. 

10. Let’s look at the code sections we flagged. Directly below the OptimUnit.Update bar is a new scripting bar. This bar represents all of the new sampled code. Select it and one of the new sample labels will appear. 

11. Click on the Timeline dropdown and select Hierarchy.  

12. The frame data will change to a list view, with the labels for the four code sections automatically selected.  

In this view, it becomes immediately clear in the Time ms column that the issue is in the Moving method! Now that we have the issue identified, it’s time to try and resolve it in the code.

Profiler window with the Clear button highlighted.

In the Profiler window, the “Timeline” dropdown is expanded with a mouse cursor hovering over the “Hierarchy” option.

In the Hierarchy view of the Profiler window, the row for the “Moving” label is highlighted, showing 77.42ms for the Time column.

1. Return to the OptimUnit script and scroll down until you find the Move method call in Update. Hold the Ctrl (Windows) or Cmd (Mac) key and left-click Move to jump down to the method itself. 

void Move()
{
    Vector3 position = transform.position;

    float distanceToCenter = Vector3.Distance(Vector3.zero, position);
    float speed = 0.5f + distanceToCenter / areaSize.magnitude;

    int steps = Random.Range(1000, 2000);
    float increment = Time.deltaTime / steps;
    for (int i = 0; i < steps; ++i)
    {
        position += currentVelocity * increment * speed;
    }

    transform.position = position;
}

The Move method calculates several variables, and iterates a for loop between 1,000 and 2,000 times to calculate the new position of the forklift. Multiply that by 2,000 forklifts (2-4 million loops!), and consider that this method runs once per frame — it’s easy to see why this method is so slow. These calculations are redundant to currentVelocity, which is calculated in the Boundary Check code, so it is easy to simplify this method so it only takes care of moving the forklift.


2. Replace the body of Move with the following line: 

void Move()
{
    transform.position = transform.position + currentVelocity * Time.deltaTime;
}

3. Save the script and return to the Editor. 

4. Clear the Profiler data and capture more data once again in Play mode. 

The change in the Profiler is dramatic! Previously, the Move code was taking 77.42ms to complete. After the optimization changes, it only takes 0.36. The total CPU ms have also dropped to 9.75, which is beneath the 16 ms target! 

In the game view, the FPS has jumped to 143! 

In the Hierarchy view of the Profiler window, the row for the “Moving” label is highlighted, now showing 0.36ms for the Time column, and a total CPU render time of 9.75ms for the entire frame.

Game view from the Optimization scene, which has 2000 forklifts moving in random directions. The Game Stats window is open in the top-right corner, now showing a frame rate of 143.2 FPS (7.0ms).

Although this was an extreme example, this sample scene illustrates how simple scripting mistakes can sometimes make a large impact on the performance of an application. In an application that’s being produced for a commercial purpose, you’ll likely find many different bottlenecks across many scripts, but the process will always remain the same. Use the Profiler to identify problem scripts, and use the Profiler Sample methods to isolate blocks of code that you suspect may be an issue. Once the specific problem code is identified, refactor it, profile again, and repeat until you’ve addressed all of the issues. You now have the tools to identify inefficient code in your own projects. 

Profile code to identify issues

1. Overview

2. Explore the scene

3. Gather profiling data

4. Establish a millisecond budget

5. Explore the Profiler Timeline

6. Add Profiler sample methods

7. Optimize the Code

8. Summary

Complete this tutorial