DEV Community: Game Dev Notes (Korea)

Unity vs Unreal: 5 Things I Had to Relearn the Hard Way

Game Dev Notes (Korea) — Wed, 10 Jun 2026 16:00:02 +0000

The first time I opened Unreal after years of living in Unity, I sat there for a full ten minutes trying to figure out where the play button was. Not because I couldn't see it. Because I didn't trust that pressing it would do what I expected. Every muscle memory I'd built up — drag a script onto a GameObject, hit play, see the thing wiggle — was suddenly worthless. The viewport looked similar enough to lull me into a false sense of familiarity, and then five seconds later I was fighting the editor over what "save" even means.

Going the other direction is just as bad. Unreal devs who jump into Unity often spend their first week asking why the engine keeps eating their references on hot reload, or why the Inspector won't show their perfectly reasonable struct.

I've shipped work in both engines at this point, and the honest truth is that the syntax barrier (C# vs C++) is the easy part. What actually slows you down is the dozens of small mental model mismatches that nobody warns you about until you've already lost a weekend to them. The engines look like they solve the same problems, so you assume the shape of the solution is the same. It isn't.

Here are five things our studio had to genuinely rewire our brains around. Not engine trivia — the stuff that quietly costs you days if you don't catch it early.

1. Garbage Collection Lives in Different Universes

Unity gives you C# and the .NET GC. Unreal gives you C++ and a custom mark-and-sweep GC that only knows about objects you've explicitly told it about. These sound similar. They are not.

In Unity, you write a class, you new it up, and the GC takes care of it whenever it feels like. The classic gotcha is performance (allocations in Update = GC spikes), but the correctness model is straightforward. Everything's an object, everything's tracked.

In Unreal, the GC only tracks UObject subclasses, and only through references it can see — meaning references marked with UPROPERTY(). If you store a UObject* as a raw pointer without that macro, the GC has no idea you care about it, and your pointer becomes a dangling reference the next sweep. The object literally gets collected out from under you.

UCLASS()
class AEnemy : public AActor {
    GENERATED_BODY()

    // Safe: GC knows you reference this
    UPROPERTY()
    UWeapon* EquippedWeapon;

    // Time bomb: GC will happily delete this
    UWeapon* SecretWeapon;
};

The mental rewire: in Unity, the GC is a performance concern. In Unreal, the GC is a correctness concern. You don't fight it for frame time, you fight it for object lifetime. Once that clicked, half of my "why is my pointer null" bugs disappeared.

The flip side: Unity devs jumping to Unreal often over-use TWeakObjectPtr because they're scared of the GC. Don't. Just use UPROPERTY() and stop overthinking it.

2. Tick Is Not Update (And Lifecycle Is Not Awake)

On paper, MonoBehaviour.Update() and AActor::Tick() look like the same idea. Per-frame callback, runs every frame, do your thing. In practice the lifecycle and scope rules around them are different enough that you can't just port habits across.

Unity's MonoBehaviour has a fairly chatty lifecycle (Awake, OnEnable, Start, Update, LateUpdate, OnDisable, OnDestroy) and most of those fire reliably in the editor too. You can lean on Start for cheap initialization and forget about it.

Unreal splits actor lifetime across PostInitializeComponents, BeginPlay, Tick, EndPlay, with components having their own OnRegister / InitializeComponent flow. BeginPlay only fires when the game actually starts, which catches a lot of Unity converts off guard the first time they try to do initialization in the constructor and wonder why nothing's wired up yet.

AEnemy::AEnemy() {
    // Constructor runs at CDO creation. World is NOT valid here.
    PrimaryActorTick.bCanEverTick = true;
}

void AEnemy::BeginPlay() {
    Super::BeginPlay();
    // Now the world exists. Do gameplay setup here.
}

And then there's the other direction: Unreal devs in Unity assume Update runs at a consistent rate. It does not. Variable frame time is the default; you want FixedUpdate for physics-coupled logic, and the difference between the two is one of those things you only learn after your character starts vibrating at high frame rates.

The rewire: in Unity, lifecycle is flat and most things fire on a single timeline. In Unreal, lifecycle is staged: constructor for defaults, BeginPlay for runtime, and Tick is opt-in (you have to enable it explicitly, which is honestly a feature, not a bug). Treat them as different shaped tools.

