Capítulo 26B. Dev tooling moderno: inspector, BRP, Tracy y el editor que está llegando

— Decía un programador de Unity en un tweet. Y tenía razón. También aplica a Bevy.

26B.1 Las tres herramientas que un Bevy-dev moderno usa a diario

El cap. 26 mencionó Tracy en una línea. Eso fue una injusticia. El ecosistema Bevy tiene tres herramientas que, combinadas, te dan visibilidad total sobre lo que está pasando en tu juego mientras corre:

1. bevy_inspector_egui: un panel flotante de egui con todas las entidades, componentes, recursos y assets, navegables y editables en vivo.
2. Bevy Remote Protocol (BRP): una API JSON-RPC 2.0 sobre HTTP para controlar el App desde fuera (un IDE, un script, otro juego).
3. Tracy profiler: el profiler de Rust que ve el costo de cada sistema, cada pase de render, cada evento.

El editor oficial de Bevy está en desarrollo (el Inspector General working group, anunciado en octubre 2025). Hasta que llegue, este combo de tres es tu día a día.

26B.2 bevy_inspector_egui: tu ventana al ECS en runtime

Instalación:

# cap-26B — sección 26B.2: Cargo.toml.
[dependencies]
bevy = { version = "0.19", features = ["2d"] }
bevy_inspector_egui = "0.37"  # 0.37.0 (jun 2026), compatible con Bevy 0.19.

Setup:

//! cap-26B — sección 26B.2: setup del inspector.
use bevy::prelude::*;
use bevy_inspector_egui::prelude::*;
use bevy_inspector_egui::quick::WorldInspectorPlugin;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(WorldInspectorPlugin::new())  // ← el inspector.
        .run();
}

Eso es todo. Cuando corras tu juego, vas a ver un panel lateral con la jerarquía de entidades, los componentes, los recursos. Click en una entidad, ves sus componentes. Click en un componente con campos editables (un f32, un String, un Vec3), podés modificar el valor en vivo y ver cómo cambia el juego.

Truco: marcar tus componentes con #[derive(Reflect)] para que aparezcan en el inspector:

//! cap-26B — sección 26B.2: componente reflectable.
use bevy::prelude::*;
use bevy::reflect::Reflect;

#[derive(Component, Reflect, Default, Debug, Clone)]
#[reflect(Component)]
struct Health { current: f32, max: f32 }

Sin Reflect, el inspector puede ver que el componente existe pero no puede mostrar sus campos.

Cuidado: el inspector no debe ir en builds de release. Usá una feature flag para activarlo solo en debug:

//! cap-26B — sección 26B.2: feature flag para el inspector.
#[cfg(feature = "debug-inspector")]
use bevy_inspector_egui::quick::WorldInspectorPlugin;

fn main() {
    let mut app = App::new();
    app.add_plugins(DefaultPlugins);
    #[cfg(feature = "debug-inspector")]
    app.add_plugins(WorldInspectorPlugin::new());
    app.run();
}

Y en Cargo.toml:

[features]
debug-inspector = ["dep:bevy_inspector_egui"]

Build normal: cargo run. Build con inspector: cargo run --features debug-inspector.

26B.3 Bevy Remote Protocol (BRP): controlar tu juego desde fuera

Bevy 0.16+ trae BRP built-in. Es una API JSON-RPC 2.0 sobre HTTP (por defecto en 127.0.0.1:15702) que expone el estado del ECS. Cualquier cliente HTTP puede consultar y modificar el mundo.

Setup:

//! cap-26B — sección 26B.3: activar BRP.
use bevy::prelude::*;
use bevy::remote::{RemotePlugin, http::RemoteHttpPlugin};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(RemotePlugin::default())
        .add_plugins(RemoteHttpPlugin::default())
        .run();
}

Ahora podés hacer:

# Listar los tipos de componentes registrados (método `bevy/list`).
curl -X POST http://127.0.0.1:15702 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"bevy/list","params":{},"id":1}'

# Obtener el componente Transform de la entidad 42 (método `bevy/get`).
curl -X POST http://127.0.0.1:15702 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"bevy/get","params":{"entity":42,"components":["bevy_transform::components::transform::Transform"]},"id":1}'

