Forem: Rahul Barate

🐞Bug Resistant Development: Fail Fast – Part 3 (Compile Time Safety)

Rahul Barate — Thu, 12 Mar 2026 16:19:54 +0000

In the last blog we talked about Data Validation attributes like Min, Range, etc. These attributes help us Fail Fast. Fail Fast means detecting problems early rather than when the game is running.

In this blog we’ll talk about compile-time safety measures.

🤔What are Compile-Time Safety Measures?

Compile-time safety measures are simple tips and techniques that help catch errors during compilation, instead of Unity throwing them at you at runtime.

The earlier an error appears, the easier it is to fix.

Let’s look at some techniques I personally use.

✏️1. Enums > Strings

Now, what does this mean?

In your journey as a Game Developer you must have come across this scenario. Let’s say you have a state system that uses strings like "GameOver", "GameWon", etc. to set or get different states of the game.
Once the game is over you want to display a UI to restart the game, and you wrote the logic something like this:

if(state == "GamesOver")
{ 
    gameOverUI.SetActive(true);
}
else
{
    return;
}

Now, if you have a keen eye then you might have noticed what’s wrong. If you didn’t, then you must have pulled your hair debugging this type of bug.

Just know that a simple spelling mistake might cost you hours of debugging.

But I have a solution — Enums.

Enum is a value type similar to int, float, etc. Enum allows us to define named constants that hold numerical values behind the scenes.

If you are not familiar with enum then check out the official documentation for more details.

Instead of using a string-based state system we can use an enum-based state system.

Take a look at the following example:

public enum State
{
    GameWon,
    GameOver,
    GamePaused
}

public State gameState;

void ReduceHealth(int points)
{
    health -= points;

    if(health <= 0)
        gameState = State.GameOver;
}

void Update()
{
    if(gameState == State.GameOver)
        gameOverUI.SetActive(true);
}

You might be wondering how this is different from a string-based system.

In the string-based system your code will simply keep hitting the else block without telling you what went wrong. But in the enum example, if you mistype a value like State.GameOvr, the compiler (or even your IDE) will immediately show an error.

This saves you hours of debugging by failing fast.

✏️2. Avoid Magic Strings — Use nameof

Yes, this one is also about strings, and this will also save you from debugging for hours because of a simple spelling mistake.

nameof is an expression that returns the name of a variable, type, or method as a string value.

nameof specifically becomes useful when you need to provide the name of a method as a parameter, which opens the room for spelling mistakes.

Take a look at the following example:

// bad
Invoke("ResetGame", 2f); // using string again.

// good
Invoke(nameof(ResetGame), 2f); // using method name directly

The problem with the "bad" example is that if you change the method name and forget to update the string value, then you won’t even know what went wrong.

But if you use nameof, the compiler will throw an error immediately if the method name changes.

✏️3. private > public

This one is simple.

Keep your class members private unless you really need to access them outside the class. This reduces the chances of accidental modifications.

Take a look at the following example:

// bad
public int health = 100;

// good
private int health = 100;

In the "bad" example, any script can access the health variable and change its value.

Imagine your AudioManager having access to the player's health. You tried to change the volume but somehow your player's health goes up and down.

Nightmare scenario, isn’t it?

Keeping members private helps prevent such accidental access and modifications.

✏️4. readonly and const

To stop mutation or modification of values we use readonly or const.

We use const for compile-time constants like int, float, bool, etc. because the value is known at compile time and cannot be changed at runtime.

We can assign the value only during declaration.

We use readonly to stop reassignment of a reference type like List, Dictionary, etc.

With readonly, you can only assign the reference once during declaration or inside the constructor.

We cannot use const with types like List or Dictionary because their values are determined at runtime.

Take a look at the following example:

// bad
private Dictionary<string, int> map = new Dictionary<string, int>();
private int maxHealth = 100;

void Start()
{
    map = new Dictionary<string, int>(); // reassignment
    maxHealth = 80; // easily changed even though it should be fixed
}

// good
private readonly Dictionary<string, int> map = new Dictionary<string, int>();
private const int maxHealth = 100;

void Start()
{
    map = new Dictionary<string, int>(); // will throw error
    maxHealth = 80; // will throw error
}

⚠️Note: readonly prevents reassignment of the reference, but the contents of the object can still be modified.

💡Key Takeaway

Compile Time Safety helps catch problems before the game even runs.

Using enums instead of strings, avoiding magic strings with nameof, keeping members private, and using const or readonly where appropriate can significantly reduce the chances of runtime bugs.

The earlier a bug appears, the easier it is to fix.

🐞Bug Resistant Development: Fail Fast – Part 2 (💾Data Validation Attributes – Min, Range, etc.)

Rahul Barate — Thu, 26 Feb 2026 13:53:43 +0000

In the last blog post we talked about RequireComponent and OnValidate, which help you fail fast.
Fail fast means detecting problems early rather than when the game is already running.

In this blog we’ll talk about Unity attributes used for data validation that help us catch issues in the Inspector itself.

🤔What are Attributes?

An attribute tells the Editor how to behave with the fields, classes, or methods to which it is attached, without writing extra code.

There are many attributes for different purposes such as:

reference safety

serialization

Inspector visualization

In this blog we’ll focus only on the ones used for data validation and safer data entry.

⚠️Important Note

These attributes do not enforce rules at runtime.

They only validate data inside the Inspector.

If you change values through code, these attributes will not stop invalid data.
For runtime safety, you still need validation logic in your scripts.

✏️Data Validation Attributes

1) [Min()]

This attribute restricts an int or float to a minimum value in the Inspector.

[Min(0)] public int health; //prevents negative values from being entered through the Inspector.

2) [Range()]

This attribute restricts a value to a specific range and also shows it as a slider in the Inspector.

[Range(0, 100)] public float volume; // No negative values and nothing above 100.

3) [Tooltip()]

This displays a message when you hover over a field in the Inspector.

[Tooltip("Represents the current health of the enemy")]
public int enemyHealth = 100;

4) [Header()]

Adds a header to group related fields.
This improves readability and reduces the chances of assigning wrong values.

