Fields and properties tell you more about a class. They're technically variables, so they're like mini-storage locations for any information related to the class.

Since classes are declared using nouns, think of fields and properties as the adjectives.

For example, if the game you're making in the Unity Game Engine has non-playable villager characters (NPCs), you can create a Villager class to store all the code related to villagers.

Each villager will need a name, an occupation, and some money. These three will become the Villager class's fields or properties because they're telling us more about each villager.

This article assumes you understand how to work with classes and access modifiers in C#.

If you're a visual learner, scroll to the bottom for the video version, or you can watch it on YouTube.

Fields in C# Explained

Fields are declared similarly to variables except:

• You declare fields directly in the class, but you declare variables in methods.
• Fields and variables use the Camel Case naming convention, but fields begin with an underscore.
• Fields must have an access modifier, while variables shouldn't.

public class EnemySoldier
{
  // These are fields.
  private sbyte _health;

  private string _role;
}

Fields are part of a class's implementation and should therefore be marked private. Doing otherwise isn't guaranteed to break your game's code, but it's a recommended practice to prevent bugs.

Implementation details are details other classes shouldn't know or interact with.

For example, if you have a Player class that controls the main character, it'll likely have a field called _health representing the player's remaining health.

You wouldn't want the player's health to decrease whenever they open a door because only the Player class should interact with that value.

That's why you declare the _health field as private. If you changed the access modifier to public, the code that opens doors would now have access to the field and could accidentally manipulate it.

Placing related code inside a class while restricting access to certain parts to hide implementation details is known as encapsulation in programming.

Regardless, there'll be times you want to expose some information to other classes or methods, and you can do so using properties.

Why Use a Field?

Fields let you reuse code within the class.

For example, the player in your Unity game could have a speed value that changes every time they pick up a speed booster or run across muddy terrain.

This speed can be 5 miles per hour for demo purposes, and the Player class will have methods to increase and decrease the speed.

Without a field, you'd have to create a variable in each method to represent the initial speed, assign 5 to the variable, and adjust it in multiple places.

public class Player
{
  // Remember what access modifier this method will have??
  int IncreaseSpeed()
  {
    var speed = 5;

    speed += 5; // Remember this operator??

    return speed;
  }

  private int DecreaseSpeed()
  {
    var speed = 5; // <- This variable is created in two places.

    speed -= 2;

    return speed;
  }
}

This kind of code is fragile because if you change the initial speed to 10 in one method and leave it at 5 in another, the initial speed is inconsistent.

A better approach would be to declare a _speed field and use it in the methods, so you can adjust the initial speed in one place and have the change reflected everywhere.

public class Player
{
  private int _speed = 5; // <- Field is created once.

  int IncreaseSpeed()
  {
    _speed += 5;

    return _speed;
  }

  private int DecreaseSpeed()
  {
    _speed -= 2;

    return _speed;
  }
}

Field Initialization

The process of giving a field a value is known as field initialization. It occurs on the same line you create the field, inside the class's constructor, or in a method.

public class HealingItem
{
  private sbyte _healthAdded = 50; // <- Initialized on creation line.

  private string _type;

  private bool _isAvailable;

  public HealingItem(string customType)
  {
    _type = customType; // <- Field initialized in a class constructor.
  }

  public void MakeAvailable()
  {
    _isAvailable = true; // <- Field initialized in a method.
  }
}

In addition to the access modifier, you can also mark a field as readonly.

You initialize a readonly field in only two places:

• On the same line that you declared it.
• In the class's constructor

public class Tank
{
  ✅ // 'readonly' field can be initialized here.
  private readonly byte _shields = 250;

  public Tank(byte customShields)
  {
    ✅ // The field can also be initialized in the constructor.
    _shields = customShields;
  }

  public void BoostDefense()
  {
    _shields = 500; ❌ // Can't initialize the field here.
  }
}

A common mistake in Unity tutorials is declaring a field as public solely to expose it in the Unity Editor. Doing so may show it in the Unity Editor, but it can cause bugs in your Unity game's code.

A better solution is to keep the field private and place the [SerializeField] attribute above it to expose it in the Inspector window so you can manipulate it while respecting the encapsulation principle.

public class Player : MonoBehaviour
{
  public float _speed; ❌ // Fields should be 'private'.