Pero el caso real es usar un cliente que sepa de BRP. Los más útiles:

1. splo.vscode-bevy-inspector (extensión de VSCode): ves entidades, componentes, recursos, y podés modificarlos en vivo. Funciona con Bevy 0.15+ (algunas features requieren 0.16+).
2. Emacs / Neovim con plugins: existen varias integraciones via bevy_brp o similares.
3. BerrysCode (IDE dedicado): un IDE completo purpose-built para Bevy, descrito en crates.io como "The IDE built for the Bevy game engine". Versión publicada 0.7.3 (mayo 2026), repo KyosukeIshizu1008/berryscode (con "s"). Hecho por un tercero, no oficial. https://lib.rs/crates/berryscode.

La potencia de BRP: podés escribir scripts en Python o Node que controlen tu juego. Tests E2E, bots de prueba, demos automatizadas.

# cap-26B — sección 26B.3: script Python que mueve al player con `bevy/insert`.
import requests

def move_player(entity_id, x, y):
    requests.post("http://127.0.0.1:15702", json={
        "jsonrpc": "2.0",
        "method": "bevy/insert",
        "params": {
            "entity": entity_id,
            "components": {
                "bevy_transform::components::transform::Transform": {
                    "translation": [x, y, 0.0]
                }
            }
        },
        "id": 1
    })

move_player(42, 100.0, 50.0)

Cuidado: BRP permite modificar el estado del juego desde fuera. No lo actives en builds de release o en juegos en producción. Solo en builds de desarrollo.

Nota v4.0 — #[reflect(Resource)] cambió en 0.19: en Bevy 0.19, ReflectResource pasa a ser un ZST (zero-sized type) y #[reflect(Resource)] también refleja el trait Component. Esto rompe código que usaba ReflectResource directamente (típicamente en BRP y bevy_world_serialization). Si tu proyecto usaba BRP y migras a 0.19, usa ReflectComponent en su lugar. El error de compilación es confuso: "expected ReflectResource, found ReflectComponent" o similar. La solución: cambiar ReflectResource por ReflectComponent en tu registro de tipos.

26B.4 Tracy: el profiler de Rust/Bevy

Tracy es un profiler de tiempo real que muestra cuánto tarda cada sistema, cada frame, cada evento. Se activa con una feature de Bevy.

# cap-26B — sección 26B.4: Cargo.toml.
[dependencies]
bevy = { version = "0.19", features = ["2d", "trace_tracy"] }

# cap-26B — sección 26B.4: instalar el cliente Tracy.
# macOS:
brew install tracy
# Linux (build from source): ver Tracy docs.
# Windows: binarios en el sitio oficial.

Ejecutar:

# 1. Abrir el cliente Tracy (tracy GUI).
# 2. En otra terminal, correr tu juego.
cargo run --release --features bevy/trace_tracy
# 3. Tracy se conecta automáticamente, ves los frames en vivo.

Lo que ves:

• CPU: cada sistema Bevy con su tiempo. Click en un sistema, ves qué schedules corren y cuánto tarda cada uno.
• GPU: una fila separada "RenderQueue" con los pases de GPU. Tracy mide cuando puede, no es perfecto, pero da una idea.
• Memoria: con bevy/trace_tracy_memory, también ves allocaciones.
• Eventos: si emitiste eventos de Bevy, los ves como "fuegos" en la timeline.

Para un Bevy dev, Tracy es lo que muestra la verdad. Tu juego va a 60 fps pero un sistema come 15 ms. Ves eso en Tracy, no en el "FPS counter" del HUD.

Caveat oficial: para medir GPU, Tracy da solo una "vista de alto nivel". El MTPC (mean time per call) de Tracy para GPU es la métrica confiable. Mirar frames individuales puede ser engañoso porque la GPU los submuestrea.

26B.5 Instrumentar tu propio código: spans y TracyLayer

Para que Tracy sepa cuánto tarda tu sistema, Bevy ya lo mide automáticamente (todos los sistemas tienen un span). Para spans custom dentro de un sistema, usás bevy::log::info_span! o tracing::span!.

//! cap-26B — sección 26B.5: span custom dentro de un sistema.
use bevy::prelude::*;
use bevy::log::{info_span, info};
use tracing::Instrument;

