bevy-porting

Bevy 0.19 — 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.19.
• Evaluating feasibility — does my engine's feature X have a Bevy 0.19 equivalent?
• 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

Engine	Coverage	Scripts
Unity	Deep (8 subsystem refs) — see § Unity below	4 Python extractors in scripts/unity/
Unreal Engine 5	references/unreal.md — Actor/Component → ECS, UMG → bevy_ui, Niagara/animation gaps	scripts/unreal/ue5_python_export.py (drops into UE5 editor)
Godot 4	references/godot.md — node-tree → ECS, .tscn text format, GDScript → Rust	scripts/godot/tscn_inventory.py (stdlib, no Godot needed)
Cocos Creator 3	references/cocos.md — TypeScript node-tree → ECS, JSON .scene/.prefab	inline Python recipe in the reference
Vanilla JavaScript / Canvas / HTML5	references/javascript.md — class+rAF loops → ECS systems, Canvas 2D → Sprite	— (port is a rewrite, not extraction)
Phaser 3	references/phaser.md — Scene/preload/update → systems, Arcade physics, tweens	—
Flash / SWF	references/flash-swf.md — ffdec-based extraction, AS3 → Rust rewrite	scripts/flash/swf_assets.py (requires ffdec on PATH)
Defold	references/defold.md — message-passing → Bevy Messages, Lua → Rust, 2D-first	inline Python recipe in the reference
Roblox	references/roblox.md — Instance tree → ECS, asset-ID extraction, Luau → Rust	scripts/roblox/rbxlx_inventory.py (XML .rbxlx only)
GameMaker Studio 2	references/gamemaker.md — Object events → systems, JSON project files	scripts/gamemaker/gms2_inventory.py (stdlib, walks .yyp)

Unity (priority)

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

Subsystem	Reference	Bevy primitives
Architecture (GameObject, MonoBehaviour, ScriptableObject, coroutines)	references/unity-architecture.md	Entity + ChildOf, Component + System, Asset/Resource, async tasks
Asset pipeline (Prefab, Material, Addressables, GUIDs)	references/unity-assets.md	Bundle/spawn fn, StandardMaterial, AssetServer + Handle<T>
Scene → glTF extraction	references/unity-scenes-gltf.md	bevy_gltf, WorldAssetRoot, glTFast / Blender bridge
Animator / Mecanim	references/unity-animation.md	AnimationGraph, AnimationTransitions::play, #[derive(AnimationEvent)]
Input System	references/unity-input.md	ButtonInput, Axis, Touches, Gamepad*
UGUI / UI Toolkit	references/unity-ui.md	Node, BackgroundColor, BorderColor, Taffy/flex
Audio (AudioSource, AudioListener, mixers)	references/unity-audio.md	AudioPlayer, SpatialListener, bevy_audio
Build / deploy (Build Settings, IL2CPP, WebGL)	references/unity-build.md	cargo build --target, Cargo.toml features, WASM

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

Script	What it does
scripts/unity/scene_inventory.py	Parse .unity YAML → JSON inventory of GameObjects + transforms + components
scripts/unity/prefab_inspector.py	Parse .prefab YAML → component graph per prefab
scripts/unity/animation_extractor.py	Parse .anim YAML → keyframe JSON, formatted for AnimatableKeyframeCurve::new([...])
scripts/unity/asset_audit.py	Walk Assets/ → inventory by type, size, GUID, and (optionally) dependency graph

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: deterministic simulation belongs in FixedUpdate, frame-driven main-world presentation belongs in Update, and renderer work belongs in render schedules. Interpolate with 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.

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; write spawn functions 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's editor story is in flux; 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.
• Pin physics integrations to Bevy 0.19. Current compatible lines are bevy_rapier2d/bevy_rapier3d 0.36 and avian2d/avian3d 0.7. Physics is separate from rendering; see bevy-rendering before choosing headless or debug-render features.

See also

• bevy — router; pins Bevy 0.19 and indexes every sibling skill.
• bevy-animation — AnimationGraph, AnimationTransitions, #[derive(AnimationEvent)]. Cross-linked from unity-animation.md.
• bevy-ui — Node + Taffy/flex model. 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 components and camera modes; close to Unity's Camera component.
• bevy-rendering — renderer selection and the physics/rendering boundary.
• bevy-physics — Rapier bodies, colliders, controllers, queries, and fixed-step integration.
• bevy-migration-0-17-to-0-18 — useful if you find a tutorial pinned to a pre-0.18 release.