  [SerializeField] ✅ // Shows field in Unity while still 'private'.
  private float _rotationSpeed;

  ✅ // The attribute can be placed on the same line.
  [SerializeField] int _damage;
}

Properties in C# Explained

Properties are similar to fields, but unlike fields, they're public by default and use getters and setters (accessors).

If you need to expose certain parts of a class to other classes, it's better to use a property instead of a field.

The earlier example mentioned a Villager class for NPCs. Let's say you want to spawn farmer villagers in a particular area.

Before you spawn any villagers, you'll first need to know their occupation. If their occupation is private, there's no way for the code spawning NPCs to know which villager is a farmer.

Instead of using a private field for the occupation, use a public property. Using a property automatically creates a private backing field behind the scenes.

public class Villager
{
  // These are properties.
  public string Name { get; set; }

  public string Occupation { get; set; }

  public int MoneyHeld { get; set; }
}

The get and set keywords are getters and setters that retrieve and update the value of the private backing field accordingly.

With a property, you don't have to worry about interfering with implementation details because the property acts as a buffer between the inner class logic and the outside world.

You can think of the private backing field as being inside a building, and the property is the window that lets you see inside without entering the building.

Getters and Setters

The get keyword represents a property's getter. It retrieves the private backing field's value so the outside world can see it. The setter sets and updates the private backing field.

For example, you could use a property to represent each villager's remaining money and update it whenever they sell items.

You can make adjustments when getting or setting a property's value inside the getter and setter code blocks.

There are no code blocks for the properties in the code above because they're auto-implemented.

They don't make any adjustments when getting or setting the value of the private backing field. They only retrieve and set it. Nothing more.

Here's what they look like when written with code blocks.

public class Villager
{
  // Auto-implemented property.
  public string Occupation { get; set; }

  // #region Long version of an auto-implemented property.
  private string _name; // <- 'private' backing field.

  public string Name // <- Property.
  {
    get { return _name; }
    set { _name = value; }
  }
  // #endregion
}

Let's say your Unity game has an active perk granting villagers a 50% bonus on all sold items. You can adjust the setter's code to multiply the value you provided by 1.5.

public class Villager
{
  public bool PerkIsActive { get; set; } = false;

  private float _moneyHeld; // <- 'private' backing field.

  public float MoneyHeld // <- Property.
  {
    get { return _moneyHeld; }

    set
    {
      if (PerkIsActive)
        _moneyHeld = value * 1.5; // <- Apply 50% bonus.

      else
        _moneyHeld = value; // <- No bonus if perk is inactive.
    }
  }
}

If you need to, you can also use access modifiers, such as private, protected, etc., on getters and setters to control what code can interact with them.

There are other ways to achieve these gameplay mechanics, and tweaking properties is merely one of them.

Fields vs. Properties: Which Should You Use?

Despite their similarities, fields and properties work better in different scenarios.

Use a field if:

• You have code that should only be accessible within the class.
• You want to adjust a value in the Unity Editor. Properties currently can't be exposed in the Unity Editor.

Use a property if:

• Other parts of the code need access to the class's information.
• You want to make some adjustments when getting or setting fields.

Recap

• A field is a variable declared directly inside a class.
• Fields are implementation details and should be private.
• A property is a mechanism for retrieving or manipulating a private backing field.
• Properties are public by default.
• Use the [SerializeField] attribute instead of making a field public to expose it in the Unity Editor.

This article is the twelfth in a series breaking down common C# concepts used in game development with the Unity Game Engine.

The next one discusses how to use methods to perform specific actions in your game's code.

Here's the complete list of articles in the series:

• A Game Developer's Guide to Variables in C#
• A Game Developer's Guide to Constants in C#
• A Game Developer's Guide to Numbers in C#
• A Game Developer's Guide to Operators in C#
• A Game Developer's Guide to Strings in C#
• A Game Developer's Guide to Booleans in C#
• A Game Developer's Guide to Enums in C#
• A Game Developer's Guide to Conditional Statements in C#
• A Game Developer's Guide to Loops in C#
• A Game Developer's Guide to Classes in C#
• A Game Developer's Guide to Access Modifiers in C#
• A Game Developer's Guide to Fields & Properties in C# (you are here)
• A Game Developer's Guide to Methods in C#
• A Game Developer's Guide to Lists & Arrays in C#
• A Game Developer's Guide to Dates & Times in C#