fn heavy_system(
    mut q: Query<&mut Transform>,
) {
    let _span = info_span!("heavy_system").entered();

    for mut t in q.iter_mut() {
        let _iter_span = info_span!("update_one_transform").entered();
        // ...trabajo pesado...
    }
}

Tracy muestra "heavy_system" como un span, con un sub-span "update_one_transform" por iteración. Click en uno, ves la duración. Útil para encontrar "qué parte del sistema es la lenta".

26B.5b Hot-patch de CÓDIGO con bevy_simple_subsecond_system

Hasta ahora hemos hablado de hot-reload de assets (texturas, sonidos, mallas) en 26B anterior. Eso está bien, pero el verdadero freno del dev-loop de Bevy no son los assets: es la recompilación. Estás ajustando la gravedad del salto del jugador: 0.5, 0.6, 0.55, 0.45. Cuatro valores. Cuatro Ctrl+C, cuatro cargo run, 30 segundos cada uno. Dos minutos para probar cuatro números. Si te equivocas, vuelta a empezar. Multiplica por 50 valores al día y tienes un día laboral perdido en compilación.

Analogía absurda: el dev-loop clásico de Rust es como cocinar pasta desde el trigo. Coges la espiga, la mueles, haces la masa, la hierves, la sirves. Tarda 30 minutos. Subsecond es como tener pasta precocida en la nevera: tú solo la calientas 90 segundos en el microondas y la sirves. No es tan buena como la hecha en el momento, pero cuando estás iterando una salsa, no quieres esperar media hora por cada prueba.

bevy_simple_subsecond_system (de TheBevyFlock: james-jdm-dev, ToasterRoaster y compañía, diciembre 2024) usa la tecnología Dioxus subsecond para recompilar una función aislada y reemplazar su cuerpo en memoria mientras el juego sigue corriendo. Sin reinicio, sin recompilación completa, sin pérdida de estado. Funciona gracias a dos pilares: (1) el compilador de Rust tiene un modo "single function recompile" experimental; (2) Dioxus lo envuelve en un crate que sabe cómo parchear binarios en ejecución. Bevy se integra con un plugin que expone un sistema Subsecond que detecta cambios en los archivos y los aplica.

Setup paso a paso:

1. Instala la CLI de Dioxus (alpha): cargo install dioxus-cli --version 0.7.0-alpha.1. Esto trae el binario dx que sabe cómo parchear.
2. Toolchain nightly en tu proyecto: añadí rust-toolchain.toml con channel = "nightly". Subsecond usa features unstable del compilador.
3. Dependencia en Cargo.toml:

# cap-26B — sección 26B.5b: Cargo.toml para subsecond.
[dependencies]
bevy = "0.19"
bevy_simple_subsecond_system = { version = "0.2", features = ["subsecond"] }
dioxus = { version = "0.7.0-alpha.1", features = ["subsecond"] }

4. Anotá las funciones hot-patchables con #[subsecond::hot]:

//! cap-26B — sección 26B.5b: anotar un sistema.
use bevy::prelude::*;
use bevy_simple_subsecond_system::subsecond;

#[subsecond::hot]
fn ajustar_salto(
    time: Res<Time>,
    mut query: Query<&mut Movement>,
) {
    for mut m in &mut query {
        // Editá el 0.5 en vivo y mirá el cambio.
        m.velocity.y += -9.8 * 0.5 * time.delta_secs();
    }
}

5. Arrancá tu juego con dx run (no cargo run): dx run --bin my_game. La CLI compila con hot-patch habilitado.
6. Editá el código, guardá el archivo, mirá la pantalla: el cambio se aplica en menos de un segundo. Tu juego sigue corriendo, con su estado, sus entidades, su UI. Solo el cuerpo de la función cambia.

Limitaciones importantes:

• Solo cambia el cuerpo de la función, no la firma ni el layout. Si añades un campo a un struct, no funciona. Si cambias el &mut Query<...> por otra cosa, no funciona.
• Solo en dev (debug). En release, los símbolos se optimizan y el parche no es posible. Por seguridad, la dependencia debería ir en [dev-dependencies] o detrás de un #[cfg(debug_assertions)].
• Requiere nightly. Si tu equipo está en stable, no aplica.
• No funciona en WASM (no hay "binario en ejecución" en el navegador).
• El rendimiento durante el parcheo es menor que un binario normal, porque el código parcheado pasa por una capa de indirección. Por eso se desactiva en release.

