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.tomlfeatures.
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:
- 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 freefnSystems. Don't try to recreateMonoBehaviour/Actor/Nodeas one Rust struct; split it. - 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."
- 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.
- 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 inUpdate, and renderer work belongs in render schedules. Interpolate withTime<Fixed>. Decide early which systems live where — seebevy-core-conceptsandbevy-animation/references/procedural-animation.md. - 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
renotpyyaml— easier to install. - No source engine required. All Unity scripts read text-format
.unity/.prefab/.anim/.metafiles 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+statfor 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.36andavian2d/avian3d 0.7. Physics is separate from rendering; seebevy-renderingbefore 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 fromunity-animation.md.bevy-ui—Node+ Taffy/flex model. Cross-linked fromunity-ui.md.bevy-cargo-features— replaces Unity Build Settings / PlayerSettings.bevy-wasm-webgpu— Unity WebGL → wasm32 / WebGPU port story.bevy-cameras—RenderTargetcomponents 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.