Flame or plain widgets? How we decided across seven games

In this post

1. The criterion, applied
2. What our portfolio actually shows
3. Why the idle games ended up on Flame
4. Where plain widgets win easily
5. Where Flame wins, and wins big
6. The mental model that works
7. When even Flame is not enough
8. The mistake we made
9. Summary

Every discussion about games in Flutter collapses into the same binary question: Flame or no Flame?

The binary framing is poor because the answer depends on a property of the game that is almost never named. After seven games, our criterion fits on one line:

Does the game state change per frame or per event?

Everything else follows.

The criterion, applied

A game that changes per event has stable state between interactions. Nothing happens until someone touches the screen: puzzles, cards, merge, turn-based and most idle games.

A game that changes per frame has a simulation running continuously — position, velocity, collision. It keeps happening with your finger still.

Note that "per event" does not mean static. An idle game accrues resources over time — but that is a function of the clock, evaluated when the screen needs to draw, not a 60-frames-per-second simulation.

What our portfolio actually shows

This is where the post becomes more useful than a tidy rule, because the numbers do not obey the rule as neatly as we would like. Seven games:

Five of seven on Flame. Exactly one on plain widgets. If the criterion were "idle means widgets", four of those rows would be wrong.

Why the idle games ended up on Flame

Godforge, Zombounty and Mewtopia are idle games — by the stated criterion they should be plain widgets. They are not. That is not incoherence: it is that "idle" describes the economy, not the screen.

In an idle auto-battler the player makes no decisions during the fight. But the fight happens: the hero shoots, the zombie walks, damage numbers pop, the boss has a bar that drains. That is per-frame simulation with many objects at once — the original criterion, applied to the right part of the game.

What confuses is the genre label. "Idle" describes the progression loop: you close the app and keep earning. It says nothing about how many sprites move on screen while it is open.

Kombate is the only one on plain widgets and the reason is exact: turn-based board strategy, Stratego-style. A piece moves only when someone moves it. There is no frame in which anything changes on its own — not in progression, not in combat.

Where plain widgets win easily

For event-driven games, using Flame adds a parallel system you do not need.

Responsive layout for free. A grid that adapts to any screen size is the problem Flutter solves better than anything. Reimplementing it inside a canvas is pure work.

Accessibility and input. Touch, drag, focus, screen readers — all already work. Inside a canvas none of it exists until you build it.

One system. Menu, store, settings and the game share widgets, theme and navigation. No bridge between two worlds.

Tooling. Real hot reload, the widget inspector, everything that already exists.

Kombate is the clearest example on our list: a board, pieces, setup, turn-based combat, an online mode and a bot. None of that is per-frame simulation. It is state, rules and transitions — and the UI is a responsive grid, which is the house speciality.

The instructive counterexample is Mewtopia Merge, with its 5×6 grid, drag-and-drop merging and passive income. From the description it is the most obvious plain-widget candidate in the entire portfolio. It runs on Flame — and in hindsight it is the strongest candidate for having adopted an engine as a precaution, which is exactly the mistake described at the end of this post.

Where Flame wins, and wins big

When state changes per frame, writing it by hand means reimplementing four things:

1. 1. A game loop with delta time. An AnimationController gives you a

per-frame trigger, but you still need an update model with elapsed time, or speed changes with the device.

1. 2. A component tree with lifecycle. Objects that spawn, update, collide and

die. Without structure that becomes a list full of conditionals.

1. 3. Collision detection. The item that looks simplest and consumes the most

time. Continuous collision across many objects is not a rectangle if.

1. 4. Camera and world coordinates. Separating world space from screen space is

what enables camera, zoom and parallax.

Doing all four by hand is writing Flame with fewer testing hours behind it.

Our endless flyer sits on that side: continuous flight, approaching obstacles, bosses, collisions throughout. There is no reasonable plain-widget version of it.

The mental model that works

The confusion comes from treating Flame as an alternative to Flutter. It is not — GameWidget is a widget.

MaterialApp
 ├─ MenuPage        (ordinary Flutter)
 ├─ StorePage       (ordinary Flutter)
 └─ MatchPage
     └─ GameWidget  (Flame starts here)
         └─ HUD     (can be Flutter again, on top)

That dissolves the false choice. You do not decide for the whole app; you decide for the match screen. Menu, settings, store and leaderboard stay Flutter in every scenario — and they are most of the screens.

When even Flame is not enough

There is a third step, and it is about tooling, not rendering.

When the game needs physics with bodies and materials, tilemaps, a scene editor and a level-authoring flow usable by someone who does not program, the conversation changes. What is missing is not a rendering library: it is an authoring environment.

The criterion is short:

Is anyone going to draw levels in this game?

If yes, you need an editor. Levels written in code are sustainable up to the third; from the tenth on it is suffering.

The mistake we made

Worth recording, because it is the most common one: starting with Flame just in case.

The reasoning sounds prudent — "what if we need motion later?". In practice the cost arrives before the benefit: you enter a custom coordinate system, lose responsive layout, and reimplement buttons and lists inside a canvas for a need that may never come.

The cheap path is the opposite. Start with widgets and move the match screen to Flame if it needs it. The migration is local, because only that screen changes.

That asymmetry is the whole argument. Going from widgets to Flame costs one screen. Going from Flame back to widgets costs the layout, the input handling and the accessibility you reimplemented inside a canvas — which is why nobody does it, and why "we can always simplify later" is not true in this direction.

Summary

• The question is whether state changes per frame or per event. Everything else

follows.

• Ask it about the screen, not the game. "Idle" describes progression, not

rendering — five of our seven games use Flame, three of them idle.

• Per event: plain widgets. You keep responsive layout, accessibility, tooling and

a single system.

• Per frame: Flame. You avoid reimplementing a delta-time loop, component

lifecycle, collision and camera.

• Flame is a widget, not a Flutter replacement. The decision is per screen.
• If somebody is going to draw levels, what is missing is an editor — and that is

a full-engine conversation.

• Do not adopt an engine as a precaution. The migration is cheap in one direction

only.

Frequently asked questions

Does Flame replace Flutter?

No. Flame runs inside Flutter, in a widget. That is its biggest advantage: menus, store and settings screens stay ordinary Flutter, with the widgets you already know.

Can you build a game with just an AnimationController?

You can, and it is the right call for turn-based, puzzle and card games — the ones that only change when someone taps. Be careful with the 'idle' label: it describes progression, not the screen. An idle auto-battler has animated combat with many objects, and that is a per-frame loop like any other.

When does Flame start to pay off?

When you need per-frame updates over many objects, continuous collision detection or fine camera control. If your game has those three, writing it by hand is reimplementing Flame worse.

And when is Flame not enough?

When the game needs physics bodies, tilemaps, a scene editor and level authoring tools. Then the conversation is not about a library, it is about a full engine — and leaving Flutter is on the table.