[Header("General Popup settings")]
public float popupAppearDuration = 0.5f;
public float popupStayDuration = 2f;
public float popupDisappearDuration = 0.5f;

5) [Space()]

Adds spacing between fields to make the Inspector cleaner.

public AudioMixer audioMixer;

[Space(20)]
public AudioMixerSnapshot muteSnapshot;
public AudioMixerSnapshot defaultSnapshot;

[Space(20)]
public AudioSource gameWonAudio;
public AudioSource gameOverAudio;

🖼️Checkout these screenshots of inspector window

💡Key Takeaway

These attributes won’t stop bad code, but they will stop bad data from being entered in the Inspector and that alone prevents a lot of bugs.

Fail Fast is not just about catching null references.
It’s also about guiding the user so wrong values are never entered in the first place.

🐞Bug Resistant Development: Fail Fast – Part 1 (RequireComponent & OnValidate)

Rahul Barate — Wed, 18 Feb 2026 06:10:24 +0000

It’s been a while since I last posted a blog. I was busy with a few things, I had a deadline to meet for my new game which is now in the closed testing phase and will be available to download next month.

Apart from this, I also have some good news to share, I am now a Unity Certified Associate Game Developer 🎉

Anyways, with that said, let’s start with today’s blog.

With this post we are starting a new blog series where we’ll learn techniques that make your development process bug resistant, systems that fail early and tell you what went wrong, instead of throwing errors at runtime.

🤔What does Fail Fast mean?

Fail fast means detecting problems during development or in the Editor rather than discovering them while the game is running.

The earlier something breaks, the easier it is to fix.

⚠️The problem with GetComponent()

While writing gameplay logic in C#, you must have used GetComponent().
It is used to get a reference to another component on the same GameObject.
But if you forget to add that required component…

💥 NullReferenceException

So, what if we could make sure that component is never missing?

🗝️RequireComponent

This is where RequireComponent comes into the picture.

RequireComponent is an attribute that automatically adds the required component when the script is attached to a GameObject.

You don’t have to remember to add it manually.

[RequireComponent(typeof(Rigidbody))]
public class PlayerMovement : MonoBehaviour
{
}

Now whenever this script is added, Unity will also add a Rigidbody.

📝Note:
This does not cache the reference. You still need to call GetComponent() in your script but now you are safe because the component will always exist.

🤔What about other types of data?

RequireComponent works for components.

But what about:

integers
floats
strings
optional references
value validation?

This is where OnValidate() comes in.

🗝️OnValidate()

OnValidate() is an Editor-only method.
It is called when:

values change in the Inspector
the script is recompiled
entering Play mode
the scene loads
It does not run in builds.

We can use it to:

perform null checks
clamp values
auto-assign references
validate scene-only usage
keep serialized data in sync

RequireComponent is for mandatory components.
OnValidate is for data validation and smart auto-setup.

Example

private void OnValidate()
    {
        if (canvasGroup == null)
        {
            canvasGroup = GetComponent<CanvasGroup>();
            if (canvasGroup == null)
            {
                canvasGroup = gameObject.AddComponent<CanvasGroup>();
                Debug.Log($"Added missing CanvasGroup to {gameObject.name}");
            }
        }

        if (masterVolume < -80f) masterVolume = -80f;
        if (masterVolume > 0f) masterVolume = 0f;

        if (uiElement == null)
        {
            Debug.LogWarning($"[Validation] {gameObject.name}: UI Element is not assigned!", gameObject);
        }

        if (sceneSpecificLight != null)
        {
            // Check if the object being validated is a Prefab or a Scene Instance
            bool isPrefab = EditorUtility.IsPersistent(this);
            bool isLightInScene = !EditorUtility.IsPersistent(sceneSpecificLight);

            if (isPrefab && isLightInScene)
            {
                Debug.LogError($"[Validation] {gameObject.name}: You cannot assign a Scene object (Light) to a Prefab asset! Please clear this field.");
                sceneSpecificLight = null; // Force clear to prevent broken references
            }
        }

        if (actionButton != null && !actionButton.interactable)
        {
            Debug.Log($"{gameObject.name}: Action Button is currently set to Non-Interactable.");
        }
    }

💡Key Takeaway

Don’t wait for runtime errors to tell you something is wrong.

Using RequireComponent and OnValidate, you can detect problems in the Editor itself and make your scripts far more reliable. This is the first step towards a bug resistant development workflow.

What is Time.deltaTime and how does it work?

Rahul Barate — Wed, 10 Dec 2025 14:42:15 +0000

If you are a beginner Game Developer or Programmer in Unity, you must have come across the term Time.deltaTime. You might even know what it does, but have you ever wondered how it actually works?

Let’s break it down in a simple way.

🤔What is Time.deltaTime?

To understand Time.deltaTime, you first need to know what the Update() method is.

The Update method is the main player loop method in Unity. The Update() method is called every frame. Whatever tasks you define in the Update method will run every frame. One of the very first things you learn to do inside Update is to make your character move in the world.

Now let’s say you wrote some code that makes your character move 1 unit when you press a button. You save the code, Unity compiles it, and your character starts moving. Excited, you send the build to your friend who has a potato PC.

Now on his PC, the character moves slower and travels less distance than on your PC.

Why does this happen?

🔴The Real Problem: FPS

The issue here is Frames Per Second (FPS).

You have a powerful PC, so your game runs at a high FPS. This means your Update method gets called more times per second. So your character gets moved many more times.

Your friend’s PC is slower, giving fewer FPS. That means Update runs fewer times per second, so your character moves fewer times.

Result:
Higher FPS → Faster movement
Lower FPS → Slower movement

This is where Time.deltaTime comes to the rescue.

Time.deltaTime gives us the time (in seconds) passed since the last frame. When we multiply our movement with Time.deltaTime, it converts movement from per-frame movement to per-second movement.

So now, no matter how fast or slow the computer is, the character will travel the same distance in the same amount of real time.

⚙️How does it work?

Let’s understand it with numbers.
Let’s say:

Your PC runs at 120 FPS
Your friend’s PC runs at 60 FPS

Example 1: WITHOUT Time.deltaTime.

Movement each frame = 1 unit.

On 60 FPS machine:

