flutter/games: official Flutter templates for casual games

A template repository, not a game engine

flutter/games describes itself as the home of the Flutter Casual Games Toolkit and other Flutter gaming templates, and the README says it is home to the official code for the Flutter Casual Games Toolkit and other Flutter gaming templates. The site linked from the README is flutter.dev/games.

The important thing to understand is what kind of artefact this is. It is a collection of complete project directories, each of which you copy and then write your game inside. There is no engine here, no entity component system, no physics library, and no plugin API for the toolkit. The templates give you a project structure and, in the samples, working examples of the pieces that are awkward to get right yourself.

The README splits the contents into two categories, and the distinction is useful.

Templates are a small number of starting points for your game project, intended to give you a simple project structure on top of which you can build your game. They differ to accommodate different game types, from the simplest casual games through drag and drop board games to 2D platformers.

Samples are intended to show functionality beyond the basics, such as multiplayer or ads integration.

So the templates answer the question of how to lay out a Flutter game project, and the samples answer the question of how to do the one or two things you probably cannot find a tutorial for. The directory structure the README shows makes the split concrete:

.
├── templates
│   ├── basic
│   ├── card
│   └── endless_runner
└── samples
    ├── ads
    ├── multiplayer
    └── ...

The repository root confirms the shape: a templates directory, a samples directory, a LICENSE, an AUTHORS file, a CONTRIBUTING.md, and three CI shell scripts, flutter_ci_script_beta.sh, flutter_ci_script_shared.sh and flutter_ci_script_stable.sh, which tells you the samples and templates are exercised against both the stable and beta Flutter channels.

Getting a project with sample_downloader

The easiest way to get any of the samples and templates is to install the sample_downloader tool from pub.dev and use it.

On the command line, with the Flutter SDK installed, you activate it globally:

dart pub global activate sample_downloader

Then, from any directory, you run the newly installed tool and follow its instructions:

sample_downloader

The two step design is worth noting. The activation is a one time global install of a Dart package, and the tool then runs interactively and asks which project you want, presumably where to put it. That is a better experience than cloning a monorepo with several complete Flutter applications in it and deleting the ones you do not want, and it is also the reason the README calls it the easiest way.

The tool itself is a separate package on pub.dev, not part of this repository. That is worth knowing for two reasons. First, the version of the tool you get is whatever is current on pub, so a change in its behaviour is not tied to a change in this repository. Second, a tool that installs code for you is something to run with the same care as any other code you fetch from the network.

The Flutter SDK is a hard prerequisite either way, and the README says so up front, telling newcomers to install the Flutter SDK first, with the installation instructions linked.

The manual path, including the partial clone trick

If you would rather not use the tool, the README documents a manual route, and it is the part of the documentation with the most practical detail.

You clone the repository, and to minimize download size you can use a partial clone:

   git clone --filter=blob:none https://github.com/flutter/games.git

The alternative is to download the ZIP file from the archive of the main branch and uncompress it on your workstation. The partial clone matters more than it might look, because the repository holds several complete Flutter applications, and each one carries its own dependency tree and platform folders. Fetching only the blobs you actually need is a meaningful saving.

Then you change into the project you are interested in:

   cd templates/card

The README notes you can alternatively copy the contents of a project somewhere else and change to that directory, which is the route most people take since a template is going to be modified heavily anyway.

Step three is optional renaming with the rename tool from pub.dev, and step four is to open the project in your editor and get on with it.

So the manual path is: clone, cd into a directory, optionally rename, open. There is no build step, no code generation and no configuration to fill in, which is a sign of what these projects are. They are deliberately unopinionated, and the value is in the structure rather than in machinery.

Templates for three game shapes, samples for the hard parts

The three templates named in the tree cover three recognisably different kinds of game, and picking the wrong one costs more than picking a framework.

The basic template is the floor. The card template is for a card game. The README's own summary of the range runs from the simplest casual games through drag and drop board games to 2D platformers, and the directory names line up with that description. The endless runner and the card game are also the two genres where the interaction model is fixed enough that a structure is worth copying, while a platformer has more variation in level structure.

