💾 Lesson 5.3: Saving with PlayerPrefs

A Tiny Key-Value Store

PlayerPrefs stores named values that survive between play sessions. You write with a key (a string like "MasterVolume") and a value; later you read it back by the same key. It supports exactly three types — int, float, and string — and nothing else.

Think of it as a small dictionary Unity saves to disk for you. No file paths, no serialization, no setup. That simplicity is its whole appeal and also the source of every mistake people make with it.

The API: Set, Get, Save

The entire everyday API fits on one screen. Writing:

using UnityEngine;

// Store values (key first, value second)
PlayerPrefs.SetFloat("MasterVolume", 0.75f);
PlayerPrefs.SetInt("LastLevel", 3);
PlayerPrefs.SetString("PlayerName", "Ray");

// Flush the writes to disk right now.
PlayerPrefs.Save();

Reading back — later, or after a restart:

float volume = PlayerPrefs.GetFloat("MasterVolume", 1f); // 1f = default if missing
int   level  = PlayerPrefs.GetInt("LastLevel", 0);
string name  = PlayerPrefs.GetString("PlayerName", "Player");

The Get methods take an optional second argument: the default returned when the key doesn't exist yet (a brand-new player has no saved volume). Always supply it — it saves you a pile of "why is my volume 0 on first launch?" bugs.

Rounding out the API, you can check for and remove keys:

if (PlayerPrefs.HasKey("PlayerName")) { /* it exists */ }

PlayerPrefs.DeleteKey("LastLevel");  // remove one key
PlayerPrefs.DeleteAll();             // wipe EVERYTHING for this app

Defaults & HasKey

Because a fresh install has no saved data, robust code always plans for "the key isn't there yet." You have two clean patterns:

1. Default argument (preferred for simple values): PlayerPrefs.GetInt("LastLevel", 0) returns 0 when the key is missing.
2. HasKey guard (when the very first run needs special handling): check PlayerPrefs.HasKey(...), and if it's the first launch, seed defaults and maybe show a welcome flow.

void ApplyOrSeedSettings()
{
    if (!PlayerPrefs.HasKey("MasterVolume"))
    {
        // First ever launch — seed sensible defaults.
        PlayerPrefs.SetFloat("MasterVolume", 0.8f);
        PlayerPrefs.SetInt("Fullscreen", 1);
        PlayerPrefs.Save();
    }

    AudioListener.volume = PlayerPrefs.GetFloat("MasterVolume");
    Screen.fullScreen    = PlayerPrefs.GetInt("Fullscreen") == 1;
}

Notice PlayerPrefs has no bool type, so booleans are stored as an int: 1 for true, 0 for false. That's a standard idiom you'll see constantly.

A Settings Menu Bound to PlayerPrefs

The textbook use of PlayerPrefs is an options screen. A volume slider, a fullscreen toggle, and a graphics dropdown — each reads its saved value on open and writes it back on change. Here's the panel we're wiring, drawn as it appears in-game:

The script behind it is short. On Start it loads saved values into the controls; each control's callback writes back:

using UnityEngine;
using UnityEngine.UI;

public class SettingsMenu : MonoBehaviour
{
    [SerializeField] Slider volumeSlider;
    [SerializeField] Toggle fullscreenToggle;
    [SerializeField] Dropdown qualityDropdown;

    void Start()
    {
        // Load saved prefs into the UI (with first-launch defaults)
        volumeSlider.value      = PlayerPrefs.GetFloat("MasterVolume", 0.8f);
        fullscreenToggle.isOn   = PlayerPrefs.GetInt("Fullscreen", 1) == 1;
        qualityDropdown.value   = PlayerPrefs.GetInt("QualityLevel", 2);

        // Apply them to the actual systems
        ApplyAll();
    }

    public void OnVolumeChanged(float v)
    {
        PlayerPrefs.SetFloat("MasterVolume", v);
        AudioListener.volume = v;
    }

    public void OnFullscreenChanged(bool on)
    {
        PlayerPrefs.SetInt("Fullscreen", on ? 1 : 0);  // bool -> int
        Screen.fullScreen = on;
    }

    public void OnQualityChanged(int index)
    {
        PlayerPrefs.SetInt("QualityLevel", index);
        QualitySettings.SetQualityLevel(index);
    }

    // Hook to the Apply button to flush everything to disk.
    public void Apply()
    {
        PlayerPrefs.Save();
    }

    void ApplyAll()
    {
        AudioListener.volume = volumeSlider.value;
        Screen.fullScreen    = fullscreenToggle.isOn;
        QualitySettings.SetQualityLevel(qualityDropdown.value);
    }
}

Hook each control's On Value Changed event to the matching method in the Inspector, and the Apply button to Apply(). That's a complete, persistent options screen.

Where Is It Stored?

PlayerPrefs doesn't create a file you choose. Unity picks a per-platform location keyed by your Company Name and Product Name (set in Project Settings ▸ Player):

• Windows: the registry, under HKCU\Software\[CompanyName]\[ProductName].
• macOS: a preferences .plist at ~/Library/Preferences/unity.[CompanyName].[ProductName].plist.
• Linux: a file under ~/.config/unity3d/[CompanyName]/[ProductName]/.
• Android / iOS: the OS's shared-preferences / NSUserDefaults store for the app.
• WebGL: the browser's IndexedDB for that page origin.

Two consequences follow from this. First, because the path uses Company and Product name, renaming your product orphans the old prefs — the game looks like a fresh install. Second, on desktop the values are stored in plain text / plain registry entries a curious player can open and edit.

💡 Editor vs. build. In the Editor, PlayerPrefs uses a location tied to the Editor and your project, separate from a built game's store. So a value you saved while testing in Play mode won't magically appear in a standalone build, and vice versa — that's expected, not a bug.

What PlayerPrefs Is NOT For

Because it's so easy, people reach for PlayerPrefs to store their entire save game — serializing an inventory into one giant string, cramming level layouts into keys. Resist that. PlayerPrefs is the right tool for a narrow job and the wrong one for everything else.

Figure 2: Choosing where data lives. PlayerPrefs handles the small, flat stuff; structured state belongs in a JSON file; anything cheat-sensitive belongs on a server.

Specifically, do not use PlayerPrefs for:

• Complex / structured data — an inventory, a list of quests, a world layout. There's no nesting, no arrays, no objects. You'd be hand-serializing into strings, which is exactly what a real save system (next lesson) does properly.
• Large data — it's tuned for small values. Megabytes of game state will be slow and clumsy.
• Secure or anti-cheat data — it's trivially editable on desktop. Currency, unlocks, or leaderboard scores that matter must be validated server-side, never trusted from PlayerPrefs.

Hands-on Challenge

Summary

🚀 What's Next?

PlayerPrefs handles the small, flat stuff beautifully. But a real save game — the player's position, their stats, an inventory of items — is structured, and that's precisely what PlayerPrefs can't do. In Lesson 5.4: A JSON Save/Load System we build a proper save file with JsonUtility and write it to disk, tying the whole module together in a mini-project.