Update runs 60 times per second
Movement per frame = 1 unit
Movement per second = 60 × 1 = 60 units

On 120 FPS machine:

Update runs 120 times per second
Movement per frame = 1 unit
Movement per second = 120 × 1 = 120 units.

Result: Faster machines move the character faster — BAD.

Example 2: WITH Time.deltaTime.

Movement each frame = 1 unit × Time.deltaTime

On 60 FPS machine:

Time.deltaTime ≈ 1 / 60 = 0.01666 seconds
Movement per frame = 1 × 0.01666 = 0.01666 units
Movement after 60 frames (1 second): 0.01666 × 60 = 1 unit

On 120 FPS machine:

Time.deltaTime ≈ 1 / 120 = 0.00833 seconds
Movement per frame = 1 × 0.00833 = 0.00833 units
Movement after 120 frames (1 second): 0.00833 × 120 = 1 unit.

Result: Consistent character movement, regardless of FPS.

🌠How to use it?

Using Time.deltaTime is very simple.
Just multiply your movement value with Time.deltaTime.
Take a look at following code snippet:

transform.Translate(Vector3.forward * 1f * Time.deltaTime);
// or
transform.position += movementSpeed * Time.deltaTime * transform.forward;

💡Key Takeaway

If you want to perform operations in the Update method and you want them to be frame-rate independent, then Time.deltaTime is your best buddy. Never do time-based movement in Update without it, unless you truly want different behavior on different machines.

💝Note

If you like what do, please hit a like, drop a comment and share this blog. This will help me stay motivated and bring you folks more interesting blogs like this. Thank You!

Saving Game Data in Unity — Part 4: SQLite

Rahul Barate — Thu, 20 Nov 2025 14:12:13 +0000

In the last blog, we talked about how you can store data using ScriptableObjects. ScriptableObjects are great for storing static or design-time data.
But what if your game needs to store huge amounts of data?
I’m talking hundreds or thousands of records — dialogues, inventories, quest data, item lists, etc. JSON or XML will start slowing down at that point.
And that’s exactly what we’re going to talk about today.

🤔What is SQLite?

SQLite is a free and open-source relational database. It’s lightweight, self-contained, and perfect for storing large amounts of structured, queryable data. It’s also cross-platform and works extremely well inside Unity.
SQLite is a great choice when you want to store data that is both huge and queryable, for example:

➡️Item lists
➡️Inventories
➡️Dialogue trees
➡️NPC data
➡️Quest systems
➡️Any dataset you need fast search/filter operations on

⚙️Setting up SQLite in Unity

Setting up SQLite is not as straightforward as PlayerPrefs or ScriptableObjects, but don’t worry — I’ll walk you through everything. Just follow the steps exactly.

⚠️Prerequisites

You should know the very basics of SQL — what a table is, what a query is, and how SELECT/INSERT work.

⚙️Initial Setup

➡️Download or clone the repo: on your PC.
➡️Create a new Unity project.
➡️Copy the following folders/files from the repo into your project in the exact same locations:
- ➡️Assets/Plugins folder
- ➡️Scripts/DataService.cs and Scripts/SQLite.cs
- ➡️StreamingAssets folder
➡️Download and install DB Browser for SQLite.

🤔What are the DataService and SQLite scripts?

✏️DataService
This class creates a connection to your database using SQLite’s methods. Once the connection is open, you can query or store data just by calling DataService methods. You mainly need its constructor and the helper functions inside it.

✏️SQLite script
This is the interface that provides low-level methods for opening/closing connections, creating tables, inserting data, deleting data, etc.

💡Note:
You don’t need to understand how the full implementation works internally. You only need to know how to use the DataService to interact with your database.

🤔What are the .db files inside StreamingAssets?

These are the actual SQLite database files.
Unity keeps everything inside StreamingAssets as-is, meaning the database file is copied exactly into the build. SQLite then opens this file and reads/writes data during gameplay.

🚀Creating Your Own Database

You can do this in two ways:
➡️Option A:
Duplicate any .db file from StreamingAssets, rename it, open it in DB Browser, and clear the existing data so you can add your own later.
➡️Option B:
Rename one of the existing .db files and delete all the data inside it. You will write fresh data using Unity scripts.

🔗Setting up a Connection

To connect to your database, create an instance of the DataService class in your main script:
DataService dataService = new DataService("YourDatabaseName.db");
This opens the connection and prepares everything for inserting or reading data.

📑Creating a Table

First, define the structure of your table using a C# class.
For example, here is a simple Word table:


public class Word
{
    public string Text { get; set; }
    public int IsUsed { get; set; }
    public int TextLength { get; set; }
}

Once your class is ready, you need to write a method inside DataService that creates the table:

public void CreateTable()
    {
        try
        {
            _connection.CreateTable<Word>();
        }
        catch (System.Exception e)
        {
            Debug.LogError(e.Message);
        }
    }

Similarly, you can then use the _connection object inside DataService to access all SQLite methods. You can check the SQLite class to see what methods are provided or paste the file into ChatGPT (or any AI) to understand the available functions.
Below is a basic example of DataService class to get you started:

public class DataService
{

    private SQLiteConnection _connection;
        // constructor will be here; I removed to keep the script simple. Make sure you have it.
    public void CreateTable()
    {
        try
        {
            _connection.CreateTable<Word>();
        }
        catch (System.Exception e)
        {
            Debug.LogError(e.Message);
        }
    }
    public void AddWordsToDatabase(List<Word> words)
    {
        try
        {
            _connection.InsertAll(words);
        }
        catch (System.Exception e)
        {
            Debug.LogError(e.Message);
        }
    }
    public IEnumerable<Word> GetAllWords()
    {
        return _connection.Table<Word>();
    }
    public List<Word> GetWords(int wordLength, int numberOfWords)
    {
        List<Word> words = new List<Word>();
        try
        {
            TableQuery<Word> result = _connection.Table<Word>()
            .Where(x => x.TextLength == wordLength && x.IsUsed == 0)
            .Take(numberOfWords);

            foreach (Word word in result)
                words.Add(word);

            return words;
        }
        catch (System.Exception e)
        {
            Debug.LogError($"Error fetching words from database: {e.Message}");
        }
        return words;
    }
    public void DropTable()
    {
        try
        {
            _connection.DropTable<Word>();
        }
        catch (System.Exception e)
        {
            Debug.LogError(e.Message);
        }
    }


}

