Fluorite Game Engine

Fluorite is a 3D game engine built for deep integration with Flutter, positioned as the first console-grade engine tailored to the Flutter ecosystem. It lets developers write game logic entirely in Dart while a high-performance C++ core handles the heavy lifting, so teams can stay productive in a familiar language without giving up low-level performance.

The engine's headline widget is FluoriteView, which renders game scenes directly inside a Flutter widget. It supports multiple simultaneous 3D scenes and shares state between game entities and the surrounding UI components, effectively blending a game world with a normal Flutter app in one screen.

It is documented and distributed from the official site at fluorite.game. For Flutter developers who want 3D capability, depth of integration, and a Unity-like ambition without leaving Dart, Fluorite is the most direct answer within the Flutter world.

• High-performance ECS core - a C++ entity-component-system core maximizes speed even on low-end devices
• Dart game logic - write gameplay in Dart and rely on the familiar Flutter developer ecosystem
• Console-quality graphics - powered by Google's Filament and Vulkan, with realistic lighting and advanced post-processing
• Interactive 3D zones - define clickable areas directly in Blender and trigger them from code for 3D menus and interactions
• FluoriteView widget - render multiple simultaneous 3D scenes inside a single Flutter view
• Shared state - seamlessly pass state between game entities and UI components, the Flutter way
• Instant hot reload - update game code or assets and see changes without restarting

Fluorite separates the screaming-fast internals from the developer-facing API. The simulation and rendering run in a C++ core built around an entity-component-system (ECS), a pattern well suited to data-oriented game code because it keeps memory layout cache-friendly and predictable across CPU cores.

Gameplay is expressed in Dart on top of that core. This hybrid gives developers the safety and tooling of Dart while letting the engine hit console-class performance on modest hardware. FluoriteView is the glue: a Flutter widget that hosts one or more 3D scenes and keeps a live bridge between entity data and the normal widget tree, so HUDs and menus are just Flutter widgets reading game state.

Flutter UI (widgets, HUD, menus)
        |
   FluoriteView (one or more 3D scenes)
        |
   Shared state bridge
        |
   Dart game logic
        |
   C++ ECS core + Filament/Vulkan rendering

Multiple FluoriteView instances can render separate 3D scenes simultaneously, and because state flows through normal Dart objects, a change in a game entity immediately re-renders the relevant Flutter UI with no manual synchronization step.

Fluorite builds its rendering stack on Google Filament, a physically based (PBR) renderer designed for mobile and embedded devices, driving the graphics API through Vulkan. This combination targets console-quality visuals: realistic lighting, material models, shadow mapping, and a library of post-processing effects.

• PBR materials - metalness/roughness workflows familiar to modern renderers
• Realistic lighting - directional, point, and spot lights with image-based lighting support
• Advanced post-processing - tone mapping, bloom-style effects, and camera effects for a polished final frame
• Vulkan backend - a low-level GPU API for efficient draw call throughput on supported devices

The intent is to close the gap between Flutter-centric 2D tooling and native game engines, giving Flutter developers a path to 3D scenes that look like they came from a dedicated engine rather than a widget toolkit.

The integration model is intentionally Flutter-first. Instead of a separate editor runtime, Fluorite exposes 3D scenes through widgets, so a typical project adds the engine as a dependency and places a FluoriteView where the game should appear:

// Add the engine to pubspec.yaml, then mount a scene inline:
FluoriteView(
  scenes: [myGameScene],   // one or more 3D scenes
  onSceneReady: (scene) {
    // scene is now live and can read/write game state
  },
)

Because the rest of the app is ordinary Flutter widgets, a scoreboard, inventory, or pause menu can sit beside the view and react to entity state through normal Flutter reactivity (setState, streams, or a state-management package) with no engine-specific glue.

Fluorite is built around a smooth content pipeline. Artists model and lay out scenes in Blender, where they can also define interactive "3D zones". These zones are clickable regions that developers reference from Dart code, which makes 3D menus, hotspots, and object-picking natural to author without hand-placing invisible colliders.

1. Author in Blender - model the scene and mark interactive 3D zones
2. Import into Fluorite - bring the asset into the engine and its editor for wiring
3. Logic in Dart - attach behaviors to entities and respond to zone triggers in code
4. Hot reload - edit game code or assets and watch changes appear instantly without a rebuild

The instant hot reload is a major productivity lever for a 3D pipeline. Tuning lighting, tweaking a zone size, or adjusting a physics parameter no longer requires a full restart, so iteration speed approaches what Flutter developers already enjoy for widgets.

Fluorite competes both with Flutter-native 2D engines and with full standalone 3D engines. Its differentiator is 3D quality plus tight Flutter integration, in Dart.

Criteria	Fluorite	Flame	Unity	Godot
Dimensions	3D	2D	2D and 3D	2D and 3D
Language	Dart + C++ core	Dart	C#	GDScript / C#
Flutter integration	Native, via FluoriteView	Native, via GameWidget	None	None (export only)
Visual editor	Blender + engine editor	Code-first	Full editor	Full editor
Rendering	Filament + Vulkan PBR	Flutter canvas	Built-in render pipelines	Vulkan / Metal
Target	Flutter 3D games and apps	Flutter 2D games	Broad commercial games	Indie and open games

Fluorite vs Flame: Flame is the mature 2D choice and has a far larger community, docs, and package ecosystem. Fluorite steps in only when you need real 3D scenes, PBR rendering, and Blender-authored interactivity while keeping game logic in Dart. For a 2D game, Flame is simpler and more battle-tested; for 3D, Fluorite is the Flutter-native answer.

Fluorite vs Unity: Unity is unmatched for large commercial titles, asset store economics, and console distribution. Fluorite cannot replace that ecosystem, but it avoids Unity's licensing model and lets a Flutter shop build 3D experiences without switching languages or learning a separate editor workflow.

Fluorite vs Godot: Godot is a polished open-source creator with a mature editor and broad feature set. Fluorite's advantage is depth of Flutter integration: scenes live inside ordinary widgets and share state with UI in Dart, which Godot cannot offer since it is a standalone engine you export from.

Fluorite positions itself inside the broader Flutter game ecosystem, sitting alongside 2D engines like Flame and Rive-animated UI as a higher-fidelity 3D layer. Its official home and documentation live at fluorite.game, where the engine, editor, and asset pipeline are introduced.

Because it leans on established open components, developers can build on a familiar foundation: Dart and Flutter for application code, Google Filament for rendering, Vulkan for the GPU backend, and Blender for content authoring. This reuse lowers the barrier for Flutter-first teams that want console-grade 3D without adopting a completely separate engine and ecosystem.