Open challenges

This is the honest list. Stuff that’s not done, or is partly done, or is genuinely hard. Nothing here is shipped. If you want to take a swing at any of it, please file an issue first so we can talk through the approach.

Windows dylib loading

The dylib path (where the editor dlopens a hot-reloadable game .so) doesn’t currently work on Windows. The PE binary format has a 65,535 export cap, and bevy + jackdaw types together blow past that.

It’s a binary-format property, not a linker setting. Switching to rust-lld instead of MSVC link.exe was tried and doesn’t help. eugineerd attempted splitting bevy into multiple per-subcrate dylibs and ran into the diamond dependency problem described here.

Where to dig in: making per-bevy-subcrate dylibs work needs upstream bevy crate-type changes; we can’t fix this entirely inside jackdaw. The static-template path works on Windows today and is the recommended setup. If you have a clean idea for the multi-dylib split (especially one that avoids the diamond), let us know.

Play-In-Editor (PIE) maturity

PIE is the “click play to run your game inside the editor” flow. The first three phases shipped:

• BRP foundation (the Bevy Remote Protocol plumbing).
• Entity browser for the live game state.
• Read-only remote inspector.

What’s not done: bidirectional editing (changing a value in the inspector and having it ride back to the game), WebSocket streaming instead of HTTP polling, full component widget metadata, and a clean story for spawning the game in its own process versus loading it as a dylib.

The big open question is in-process vs. out-of-process. In-process is cheap (no IPC) but a panicking game can take down the editor. Out-of-process is safer but needs a real protocol for state sync. Discussion lives in the GitHub issues and on Discord.

Where to dig in: pick a small slice (like “round-trip a single Transform edit”) and prototype the wire format.

Migration to BSN

Cart’s BSN PR for Bevy 0.19 establishes scene-document-as- source-of-truth at the engine level. Jackdaw’s current JSN-first refactor was deliberately shaped to mirror BSN, so the swap should be mostly mechanical.

What’s not done: the actual swap. We need to wait for BSN to land, then port. The risk is timing; BSN might land between a jackdaw release cycle, and we want to stay shippable throughout.

Where to dig in: track the BSN PR upstream, run the JSN-to-BSN diff on a test scene as soon as the upstream format is stable, and prototype the loader changes against a local bevy fork.

Engine-feature gaps

Compared to other game engines, jackdaw is missing a bunch. None of these are blockers; they’re places where someone with taste in the area could lead. One line each:

• Animation graph editor. Started in crates/jackdaw_animation, not finished.
• Particle / VFX editor. Not started.
• Material graph editor (shader-graph style). Not started.
• Light baking and lightmap pipeline. Not started.
• Navmesh debug overlay. We have a navmesh component but no visualisation.
• Cinematics / cutscene editor. Not started.
• Audio mixer. Not started.
• Localization (i18n). Not started.
• In-editor profiler / frame-time inspector. Not started.
• Asset import beyond GLTF (FBX, USD, batch texture compression). Not started.
• Level streaming for large open worlds. Not started.

If you care about any of these, opening a small “here’s what I’d do” issue is the best starting point. We don’t want to solo-design any of them.

Asset processing pipeline

Right now asset processing only happens at editor runtime. If you want to pre-process textures or bake meshes for a CI build, you have to start the editor headlessly, which is not great.

andriyDev raised this in editor-dev. The natural shapes are:

• Split the user’s game into a library plus multiple binaries (run, process). Closer to Unreal’s UAT model. Invasive for the static template.
• Add a cargo jackdaw subcommand with process, build, etc. Closer to Unity’s CLI. Less invasive but more code in jackdaw.

Where to dig in: pick one shape and prototype it against a small game. We’d like to see the workflow before locking in the design.

Single-entity editor-only ergonomics

Today EditorOnly skips the whole entity from save, so to have a PlayerSpawn marker that ships and a visual indicator that doesn’t, you author a parent (with PlayerSpawn) and a child (with EditorOnly + a mesh).

Jan asked whether the same entity could carry both. It can’t today, because the save filter is at entity granularity. A future EditorOnlyVisuals marker that strips visual components (Mesh3d, MeshMaterial3d, etc) at save time but keeps the entity and its non-visual components would enable single- entity authoring. The cost is a small allowlist of “visual” component types that grows as bevy adds new ones.

Where to dig in: design the allowlist, file an issue, then implement. The semantics decision is the harder part than the code.

Brush face children as a custom relationship

Each brush spawns N face child entities for rendering. They carry EditorHidden (so they’re not in the outliner) and NonSerializable (so they’re not in the save). But Children queries on the brush still enumerate them, which means user code that walks brush children sees jackdaw’s implementation detail.

A custom Bevy relationship (not ChildOf) for face entities would solve this cleanly. The face entities would be reachable through the relationship but invisible to standard Children queries. The cost is a small per-frame propagation system that reads the brush’s GlobalTransform and writes the face’s.

Where to dig in: the relationship API in Bevy 0.18, and whether we can do this without breaking BrushFaceEntity queries that already work.