Games turn a practice objective into a web game your class can open from a link. You describe what learners should practise, TutorFlow writes a plan you can edit, and the approved plan becomes a self-contained game that runs in the browser.
Nothing is installed and nothing is hosted by your institution. The game is an ordinary web page, so the tablets and phones already in the room can open it.
At a glance
- A plan comes first. TutorFlow drafts the game concept, what the player does, and how a round is won or lost. You edit it before anything is built.
- Two checks on every version. An automated check on the generated page, then a real playthrough that opens the game and works the controls.
- Revisions in plain language. Describe the change in a chat panel beside the game and TutorFlow rebuilds it.
- Full version history. Every build, revision, and restore is kept, and any earlier version can be restored.
- Private by default. A game is only reachable by a link once you switch it to public.
What a game is made of
A generated game is a single HTML page. It carries its own levels, scoring, and end screen, and it draws to a canvas. Only a fixed set of vendor libraries is available to it, served from TutorFlow rather than fetched from the internet at play time, so a game cannot break because a third-party CDN changed.
Because the page is self-contained, sharing it is sharing a URL. There is no build step for you, no deployment, and no plug-in for learners to enable.
What gets checked before you see it
A generated game that will not start is worse than no game, so a version has to pass two separate checks before it reaches you.
| Check | What it does |
|---|---|
| Automated validation | Reads the generated page and rejects anything outside the allowed set of libraries, or a page too large to load reliably |
| Playthrough | Opens the game, presses the controls on the title screen, and watches whether the game actually starts and keeps running |
The playthrough is the one that catches the failures that matter. It opens a fresh copy of the game for each control it tries, because the first button on a title screen is rarely the one that starts play. It then watches the frames the game draws: a game whose loop stops rescheduling has visibly stopped, and that version is rebuilt rather than sent to you.
What these checks do not judge is whether the game suits your class. They confirm that it runs. Difficulty, wording, and whether the questions match what you are teaching are still worth a look, so play yours through once before your learners do.
Credits
Game generation draws on your organization's AI Credit balance.
| Action | Credits |
|---|---|
| Plan (brief) | 1 |
| Build | 12 |
| Revision | 10 |
The plan is priced well below the build on purpose. Exploring an idea, reading the plan, and deciding against it should not cost what building it costs.
Where games fit
Games are a practice format, not a replacement for a lesson. They work best where repetition is the point and another worksheet has stopped landing:
- A five-minute drill the whole class can run on shared tablets
- Vocabulary or arithmetic practice built around one topic at a time
- Safety and compliance scenarios that people actually finish
- A warm-up or a closer around a lesson that already exists
Building games from another system
Everything on this page is also reachable from the Content API: creating, listing, updating, deleting, restoring a version, and the three generation steps. The API routes through the same services the admin screens use, so a game built from an integration costs the same credits and passes the same checks.
See Games over the Content API.