GO — Healthy across all four use cases

• Last commit today
• 3 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 97% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Fyrox is a production-ready 2D/3D game engine written in Rust with an integrated scene editor, formerly known as rg3d. It provides rendering via GLSL shaders (246KB of shader code), physics simulation, audio via fyrox-sound, UI widgets via fyrox-ui, skeletal animation via fyrox-animation, and scriptable game logic through fyrox-scripts. The engine compiles to both native binaries and WebAssembly for browser-based games. 18-crate monorepo structure: core engine in fyrox crate, rendering abstraction in fyrox-graphics with OpenGL backend in fyrox-graphics-gl, ECS/scene graph in fyrox-core, UI system in fyrox-ui, GLSL shaders in uncovered directories, standalone editor (editor/) and editor library (editor-standalone/) both building on the engine, project-manager for game templates, and specialized modules for sound (fyrox-sound), animation (fyrox-animation), and derived macros (fyrox-core-derive). Dependencies declared in root Cargo.toml with resolver = "2" for workspace isolation.

Game developers targeting Windows/Linux/Web who want type-safe game development in Rust without C++ interop; both indie developers using the scene editor and teams building projects with the fyrox crate; contributors extending the engine's rendering, physics, or scripting systems.

Actively maintained and production-ready: the project has 10.1MB of Rust code across 18 workspace members, CI/CD via GitHub Actions (.github/workflows/ci.yml), release profiles optimized for different targets (editor-standalone, project-manager with LTO), and Discord community support. Recent activity visible in Cargo.toml workspace configuration and multiple crates at stable versions on crates.io. The 'formerly known as rg3d' note indicates long history and deliberate rebrand for maturity.

Moderate complexity risk: the monorepo spans 18 interdependent crates (fyrox-core, fyrox-graphics-gl, fyrox-material, fyrox-autotile, etc.) creating tight coupling and potential cascading breakage. GLSL shader code (246KB) is non-Rust and harder to test; no visible test directory in the top 60 files suggests tests may be sparse or embedded. Single primary maintainer model typical of Rust game engines increases bus factor; breaking changes possible across major versions.

Active development indicated by release profile definitions for CI (github-ci profile with opt-level=3, strip=symbols), editor-standalone profile tuning (opt-level=1), and project-manager stripped binary optimization (lto=true, panic=abort). Workspace includes template-core and template directories suggesting recent work on game project scaffolding. The CHANGELOG.md and GitHub Actions CI suggest regular releases and testing.

Clone the repository: git clone https://github.com/FyroxEngine/Fyrox.git && cd Fyrox. Install Rust (if not already): curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh. Build the engine: cargo build --release. To use in a game project, add fyrox = "0.x" to your Cargo.toml (version from crates.io), or locally: fyrox = { path = "./fyrox" }. Run the editor: cargo run --bin editor-standalone --profile editor-standalone.

Daily commands: For the editor: cargo run --bin editor-standalone --profile editor-standalone. For a game using fyrox crate: create a new binary project, add fyrox = { path = "./fyrox" } to Cargo.toml, then cargo run. For project-manager: cargo build --bin project-manager --profile project-manager. For CI testing: cargo build --profile github-ci. WebAssembly targets: cargo build --target wasm32-unknown-unknown (requires setup in fyrox-impl or core crate).

• Cargo.toml — Root workspace configuration defining all 17 member crates (core, graphics, UI, sound, animation, editor); essential for understanding project structure and dependencies.
• fyrox/Cargo.toml — Main engine crate aggregating graphics, UI, animation, and sound; primary entry point for game developers using the framework.
• fyrox-core/Cargo.toml — Foundation crate providing math, pooling, visitor patterns, and core abstractions that all other crates depend on.
• fyrox-graphics/Cargo.toml — Rendering backend abstraction layer; critical for understanding graphics pipeline and shader management.
• fyrox-ui/Cargo.toml — Immediate-mode UI system for in-game interfaces and editor; heavily used by both runtime and editor applications.
• editor/Cargo.toml — Scene editor application; demonstrates engine capabilities and serves as reference for complex game projects.
• ARCHITECTURE.md — High-level design documentation explaining engine layers, module organization, and design principles.

Add a New Scene Node Type

