Fyrox: a general purpose game engine written in Rust

What a Rust game engine commits to

The README calls Fyrox a feature rich, production ready, general purpose 2D and 3D game engine written in Rust with a scene editor. That sentence is a claim worth taking apart, because each phrase carries weight. General purpose means it does not target a single genre or a single rendering backend. Production ready is a statement about stability rather than about features, and the 1.0.0 tag is the evidence behind it. Scene editor means there is a graphical tool in the box, not only a library you drive from your own code.

The language choice shows up in the shape of the repository. Rust has no garbage collector and no runtime, so an engine written in it has to make explicit choices about ownership across every subsystem boundary. The result here is a workspace rather than one crate, which is the practical expression of that. The README also notes the project was formerly known as rg3d, and the module prefix in the crate names still carries that history in spirit if not in letter.

The scale is worth stating plainly: 9,561 stars, 452 forks, 58 open issues, MIT licensed, last pushed on 2026-09-20. A low open issue count against that star count is a meaningful signal, because it means the repository is not sitting on a large backlog of unresolved work.

Twenty-four crates and what each one owns

The workspace manifest is the most informative file in the repository, because it names every subsystem as a separate crate and puts them in dependency order. It is worth reading as a map of the engine:

[workspace]
members = [
    "fyrox-core-derive",
    "fyrox-core",
    "fyrox-sound",
    "fyrox-ui",
    "fyrox-resource",
    "fyrox-scripts",
    "fyrox-animation",

Reading further down the list tells you how much of an engine this actually is. `fyrox-math` and `fyrox-graph` are the foundation crates. `fyrox-texture`, `fyrox-material`, `fyrox-autotile` and `fyrox-graphics` handle assets and the rendering abstraction, with `fyrox-graphics-gl` and `fyrox-graphics-wgpu` as the two concrete backends underneath, which is the interesting part: the engine carries both OpenGL and WebGPU.

The tooling crates matter as much as the runtime ones. `fyrox-build-tools` handles asset processing at build time, `fyrox-build` aside, while `editor`, `editor-standalone`, `project-manager`, `template-core` and `template` form the authoring side of the project. A `template` crate existing at all tells you new projects are generated from code in this repository rather than from a separate template repository, which keeps the starting point and the engine version in step.

Build profiles that say what the tools are for

The manifest also defines four Cargo profiles, and they reveal intent more directly than the feature list does:

[profile.project-manager]
inherits = "release"
opt-level = "z"
debug = false
strip = true
panic = "abort"
lto = true

`project-manager` is compiled for the smallest possible binary: `opt-level = "z"` optimizes for size rather than speed, symbols are stripped, panics abort instead of unwinding, and link time optimization is on. That is the profile you would choose for a tool you distribute as a bootstrap executable, which is exactly what a project manager is. It is a small detail that tells you the maintainers think about download size for their users.

The other profiles make the same kind of point. `editor-standalone` inherits from dev with `opt-level = 1`, trading some build speed for a faster editor. The release profile uses `opt-level = 3` but keeps `debug = true`, so shipped builds retain debug symbols for crash reports. And `github-ci` is a separate profile with symbols stripped and optimization turned up, which keeps continuous integration fast without shipping debug information in test artifacts.

Two rendering backends, one abstraction

The crate list contains both `fyrox-graphics-gl` and `fyrox-graphics-wgpu` sitting above a shared `fyrox-graphics` crate. For an engine at this stage of maturity that is a meaningful amount of work, because a rendering abstraction that genuinely holds across OpenGL and WebGPU is not something you can fake with a thin wrapper.

What the repository does not settle is which backend is the default for a fresh project, or how close the two are in feature coverage. The README does not mention backends at all, and neither does the manifest excerpt you can see from the repository. That question belongs to the online book, which the README links as the official Fyrox book and describes as starting with how to build and ending with tutorials.

The honest reading is that Fyrox has chosen to hold two backends rather than to pick one, and that the choice costs maintenance it is willing to pay. For a reader deciding whether to adopt it, the practical consequence is that you can target whichever your platform needs, including the modern one, without waiting for the engine to add it.

The release history and what 1.0 claims

The release list is short and recent, which for an engine project is informative. Version 1.0.0-rc.1 was published on 2025-10-21, 1.0.0-rc.2 on 2026-02-09, and 1.0.0 on 2026-03-29. Two release candidates over about five months before the stable tag is a cautious path to 1.0 rather than a rushed one, and it gives the maintainers a window in which API-breaking changes were still acceptable.

Each release entry points to the same download page at fyrox.rs/download.html and to per-release notes on the project's blog. That means the changelog detail lives off the repository. The repository does carry a `CHANGELOG.md` at its root, and there is also an `ARCHITECTURE.md`, which is the more interesting of the two for anyone planning to contribute, because a codebase this size needs its layering written down somewhere.

The 1.0 tag is the thing to anchor a decision on. An engine that has published 1.0 has told its users that the API is stable enough to build against, which is a stronger commitment than a 0.x version number ever carries. Anyone arriving after 2026-03-29 is working against that settled API rather than against something in flux.

Where the learning material actually is

The repository is light on prose and the project is upfront about it. The README's learning section is a single paragraph pointing at the book hosted at fyrox-book.github.io, described as comprehensive and running from how to build through tutorials. Examples are handled the same way: you can run them directly in a browser, the full list of demos is on fyrox.rs/examples.html, and the source for those demos lives in a separate repository at FyroxEngine/Fyrox-demo-projects.

That split is a real characteristic of how Fyrox is developed, and it cuts both ways. The separation keeps demo projects from bloating the engine repository and lets them evolve on their own schedule, but it also means the most realistic usage examples are not in the tree you are reading. The repository does contain a few examples of its own, including `examples/2d.rs` and `examples/navmesh.rs`, plus an `examples/data/` directory, so there is something to start from.

Community support runs through Discord and GitHub Discussions, and the README calls contributions very welcome while pointing at a good first issue label as the place to start. Funding is handled through Boosty and Patreon, and JetBrains provides an open source licence for their products, which the README notes as having helped development considerably.

Editorial conclusion

Fyrox's strongest argument is structural rather than feature count: a game engine in which rendering, animation, sound, UI, resources, autotiling and math are separate crates, each publishable and each usable on its own. Version 1.0.0 shipped on 2026-03-29 after two release candidates, which means the project considers its API settled, and the 58 open issues on a repository with 9,561 stars suggest a project that finishes what it takes. The weaker point is documentation depth in the repository itself, since the substance lives in the online book. Start with the `fyrox` crate and the `template` project, read `ARCHITECTURE.md` before contributing, and treat the demo projects repository as the real usage reference.

Frequently asked questions

Official sources

1. FyroxEngine/Fyrox on GitHub
2. License: MIT
3. Project website
4. README
5. Releases