BEVY TIPS FOR NINTENDO SWITCH DEVELOPERS

Architecting for a console state machine requires treating your game less like a standard desktop application and more like a real-time embedded system—much like managing hardware interrupts, device hot-plugging, or DSP buffer states on a custom hardware synth or groovebox. Bevy’s Entity Component System (ECS) and its robust States implementation are perfectly suited for this, allowing you to instantly gate behavior without polluting your gameplay code with hardware checks. Architecting for Hardware Interrupts Instead of polling for hardware changes deep inside your game loops, you broadcast OS-level interruptions as distinct state transitions. The instate Run Condition The core of your architecture should rely on Bevy's SystemSets combined with the .runif(instate(...)) run condition. By grouping your physics, input parsing, and gameplay logic into a unified GameplaySet, you can instantly freeze them when a hardware interrupt occurs. Because Bevy processes state transitions right before the main Update schedule where your game logic lives, transitioning out of HardwareState::Active immediately prevents the next frame's gameplay systems from executing. This ensures absolutely no inputs are read during a suspend event. Handling Suspend and Resume (Sleep Mode) When the Switch is put to sleep, the OS forcefully halts your application. When it resumes, your game must pick up perfectly. You handle this by listening for the OS-level suspend event (provided via the proprietary Nintendo SDK bindings) and queuing a transition to HardwareState::Suspended. Utilize Bevy's OnEnter(HardwareState::Suspended) and OnExit(HardwareState::Suspended) schedules to strictly manage the side effects of this hardware interruption. OnEnter: Pause the virtual time (Time<Virtual), halt physics stepping, and flush your audio buffers. If you are running real-time audio threads, you must explicitly silence the graph here, or the console may freeze while emitting a loud buzzing artifact. OnExit: Re-sync your timers, reload any GPU resources the OS might have evicted to save memory, and safely fade the audio back in. Crucial Caveat: Remember that system set configurations in Bevy are evaluated per-schedule. A configuration applied to your Update schedule will not automatically carry over to OnEnter or OnExit. Your setup and teardown logic must be explicitly configured for those specific transition schedules. Handling Controller Hot-Swapping Controller disconnects are sudden and must immediately halt the game—exactly like pulling a USB peripheral from a live hardware hub. You can model this using orthogonal states (running multiple independent state machines simultaneously). 1. Listen to Connection Events: Bevy's event system can monitor gamepad connection status. When a disconnect event fires, transition a secondary orthogonal state to InputState::Disconnected. 2. Gate the Game: This transition should trigger a high-priority system that pauses the HardwareState and overlays the mandatory Nintendo controller-reconnect UI. 3. Isolate Input Systems: Ensure your low-level input mapping systems—the ones translating raw hardware signals into in-game actions—are isolated in a system set that only runs instate(InputState::Connected). This guarantees that a dying battery does not register as a stuck joystick input during the exact millisecond the console pauses. By heavily leveraging orthogonal states and schedule-wide run conditions, you keep your Bevy game logic pristine while the ECS automatically manages the chaotic reality of console hardware states. When the Nintendo Switch moves between handheld (typically 720p) and docked (1080p), the OS fires a resolution change. In Bevy, this is caught by the windowing backend and broadcast as a window resize event. To ensure your custom WGSL shaders scale dynamically without stretching or crashing, you need to handle this resolution shift at two levels: in the shader code itself using Bevy's built-in uniforms, and in your Rust ECS logic for any custom off-screen textures. 1. Accessing Dynamic Resolution in WGSL The biggest mistake when writing custom shaders for a console is passing the screen resolution as a manual custom uniform. You do not need to do this. Bevy automatically maintains a View uniform containing the current camera's viewport size. You can access this directly in your WGSL by importing the View struct. By reading view.viewport.zw, you guarantee your shader instantly adapts on the exact frame the console is docked or undocked. 2. Resizing Custom Render Targets (Rust ECS) If your WGSL shader is driving a custom post-processing effect (like bloom, chromatic aberration, or custom UI distortion), you are likely rendering to an off-screen Image backing texture. While Bevy automatically resizes the main window frame buffer when the Switch is docked, it does not automatically resize custom off-screen textures. If your custom render target stays at 720p while the Switch outputs 1080p, your shader…