Cuándo NO usarlo:

• En CI o en builds automatizados (solo el dev local lo necesita).
• En equipos donde el tooling común es stable Rust (es un showstopper).
• Si tu juego tiene lógica con muchos genéricos o lifetimes complejos: el parcheo tiene más fricción.

Cuándo SÍ usarlo:

• Juegos con muchos parámetros de feel (gravedad, fricción, jumpspeed, damage multipliers) que ajustas interactivamente.
• Equipos de 2-3 personas donde el dev-loop rápido compensa el coste de nightly.
• Game jams donde cada minuto cuenta.

bevy_simple_subsecond_system es experimental (alpha, en pleno desarrollo). Úsalo sabiendo que puede romper entre versiones. Pero cuando funciona, es la diferencia entre ajustar 10 valores en 10 minutos y ajustar 10 valores en 10 segundos. La elección, como siempre, es tuya.

26B.6 RenderDoc: el "X-ray" del render

RenderDoc es una herramienta libre de captura de frames GPU. La instalás, abrís tu juego desde RenderDoc, capturás un frame, y podés:

• Ver cada draw call (qué mesh, qué material, qué shader).
• Ver el framebuffer final y los intermedios.
• Inspeccionar uniforms y texturas.
• Reproducir el frame paso a paso.

# cap-26B — sección 26B.6: RenderDoc.
# 1. Instalar RenderDoc (https://renderdoc.org/).
# 2. Abrir RenderDoc, hacer click en "Launch App".
# 3. Tu juego se inicia, RenderDoc captura cada frame.
# 4. Presionar F12 (o el botón de captura) en el momento que querés.
# 5. Inspeccionar.

Para Bevy, RenderDoc funciona con Vulkan/Metal/DX12 (todos los backends que wgpu soporta). No funciona con WebGPU directamente (para eso, las DevTools de Chrome con --enable-unsafe-webgpu).

Casos de uso:

• "¿Por qué este sprite se ve negro?": capturás el frame, abrís el draw call, ves qué shader se usó y qué valores tenían los uniforms.
• "¿Por qué mi post-process no se ve?": ves si el shader corrió, qué texturas leyó, qué output dio.
• "¿Por qué tengo 500 draw calls?": ves la lista de draws, agrupás por material, ves dónde está la fragmentación.

26B.7 wgpu tracing: ver lo que la GPU hace

Para un debug más fino de la GPU, Bevy 0.18+ integra tracing de wgpu. Activás la feature bevy/trace y los spans de wgpu aparecen en Tracy y en los logs.

# cap-26B — sección 26B.7: tracing completo.
[dependencies]
bevy = { version = "0.19", features = ["2d", "trace", "trace_tracy"] }

Cuidado: trace produce muchos spans. Útil cuando estás debug de GPU; molesto en el día a día.

26B.8 El Inspector General working group: el futuro

El 27 de octubre de 2025, el blog "This Week in Bevy" anunció la formación del Inspector General working group, un grupo de trabajo dedicado a construir un inspector de entidades nativo para Bevy. Es el equivalente Bevy del Inspector de Unity o el Outliner de Unreal.

A fecha de esta edición (principios de 2026), el grupo está activo, hay propuestas, pero no hay release. Lo que se puede decir:

• El objetivo es un inspector built-in, sin crates externos.
• Probablemente use egui o una UI propia.
• El alcance es más ambicioso que bevy_inspector_egui: integración con el asset graph, system graph, query visualizer.

Mientras tanto, bevy_inspector_egui es el camino. Cuando el Inspector General llegue, probablemente haya un periodo de transición donde ambos coexisten.

26B.9 El sistema de dev tooling en la práctica: el día a día

Un flujo de trabajo realista de un Bevy-dev:

