Vector3 (a struct) constantly but your own custom data types are usually classes, this one's for you. Especially as a beginner, it's important to understand the differences between the two, since it can affect performance in your project! We're going to elaborate on the stack and the heap, and how exactly things are computed under the hood.Let's dive in!
What Exactly Are Classes and Structs?
It's important to understand what this actually is. Both are blueprints for grouping related data and behavior together. So, instead of juggling seperate variables for a player's health, name, and level, you bundle them into one type. Both classes and structs let you do exactly that, with the same basic syntax for defining fields and methods.
Take a look at this code:
public class PlayerClass
{
public string playerName;
public int health;
}
public struct PlayerStruct
{
public string playerName;
public int health;
}
Looks nearly identical, right? That's precisely why this trips people up. The real difference isn't in how you write them, it's in how C# stores and copies them behind the scenes. Understanding a struct vs class Unity developers actually need to know comes down to one core concept: reference types versus value types. Alright, let me try to explain this as best as I can.
Reference Types vs Value Types: The Core Difference
Let the following marinate in your brain for a second:
- A class is a reference type. When you assign one class variable to another, both variables point to the exact same object in memory. Change one, and the other reflects that change too.
- A struct is a value type. When you assign one struct variable to another, C# copies the entire thing. So now the two variables are completely independent.
// CLASS example: both variables point to the SAME object
PlayerClass a = new PlayerClass();
a.health = 100;
PlayerClass b = a;
b.health = 50;
Debug.Log(a.health); // 50, because a and b are the same object
// STRUCT example: b gets its own independent COPY
PlayerStruct x = new PlayerStruct();
x.health = 100;
PlayerStruct y = x;
y.health = 50;
Debug.Log(x.health); // still 100, because y is a separate copy
That's the whole ballgame right there. With the class, changing b changed a too, since they're literally the same object with two names pointing at it. With the struct, changing y left x completely untouched, since y got its own independent copy the moment it was assigned.
The Stack And The Heap: Where Your Data Actually Lives
So why do reference types and value types behave so differently? It comes down to where they live in memory. C# uses two main areas, and understanding them makes the whole classes vs structs C# debate click.
The stack is small, fast, and tidy. Every time a method runs, it gets its own chunk of the stack for its local variables. The moment that method finishes, the whole chunk is wiped instantly. No cleanup crew, no waiting around.
The heap is the big, flexible pool of memory for objects that need to stick around longer than a single method call. Allocating there is slower, and nothing gets removed right away. Objects sit on the heap until the garbage collector notices that nothing references them anymore and sweeps them up.
stack: method starts → locals pushed → method ends → locals popped instantly
heap: new object → lives on until nothing references it → garbage collector cleans it up
Let me show you what that looks like with the example from earlier:
private void SpawnEnemy()
{
PlayerStruct s = new PlayerStruct(); // the data itself lives on the stack
PlayerClass c = new PlayerClass(); // the object lives on the heap
}
Notice what happens with c. The variable itself sits on the stack, but it's really just an address pointing at the actual object on the heap. When SpawnEnemy() ends, c vanishes instantly along with the rest of the stack frame, but the object it pointed to hangs around on the heap until the garbage collector gets to it. The struct s, on the other hand, holds its data directly, so when the method ends, it's simply gone. Nothing left to clean up.
One thing, though, since "structs live on the stack" gets repeated as if it were law: it's really a rule of thumb. A struct stored as a field inside a class lives inside that class's object on the heap, and an array of structs lives on the heap too. The classic stack case is a struct used as a local variable inside a method.
Why This Matters For Struct vs Class Unity Decisions
Here's where this stops being theory. Every time the garbage collector runs, it can cause a brief spike in your frame rate. Spawn a pile of short-lived class objects inside Update() every frame, and you're quietly feeding the garbage collector a steady diet of work, which shows up as stutters at the worst possible moments. Small structs used as local variables never touch the heap, so they never create garbage in the first place.
That's a big part of why Unity makes Vector3 and Quaternion structs. Your game does math with them thousands of times per frame, and none of it should leave garbage behind!
One sneaky gotcha: boxing. If you take a struct and treat it as it were an object (or hand it to something expecting one), C# quietly wraps it in a heap object behind your back, which creates garbage after all. It's worth knowing the term, since it's one of the most common ways to accidentally undo the benefit of using structs.
Why Unity Uses Structs for Vector3
This is where it actually clicks for most people. Vector3, Quaternion, Color, these are all structs in Unity, and now you know why. They're small, simple bundles of a few numbers, and you want each one to behave as its own independent value, not something that silently shares state with every other variable pointing at it.
Vector3 spawnPoint = new Vector3(0, 0, 0);
Vector3 enemyPosition = spawnPoint;
enemyPosition.x = 10;
Debug.Log(spawnPoint.x); // still 0, completely unaffected
Imagine if Vector3 were a class instead. Moving one enemy would risk accidentally moving every other object that happened to reference the same position variable. That would be chaos. Structs sidestep that entire problem by always copying instead of sharing.
So When Should You Actually Use Each One?
Here's where the struct vs class Unity decision actually gets practical. A few solid rules of thumb:
- Small, simple data with no identity - a 2D coordinate, an RGB color, a short-lived calculation result. Struct.
- Complex objects with behavior and identity - an enemy, a player, an inventory system, anything that represents a "thing" rather than just a "value." Class.
- Data you want to copy freely without side effects - struct.
- Data multiple systems need to share and modify together - class, since you want everyone pointing at the same object.
- Frequently created and destroyed in large numbers - struct, since structs avoid some of the memory allocation overhead classes carry.
Microsoft's own general guidance is that a struct should typically be small, logically represent a single value, and be immutable or close to it. The moment your type starts needing inheritance, or starts representing something more like an "entity" than a "value," a class is almost always the better fit.
A Quick Word on Inheritance
One more practical difference worth knowing: classes support inheritance, structs don't. If you're building a system where Enemy inherits from a base Character class, and Boss inherits from Enemy, that entire hierarchy has to be built with classes. Structs can implement interfaces, but they can't inherit from another struct or class, and nothing can inherit from a struct either.
This alone settles a lot of the classes vs structs C# debate in practice. The moment inheritance enters the picture, the decision's already made for you.
So Which One Should You Actually Use?
Here's the no-fluff version, the gut check you can run through in your head:
- Need inheritance → class, structs can't do this
- Representing a simple value (position, color, a small data pair) → struct
- Representing a complex "thing" with identity and behavior → class
- Want independent copies with no shared state → struct
- Want multiple references pointing at the same shared object → class
- Not sure yet → class is the safer default while you're learning, structs have sharper edges once you factor in copying behavior
Picking the right one in the struct vs class Unity decision isn't about which is objectively better, it's about asking "do I want this to behave like a value that gets copied, or an object that gets shared?" That question settles it almost every time.
Wrapping This Up
Classes and structs look nearly identical on the surface, same fields, same methods, same basic syntax, but the reference-versus-value distinction underneath changes how your data actually behaves once it starts getting passed around your codebase. Default to classes for your own gameplay objects, reach for structs when you're modeling small, simple values like Unity's own Vector3 does, and you'll avoid a whole category of sneaky bugs down the line.
~happy Coding!
No comments:
Post a Comment