🗝️Key Takeaway

SQLite is perfect when your game needs to store large, structured, searchable data.
If your data grows beyond what JSON/XML or ScriptableObjects can handle easily, SQLite gives you a fast and scalable solution right inside Unity.

Saving Game Data in Unity — Part 3: ScriptableObjects

Rahul Barate — Wed, 12 Nov 2025 13:47:00 +0000

In the last blog, we talked about how you can store data using JSON/XML files. JSON and XML are excellent choices for saving structured data at runtime, like player progress or save files.

On the other hand, ScriptableObjects are great for storing static or design-time data.

Static data means information that has only one copy (shared by multiple scripts) — for example, base weapon stats, character attributes, or item definitions.
Design-time data means data you create beforehand while designing your game — something you write once and rarely update during gameplay.

One thing I like about ScriptableObjects is that they exist as assets in your project, so they retain their values even when you close and reopen Unity. They also help you separate data from logic, making your code cleaner and more modular.

Why Use ScriptableObjects?

They’re more memory efficient than duplicating MonoBehaviour data.
Multiple objects can share the same ScriptableObject instance.
Perfect for storing configuration or reference data.
They keep your project organized, especially when working with designers.
Values are serialized and saved as .asset files, so they persist across editor sessions.

How to Create a ScriptableObject

Unlike MonoBehaviours, you don’t attach ScriptableObjects to GameObjects.
Instead, you create a custom class that inherits from ScriptableObject, and then you can create instances of it as project assets.
To do that, use the CreateAssetMenu attribute — it lets you create ScriptableObject instances directly from the Unity Editor’s right-click menu.
Take a look at following example structure

using UnityEngine;

[CreateAssetMenu(fileName = "NewWeaponData", menuName = "Game/Weapon Data")]
public class WeaponData : ScriptableObject
{
    public string weaponName;
    public int damage;
    public float range;
    public float fireRate;
    public Sprite icon;
}

Now, you can create an instance by right-clicking in your Project window:
Create → Game → Weapon Data
Unity will create a .asset file in your project folder that holds your weapon data.
You can then drag and drop this asset into any script field in the Inspector, just like any other reference.

The following is an example use case.

using UnityEngine;

public class Weapon : MonoBehaviour
{
    public WeaponData weaponData;

    private void Start()
    {
        if (weaponData != null)
        {
            Debug.Log($"Equipped: {weaponData.weaponName} | Damage: {weaponData.damage} | Range: {weaponData.range}");
        }
        else
        {
            Debug.LogWarning("No WeaponData assigned!");
        }
    }

    public void Fire()
    {
        if (weaponData == null) return;

        Debug.Log($"{weaponData.weaponName} fired! Damage: {weaponData.damage}");
        // Add shooting logic here
    }
}

Attach this script to Weapon GameObject, assign your created WeaponData asset in the Inspector, and you’re done!

Key Takeaway

ScriptableObjects are perfect for storing static, shared, or configuration data in Unity.
They keep your code modular, improve memory efficiency, and make it easy to manage data outside of scenes.
If you find yourself copying the same data into multiple prefabs or scripts, it’s time to consider moving that data into a ScriptableObject.

Saving Game Data in Unity — Part 2: JSON/XML files

Rahul Barate — Wed, 05 Nov 2025 13:34:48 +0000

Hello folks!
Sorry for not posting anything over the last few weeks — I was away for Diwali holidays and caught up with some other work. But I’m back now!
In my last blog post, we talked about PlayerPrefs, which was the first entry in my “Different Ways of Storing Game Data” series. Today, we’ll look at another way to store data in Unity — using JSON and XML files.

What is JSON?

For those who don’t know, JSON stands for JavaScript Object Notation. It’s a lightweight text format that’s easy for both humans and machines to read and write. Because of its simplicity, JSON has become the standard for transferring and storing data across different systems.
JSON is language-independent, meaning you can use it with almost any programming language once you understand its structure. It stores data as key-value pairs, separated by commas. JSON supports numbers, booleans, strings, arrays, objects, and null values.
Here’s a simple example of JSON:

{
  "firstName": "John",
  "lastName": "Doe",
  "isEmployed": true,
  "skills": ["JavaScript", "Python", "SQL"],
  "address": {
    "street": "123 Main St",
    "city": "Anytown"
  }
}

(I’ll leave some useful links at the end where you can learn more about JSON and XML.)

What is XML?

XML stands for Extensible Markup Language. It’s similar to HTML in structure but unlike HTML, XML is extensible — meaning you can define your own custom tags to describe the data.
XML doesn’t “do” anything by itself; it’s just a structured way of storing and describing information using tags. It’s also widely used for data storage and transfer, though it’s typically more verbose than JSON.
Here’s an example of what XML looks like:

<bookstore>
  <book category="cooking">
    <title lang="en">Everyday Italian</title>
    <author>Giada De Laurentiis</author>
    <year>2005</year>
    <price>30.00</price>
  </book>
  <book category="children">
    <title lang="en">Harry Potter</title>
    <author>J. K. Rowling</author>
    <year>2005</year>
    <price>29.99</price>
  </book>
</bookstore>

How to Use JSON in Unity

Using JSON in Unity is straightforward.
To store data in JSON format, you first need to convert your data into a JSON string using JsonUtility.ToJson().
To read or parse that data, you can use JsonUtility.FromJson() to convert it back into your desired C# type (either a built-in type or a custom class).
JSON files are typically stored in Application.persistentDataPath, so they persist between sessions. You can also create subfolders inside that path to organize your saves.
Here’s the structure of what it might look like in code:

using UnityEngine;
using System.IO;

[System.Serializable]
public class PlayerData
{
    public int level;
    public int coins;
    public string playerName;
}

public class JsonSaveSystem : MonoBehaviour
{
    private string savePath;

    private void Awake()
    {
        savePath = Path.Combine(Application.persistentDataPath, "playerSave.json");
    }