The samples are where the repository earns its keep. The samples directory in the repository listing holds ads, crossword and multiplayer, and the README names ads integration and multiplayer as the two things the samples exist to demonstrate. The crossword sample is not in the README tree diagram, which shows an ellipsis, but it is present in the repository layout.

Ads and multiplayer are the two problems that are genuinely hard to get right in a browser game. Ad integration is hard because the ad networks have their own SDKs, their own consent requirements and their own build step requirements, and a template that already has a working integration saves you from discovering those constraints in the middle of a release. Multiplayer is hard because the transport, the room model and the state synchronisation are all decisions, and a working example lets you start from a decision rather than from a blank file.

That is a coherent editorial position. The templates solve the boring 80 percent, the samples solve the remaining 20 percent that people get stuck on, and the Flutter SDK and the ecosystem libraries are left to you.

What the samples are not, and the limits of the approach

Several limitations follow from the design, and they are worth being blunt about.

First, this is a collection of starting points, not a maintained framework. There is no API, no version compatibility policy and no plugin ecosystem of its own. The samples reference the wider Flutter packages, and those move on their own schedule. When a package the multiplayer sample depends on changes its API, the sample needs updating, and the update lands in this repository as an ordinary commit rather than as a coordinated release.

Second, and this is the practical trap, browser games have a hard constraint that a Flutter application does not. The code runs in a browser, and a browser game is judged on how quickly it loads and how it behaves on a mid range machine. A template that gives you a nice project structure does not by itself make your game fast, and the samples do not claim to. Anyone using this as a base needs to measure and profile for the web target rather than assuming the desktop behaviour carries over.

Third, the licence. The repository licence is recorded as a custom one that GitHub cannot categorize, and there is a LICENSE file at the root. That is a different situation from the familiar MIT or BSD headers you would see on most Flutter sample code, and it matters more than usual here because the intended use is to copy the code into a product. Read the LICENSE file and the AUTHORS file before you ship anything derived from a template, and check the terms of whatever ad SDK the ads sample integrates rather than assuming the repository terms cover the ad network's terms.

Fourth, the samples are reference implementations, not battle tested product code. The multiplayer sample demonstrates the mechanism; it does not include the reconnection logic, the cheat handling and the load testing that a real multiplayer game needs. Treat the code as an example to learn from and then rewrite the parts that matter.

Where to get help, and where to file bugs

The support section is short and points somewhere specific.

For a general question about one of the samples, or about how to adapt its techniques to your own application, the README lists three places. The FlutterDev Discord, the Flame Discord, and Stack Overflow with the flutter tag. The Flame Discord is the game engine one, and its presence is a hint that the gaming templates are built with or at least intended to sit alongside Flame, the Flame based game engine for Flutter.

The bug reporting route is the one that surprises people. If you run into a bug in one of the samples, the instruction is to file an issue in the flutter/flutter issue tracker, not in this repository. That makes sense given the structure, since the samples are Flutter applications and the tooling that runs them lives in the main Flutter repository, but it means issues filed against flutter/games are effectively not the project's own tracker.

For contribution, the README points to the contributor's guide in CONTRIBUTING.md.

On maintenance, the repository is not archived and the last push was on 2026-10-19, with a build status badge for a main workflow. There are no GitHub releases, which is consistent with the nature of the project, since the artefacts here are source directories you copy rather than packages you version. The three CI scripts for the beta, shared and stable channels are the mechanism that keeps the samples working across Flutter releases, and that is the thing to look at if you are wondering whether a template still builds.

The practical takeaway for someone starting a Flutter game today: clone the relevant template, rename it, and treat the sample you need as documentation rather than as a dependency. Nothing here is versioned, so the code you take becomes your code, and the only ongoing relationship is that you may want to pull in fixes from upstream when Flutter itself changes.

Editorial conclusion

Adopt flutter/games if you are building a browser game in Flutter and want an official project structure to start from, especially if you need the ads or multiplayer samples as a reference. Do not adopt it as a game engine or a set of reusable gameplay systems, because the value is in the project skeleton rather than in the mechanics. Verify first that the template you pick matches your game type, that the game runs in the browser targets you care about rather than only on desktop, and that the sample code you copy is under a licence compatible with your product.

Frequently asked questions

Official sources

1. flutter/games on GitHub
2. Issues
3. README