1. Define the node struct in fyrox-impl, implementing Visit trait for serialization (fyrox-impl/src/scene/node/<your_node_type>.rs)
2. Register the node in the scene graph by adding to node factory in scene module (fyrox-impl/src/scene/mod.rs)
3. Expose via public API in fyrox/src/lib.rs (fyrox/src/lib.rs)
4. Add editor UI representation in editor property panel handlers (editor/src/inspector/mod.rs)

Add a New UI Widget

1. Create widget struct implementing Widget trait in fyrox-ui (fyrox-ui/src/widget/<your_widget>.rs)
2. Add builder pattern struct for ergonomic construction (fyrox-ui/src/widget/<your_widget>.rs)
3. Register in widget module exports and builders module (fyrox-ui/src/lib.rs)
4. Add editor widget creation button in editor's widget creation menu (editor/src/ui/mod.rs)

Add a New Material Property Type

1. Define parameter type implementing MaterialProperty in fyrox-material (fyrox-material/src/lib.rs)
2. Create corresponding shader uniform handler in graphics backend (fyrox-graphics-gl/src/material.rs)
3. Add inspector property UI in editor's material inspector (editor/src/inspector/property_editors/material.rs)
4. Update shader templates to expose the new parameter (fyrox-material/src/shaders/<shader_type>.glsl)

Add a New Asset Format Loader

1. Implement ResourceData trait in fyrox-resource (fyrox-resource/src/lib.rs)
2. Create loader struct implementing ResourceLoader trait (fyrox-resource/src/loaders/<format_name>.rs)
3. Register loader in resource manager factory (fyrox-resource/src/manager.rs)
4. Add build-time asset compilation if needed (fyrox-build-tools/src/lib.rs)

• Rust — Memory safety without garbage collection, zero-cost abstractions, and strong concurrency guarantees essential for real-time 3D rendering and multi-threaded asset loading.
• OpenGL 3.3+ via fyrox-graphics-gl — Wide cross-platform support (Windows, macOS, Linux, WebGL) while providing modern programmable pipeline without high-level API overhead.
• Immediate-mode UI (fyrox-ui) — Simplifies editor UI logic, enables rapid iteration on editor features, and provides flexible in-game UI for games without retained-state complexity.
• Visitor pattern for serialization — Decouples serialization from data structures, enabling schema evolution, multiple format support (RON, binary), and procedural macro-driven code generation.
• Hot-reloadable scripts via fyrox-dylib — Reduces edit-compile-run iteration time for game logic, critical for rapid prototyping and content creation workflows.

• Workspace with 17 separate crates instead of monolithic crate

  • Why: Allows independent versioning, optional features, parallel compilation, and reuse in non-game contexts (e.g., fyrox-math as standalone).
  • Consequence: Higher complexity for users importing multiple crates; requires careful dependency management to avoid circular dependencies.

• Immediate-mode UI over retained-mode widget tree

  • Why: Stateless rendering simplifies editor architecture and enables radical UI changes per frame without state reconciliation.
  • Consequence: Less efficient for static UIs; higher CPU cost for complex layouts, mitigated by caching render targets.

• Abstract graphics API (fyrox-graphics) with pluggable backends

  • Why: Future-proofs against graphics API changes (e.g., Vulkan, Metal) and supports headless rendering.
  • Consequence: Additional abstraction layer adds ~10-15% overhead vs. direct API calls; currently only OpenGL backend production-ready.

• Async resource loading with explicit caching

  • Why: Prevents frame drops during asset loading; enables streaming large scenes.
  • Consequence: Developers must handle async resource availability; simple cache eviction policies may cause stutters under memory pressure.

• Script hot-reload via dynamic libraries (fyrox-dylib)

  • Why: Near-instant iteration without full engine restart; preserves runtime state.
  • Consequence: Symbol

No obvious environment variables documented in top-level files (check CONTRIBUTING.md and ARCHITECTURE.md for OS-specific build requirements). GLSL shader compilation happens at runtime or build-time depending on backend; shader errors may not surface until runtime or editor scene load. The 18-crate workspace uses resolver = "2" which requires Rust 1.51+; older toolchains will fail silently. Editor-standalone and editor binaries are separate targets; the editor/ crate is a plugin/library while editor-standalone is the runnable executable—using wrong target results in missing binaries. Project uses custom profiles (editor-standalone, project-manager, github-ci) so cargo build without --profile may not match CI behavior. WebAssembly support likely incomplete; check fyrox-impl and fyrox/Cargo.toml for wasm32 feature gates before assuming browser deployment works.

