# Flame: a Flutter-based game engine for Dart developers

> Flame is a Flutter-based game engine distributed as a pub package. It suits Dart developers building 2D games who want Flutter's rendering and tooling rather than a separate runtime.

**flame-engine/flame** — A Flutter based game engine.

- Repository: https://github.com/flame-engine/flame
- Website: https://flame-engine.org
- Stars: 10,769 · Forks: 1,044
- Language: Dart
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/flame-engine-flame

## The gap Flame fills between Flutter and a game engine

Flutter gives you a rendering pipeline, an input system and a widget tree, but it gives you no game loop, no scene graph and no notion of a sprite that updates sixty times a second. Writing those yourself is the first week of any Flutter game project, and the work is repetitive: a ticker, a list of objects to update, a list to render, a way to pause when the app goes to the background. Flame's stated goal is to supply "a complete set of out-of-the-way solutions for common problems that games developed with Flutter might share", and the feature list maps directly onto that: a game loop, a component/object system, effects and particles, collision detection, gesture and input handling, images, animations, sprites and sprite sheets, plus general utilities.

The audience is narrow and identifiable. If you are a Dart developer who wants to ship a 2D game to mobile, web or desktop through the same build you already use for Flutter apps, Flame removes the boilerplate without asking you to learn a new language or a new rendering backend. If you want a visual level editor, a 3D pipeline, or an engine with a scripting language layered on top, the README points elsewhere by omission: it describes libraries and packages, not an editor.

## How the component tree and game loop actually fit together

Flame's architecture is a component system, abbreviated FCS in the README, sitting on top of Flutter's rendering. A game is a component that owns other components. Each component has an update step and a render step, and the engine drives both on a loop. That is the same shape as Flutter's widget tree, which is why the mental transfer is cheap for Flutter developers: a component that holds children behaves like a widget that holds children, except the update method runs every frame instead of only on rebuild.

Collision detection, input handling and animation are components or mixins layered onto that tree rather than separate subsystems with their own lifecycles. The rendering itself is Flutter's, so a Flame game is ultimately a Flutter app drawing through the canvas API. That is the central design decision and it cuts both ways. You inherit Flutter's platform support and hot reload, and you also inherit Flutter's constraints, including its rendering behaviour on low-end devices and the size of a Flutter build.

Extension happens through bridge packages rather than a plugin protocol of Flame's own. The README lists flame_audio for AudioPlayers, flame_bloc for Bloc, flame_fire_atlas for FireAtlas, flame_forge2d for Forge2D (a Box2D physics engine), flame_gamepads, flame_isolate, flame_lint, flame_lottie, flame_network_assets, flame_rive, flame_svg, flame_texturepacker and flame_tiled. Each wraps another Dart package in Flame components and helpers, so the integration surface is Dart code you can read, not a binary plugin boundary.

## Installing Flame and getting a first game on screen

Flame is distributed on pub.dev as the package flame, so installation is a pub dependency rather than a binary download or an installer. The README links the Pub badge and the API reference on pub.dev, and the documentation site at docs.flame-engine.org is where the tutorials live. The repository itself is organized as a monorepo: the top level holds packages/, examples/, doc/, scripts/, a pubspec.yaml and a CHANGELOG.md, and the README notes the project is maintained with melos.

The README does not print an installation snippet, so the dependency name to add is the package name it links on pub.dev, flame, and the version constraint is yours to choose. The repository's examples directory carries its own pubspec.yaml, which is the layout the maintainers use for sample code. From the project root, the pub tool fetches the dependency once it is declared:

```bash
flutter pub get
```

The README points at examples.flame-engine.org, which runs most features in the browser, and each example has a code button in the top right corner that reveals its source. That is the fastest way to see the engine running before writing anything, and the tutorials listed at docs.flame-engine.org/main/tutorials/tutorials.html are where the getting-started steps live. What you should expect from a working setup is a Flutter app whose body is the game canvas, with the component tree updating each frame.

## Where Flame stops being the right tool

The first limitation is scope. Flame is 2D. There is no 3D renderer in the README's feature list, and the bridge packages are all 2D concerns: tile maps, sprite sheets, SVG, Lottie, Rive, Box2D physics. If your game needs a 3D scene graph, Flame is the wrong starting point and no amount of bridge packages changes that.

The second is the absence of an editor. The README's feature list is a library list. There is no scene editor, no asset pipeline tool, no visual scripting described. Level design arrives through flame_tiled, which loads maps made in the external Tiled editor, and texture atlases arrive through flame_texturepacker, which loads output from the external TexturePacker tool. Both are bridges to other products, not built-in tooling. Teams that expect to iterate on levels inside the engine will be assembling their own workflow.