    public void SaveGame()
    {
        PlayerData data = new PlayerData()
        {
            level = 5,
            coins = 200,
            playerName = "Rahul"
        };

        string json = JsonUtility.ToJson(data, true);
        File.WriteAllText(savePath, json);
        Debug.Log("Game saved to: " + savePath);
    }

    public void LoadGame()
    {
        if (File.Exists(savePath))
        {
            string json = File.ReadAllText(savePath);
            PlayerData data = JsonUtility.FromJson<PlayerData>(json);
            Debug.Log($"Loaded: Level {data.level}, Coins {data.coins}, Name {data.playerName}");
        }
        else
        {
            Debug.LogWarning("No save file found!");
        }
    }
}

💡Note: Unity’s built-in JsonUtility is fast but limited. It doesn’t handle nested lists or dictionaries well.
For more advanced cases, you can use the Newtonsoft JSON package (Json.NET), which supports more complex data structures.

How to Use XML in Unity

To work with XML in Unity, you’ll use the XmlSerializer class.

Create an XmlSerializer instance for your data type.
Create a FileStream to write your data to disk.
Use the Serialize() method to write your object as XML to the file.
To read data, do the same but call Deserialize() instead.

Just like JSON, XML files are stored inside Application.persistentDataPath so your data remains saved between sessions.
Here’s a simple structure for XML in code:

using UnityEngine;
using System.IO;
using System.Xml.Serialization;

[System.Serializable]
public class PlayerDataXML
{
    public int level;
    public int coins;
    public string playerName;
}

public class XmlSaveSystem : MonoBehaviour
{
    private string savePath;

    private void Awake()
    {
        savePath = Path.Combine(Application.persistentDataPath, "playerSave.xml");
    }

    public void SaveGame()
    {
        PlayerDataXML data = new PlayerDataXML()
        {
            level = 5,
            coins = 200,
            playerName = "Rahul"
        };

        XmlSerializer serializer = new XmlSerializer(typeof(PlayerDataXML));
        using (FileStream stream = new FileStream(savePath, FileMode.Create))
        {
            serializer.Serialize(stream, data);
        }

        Debug.Log("Game saved (XML) to: " + savePath);
    }

    public void LoadGame()
    {
        if (File.Exists(savePath))
        {
            XmlSerializer serializer = new XmlSerializer(typeof(PlayerDataXML));
            using (FileStream stream = new FileStream(savePath, FileMode.Open))
            {
                PlayerDataXML data = (PlayerDataXML)serializer.Deserialize(stream);
                Debug.Log($"Loaded (XML): Level {data.level}, Coins {data.coins}, Name {data.playerName}");
            }
        }
        else
        {
            Debug.LogWarning("No XML save file found!");
        }
    }
}

⚠️ Note: XML is great for readability and structured data but is generally heavier and slower compared to JSON.
Use it when you specifically need hierarchical tagging or compatibility with systems that expect XML.

Key Takeaway

JSON and XML are both excellent choices for saving structured data in Unity.

Use JSON when you want lightweight, human-readable data with quick serialization and deserialization.
Use XMLwhen your data needs a more descriptive structure or you’re working with systems that rely on XML.

Both methods are great for saving player progress, inventory data, or custom level information — especially when you want control over your save files.

Saving Game Data in Unity — Part 1: PlayerPrefs

Rahul Barate — Tue, 07 Oct 2025 13:02:52 +0000

When it comes to storing game data in Unity, there are several ways to do it — and choosing the right one is important. The data storage method you pick can directly affect your game’s efficiency, speed, and overall performance.

If you want to store static data like item stats, lists, or character configs, ScriptableObjects are a great choice.
If you want to store game saves, player progress, or structured runtime data, JSON/XML files are better.
If you’re dealing with large, queryable datasets, SQLite databases are ideal.
When you want to bundle data or assets with your build, Resources or Addressables are useful.
And if you want to prototype data storage or save non-sensitive information such as settings, control layouts, or the last completed level — PlayerPrefs is the best option.

One by one, we’ll explore each of these in upcoming blogs. Today, let’s start with PlayerPrefs.

What is PlayerPrefs?

PlayerPrefs is a Unity class that allows you to store small and simple pieces of data locally. It’s best used for quick, lightweight saves — not full save files or complex objects.
Internally, PlayerPrefs stores data in the local registry or system-specific storage, without any encryption. It’s great for prototyping or saving basic settings, but you should avoid using it for sensitive or large-scale game data.
You can store int, float, and string values directly. You can also serialize objects into JSON strings if needed.

When to Use PlayerPrefs

Use PlayerPrefs when you need to save:

Game settings (volume, graphics quality, key bindings)
Last level completed
Player name or preferences
Control layouts
Other lightweight data

Avoid using it for:

Inventories, save files, or complex structured data
Sensitive information like login details or in-game purchases

Common Methods

PlayerPrefs exposes several static methods to handle data operations. Here’s an example script that demonstrates how to use them:

using UnityEngine;
public class GameSettingsManager : MonoBehaviour
{
    // Example game settings
    private float masterVolume = 0.8f;
    private float brightness = 1.0f;
    private int difficultyLevel = 2; // 0 = Easy, 1 = Medium, 2 = Hard

    private void Start()
    {
        // Load settings on start
        LoadSettings();
    }

    public void SaveSettings()
    {
        // Save individual settings
        PlayerPrefs.SetFloat("MasterVolume", masterVolume);
        PlayerPrefs.SetFloat("Brightness", brightness);
        PlayerPrefs.SetInt("DifficultyLevel", difficultyLevel);

        // Ensure data is written to disk
        PlayerPrefs.Save();

        Debug.Log("Settings saved!");
    }

    public void LoadSettings()
    {
        // Check if a key exists before reading
        if (PlayerPrefs.HasKey("MasterVolume"))
            masterVolume = PlayerPrefs.GetFloat("MasterVolume");

        if (PlayerPrefs.HasKey("Brightness"))
            brightness = PlayerPrefs.GetFloat("Brightness");

        if (PlayerPrefs.HasKey("DifficultyLevel"))
            difficultyLevel = PlayerPrefs.GetInt("DifficultyLevel");

        Debug.Log($"Settings loaded:\nVolume: {masterVolume}\nBrightness: {brightness}\nDifficulty: {difficultyLevel}");
    }