• Entity Component System (ECS) — Fyrox-core implements ECS for decoupled game logic; understanding ECS composition over inheritance is essential for writing scalable game systems in Fyrox
• Scene Graph / Spatial Node Hierarchy — Fyrox-graph provides hierarchical scene representation (parent-child transforms, local/global space); critical for editor workflows and 3D/2D node placement
• GLSL Shader Compilation and Hot-Reload — 246KB of GLSL code is compiled by fyrox-graphics-gl; understanding shader stages (vertex, fragment, geometry) and material property binding is necessary for custom rendering
• Resource Streaming and Asset Loading — Fyrox-resource manages async texture, mesh, and script loading; necessary for understanding how large projects handle memory and load times efficiently
• Skeletal Animation and Blend Spaces — Fyrox-animation provides skeletal rigging, keyframe interpolation, and blend trees; essential for character animation and state machine-driven motion
• Rust Procedural Macros and Derive Macros — Fyrox-core-derive provides derive(Visit, Clone, etc.) macros for serialization and reflection; understanding macro-generated code is key to extending core types
• WebAssembly (wasm32) Compilation and Browser Embedding — Fyrox targets wasm32-unknown-unknown for browser deployment; understanding wasm feature gates, JS interop, and DOM canvas binding is necessary for web game deployment

• bevyengine/bevy — Alternative Rust game engine with ECS architecture; both target similar use cases (indie 2D/3D games) and Rust ecosystem, making it a direct competitor and learning reference
• amethyst/amethyst — Predecessor Rust game engine using data-driven ECS design; Fyrox borrowed architectural concepts from Amethyst and the community (see Erlend Sogge Heggen sponsor from Amethyst)
• gfx-rs/gfx — Low-level Rust graphics abstraction layer; Fyrox's fyrox-graphics could be ported to gfx instead of direct OpenGL to support more backends (Vulkan, Metal, DX12)
• FyroxEngine/Fyrox-demo-projects — Official example games and demo projects; running source for each demo shows engine capabilities and serves as templates for new projects
• FyroxEngine/Fyrox-book — Official tutorial and documentation repository; where users and contributors learn engine API, architecture, and best practices (linked in README)

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add missing CI workflow for WASM/WebGL target builds

The repo has a comprehensive CI pipeline (.github/workflows/ci.yml) but given Fyrox supports multiple platforms and has graphics modules (fyrox-graphics-gl, fyrox-graphics), there's no documented WASM compilation check. Many Rust game engines struggle with WASM builds breaking silently. Adding a CI job to verify fyrox-core and fyrox-ui compile to wasm32-unknown-unknown would catch regressions early and unlock web game development.

• [ ] Review .github/workflows/ci.yml to understand existing CI matrix
• [ ] Add a new job targeting wasm32-unknown-unknown that builds fyrox-core and fyrox-ui crates
• [ ] Ensure web target-specific features are conditionally compiled (e.g., graphics backends)
• [ ] Document the WASM build process in CONTRIBUTING.md with any platform-specific setup needs

Add integration tests for scene serialization/deserialization

With 20+ workspace members and a scene editor (editor/), the engine must reliably serialize/deserialize game scenes. The file structure shows extensive editor resources but no visible tests directory for scene I/O. Testing scene round-trips (save → load → verify) would catch data loss bugs early and ensure editor-generated content remains portable across versions.

• [ ] Create tests/ directory at repo root with fyrox_scene_integration_tests crate
• [ ] Write tests that create sample scenes programmatically with various node types (meshes, lights, physics)
• [ ] Test serialization to the editor's native format and verify deserialization produces identical scenes
• [ ] Run tests in CI by adding test invocation to .github/workflows/ci.yml for this new crate

Add architecture-specific performance benchmark suite

ARCHITECTURE.md exists but there are no visible benchmarks for core operations (physics, rendering, scene graph queries). The workspace includes fyrox-graph, fyrox-math, and fyrox-animation—all performance-critical—but no benches/ structure. Adding Criterion benchmarks for these modules would help maintainers catch performance regressions and guide optimization efforts.

• [ ] Create benches/ directory and add Criterion benchmark harness to Cargo.toml
• [ ] Write benchmarks for fyrox-graph node traversal, fyrox-math matrix/vector ops, and fyrox-animation blend operations
• [ ] Add benchmark results to ARCHITECTURE.md documenting baseline performance on reference hardware
• [ ] Integrate benchmark runs into CI (optional: only on releases or manual dispatch to avoid CI bloat)

