Heathen Engineering

Migrating from Unity to Godot

Moving a project (or just your own working habits) from Unity to Godot is mostly a change in how you think about a scene, not a change in what you’re capable of building. This guide maps Unity’s core concepts onto Godot’s equivalents and covers where Heathen’s own cross-engine tools can help along the way.

This is a conceptual and architectural guide, not a line-by-line code port. The goal is to get your mental model right before you touch a single script.

Core concept mapping #

The single biggest mental shift: Unity separates GameObject (the container) from Component (the behaviour). Godot doesn’t; a Node is both at once. A Sprite2D node already knows how to render itself; you don’t attach a “SpriteRenderer component” to an empty container the way you would in Unity.

UnityGodotNotes
GameObject + Component (MonoBehaviour)NodeA Node is both the container and the behaviour, no split.
SceneScene (a Node tree)Same word, different scope, see below.
PrefabScene (saved as a reusable, instanceable sub-tree)Godot has no separate “prefab” concept; any scene can be instanced inside another, nested arbitrarily deep.
ScriptableObjectResourceSerializable data asset, same job, different name.
C# events / UnityEventSignalsBuilt into every node: connect a signal to a method in the editor or in code.
Coroutines (IEnumerator)await on a signalDifferent mechanism, same intent: pausing execution until something happens.
PhysXGodot Physics / JoltGodot ships its own physics engines, not PhysX. Expect some tuning differences.
Unity Package Manager (UPM)AssetLib + manual addons/No built-in dependency resolver. This is the gap Heathen’s own Extension Resolver was built for, see below.

Scenes mean something different #

In Unity, a Scene is usually one big level or menu: a flat-ish list of GameObjects sharing one space. In Godot, “Scene” means something closer to Unity’s Prefab: any node tree, no matter how small, can be saved as its own scene and instanced elsewhere. A single button, a whole level, and your player character are all just “scenes” at different scales, and scenes nest inside scenes natively. This is more powerful than Unity’s nested-prefab support, but it does mean re-learning where the boundary between “a reusable thing” and “the level” actually sits. In Godot, there often isn’t one.

Scripting language and paradigm shift #

  • GDScript is Godot’s primary, tightly-integrated language: Python-like syntax, fast hot-reload, and it’s what most editor tooling and documentation assumes first.
  • C# is fully supported, and if your team’s expertise and existing code is C#-heavy, staying in C# is a completely reasonable choice, though tooling maturity and community example coverage still skews toward GDScript in places.
  • GDExtension exists for native C++ code, roughly analogous to a Unity native plugin, for performance-critical work that needs to sit outside the scripting layer entirely.
  • Signals replace a lot of what Unity developers reach for interfaces or manual event subscription to do. If you find yourself writing an interface purely so multiple unrelated objects can react to one event, that’s usually a signal in Godot instead.

Project and asset structure #

Godot’s project filesystem (res://) is flatter and lighter-weight than Unity’s Assets/ folder. There’s no per-asset .meta sidecar file to manage, and moving/renaming files inside the editor is generally safer than doing the same thing to a Unity asset from outside the Editor. Where Unity leans on Addressables or Asset Bundles for content you want to load dynamically, Godot’s resource loading is more direct by default (load() / preload()), with dedicated systems only if you need them for larger content-delivery cases.

What transfers, what you’ll need to rebuild #

Transfers reasonably well: your actual game logic and data structures, your understanding of component-style composition (even though the mechanism differs), UI layout thinking (Godot’s Control nodes cover similar ground to Unity’s UGUI), and general C# knowledge if you stay in C#.

Needs rebuilding, not porting: anything built directly against Unity’s physics tuning (PhysX-specific values won’t map 1:1 onto Godot Physics/Jolt), any editor tooling you wrote against Unity’s Editor API (Godot’s plugin API is a different shape entirely), and any workflow that assumed UPM’s dependency-resolution behaviour, since Godot has no exact equivalent.

Heathen tooling across this migration #

Some Heathen tools have full parity across Unity and Godot today. Some don’t yet:

  • Game Framework: available on Unity and Godot.
  • Foundation for Steamworks: available on both. Toolkit is available on both; Godot’s is earlier and less complete than Unity’s.
  • GameplayTags: Foundation available on both. Toolkit is Unity-only.
  • Lexicon Localisation: Foundation available on both. Toolkit is Unity-only.
  • Ogham Storyteller: Foundation and Toolkit available on both.
  • Unity-only, not available on Godot: DataLens, Attribute Tag Engine (HATE), Discord Social.

Related guides #

Rate This Article!

Contents