    public void ResetSettings()
    {
        // Delete a single key
        PlayerPrefs.DeleteKey("MasterVolume");
        PlayerPrefs.DeleteKey("Brightness");
        PlayerPrefs.DeleteKey("DifficultyLevel");

        Debug.Log("Individual settings deleted!");
    }

    public void DeleteAllSettings()
    {
        // Delete everything saved by PlayerPrefs
        PlayerPrefs.DeleteAll();
        Debug.Log("All PlayerPrefs cleared!");
    }

    // Example for toggling between difficulty levels
    public void CycleDifficulty()
    {
        difficultyLevel = (difficultyLevel + 1) % 3;
        SaveSettings();
    }
}

Where Unity Stores PlayerPrefs

Unity stores PlayerPrefs in different locations depending on the operating system:

Windows: Registry — HKEY_CURRENT_USER\Software[CompanyName][ProductName]
MacOS: ~/Library/Preferences/com.[CompanyName].[ProductName].plist
Android: /data/data/[pkg-name]/shared_prefs/[pkg-name].v2.playerprefs.xml
iOS: Uses [NSUserDefaults standardUserDefaults] API
Linux: ~/.config/unity3d/[CompanyName]/[ProductName]
WebGL: Stored in the browser’s IndexedDB, up to 1MB

Key Takeaway

PlayerPrefs is a quick and easy way to store small pieces of data in Unity. It’s perfect for prototyping, player settings, and preferences — but not ideal for complex or sensitive data. In the next part, we’ll explore other data storage methods like JSON files and ScriptableObjects to handle larger or more structured data.

Making Your Unity UI Come Alive with Videos

Rahul Barate — Tue, 30 Sep 2025 14:42:58 +0000

Intro:

In my previous games, I’ve always used images and buttons to create the Level/Mission selection menu. But this time, I wanted players to feel the game was more alive instead of staring at static pictures. That’s when I thought — why not add videos?
Each selection button could play a short looping clip of that level or mission, giving players a glimpse of what’s ahead before they dive in. This not only makes the UI more dynamic but also helps players connect with the game world earlier.

Pre-requisites:

Have your videos ready and imported into Unity.
Make sure they don’t have blank frames at the start or end (for smooth looping).

Steps (Method 1: RawImage + VideoPlayer + RenderTexture):

Import your videos into the Unity Project.
Create a RenderTexture for each video:
a) Right-click in the Project window → Create → Rendering → Render Texture.
b) Set Dimension to 2D.
c) Adjust the size based on your aspect ratio (I used 640x360 for 16:9).
d) Other settings are optional — check Unity docs if you want to tweak.
Inside your Canvas, create a Raw Image:
a) Right-click in the Hierarchy → UI → Raw Image.
b) Set its Width/Height (I matched my RenderTexture size).
c) Assign the RenderTexture you created to the Raw Image’s Texture
field.
Add a Video Player:
a) Right-click the Raw Image in the Hierarchy → Video → Video Player.
b) Set Source to Video Clip.
c) Assign the video you imported.
d) Enable Play On Awake and Loop (if you want looping).
e) Set Render Mode to Render Texture and assign the RenderTexture you created.
f) Adjust settings like playback speed, mute, or volume as needed.

And that’s it — you’ve added video to your UI.

Why This Approach?

This RawImage + RenderTexture + VideoPlayer setup is reliable and works well for menus, previews, or even background animations. It keeps your UI flexible, since you can use multiple videos across different slots or buttons.
There are other approaches too — such as directly assigning a video to a material or using Unity’s UI Toolkit (if you’re on newer versions). But for most UI menus, this method strikes the right balance of simplicity and control.

Key Takeaway:

Adding videos to your Unity UI isn’t complicated. With a simple RenderTexture setup, you can replace static images with dynamic clips that make your menus feel alive and give players a preview of what’s coming.

Unlock More FPS with Object Pooling

Rahul Barate — Tue, 23 Sep 2025 18:02:06 +0000

I’m starting a new series of blogs where I’ll share the tips and tricks I use to optimize games for better FPS. I’ll only share the techniques that I learn myself or actually use in my projects.

Today, let’s talk about one of the biggest game optimization techniques in Unity: Object Pooling.

Problem: Instantiate and Destroy Everywhere

For reference, here’s a scenario from one of my games.

I was working on a bombing and cannon fire mechanism. Bombs drop from above at fixed intervals but from random locations, and cannons fire cannonballs at fixed intervals sequentially. I wrote a script where I assigned the bomb/cannonball prefab, instantiated it at runtime, and fired it. Once the bomb/cannonball touched anything, it would self-destruct using the Destroy method.

On PC, this worked fine — I was getting around 200 FPS. But when I built the APK and ran it on my mobile, FPS dropped to barely 30 and my phone was heating a lot.

After some research, I learned why: instantiation and destruction are among the heaviest operations you can perform at runtime. And since I was doing this every 3–5 seconds, it was tanking mobile performance.

Every time you instantiate an object Unity allocates memory for:

The GameObject itself
All its components
Meshes, colliders, scripts, etc.
Clone all component data
Initialize references
Register it with the physics system (if it has Rigidbody/Collider)
Register it with a rendering system.

Every time you destroy an object using Unity it has to:

Remove it from the Scene hierarchy
Clean up references
Free memory
Unregister physics/rendering data. (This might be cheaper than instantiation however, GC spikes can happen later, which adds hidden cost.)

Solution: Reuse Instead of Recreate

There are two main ways to solve this problem.

Approach 1: Enable/Disable

Add the bomb or cannonball object to the scene and keep it hidden.
When needed, place it in the correct location, enable it, and fire/drop it.
When it collides, disable it instead of destroying it.
Repeat the process.

This works great if you only need one object at a time. For example, in my scenario, only one cannon fires at a time, so I could reuse the same cannonball.

But I plan to add multiple cannons and bomb drops later, so this approach wouldn’t scale.