• Add integration tests for fyrox-material module: No visible test directory for fyrox-material/src in file list. Create tests/material_tests.rs covering material loading, property setters, and shader binding. Helps catch regressions and improves test coverage visibility.
• Document required Rust version and platform-specific dependencies: README mentions building but doesn't specify minimum rustc version (resolver v2 requires 1.51+), OpenGL driver version, or Linux dependency packages (libxcb, libxrandr, etc.). Add a 'Building' section in CONTRIBUTING.md with exact requirements.
• Extract shader build examples from fyrox-graphics-gl into docs/: The 246KB of GLSL code is unmaintained in the file list. Create docs/shader-compilation.md explaining how shaders are compiled, bundled, and loaded at runtime; include a minimal example shader. Improves contributor onboarding for rendering work.

The Fyrox engine repository demonstrates reasonable security practices with proper use of Cargo profiles for different build contexts. However, there are opportunities for improvement: (1) debug symbols are retained in release builds, increasing attack surface, (2) build profile consistency could be better enforced across multiple binaries, and (3) security documentation and policies are not visible. The codebase itself appears to be Rust-based, which provides inherent memory safety benefits. No hardcoded secrets, obvious injection vulnerabilities, or Docker misconfigurations are visible in the provided file structure. The main recommendations are to tighten build configurations and establish clear security disclosure policies.

• Medium · Workspace with Multiple Binary Outputs — Cargo.toml (workspace configuration). The workspace contains multiple binary targets (editor, editor-standalone, project-manager) with different security profiles. The 'github-ci' profile uses 'opt-level = 3' with 'debug = false' but retains symbol information, which could expose internal details. Additionally, inconsistent optimization levels across profiles may lead to unpredictable security behavior. Fix: Standardize security profiles across all binaries. Ensure production binaries have 'strip = true', 'lto = true', and 'panic = abort'. Consider using separate, well-documented profiles for development vs. production.
• Medium · Debug Information Retained in Release Builds — Cargo.toml - [profile.release] section. The release profile includes 'debug = true', which retains debug symbols in compiled binaries. This increases binary size and could potentially expose sensitive information about internal structure to reverse engineering attacks. Fix: Set 'debug = false' in the release profile, or use 'strip = true' to remove symbols after compilation. Reserve 'debug = true' only for development and testing builds.
• Low · Lack of Visible Security Policy — Repository root. No SECURITY.md or security policy documentation is visible in the file structure. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file that documents the vulnerability disclosure process, supported versions for security updates, and contact information for security reports.
• Low · IDE Configuration Files in Repository — .idea/ directory. The .idea directory (IntelliJ IDEA configuration) is committed to the repository. While not a direct security risk, this can expose development environment details and IDE-specific secrets if not properly managed. Fix: Add .idea/ to .gitignore to prevent IDE-specific configurations from being committed. Only commit shared project settings through workspace.xml if necessary, and exclude sensitive IDE settings.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/FyroxEngine/Fyrox shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live FyroxEngine/Fyrox repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/FyroxEngine/Fyrox.

What it runs against: a local clone of FyroxEngine/Fyrox — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in FyroxEngine/Fyrox | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of FyroxEngine/Fyrox. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/FyroxEngine/Fyrox.git
#   cd Fyrox
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of FyroxEngine/Fyrox and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "FyroxEngine/Fyrox(\\.git)?\\b" \\
  && ok "origin remote is FyroxEngine/Fyrox" \\
  || miss "origin remote is not FyroxEngine/Fyrox (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "fyrox/Cargo.toml" \\
  && ok "fyrox/Cargo.toml" \\
  || miss "missing critical file: fyrox/Cargo.toml"
test -f "fyrox-core/Cargo.toml" \\
  && ok "fyrox-core/Cargo.toml" \\
  || miss "missing critical file: fyrox-core/Cargo.toml"
test -f "fyrox-graphics/Cargo.toml" \\
  && ok "fyrox-graphics/Cargo.toml" \\
  || miss "missing critical file: fyrox-graphics/Cargo.toml"
test -f "fyrox-ui/Cargo.toml" \\
  && ok "fyrox-ui/Cargo.toml" \\
  || miss "missing critical file: fyrox-ui/Cargo.toml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/FyroxEngine/Fyrox"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.