1. Escribir código en VSCode/RustRover/Neovim.
2. Compilar y correr el juego. Si está lento, abrir Tracy y ver qué sistema come tiempo.
3. Modificar valores en vivo con el inspector: cambio el cooldown de un ataque de 1.0 a 0.5 sin recompilar.
4. Debug de GPU: si algo se ve mal, abrir RenderDoc y capturar el frame.
5. Tests: cargo test para la lógica; CI los corre automáticamente.
6. BRP para integrar con otros sistemas: bot de QA, demo automatizada, script de balance.

El setup de un dev Bevy serio:

# cap-26B — sección 26B.9: setup de un dev.
cargo install tracy    # profiler.
cargo install bve      # bevy-cli (cuando esté estable).
# Editor: VSCode con rust-analyzer + splo.vscode-bevy-inspector.
# O: Neovim con rust-tools + un plugin de BRP.
# O: RustRover con plugin Bevy (cuando exista).

26B.10 La regla de oro: profilear antes de optimizar

El cap. 26 te enseñó técnicas de optimización (batching, LOD, culling, asset streaming). El orden importa:

1. Mide (Tracy, RenderDoc, FPS counter).
2. Identifica el cuello de botella.
3. Optimiza SOLO eso.
4. Vuelve a medir.
5. Repetir hasta que el frame budget esté cómodo.

El error clásico: optimizar todo a la vez "para que vaya más rápido". Resultado: código complicado, bugs nuevos, y a veces más lento. Optimiza lo que se mide, no lo que se siente lento.

26B.11 Glosario del capítulo

bevy_inspector_egui: crate que añade un panel egui al juego con entidades, componentes, recursos.
Reflect: trait de Bevy que permite serializar, deserializar, e inspeccionar un struct.
WorldInspectorPlugin: plugin de `bevy_inspector_egui` que añade el panel por defecto.
BRP (Bevy Remote Protocol): API JSON-RPC 2.0 sobre HTTP (endpoint único) para controlar un App Bevy desde fuera. Métodos: bevy/query, bevy/get, bevy/spawn, bevy/despawn, bevy/list, bevy/insert, bevy/remove.
RemotePlugin: plugin de Bevy que habilita BRP (parte servidor).
RemoteHttpPlugin: plugin que expone BRP sobre HTTP (por defecto en 127.0.0.1:15702).
Inspector General: working group de Bevy que está construyendo un inspector nativo.
Editor oficial Bevy: el que el Inspector General está construyendo. Aún no hay release.
Tracy: profiler de Rust en tiempo real. Ve CPU, GPU, memoria, eventos.
trace_tracy (feature): feature de Bevy que conecta el tracing interno con Tracy.
trace (feature): feature de Bevy que activa spans de tracing.
trace_chrome (feature): feature que exporta tracing a Chrome tracing format (Perfetto).
bevy/trace_tracy_memory: feature que suma tracking de memoria a Tracy.
RenderDoc: herramienta libre de captura de frames GPU. Estándar de la industria.
Vulkan / Metal / DX12: APIs gráficas modernas. wgpu las abstrae.
wgpu: librería de Rust que Bevy usa para renderizar.
Span: un "intervalo" de tiempo que Tracy mide. Se crea con `info_span!` o `tracing::span!`.
MTPC (Mean Time Per Call): métrica de Tracy para ver tiempo promedio por llamada. Útil para GPU.

26B.12 Trivia histórica