The third is documentation drift, and the README is explicit about it: "The documentation that resides in the main branch is newer than the released documentation on the docs website." Documentation on the site carries a version selector, so you can read the docs for the release you actually depend on, but if you follow a link into main-branch docs you may be reading about behaviour that is not in your pubspec yet. That is a real source of confusion during upgrade work.

Finally, the monorepo structure means version numbers do not move together. The recent releases show Flame itself at v1.38.2 while flame_svg is at v2.0.0. A bridge package can have a major version that has nothing to do with the core engine's version, so a constraint like "Flame 1.38" tells you nothing about which flame_svg you can use.

## Flame against a general-purpose engine like Godot

The honest alternative for a 2D game is not another Flutter package, it is a standalone engine such as Godot, which ships an editor, a scene format and its own scripting language. The difference in approach is the whole argument. Godot gives you a tool that owns the project: scenes, nodes, resources and a build pipeline all defined by the engine, with the editor as the primary interface. Flame gives you a library that lives inside your existing Flutter project, with Dart source as the primary interface and no editor at all.

That means the trade is tooling for integration. With Godot you get level editing, animation editing and a preview workflow out of the box, and you give up the ability to drop a game screen into a Flutter app, share Dart models with the rest of your codebase, or ship through the same CI that builds your other Flutter targets. With Flame you keep all of that and accept that level design, atlas packing and animation authoring happen in third-party tools or in code. If your game is a small 2D title and the rest of your product is Flutter, the integration argument usually wins. If your game is the whole product and it needs heavy content authoring, a standalone engine wins.

## Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-18. Recent releases include flame_svg v2.0.0 on 2026-08-30, Flame v1.38.2 on 2026-08-27 and Flame v1.38.1 on 2026-08-26. Release cadence is therefore current, and the project is a Flutter Favorite, a designation the README displays as a badge linking to Flutter's packages-and-plugins favorites page.

Upgrade cost is shaped by the monorepo. Because core and bridge packages version independently, an upgrade is not one version bump. You change the flame constraint, then check each bridge package you use against its own changelog, then re-read the docs at the matching version selector rather than the main-branch docs. The repository keeps a CHANGELOG.md at the top level, and the README warns that a pull request should be created from the main branch and follow the checklist in .github/pull_request_template.md, which tells you the maintainers treat main as the integration point.

Licensing is straightforward: the repository carries an MIT license. MIT permits commercial use and modification with the licence and copyright notice retained, but this is not legal advice and the LICENSE file is the authority for your situation. The bridge packages are separate pub packages with their own licences, so a dependency audit should cover them individually rather than assuming the MIT terms of the core engine apply to everything you pull in.

## Conclusion

Adopt Flame if you already write Dart and want your game to ship through the same Flutter toolchain as the rest of your app, with 2D scope and the FCS component tree matching how you think about widgets. Do not adopt it for 3D, for a non-Flutter target, or if you need an editor-driven workflow, since the README describes libraries rather than a scene editor. Before committing, verify that the bridge package you need (flame_forge2d, flame_tiled, flame_audio, flame_rive) supports your Flutter and Dart SDK versions, and check the CHANGELOG for the package you depend on, because the repository is a melos monorepo whose packages version independently.

## FAQ

### What is Flame?

Flame is described in its README as a Flutter-based game engine, written in Dart and distributed as the flame package on pub.dev. It provides a game loop, a component/object system, collision detection, input handling and sprite and animation utilities for 2D games.

### How do I install Flame in a Flutter project?

Flame is published on pub.dev as the package flame, so installation is a pub dependency rather than a binary download. The README points to docs.flame-engine.org for the full documentation and tutorials rather than repeating installation steps in the repository.

### Does Flame support 3D games?

The README's feature list covers a game loop, components, effects and particles, collision detection, input handling, images and sprite sheets, all of which are 2D concerns, and the bridge packages listed are likewise 2D (tile maps, SVG, Lottie, Rive, Box2D physics). No 3D renderer is described.

### What packages can I add to Flame for audio, physics or tile maps?

The README lists official bridge packages including flame_audio for AudioPlayers, flame_forge2d for the Forge2D Box2D physics engine, flame_tiled for Tiled tile maps, flame_svg, flame_rive, flame_lottie, flame_bloc, flame_isolate and flame_texturepacker.

### What license does Flame use?

The repository includes an MIT license. The bridge packages are separate pub packages and carry their own licences, so they should be checked individually.

## Sources

- [flame-engine/flame on GitHub](https://github.com/flame-engine/flame)
- [License: MIT](https://github.com/flame-engine/flame/blob/main/LICENSE)
- [Project website](https://flame-engine.org)
- [README](https://github.com/flame-engine/flame/blob/main/README.md)
- [Releases](https://github.com/flame-engine/flame/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flame-engine-flame