Unity to Godot: a rebuild, not a converter

In September 2023, when Unity announced its per-install runtime fee, a wave of developers went looking for a "Unity to Godot converter" and found none that works on a real game. That is not for lack of trying. The two engines disagree about what a game is made of.

In Unity a GameObject is an empty container and behaviour comes from components bolted onto it. In Godot a node is a single thing with a type, and behaviour comes from the tree: a CharacterBody2D with a CollisionShape2D and a Sprite2D as children. A converter would have to decide, for every GameObject, which node it really is. That decision is design, which is why the honest answer is a rebuild.

A rebuild sounds slower than it is. Most of a Unity project, its models, textures, audio and level layout, carries across as files, and the logic is usually far smaller than the content. What has to be rewritten is the glue.

MonoBehaviour becomes a script extending a node type. Start and Awake become _ready, Update becomes _process, FixedUpdate becomes _physics_process. A prefab becomes a scene (.tscn) you instantiate. Tags become groups, layers become collision layers and masks, a ScriptableObject becomes a Resource, a coroutine becomes await, and a UnityEvent becomes a signal.

Physics: OnTriggerEnter2D becomes an Area2D's body_entered signal. A Rigidbody2D whose velocity you set by hand is usually a CharacterBody2D in Godot, which you move with move_and_slide(); a body the physics pushes around stays a RigidBody2D. In 3D both engines measure in metres. In 2D Unity measures in units and Godot in pixels, so at Unity's default 100 pixels per unit, a speed of 5 becomes 500.

UI built with uGUI becomes Control nodes, an Animator Controller becomes an AnimationTree, and Cinemachine becomes a Camera2D or Camera3D script, or an add-on such as Phantom Camera. Shaders written in ShaderLab, HLSL or Shader Graph are rewritten in Godot's shading language.

Models in FBX or glTF import into Godot 4 directly, rigs and animations included. Textures and audio copy across. Unity's Standard and URP Lit materials become StandardMaterial3D, with the same albedo, normal, metallic and roughness maps.

Unity saves scenes and prefabs as text by default (Asset Serialization: Force Text), so they are readable: positions, rotations, component values, and the GUIDs in .meta files that say which asset each one uses. That is what lets the AI rebuild a level where it was rather than guess.

Asset Store packages come under their own licences. Check each one before you move it to another engine.

Put the Unity project, or the parts of it you want, where Flockbay can read it, and open a new game. Tell Flockbay what you are bringing and how the game should play. It reads the C# and the scene files, then writes a brief: what it rebuilds first, what comes after, and what changes on the way. Nothing is built until you approve it.

It rebuilds the scenes as Godot node trees, imports the models and textures, and writes the scripts in GDScript, or in C# if you ask, since Flockbay's Godot runs both. It checks its own work by playing the game: it sends input events, reads stdout and the debugger, and takes viewport captures. Then you play both versions side by side and say what feels different.

We tried this on a small Unity 2D platformer: a Rigidbody2D player with a jump, a trigger coin and a score singleton. Rebuilt in Godot 4.7.2 as a CharacterBody2D, an Area2D and an autoload, it walked at the same 500 pixels a second and jumped to the same height, within the six pixels that frame stepping explains, and the coin scored. Feel is where a rebuild drifts: gravity scale, drag and Unity's physics material friction have no single Godot setting, so expect to tune jump and movement by playing.