public class PlayerStats {
private int health = 100;
private float strength = 500f;
public float Strength { get; set; }
public int Health {
get { return health; }
set { health = value; }
}
}
public class PlayerScript : MonoBehaviour {
PlayerStats stats = new PlayerStats();
void Start() {
Debug.Log("Player Health: " + stats.Health);
Debug.Log("Player Strength: " + stats.Strength);
}
}
When I write get {return health; } and set {health = value; } prints the âhealthâ value to the console, but when I use the shorthand around property {get; set; } to print the value of the âstrengthâ field, it is printing the value 0, not the value 500 that I defined.
Why canât I print the value 500? What is wrong with this shorthand?
You didnât implement it the same as your Health property: you are not returning the strength field explicitly.
Instead, you have an âauto-implemented propertyâ which connects itself to a field created automatically by the compiler. This field wonât be called strength, but something like __strength.
Write out your Strength property in the same syntax as your Health property.
I changed the âstrengthâ field to _strength, but it didnât resolve.
Could you change the script and post it again with corrections? This will facilitate my understanding.
You canât guess what field name the auto-implemented properties will use. The compiler will always avoid a conflict with the fields you use explicitly.
public class PlayerStats {
private int health = 100;
private float strength = 500f;
public float Strength {
get { return strength; }
set { strength = value; }
public int Health {
get { return health; }
set { health = value; }
}
}
Property is not a shortcut to a variable of the same name. (it can be when you want it to, as you have with Health)
When you do float Strength {get;set;} compiler will create underlying variable (with some âunknown nameâ).
If youâre trying to make a game, thereâs no reason to use the {get; set;} thing. It solves an obscure problem that Unity canât have.
A regular variable: âpublic float strength;â is just fine. If you want to turn it into a property later (like Health, except have it do something), you can without a problem.
For me property is just another place where to write code, if i donât need i donât use it.
protected,
private (eventually [SerializeField]),
public (eventually [HideInTheInspector]) seems to do the trick most of the time.
I think this is what the topic starter was looking for:
public class PlayerStats {
public float Strength { get; set; }
public PlayerStats() {
Strength = 500f;
}
}
Default values (=500f) are only supported in a higher C# version. For now youâll have to use the constructor to assign a value.
When fully public like this the main advantage over a field is that you can turn it into an abstract definition, which you canât do with a field.
You can also make the setter private or protected, which enables you to restrict the writing access while keeping the reading access public. This split in access is also not possible with a field.
using UnityEngine;
public class Enemy : MonoBehaviour
{
[field: SerializeField]
[field: RenameField(nameof(Health))]
public float Health { get; set; } = 1.0f;
}
Results in this:
Unity added support for C# 7.3 (the required version to use default values) with 2018.3.
