Fyrox

Fyrox is a feature-rich, production-ready game engine for building both 2D and 3D games in Rust. It ships with a comprehensive visual scene editor, a deferred+forward rendering pipeline with physically based materials, and a custom UI framework with over 30 widgets — all bundled in a single, cohesive toolchain. Released as v1.0.0 in March 2026, the engine is actively maintained and battle-tested in real game projects.

Unlike most game engines, Fyrox is written entirely in Rust and uses a generational arena (pool-based) memory model rather than a traditional ECS, providing strong cache locality and straightforward object relationships without fighting the borrow checker. The plugin architecture supports dynamic library hot-reloading, letting you iterate on game logic while the engine is running — a rare capability in the Rust ecosystem.

The engine’s modular Cargo workspace separates concerns cleanly: fyrox-core handles foundational data structures, fyrox-sound provides software binaural audio with HRTF spatialization, fyrox-ui delivers a standalone graphics-API-agnostic widget system, and fyrox-impl ties everything together. Each crate can be used independently, making Fyrox composable beyond just game development.

Fyrox targets indie developers and studios who want the performance and memory-safety guarantees of Rust without sacrificing the ergonomics of a modern, fully-featured engine. Its official book, active Discord community, and steady release cadence make it one of the most viable open-source alternatives to Unity or Godot for Rust developers.

What You Get

• Visual Scene Editor - A full-featured GUI editor for composing 3D and 2D scenes with drag-and-drop nodes, property inspection, animation editing, and asset management — all built on the engine’s own UI framework.
• Dynamic Script Hot-Reloading - Load game scripts as dynamic libraries and recompile them while the engine is running, seeing behavior changes immediately without restarting your project.
• Deferred + Forward Renderer - A dual-pipeline renderer that handles opaque objects via deferred shading and transparent objects via forward rendering, with support for PBR materials and global illumination.
• HRTF Binaural Audio - Software sound engine with head-related transfer function spatialization for realistic 3D positional audio that works across platforms without hardware audio APIs.
• Pool-Based Memory Management - Generational arena allocator that stores objects in contiguous memory blocks for cache efficiency, with handle-based access that avoids Rust borrow-checker conflicts.
• Custom UI Framework (fyrox-ui) - A standalone, graphics-API-agnostic UI library with 30+ widgets including docking managers, file browsers, and rich text, used both by the editor and runtime UIs.
• Tile Map System - Built-in 2D tile map support with autotiling, collision shapes, and terrain layers for building grid-based games and levels.
• GLTF 2.0 Asset Pipeline - Native import and runtime rendering of GLTF 2.0 models with PBR materials, skeletal animation, morph targets, and embedded textures.
• Project Manager - First-class tooling to create, open, and manage Fyrox game projects with automatic build configuration and asset directory setup.

Common Use Cases

• Indie 3D game in Rust - A solo developer uses Fyrox’s visual editor and hot-reloading scripts to rapidly prototype and iterate on a 3D adventure game without leaving the Rust ecosystem.
• 2D platformer with complex tile maps - A small team builds a large 2D platformer using Fyrox’s tile map system and autotiling to design levels efficiently with physics colliders per tile.
• Technical demo with PBR rendering - A graphics programmer creates a real-time showcase of physically based rendering techniques using Fyrox’s deferred pipeline and GLTF asset import.
• Game jam project in Rust - A developer targets Fyrox for a game jam to produce a working game fast, relying on the editor, built-in physics, and audio without assembling an engine from crates.
• Embedding engine in a Rust application - A developer integrates Fyrox as a rendering and UI subsystem inside a larger Rust application, using the modular crate design to pull in only needed components.

Under The Hood

Architecture Fyrox is structured as a monolithic engine with deliberately one-way coupling between subsystems — the renderer depends on the scene graph, but the scene has no knowledge of the renderer, keeping modifications localized. The engine explicitly rejects ECS in favor of generational arena pools, where objects live in contiguous memory blocks and are referenced by handles (index + generation pairs), avoiding borrow-checker conflicts while achieving strong cache locality. A Cargo workspace with over twenty crates gives each subsystem bounded responsibility: core data structures, sound, UI, graphics abstraction, and game logic are all independently usable crates. The plugin system and optional dynamic library crate enable runtime script hot-reloading — a technically challenging capability in Rust that Fyrox delivers through careful ABI boundary design.

Tech Stack The engine is written entirely in Rust, managed through Cargo workspaces for unified multi-crate builds. Rendering is implemented against an OpenGL backend via fyrox-graphics-gl, with custom GLSL shaders powering a deferred+forward pipeline. The UI system in fyrox-ui is graphics-API-agnostic, communicating through a message-passing architecture rather than direct mutation, making it portable and testable independently. The software sound engine provides HRTF binaural spatialization without hardware audio API dependencies, supporting Vorbis and WAV decoding. Window and input management uses winit. Asset serialization uses a custom visitor-based binary and text format rather than external formats, giving full control over versioning and compatibility.

Code Quality The codebase enforces rustfmt formatting and enables missing-docs warnings across key crates. Procedural derive macros — Reflect, Visit, and TypeUuidProvider — generate serialization, reflection, and type registration boilerplate at compile time, eliminating entire categories of runtime bugs. Integration tests cover core-derive macros thoroughly, and widget-level unit tests are present throughout fyrox-ui. The contributing guidelines explicitly require unit tests for new functionality and meaningful pull request descriptions. CI runs on GitHub Actions. Code density and inline documentation is comprehensive in the core and engine modules, though some peripheral crates have lighter coverage.

What Makes It Unique Fyrox’s most distinctive technical choice is its rejection of ECS in favor of pool-based generational arenas — a decision that simplifies object relationships, avoids systems scheduling complexity, and produces code that reads more naturally to Rust developers familiar with ownership semantics. The dynamic library hot-reload system for game scripts is genuinely rare in compiled-language engines and requires careful ABI design to avoid undefined behavior across reload boundaries. The standalone fyrox-ui crate is a full-featured UI toolkit usable outside the engine context, and its message-passing widget communication model differs meaningfully from reactive or immediate-mode alternatives. Shipping v1.0.0 in a real release in 2026 makes Fyrox one of very few open-source Rust game engines with a stable API commitment.

Self-Hosting

Fyrox is released under the MIT License, one of the most permissive open-source licenses available. This means you can use, modify, distribute, and sell software built with Fyrox — including commercial games and proprietary applications — without any royalty obligations or source disclosure requirements. The only condition is retaining the copyright notice. There are no copyleft implications, so integrating Fyrox into a proprietary codebase does not require open-sourcing your own game logic.

Running Fyrox yourself means taking full ownership of the build and deployment process. The engine compiles from source via Cargo and targets desktop platforms (Windows, macOS, Linux) with WebAssembly as an additional export target. There is no hosted infrastructure to manage — your game binary is self-contained. The main operational costs are compile times for a large Rust workspace and the engineering effort of keeping up with breaking changes between engine versions, though the v1.0.0 release signals a commitment to API stability going forward. Community support comes through Discord and GitHub Discussions, with documentation provided by the official Fyrox Book.

There is no commercial cloud tier, enterprise support contract, or hosted SaaS offering for Fyrox. This is a fully community-driven project funded through Patreon and Boosty donations. Teams that need guaranteed support SLAs, managed build infrastructure, or platform certification assistance will need to arrange those independently. Compared to Unity or Unreal Engine, the trade-off is lower licensing cost and full source access at the expense of commercial support channels, a marketplace ecosystem, and the tooling maturity that comes with a dedicated engineering organization.