RenderDoc (Baldur Karlsson, 2014) — antes de RenderDoc, debuggear shaders era cuestión de "agregar prints" al shader y ver el resultado. RenderDoc popularizó la captura de frame como flujo de trabajo. Hoy es estándar en la industria.
Tracy (Bartosz Taudul — wolfpld, 2017) — antes de Tracy, el profiling en Rust era rudimentario. Tracy popularizó el "frame profiler" con captura remota (tu juego en una máquina, Tracy en otra). Hoy es la opción dominante. (Nota: el handle wolfpld y el email del autor, wolf@nereid.pl, han confundido a algunos lectores que lo atribuyen a Wolfgang Engel; son personas distintas. Wolfgang Engel es autor de la serie de libros GPU Pro / GPU Zen y editor gráfico de Crytek, no tiene nada que ver con Tracy.)
bevy_inspector_egui (Jakob Hellermann, 2022) — el primer inspector serio para Bevy. Mantenido activamente. La comunidad lo adoptó rápido porque era el "missing piece" del flujo diario.
Bevy Remote Protocol (Bevy 0.16, 2024) — la primera versión oficial de BRP. El equipo de Bevy lo construyó inspirándose en el feedback de la comunidad sobre lo difícil que era debuggear sin un inspector oficial.
Inspector General (Bevy working group, 2025) — el reconocimiento oficial de que Bevy necesita un editor/integrated-debugger. Anunciado en This Week in Bevy #X de octubre 2025. A fecha de esta edición, sin release.
splo.vscode-bevy-inspector (splo, 2024) — la extensión de VSCode que usa BRP. Una de las mejores integraciones de un editor con Bevy hasta ahora.
BerrysCode (2025, crate publicado como berryscode 0.7.3) — primer IDE dedicado a Bevy, descrito como "The IDE built for the Bevy game engine". Repo: KyosukeIshizu1008/berryscode. Hecho por un tercero, no oficial. Usa BRP y bevy_inspector_egui por debajo.
Chrome Tracing (Chromium project, 2010) — el formato JSON que exporta la feature `bevy/trace_chrome`. Compatible con `ui.perfetto.dev` (la versión moderna de Chrome tracing).

26B.13 Metedura de pata

❌ Compilar el inspector en builds de release.
✅ Feature flag `debug-inspector`, activada solo en builds de dev.
💡 Por qué: el inspector añade 1-3 MB al binario y 5-10% de overhead. En producción, no querés eso.

❌ Activar BRP en un juego publicado.
✅ BRP solo en builds de desarrollo.
💡 Por qué: BRP permite a cualquiera con acceso HTTP modificar tu juego. Un atacante podría romper tu estado o leer datos sensibles. Nunca.

❌ Mirar el framerate y optimizar.
✅ Mirar Tracy, encontrar el sistema lento, optimizar ESO.
💡 Por qué: el framerate te dice "algo está mal". Tracy te dice QUÉ. Sin profiling, optimizás a ciegas.

❌ Asumir que el Inspector General ya existe.
✅ A fecha de esta edición (2026), sigue en desarrollo. Usá `bevy_inspector_egui`.
💡 Por qué: el working group se formó en octubre 2025. Sin release público. La promesa de que "ya hay un editor" esprematura.

🎯 26B.14 Patrón del capítulo: "el profiler miente, la GPU miente más, los logs mienten siempre"

Problema: tu juego va a 30 fps en una máquina decente. No sabés por qué. Probás cosas al azar. Rompés algo que funcionaba. No avanzás.

Solución: usá las herramientas. Mirá los datos. Optimizá lo que se mide.

1. ¿CPU o GPU bound? → Tracy, ver CPU time vs GPU time.
2. ¿Qué sistema? → Tracy, ordenar por duración.
3. ¿Qué draw call? → RenderDoc, lista de draws.
4. ¿Qué shader? → Tracy + RenderDoc + log de compilación WGSL.
5. ¿Qué evento? → Tracy event log.

Cuándo sí:

• Cualquier proyecto de más de 1000 líneas.
• Cualquier momento en que "va más lento de lo que debería".
• Antes de releases públicas, para verificar que el juego va cómodo en hardware modesto.

Cuándo no:

• Prototipos throw-away.
• Game jams (no hay tiempo).
• Cuando "el juego va bien, no toco nada".

Lo que vimos

• bevy_inspector_egui y su uso con Reflect.
• BRP y los clientes habituales (extensión VSCode splo.vscode-bevy-inspector, el IDE BerrysCode, scripts Python/Node).
• Tracy: setup, métricas, interpretación.
• RenderDoc para debug de GPU.
• wgpu tracing para bajo nivel.
• El Inspector General working group: estado actual.
• Patrón: profilear antes de optimizar.

En el siguiente

Capítulo 27 (intermedio): patrones avanzados de Bevy. Sistemas como plugins, asset hot-reload, BRP, scripting de datos. Y un bonus: cómo estructurar un proyecto Bevy que va a vivir más de 6 meses. Spoiler: si no separás lib.rs y main.rs desde el día uno, lo vas a lamentar.