Heathen Engineering

Migrating from Unity to O3DE

Of the three engines covered in this series, O3DE is the one whose object model will feel most immediately familiar to a Unity developer. Entities and Components map fairly directly onto GameObjects and Components. The bigger shift is everywhere else: the scripting story, the build pipeline, and the size of the ecosystem around it.

Core concept mapping #

UnityO3DENotes
GameObject + ComponentEntity + Component (AZ::Component)The closest architectural match of any engine in this series.
PrefabPrefabSame name, same job. O3DE’s current Prefab system (replacing the older Slice system) is a direct conceptual match.
SceneLevelDifferent word, same idea.
C# events / interfacesEBus (Event Bus)O3DE’s request/notification messaging system: more decoupled than a direct reference, closer to a built-in, structured service-locator-plus-events pattern than anything Unity ships natively.
PhysXPhysXGenuinely the same physics engine under the hood.
C# scriptingC++ (primary), Script Canvas (visual), Lua (supported)The single biggest adjustment, see below.
Unity Package Manager (UPM)Gems + Project Manager’s Gem ReposConceptually similar (a registry of installable modules), a younger, thinner ecosystem than UPM’s.

The real adjustment: C++ first, not C# #

O3DE’s primary programming path is C++, compiled through CMake. That’s a materially higher barrier to entry than Unity’s C# if your team doesn’t already have systems-level C++ experience. Two things soften this:

  • Script Canvas, O3DE’s visual scripting system, covers real gameplay-logic authoring without writing C++ directly. It’s not as central to the workflow as Blueprint is in Unreal, but several Heathen Toolkits expose real Script Canvas nodes for exactly this reason.
  • Lua is also supported for lighter scripting needs that don’t justify a full C++ Gem.

C++ changes require a real recompile, not a hot-reloaded script edit. If your team’s whole workflow rhythm depends on Unity’s edit-and-immediately-see-it iteration loop for gameplay code specifically, plan for that shift.

Project structure and the Gem system #

O3DE ships functionality as Gems: modular packages with real build-system integration (CMake), installed and managed through the O3DE Project Manager, which reads Gem Repos (JSON feeds of available gems, the same pattern Heathen’s own O3DE-Gems repository uses to list every Heathen O3DE gem in one place). It’s a real package-management story, just younger and with a smaller third-party catalogue than Unity’s Asset Store or UPM registry ecosystem.

What transfers, what you’ll need to rebuild #

Transfers well: your Entity/Component mental model (the smoothest object-model transition of the three engines covered in this series), your physics tuning intuition (same PhysX engine), and general systems-level architecture thinking.

Needs rebuilding, not porting: any C#-specific code, since this is a language change, not a syntax dialect change. Editor tooling built against Unity’s Editor API has no equivalent shortcut into O3DE’s own editor extension model. Any workflow built around fast scripting iteration will need to shift expectations around Script Canvas and Lua for the parts of your game that benefit from them, reserving C++ for what actually needs it.

Heathen tooling across this migration #

  • Foundation for Steamworks: available on O3DE. Toolkit is partial.
  • GameplayTags: Foundation available on O3DE. Toolkit is Unity-only.
  • Lexicon Localisation: Foundation available on O3DE. Toolkit is Unity-only.
  • Ogham Storyteller: Foundation and Toolkit available on O3DE.
  • Game Framework: no O3DE port. O3DE’s own AZ::Interface<> singleton access and SystemComponent activation dependencies (GetProvidedServices()/GetRequiredServices()) cover the same lifecycle-ordering job natively.
  • Unity-only, not available on O3DE: DataLens, Attribute Tag Engine (HATE), Discord Social.

Related guides #

Rate This Article!

Contents