🚢 Lesson 12.3: Quality Settings, Builds & Shipping (Mini-Project)

Quality Settings & URP Tiers

Not every machine is equal. A gaming PC can push shadows, anti-aliasing, and high-res textures that would crawl on a laptop or a phone. Unity's answer is Quality Settings (Edit ▸ Project Settings ▸ Quality): a set of named levels — typically Low, Medium, High — that the player (or your game) can switch between.

In a URP project, each Quality level points at a URP Asset (the render pipeline settings) and its Renderer. That's how a "Low" tier turns off extra features while "High" enables them. Common knobs per tier:

• Shadows — resolution, distance, and cascade count (the biggest single lever on many scenes)
• Anti-aliasing (MSAA) and render scale
• Texture quality — full res vs. half/quarter res on lower tiers
• V-Sync and target frame rate

You let players choose their tier from a settings menu, then apply it in code:

using UnityEngine;

public class QualityMenu : MonoBehaviour
{
    // Hook this to a dropdown: 0 = Low, 1 = Medium, 2 = High.
    public void SetQuality(int level)
    {
        QualitySettings.SetQualityLevel(level, applyExpensiveChanges: true);
    }
}

Player Settings

Edit ▸ Project Settings ▸ Player is your game's identity card and low-level configuration. Before you ship, set at least:

• Company Name & Product Name — these define the save-data folder path and the window title, so set them before players create save files.
• Icon and Cursor — the executable's icon and default cursor.
• Resolution & Presentation — fullscreen mode, default window size, whether the resolution dialog appears, and allowed orientations (for mobile).
• Splash Screen — the "Made with Unity" screen (removable on paid plans).
• Other Settings — the scripting backend (Mono for fast iteration, IL2CPP for shipping performance and required on many platforms), the API compatibility level, and Managed Stripping Level (which trims unused code — more on that under build size).

Build Profiles (Unity 6)

Unity 6 replaces the old single "Build Settings" window with Build Profiles (File ▸ Build Profiles). A profile bundles a platform target, its scene list, and platform-specific overrides into one reusable, switchable configuration — so you can keep a "Windows Demo" profile and a "WebGL Itch" profile side by side and swap between them in a click. Here is the window, recreated faithfully:

Target Platforms & WebGL

Each platform in the left column is a build target. To build for one you may first need its module installed via the Unity Hub (Hub ▸ Installs ▸ your version ▸ Add Modules) — WebGL, Android, iOS, and others are optional downloads, not part of the base editor.

WebGL deserves special mention because it's how you put a game on the web — playable in a browser with no download, perfect for a portfolio or a site like Ray's House of Fun. A few things are different for WebGL:

• No threads for your game logic in the usual sense, and a sandboxed filesystem — Application.persistentDataPath maps to browser storage (IndexedDB), so your Module 5 saves still work but live in the browser.
• Build size matters more — players download the whole build before playing, so compression and stripping (next section) are not optional.
• It must be served over HTTP(S), not opened as a local file://. Use Build And Run (which starts a local server) or upload the output folder to a host.
• Choose a compression format in Player Settings (Brotli gives the smallest download; Gzip is more widely compatible).

Trimming Build Size

After a build, Unity writes a Build Report (see it in the Console log, or the Build Report window). It lists what took up space — and it's almost always textures and audio, not code. Your biggest levers:

• Texture compression & max size. In each texture's Import Settings, cap the Max Size (does a UI icon really need 4096px?) and pick a compressed format. This is usually the single largest reduction.
• Audio import settings. Compress music to Vorbis and stream it; load short SFX decompressed. Long uncompressed clips bloat builds fast.
• Managed code stripping. With IL2CPP, the Managed Stripping Level (Player Settings) removes unused code. Higher levels shrink the build but can strip code reached only by reflection — test after raising it.
• Remove what you're not shipping. Exclude test/sandbox scenes from the profile's Scene List (see Figure 1), and don't ship a Development Build.

Testing the Build

A game that works in the Editor is not the same as a game that works when built. The Editor has all assets loaded, references intact, and no stripping. Always test the actual player before you call it done:

• Play it end to end. Boot scene, menu, gameplay, pause, save/load, quit. Bugs from missing scenes in the Scene List or over-aggressive stripping only show up here.
• Profile the built player. Use your Development Build profile and attach the Profiler (Autoconnect Profiler, or connect from the Profiler's target dropdown). Real device/player numbers are the only ones that count.
• Check the Player log. When something breaks in a build, the log file (path varies by platform) holds the errors the Editor Console would have shown.
• Test on a modest machine. Your dev PC is faster than most players' hardware — verify your Low quality tier actually runs well on something humble.

Mini-Project: Ship It

Time to put the whole module together on a project of your own — ideally one of the games you built earlier in this course. You'll run the complete shipping loop: profile it, fix what the Profiler flags, build it, and test the build. That loop is the heartbeat of every release:

Figure 2: The profile → optimize → build → test loop. You go around it until the built player holds its frame budget, then ship.

Course Wrap-Up

Take a breath and look back at how far you've come. You started this course knowing the Editor and basic C#. You're finishing it able to build, optimize, and ship a real game. Here's the ground you covered across twelve modules:

• Module 1 — Animation: state machines, blend trees, and animation events driving a character.
• Module 2 — Architecture & ScriptableObjects: decoupling with interfaces, events and delegates, and data-as-assets with ScriptableObject event channels.
• Module 3 — The New Input System: Input Actions, action maps, reading input in code, and rebinding across keyboard and gamepad.
• Module 4 — Advanced UI: canvas render modes, a main menu and pause system, live HUDs, and world-space UI.
• Module 5 — Scene Management & Persistence: async loading, additive scenes, PlayerPrefs, and a JSON save system.
• Module 6 — AI & Navigation: NavMesh baking, agents and patrols, and an enemy state machine that senses the player.
• Module 7 — Combat & Inventory: health and damage through interfaces, raycast hit detection, and an inventory with pickups and equipping.
• Module 8 — Lighting & Shaders: URP lighting, lightmapping and light probes, and your first Shader Graph dissolve effect.
• Module 9 — VFX & Cinematics: particle systems, GPU particles in the VFX Graph, post-processing volumes, and a Timeline cutscene.
• Module 10 — 2D Essentials: sprites and sorting, sprite sheets, tilemaps, and a 2D physics platformer base.
• Module 11 — 2D Animation & Lighting: frame-based and skeletal 2D animation, and 2D lights and shadows.
• Module 12 — Performance & Shipping: profiling, object pooling and optimization, and building for release — right here.

💡 Where to go next. Pick one small game and finish it — a complete little thing beats a dozen half-started prototypes for what it teaches you. Then explore the specializations these modules opened doors to: deeper shaders and the VFX Graph, netcode and multiplayer, addressables and streaming for larger projects, or a platform you love (mobile, console, or web). The Unity Manual, the official Learn platform, and the community forums are your ongoing companions.

Summary

🚀 What's Next?

This is the end of the road for Unity Intermediate — and the start of yours. You have every skill needed to build a complete, optimized, shippable game, and the habits to keep growing on your own. Go make something, finish it, and put it in front of players. That's the whole point.