Approach 2: Object Pooling
This is where pooling comes in.
In pooling, we create a “pool” of objects at the start. When we need an object, we fetch it from the pool. When we are done using the object, we return it to the pool instead of destroying it.
There are different ways to implement pooling in Unity. Let’s look at two common ones.

Example 1: Pooling with a Queue

Create a Queue of the object type you want to pool.
Decide the pool size (total number of objects in the pool).
Instantiate that many objects at startup, do the setup, disable them, and enqueue them.
When needed, dequeue an object, enable it, and use it.
When done, disable it and enqueue it back.

This works well for simple pooling cases. (I used this for cannonballs — I’ve attached the example below in my project code.)

Example 2: Pooling with Unity’s ObjectPool (Unity 2021+)

Unity also provides a built-in ObjectPool class. It’s more powerful and flexible.

Create an ObjectPool for the type you want to pool.
In Start or Awake, set up the pool. Provide callback functions for:
- Creating an object
- Getting an object from the pool
- Releasing an object back to the pool
- Destroying an object
- Setting pool parameters (capacity, max size, etc.)
Call Get() when you need an object.
Call Release() when the object’s done.

(I used this approach for bombs — example attached below.)

A Note on Collection Check

When you create an ObjectPool, there’s a collectionCheck parameter. By default, it’s true.

If true, Unity checks if the object you’re trying to release is already in the pool. If so, it throws an exception to prevent double releases.
If false, Unity skips the check. If you accidentally release the same object twice, it’ll silently add it again, which can cause bugs later when calling Get().

This check adds a bit of overhead. It’s O(1), but it’s still extra work. For small pools, leaving it true is fine. For large pools with frequent releases, you might want it off — but only if you’re confident in managing releases correctly.

Key Takeaway:

Instantiation and destruction are heavy operations. If you have objects that appear frequently (bullets, bombs, enemies, projectiles), don’t instantiate/destroy them every time.

Instead, reuse them with enable/disable or pooling.

For simple cases, enable/disable works.
For larger or frequent spawns, use pooling (Queue or Unity’s ObjectPool).

Pooling won’t make your logic faster, but it will prevent FPS drops and heating on mobile devices. In my case, using pooling fixed my performance issue — from 30fps on mobile back to smooth gameplay.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;


public class CannonHandler : MonoBehaviour
{


    [SerializeField] GameObject cannonBallCopy;
    [SerializeField] GameObject cannonBallSpawnPoint;
    [SerializeField] float forceAmount = 500f;
    [SerializeField] int poolSize = 10; // total pool size
    Queue<GameObject> cannonBallPool = new Queue<GameObject>(); // pool to store objects


    void Start()
    {
        for (int i = 0; i < poolSize; i++)
        {
            // instantiate object
            GameObject obj = Instantiate(cannonBallCopy);


            // perform required operation [can vary based on your game]
            obj.SetActive(false);
            Rigidbody rb = obj.AddComponent<Rigidbody>();
            rb.isKinematic = true;


            // Add them to the queue
            cannonBallPool.Enqueue(obj);
        }
    }
    // This method is called by another class after given interval
    public void FireCannon()
    {
        if (cannonBallPool.Count > 0)
        {
            // remove from the queue
            GameObject ball = cannonBallPool.Dequeue();


            // perform required operations [can vary based on your game]
            ball.transform.position = cannonBallSpawnPoint.transform.position;
            ball.transform.rotation = Quaternion.identity;
            ball.transform.localScale = new Vector3(27f, 27f, 27f);
            ball.SetActive(true);
            Rigidbody rb = ball.GetComponent<Rigidbody>();
            rb.isKinematic = false;
            rb.velocity = Vector3.zero;
            rb.angularVelocity = Vector3.zero;
            ball.GetComponent<CannonBallHandler>().cannonHandler = this;
            Vector3 localForce = new Vector3(0f, 0f, forceAmount);
            Vector3 worldForce = transform.TransformDirection(localForce);
            rb.AddForce(worldForce, ForceMode.Impulse);
        }
    }
    // This method is called by the cannon ball itself when it comes into contact with anything.
    public void ReturnToPool(GameObject obj)
    {
        // perform required operations [can vary based on your game]
        obj.SetActive(false);
        Rigidbody rb = obj.GetComponent<Rigidbody>();
        rb.isKinematic = true;
        CannonBallHandler handler = obj.GetComponent<CannonBallHandler>();
        handler.meshRenderer.enabled = true;
        handler.sphereCollider.enabled = true;


        // Add it back to the queue
        cannonBallPool.Enqueue(obj);
    }
}

using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.Pool;
using UnityEngine.UIElements;

public class BombDropper : MonoBehaviour
{
    [SerializeField] GameObject bombCopy;
    [SerializeField] float delayInBombing;
    [SerializeField] GameDataSave gameDataSave;
    bool isLevelCompleted = false;

    private ObjectPool<GameObject> bombPool;

    MeshFilter meshFilter;
    Vector3[] vertices;

    void Start()
    {
        // Get mesh filter
        meshFilter = GetComponent<MeshFilter>();
        vertices = meshFilter.mesh.vertices;
        gameDataSave.E_LevelCompleted += SetIsLevelCompleted;

        // create pool and add callback functions 
        bombPool = new ObjectPool<GameObject>(
            createFunc: () => Instantiate(bombCopy),
            actionOnGet: (obj) => {
                obj.SetActive(true);
                //perform required set of operations [can vary based on your game]
                var handler = obj.GetComponent<BombHandler>();
                handler.ResetForPool();
                handler.pool = bombPool;
            },
            actionOnRelease: (obj) => obj.SetActive(false), // Release() is called when bomb collides with anything.
            actionOnDestroy: (obj) => Destroy(obj),
            collectionCheck: false,
            defaultCapacity: 10,
            maxSize: 100
        );

        StartCoroutine(DropBombs());

    }

    private void SetIsLevelCompleted()
    {
        isLevelCompleted = true;
    }
    private void OnDisable()
    {
        gameDataSave.E_LevelCompleted -= SetIsLevelCompleted;
    }

