Bevy 0.20 — Porting from other engines

When to use this skill

• Starting a port of an existing game from Unity, Unreal, Godot, Cocos, vanilla JavaScript / Phaser, Flash/SWF, Defold, Roblox, or GameMaker into Bevy 0.20.
• Evaluating feasibility — does my engine's feature X have a Bevy equivalent in 0.20?
• Deciding which subsystem to port first (we recommend: rendering + a single playable slice).
• Extracting asset and scene data from the source engine's project tree without needing the source engine installed — see the scripts/ policy below.
• Replacing engine-specific build pipelines (Unity Build Settings, Unreal Build Configuration, etc.) with cargo + Cargo.toml features.

Engine coverage

Unity (priority)

Unity is the deepest-covered engine. The eight subsystem references and four extraction scripts together cover an end-to-end port:

Extraction scripts (all stdlib-Python, no Unity install required):

Run each script with --help to see all flags. Each script's docstring points to the matching reference.

General porting principles

These show up regardless of source engine:

1. The ECS shift. Engines other than Bevy mostly use a scene-graph + scripts model (one class = data + behaviour on one node). Bevy is data-oriented: data lives in Components, behaviour in free fn Systems. Don't try to recreate MonoBehaviour / Actor / Node as one Rust struct; split it.
2. Port the smallest playable slice first. A single character moving in a single scene with one input + one animation. Once that compiles and runs, the rest is iteration. Avoid trying to "port everything in parallel."
3. Asset pipelines are the long pole. Code ports faster than assets. Schedule asset extraction first; have a content pipeline producing glTF + KTX2 + audio formats before you start writing gameplay code.
4. Fixed-timestep mindset. Most engines hide the variable-vs-fixed timestep choice. Bevy makes it explicit: physics in FixedUpdate, rendering in Update, interpolation via Time<Fixed>. Decide early which systems live where — see bevy-core-concepts and bevy-animation/references/procedural-animation.md.
5. Coordinate-system flips. Unity is left-handed Y-up; Unreal is left-handed Z-up; Godot is right-handed Y-up; Bevy is right-handed Y-up (matches glTF). Most exporters handle the flip; spot-check by importing a scene with a known-asymmetric directional asset and confirming it isn't mirrored.

Names that changed since 0.18 (what stale LLM output looks like)

Every engine-mapping row in references/ uses the right-hand column. If a tutorial or model emits the left-hand name, translate before porting.

Scripts policy

scripts/<engine>/ contains runnable, single-file Python helpers that extract data from the source engine's project tree. The convention for this collection:

• Stdlib-only when possible. Unity's YAML is parsed with re not pyyaml — easier to install.
• No source engine required. All Unity scripts read text-format .unity/.prefab/.anim/.meta files directly. Engines whose files are binary (Roblox .rbxl, parts of GMS2) get a recipe in their reference instead.
• Inventory + extraction, not auto-conversion. None of these scripts produce a Bevy project. They give you JSON so you (or a downstream tool) know what to port. Treat them as tree + file + stat for game projects.
• Reference-backed. Each script names its matching reference in its top-of-file docstring.

Gotchas

• One-shot ports don't work. Allocate time proportional to your project's content size, not its code size.
• Prefab semantics don't transfer. Unity's "Prefab + Variant + Nested Prefab" inheritance has no direct Bevy equivalent. Bake to glTF for visual prefabs (WorldAssetRoot); write spawn functions or bsn! templates for data prefabs.
• Animation retargeting is engine-specific. Mecanim Humanoid retargeting in particular has no out-of-the-box Bevy equivalent — see references/unity-animation.md.
• Coordinate-system flips silent-fail. Most exporters handle them, but always spot-check.
• Editor scripts are out of scope. Unity [CustomEditor], Unreal Blueprints' editor tooling, Godot tool scripts — none translate. Bevy 0.20 ships Feathers widgets and PanOrbitCamera for editor-style tools, but no shipped scene editor; for porting, runtime-only.
• Don't replicate engine-internal IDs. Unity GUIDs, Unreal FNames, Godot RIDs, Roblox InstanceIDs — these are sidecar metadata only useful during extraction. Bevy uses path-based handles and ECS entity IDs.
• ui and audio are not implied by 3d/2d (0.19). A port that trims default-features must add ui and audio explicitly or buttons and AudioPlayer silently never run.
• Community crate versions move with Bevy. Verified for 0.20 (2026-11): bevy_rapier3d 0.37, avian3d 0.8, bevy_hanabi 0.20, leafwing-input-manager 0.22, bevy_asset_loader 0.28, bevy_ecs_tilemap 0.20, bevy_kira_audio 0.27, bevy-persistent 0.12, bevy_hui 0.8. Still on older Bevy: bevy_prototype_lyon 0.17 (0.19), bevy_cobweb_ui 0.22 (0.17).

See also

• bevy — router; pins Bevy 0.20 and indexes every sibling skill.
• bevy-animation — AnimationGraph, AnimationTransitions, #[derive(AnimationEvent)]. Cross-linked from unity-animation.md.
• bevy-ui — Node + Taffy/flex model, ui_widgets::Button. Cross-linked from unity-ui.md.
• bevy-cargo-features — replaces Unity Build Settings / PlayerSettings.
• bevy-wasm-webgpu — Unity WebGL → wasm32 / WebGPU port story.
• bevy-cameras — RenderTarget as a component, camera modes; close to Unity Camera component.
• bevy-migration-0-19-to-0-20 and bevy-migration-0-18-to-0-19 — full rename lists behind the table above.