3. Reflection Is the Whole Engine

This is the one I underestimated the longest.

Unity uses [SerializeField] and friends to expose fields to the inspector and serialization. It's lightweight, attribute-driven, and mostly stays out of your way. You can write a class with zero attributes and Unity will still happily serialize public fields by default.

Unreal's UPROPERTY(), UFUNCTION(), and UCLASS() macros look like the same idea but they're load-bearing structural pillars. They feed the reflection system that powers serialization, the editor, Blueprint exposure, network replication, GC tracking (see #1), and the property system. A field without UPROPERTY is invisible to all of it. A function without UFUNCTION can't be called from Blueprint or RPCs. A class without UCLASS doesn't exist to the engine at all.

UCLASS(Blueprintable)
class AEnemy : public AActor {
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Combat")
    float Health = 100.f;

    UFUNCTION(BlueprintCallable, Category="Combat")
    void TakeHit(float Damage);
};

Each meta specifier (EditAnywhere, BlueprintReadWrite, Category, Replicated, etc.) is a load-bearing instruction to a different subsystem. You'll find yourself reading the Unreal docs on property specifiers more than any other page.

The rewire: in Unity, attributes are sugar. In Unreal, macros are the API. When something doesn't show up in the editor, doesn't replicate, doesn't appear in Blueprint, or gets GC'd unexpectedly, 90% of the time it's because you forgot a specifier. Build the habit of writing the macro first, the field second.

4. Editor Extension Is a Different Sport

Both engines let you extend the editor. Both will let you build custom inspectors, tool windows, asset processors. But the shape of how you do it diverges so hard that your tooling knowledge basically doesn't carry over.

Unity editor scripting is mostly C# in an Editor/ folder, using UnityEditor APIs, EditorWindow, CustomEditor, and IMGUI (or UI Toolkit if you've gone modern). It's the same language as your gameplay code, which makes it cheap to start writing. Half our internal tools at the studio started as a 50-line EditorWindow someone wrote during lunch.

Unreal splits editor code into separate modules (you'll be editing .Build.cs files), and the UI is Slate, a declarative C++ DSL that looks like nothing else you've ever written. It's powerful, but the learning curve is real.

// Slate looks like this. Yes, really.
SNew(SVerticalBox)
+ SVerticalBox::Slot()
  .AutoHeight()
  [
      SNew(STextBlock)
      .Text(FText::FromString("Hello, tools"))
  ];

You can avoid Slate for a while using Editor Utility Widgets (UMG in the editor) or Editor Utility Blueprints, which is honestly where I tell anyone starting out to live. Pure Slate is for when you need something that genuinely belongs in the editor chrome.

The rewire: in Unity, "I'll write a quick editor tool" is a fifteen-minute commitment. In Unreal, it's an afternoon if you go native, or fifteen minutes if you accept that Editor Utility Widgets are good enough for 80% of cases. Pick the right tier for the job. Don't try to write Slate for a button that just renames some assets.

5. The Asset Pipeline Has Opinions

The thing nobody tells you: your project structure isn't just organization. It's a contract with the build system.

Unity treats anything in Assets/ as fair game. You move things around freely, the .meta files keep references intact, AssetBundles are an opt-in deployment thing you set up when you need streaming or DLC. The pipeline is forgiving. Maybe too forgiving. Most Unity projects I've inherited had Assets/ folders that looked like a teenager's desktop.

Unreal's Content/ directory is a more structured place. Every asset is a .uasset with cooked variants, references are tracked by path, and moving things around outside the editor will absolutely break your references in ways that aren't always obvious until you try to package. The cook step at build time is a whole second pipeline you have to think about: what's referenced, what gets included, what gets stripped.

// Unity                  // Unreal
Assets/                   Content/
  Scripts/                  Blueprints/
  Prefabs/                  Maps/
  Scenes/                   Materials/
  Materials/                Characters/
  Resources/                ...
                          (Cooked output → Saved/Cooked/<Platform>/)

Two specific traps worth flagging early:

Unity's Resources/ folder is convenient and almost always the wrong answer at scale. Anything in there ships in your build whether you reference it or not. Use Addressables for anything non-trivial.
Unreal's hard-vs-soft references (UPROPERTY() of UObject* vs TSoftObjectPtr<>) determine what gets pulled into memory when. Get this wrong on a mid-size project and your initial map load time will quietly balloon.

The rewire: Unity's pipeline lets you defer thinking about deployment until late. Unreal's pipeline forces you to think about it early. Neither approach is wrong, but pretending you're in the other engine's model is how you ship a 4 GB build that should've been 800 MB.

Closing Thoughts

The pattern across all five of these: the engines look like they solve the same problems with slightly different syntax, and that's the trap. They actually have different philosophies about who owns what — the GC, the editor, the build, the lifecycle, the reflection system. Once you stop trying to translate Unity habits into Unreal (or vice versa) and start learning each engine's actual mental model, everything gets faster.

The other thing this taught me: every time I assumed two systems were "basically the same," I was about to lose a day. Now when I jump into something new, I make myself find the one thing that's structurally different from what I'm used to, before I touch any code. Saves a lot of grief.

If you've made the jump in either direction, I'd genuinely love to hear what tripped you up the worst. The five above are the ones that hit our studio hardest, but I'm sure there's a sixth waiting for the next person who switches engines. Probably something about input systems, knowing my luck.

More notes from the studio coming soon. This blog's going to be a running journal of the small, unglamorous things we actually learn shipping games, so if that's your thing, stick around.

Just One More Bug

Game Dev Notes (Korea) — Tue, 09 Jun 2026 00:30:55 +0000

The lie game devs tell most often at night. To themselves.

Fix one bug, two are born. The cans pile up, the dark circles set in, and before you know it the window is bright again.

"This is really the last one" usually wasn't. Hope you actually get some sleep tonight. 🌙

Unity vs Unreal: 5 Things I Had to Relearn the Hard Way

Game Dev Notes (Korea) — Mon, 08 Jun 2026 16:00:02 +0000

Here are five things our studio had to genuinely rewire our brains around. Not engine trivia — the stuff that quietly costs you days if you don't catch it early.

1. Garbage Collection Lives in Different Universes

Unity gives you C# and the .NET GC. Unreal gives you C++ and a custom mark-and-sweep GC that only knows about objects you've explicitly told it about. These sound similar. They are not.

UCLASS()
class AEnemy : public AActor {
    GENERATED_BODY()

    // Safe: GC knows you reference this
    UPROPERTY()
    UWeapon* EquippedWeapon;

    // Time bomb: GC will happily delete this
    UWeapon* SecretWeapon;
};

The flip side: Unity devs jumping to Unreal often reach for TWeakObjectPtr reflexively because they're scared of the GC. Most of the time you just want a UPROPERTY()-marked pointer — it keeps the object alive and tracked. Save TWeakObjectPtr for the case it's actually designed for: you want to reference something without preventing its destruction (a UI panel watching a target actor that might die first).

2. Tick Is Not Update (And Lifecycle Is Not Awake)

AEnemy::AEnemy() {
    // Constructor runs for the CDO at engine init, and again for every instance.
    // In both cases the world isn't valid — no gameplay state, no other actors.
    // Defaults only; gameplay setup goes in BeginPlay.
    PrimaryActorTick.bCanEverTick = true;
}

void AEnemy::BeginPlay() {
    Super::BeginPlay();
    // Now the world exists. Do gameplay setup here.
}

And then there's the other direction, which bites just as hard. Unreal devs coming into Unity expect a staged lifecycle and instead get a flat one with a bunch of quietly-different rules. Awake runs early, sure, but it runs before the scene's other objects are guaranteed to be wired up — so anything that reaches across to a sibling MonoBehaviour belongs in Start, not Awake. Start itself doesn't fire when you Instantiate the object; it waits for the first frame the object is active. OnEnable and OnDisable fire every time you toggle the GameObject, not just at creation — which is great for pooling and a trap if you treated them as one-shot setup hooks. And the C++ instinct to "just put real init in the constructor" has to be unlearned outright: Unity reserves the right to construct MonoBehaviours for serialization purposes when no scene exists, so gameplay code in the constructor is at best ignored, at worst crashes the editor on domain reload. On top of all that, Update runs at a variable rate; physics-coupled logic belongs in FixedUpdate, and that distinction is one of those things you only learn after your character starts vibrating at high frame rates.

3. Reflection Is the Whole Engine

This is the one I underestimated the longest.

Unity uses [SerializeField], [Serializable], and [SerializeReference] to drive its inspector and YAML serializer. It feels lightweight — public fields serialize by default, private ones need a single attribute — but the rules quietly bite: polymorphic references need [SerializeReference], custom classes need [Serializable] to appear in the inspector at all, and IL2CPP will happily strip any type only reached via reflection unless you preserve it with a link.xml or [Preserve]. It's lower-ceremony than Unreal, but it's not free.

UCLASS(Blueprintable)
class AEnemy : public AActor {
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Combat")
    float Health = 100.f;

    UFUNCTION(BlueprintCallable, Category="Combat")
    void TakeHit(float Damage);
};

4. Editor Extension Is a Different Sport

Unity editor scripting is mostly C# in an Editor/ folder, using UnityEditor APIs, EditorWindow, CustomEditor, and either IMGUI for quick stuff or UI Toolkit (UXML/USS) for anything you'd actually want to maintain. It's the same language as your gameplay code, which makes it cheap to start writing. Half our internal tools at the studio started as a 50-line EditorWindow someone wrote during lunch.

// Slate looks like this. Yes, really.
SNew(SVerticalBox)
+ SVerticalBox::Slot()
  .AutoHeight()
  [
      SNew(STextBlock)
      .Text(FText::FromString("Hello, tools"))
  ];

5. The Asset Pipeline Has Opinions

The thing nobody tells you: your project structure isn't just organization. It's a contract with the build system.

// Unity                  // Unreal
Assets/                   Content/
  Scripts/                  Blueprints/
  Prefabs/                  Maps/
  Scenes/                   Materials/
  Materials/                Characters/
  Resources/                ...
                          (Cooked output → Saved/Cooked/<Platform>/)

Two specific traps worth flagging early:

Unity's Resources/ folder is convenient and almost always the wrong answer at scale. Anything in there ships in your build whether you reference it or not. For anything beyond a prototype, move to Addressables (or whichever streaming asset system your Unity version blesses — the recommendation has shifted more than once).
Unreal's hard-vs-soft references (UPROPERTY() of UObject* vs TSoftObjectPtr<>) determine what gets pulled into memory when. Get this wrong on a mid-size project and your initial map load time will quietly balloon.

Closing Thoughts

This blog's where we plan to write down the small, unglamorous stuff we keep learning the hard way. No newsletter pitch — just more of these when we hit the next one.

Just One More Bug

Game Dev Notes (Korea) — Fri, 05 Jun 2026 00:48:54 +0000

I'll just squash this one and head to bed.

The lie game devs tell most often at night. To themselves.

Fix one bug, two are born. The cans pile up, the dark circles set in, and before you know it the window is bright again.

"This is really the last one" usually wasn't. Hope you actually get some sleep tonight. 🌙

The ScriptableObject Trap: Why Your Game Data Won't Reset After You Quit Play Mode

Game Dev Notes (Korea) — Sat, 30 May 2026 00:04:23 +0000

We had a bug that only made sense if the laws of physics had quietly changed overnight. A designer would playtest a build, tweak nothing, close the editor, come back the next morning, and the boss enemy would start the fight with 40 HP instead of 400. Nobody had touched the data. Git showed no changes to any script. And yet the asset on disk had quietly rewritten itself.

The culprit was a ScriptableObject. Specifically, it was us not understanding what a ScriptableObject is. If you've ever wondered why a value you changed in play mode is still changed after you stop, this is the post I wish someone had handed me two years ago.

ScriptableObjects are assets, not instances

Here is the one sentence that fixes 90% of ScriptableObject confusion: a ScriptableObject is a single shared asset, and every object that references it points at the same instance in memory.

When you make a MonoBehaviour prefab and drop three copies into a scene, you get three independent objects. Change one's health, the other two don't care. People assume ScriptableObjects work the same way. They do not. If ten enemies all reference the same EnemyStats asset, they are all reading and writing the exact same object.

[CreateAssetMenu(menuName = "Game/Enemy Stats")]
public class EnemyStats : ScriptableObject
{
    public int maxHealth = 400;
    public float moveSpeed = 3.5f;
}

public class Enemy : MonoBehaviour
{
    public EnemyStats stats;     // a reference to the shared asset
    private int currentHealth;

    void Start() => currentHealth = stats.maxHealth;

    public void TakeDamage(int dmg)
    {
        // Fine: we mutate a local copy of the number
        currentHealth -= dmg;

        // DISASTER: this rewrites the shared asset for everyone, forever
        stats.maxHealth -= dmg;
    }
}

That second line is the whole bug in miniature. currentHealth is a private field on the component, so mutating it is safe and per-instance. stats.maxHealth is a field on the shared asset. Subtract from it and you've just changed the starting health of every enemy that uses this stats asset, in this run and every run after.

Why the change survives play mode

Here's the part that turns a confusing bug into a genuinely scary one. In the editor, ScriptableObject assets are live objects loaded from disk. When you enter play mode and mutate one, you are editing the loaded asset directly. Unity doesn't snapshot it for you. When you exit play mode, the in-memory object stays modified, and the next time Unity serializes that asset (saving the project, reimporting, or just Unity deciding to flush), your play-mode mutation gets written to the .asset file on disk.

That's why our boss "lost" 360 HP overnight. A playtest had been chipping away at maxHealth via that exact bug, play mode ended, and at some point Unity serialized the now-corrupted asset back to disk. Git eventually noticed, but by then the damage looked like it came from nowhere.

In a build it's slightly different but just as bad: there's no serialization back to disk, but the mutation persists for the entire session because the asset is loaded once and shared. So a value you "reset" in Start only resets because you happened to copy it into a local field. Anything you mutated on the asset itself stays mutated until the app closes.

The fix: treat SO data as read-only at runtime

The rule we adopted and now enforce in review: ScriptableObject fields are read-only at runtime. Runtime state lives on the component (or in a plain C# state object), seeded from the SO.

public class Enemy : MonoBehaviour
{
    public EnemyStats stats;          // read-only template
    private int currentHealth;        // mutable runtime state

    void Start() => currentHealth = stats.maxHealth;   // copy, never alias

    public void TakeDamage(int dmg) => currentHealth -= dmg;  // touch the copy only
}

If a value is a number or a struct, copying it into a local field is enough — value types copy by default. The trap reopens the moment your SO holds a reference type you intend to mutate, like a List<T> or a nested class. Copying the reference copies the pointer, not the data, so you're right back to mutating the shared asset.

[CreateAssetMenu(menuName = "Game/Loadout")]
public class Loadout : ScriptableObject
{
    public List<string> items = new() { "sword", "potion" };
}

// WRONG: runtimeItems points at the SO's own list
List<string> runtimeItems = loadout.items;
runtimeItems.Add("bomb");   // the asset now permanently has a bomb

// RIGHT: make your own list
List<string> runtimeItems = new(loadout.items);

Catching it before it ships

Two guardrails have saved us repeatedly.

First, make accidental mutation impossible to write. Expose SO data through read-only properties backed by [SerializeField] private fields, instead of public fields. Designers still edit them in the inspector; gameplay code physically cannot assign to them.

[CreateAssetMenu(menuName = "Game/Enemy Stats")]
public class EnemyStats : ScriptableObject
{
    [SerializeField] private int maxHealth = 400;
    [SerializeField] private float moveSpeed = 3.5f;

    public int MaxHealth => maxHealth;     // gameplay can read
    public float MoveSpeed => moveSpeed;   // gameplay cannot write
}

Second, when you genuinely want a runtime-mutable copy of an SO (handy for per-enemy modifiers, buffs, procedural variation), be explicit about it with Instantiate. Calling Instantiate on a ScriptableObject gives you a fresh, independent clone you can mutate freely without ever touching the source asset.

// A per-enemy mutable copy, fully isolated from the shared asset
EnemyStats runtimeStats = Instantiate(stats);
runtimeStats.ApplyModifier(eliteBuff);   // safe: this is our own object

Just remember to clean those clones up — Instantiated ScriptableObjects are objects you now own, and they won't be garbage collected as long as something references them.

What it comes down to

A ScriptableObject is shared, persistent, mutable state pretending to be a humble data file. The mental shift is to stop thinking of it as "a struct on disk" and start thinking of it as "a singleton everyone has a pointer to." Once you treat its fields as read-only templates, copy primitives, deep-copy reference types, and reach for Instantiate when you truly need a mutable variant, the whole class of "my data changed itself" bugs disappears. The data only ever changes when you decide it should, on a copy that's yours.

It Worked When I Closed the Laptop. I Swear.

Game Dev Notes (Korea) — Fri, 22 May 2026 17:24:08 +0000

Last night the build was clean. This morning, five red errors before the coffee was even warm.

git log shows the only commit in the last 11 hours is yours. "Refactor player movement".

You hold the cold coffee. You stare at the screen.

If you've shipped any game ever, you've been here. Welcome to Dev Comics #1.

This is a new weekly-ish series from a small Korean indie game studio — short comics about the unglamorous moments of making games. New comics most Tuesdays and Saturdays.

Coming up:

#2 Shader Compile Coffee — when your Unreal shader compile outlives your coffee
#3 Cat.exe Has Stopped Responding — the cat owns the keyboard now

If this hit close to home, drop a 🦖 reaction or share the worst "11 hours ago, by me" commit you've ever seen.

Unity vs Unreal: 5 Things I Had to Relearn the Hard Way

Game Dev Notes (Korea) — Fri, 22 May 2026 15:42:47 +0000

Here are five things our studio had to genuinely rewire our brains around. Not engine trivia — the stuff that quietly costs you days if you don't catch it early.

1. Garbage Collection Lives in Different Universes

Unity gives you C# and the .NET GC. Unreal gives you C++ and a custom mark-and-sweep GC that only knows about objects you've explicitly told it about. These sound similar. They are not.

UCLASS()
class AEnemy : public AActor {
    GENERATED_BODY()

    // Safe: GC knows you reference this
    UPROPERTY()
    UWeapon* EquippedWeapon;

    // Time bomb: GC will happily delete this
    UWeapon* SecretWeapon;
};

2. Tick Is Not Update (And Lifecycle Is Not Awake)

AEnemy::AEnemy() {
    // Constructor runs for the CDO at engine init, and again for every instance.
    // In both cases the world isn't valid — no gameplay state, no other actors.
    // Defaults only; gameplay setup goes in BeginPlay.
    PrimaryActorTick.bCanEverTick = true;
}

void AEnemy::BeginPlay() {
    Super::BeginPlay();
    // Now the world exists. Do gameplay setup here.
}

3. Reflection Is the Whole Engine

This is the one I underestimated the longest.

UCLASS(Blueprintable)
class AEnemy : public AActor {
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Combat")
    float Health = 100.f;

    UFUNCTION(BlueprintCallable, Category="Combat")
    void TakeHit(float Damage);
};

4. Editor Extension Is a Different Sport

// Slate looks like this. Yes, really.
SNew(SVerticalBox)
+ SVerticalBox::Slot()
  .AutoHeight()
  [
      SNew(STextBlock)
      .Text(FText::FromString("Hello, tools"))
  ];

5. The Asset Pipeline Has Opinions

The thing nobody tells you: your project structure isn't just organization. It's a contract with the build system.

// Unity                  // Unreal
Assets/                   Content/
  Scripts/                  Blueprints/
  Prefabs/                  Maps/
  Scenes/                   Materials/
  Materials/                Characters/
  Resources/                ...
                          (Cooked output → Saved/Cooked/<Platform>/)

Two specific traps worth flagging early:

Unity's Resources/ folder is convenient and almost always the wrong answer at scale. Anything in there ships in your build whether you reference it or not. For anything beyond a prototype, move to Addressables (or whichever streaming asset system your Unity version blesses — the recommendation has shifted more than once).
Unreal's hard-vs-soft references (UPROPERTY() of UObject* vs TSoftObjectPtr<>) determine what gets pulled into memory when. Get this wrong on a mid-size project and your initial map load time will quietly balloon.

Closing Thoughts

This blog's where we plan to write down the small, unglamorous stuff we keep learning the hard way. No newsletter pitch — just more of these when we hit the next one.