    IEnumerator DropBombs()
    {
        while (!isLevelCompleted)
        {
            int randomVertexIndex = UnityEngine.Random.Range(0, vertices.Length);
            Vector3 vertexPos = transform.TransformPoint(vertices[randomVertexIndex]);

            GameObject bomb = bombPool.Get(); // fetch the object when needed.

            bomb.transform.position = vertexPos;
            bomb.transform.rotation = Quaternion.Euler(0f, 0f, 180f);
            yield return new WaitForSeconds(delayInBombing);

        }
    }
}

How a Bi-Dictionary Simplified My Unity Inventory System

Rahul Barate — Tue, 09 Sep 2025 16:20:40 +0000

Problem:
In my ongoing project Last Light, I’m building an inventory system. The inventory UI has different slot sections: backpack weapons, backpack consumables, equipped weapons, equipped consumables, etc.
The InventorySystem handles the data and logic, while InventoryUIController handles the UI. To make them work together, I initially used a dictionary that maps slot sections to item types. This works when displaying items from the system to the UI. But the problem shows up in reverse — when the player clicks a slot, I need to know the section type. With a normal dictionary, I’d have to traverse the entire dictionary to find the type, which isn’t efficient.

Solution:
This is where a Bi-Dictionary comes in.
A Bi-Dictionary is a data structure that supports two-way lookups: you can find a value from a key, and a key from a value — both in O(1) time. Most programming languages don’t provide this out of the box, so I wrote my own.
The idea is simple: maintain two dictionaries internally — one mapping key → value, and another mapping value → key. Then, create methods like:

GetValue(key) → returns the value.
GetKey(value) → returns the key.
Add(key, value) and Remove(key/value) to keep both dictionaries in sync.

Example Use Cases:

Inventory System (my case): Helps map item types to UI slots and back.
Action ↔ Sound Effect: Example: GunshotAction ↔ GunshotSound. One script can play the sound given the action, another can detect the sound and resolve it back to the action.
Localization: Word ↔ Translation mappings (when you need to resolve both ways).

Key takeaway:
A Bi-Dictionary is a handy data structure for cases where you need fast, two-way lookups. Many developers don’t know about it because it’s not built into most languages, but it can save time and complexity in the right scenarios.

using System;
using System.Collections.Generic;

public class BiDictionary<TKey, TValue>
{
    private Dictionary<TKey, TValue> keyToValue = new Dictionary<TKey, TValue>();
    private Dictionary<TValue, TKey> valueToKey = new Dictionary<TValue, TKey>();

    public void Add(TKey key, TValue value)
    {
        if (keyToValue.ContainsKey(key) || valueToKey.ContainsKey(value))
            throw new ArgumentException("Duplicate key or value.");

        keyToValue.Add(key, value);
        valueToKey.Add(value, key);
    }

    public TValue GetValue(TKey key)
    {
        return keyToValue[key];
    }

    public TKey GetKey(TValue value)
    {
        return valueToKey[value];
    }

    public bool TryGetValue(TKey key, out TValue value)
    {
        return keyToValue.TryGetValue(key, out value);
    }

    public bool TryGetKey(TValue value, out TKey key)
    {
        return valueToKey.TryGetValue(value, out key);
    }

    public bool RemoveByKey(TKey key)
    {
        if (!keyToValue.TryGetValue(key, out var value)) return false;
        keyToValue.Remove(key);
        valueToKey.Remove(value);
        return true;
    }

    public bool RemoveByValue(TValue value)
    {
        if (!valueToKey.TryGetValue(value, out var key)) return false;
        valueToKey.Remove(value);
        keyToValue.Remove(key);
        return true;
    }
}

When You Have a Golden Hammer, Everything Looks Like a Nail

Rahul Barate — Tue, 02 Sep 2025 05:42:10 +0000

A while ago I came across this awesome tool called Assembly Definitions from Unity3D. As indie developers, we love finding new tools that promise to save time. Unity’s Assembly Definition sounded like a game-changer when I first discovered it. But after trying it in a small project, I realized: just because a tool is powerful doesn’t mean it’s right for every situation.

Assembly Definitions allow you to split your scripts into multiple assemblies for modularity and faster compile times. First you separate your scripts into multiple folders like Player, NPCs, Environment, and create Assembly Definition for each. Now, when you change a script in one folder, Unity only recompiles that assembly instead of the entire project. This saves a lot of time—if your project is large enough.

Now you might be thinking, isn’t that such a wonderful feature? Yes, you’re right. It is a wonderful feature but only if you use it right. The catch is Assembly Definitions enforce a strict rule: no circular dependencies. For example, if Player Assembly references NPCs Assembly, NPCs Assembly cannot reference Player Assembly. This helps prevent spaghetti code, but in small projects, it can slow development. I tried solving this using C# events but tracking how events flowed through my project quickly became a nightmare.”

I used Assembly Definitions in my small project, which barely had 10 to 15 scripts. The compile time improvement was so small I barely noticed it. And just to dodge that Circular Dependency issue, I used to many Events that after a while it became so painful for me to backtrack how the control is flowing through my scripts. I eventually realized Assembly Definitions are great for large, team-driven projects, but unnecessary for small solo projects. So, from my experience, I’ll state the Pros and Cons of Assembly Definitions and discuss when I think they are useful and when to avoid them.

Pros:

Faster compile times in large projects.
Better modularity and maintainability.
Useful for platform-specific builds.
Helps avoid tightly coupled, spaghetti code.

Cons:

No runtime performance improvement.
Adds complexity to small projects.
Circular dependency restrictions require careful planning.
When to Use Assembly Definitions:
Large projects with 1,000+ scripts.
Multiple teams working on different modules.
Platform-specific builds or reusable systems.

When to Use Assembly Definitions:

Large projects with 1,000+ scripts.
Multiple teams working on different modules.
Platform-specific builds or reusable systems.

When to Avoid:

Small, solo projects.
Projects with tightly interconnected systems.
When compile times are already fast.

Conclusion:
Assembly Definitions are powerful, but like any tool, they solve specific problems. When you see a good feature, that doesn’t mean you need to immediately start using it in your project. Always weigh the pros and cons before adopting a new feature—because when you have a golden hammer, not everything is a nail.