Game maker for schools: the deployment questions

Stage Engine is a desktop application distributed as an installer for macOS and for Windows. It is installed per machine. There is no web version, no managed browser deployment, and no thin client. A school running Chromebooks or iPads cannot use it at all, and no amount of planning changes that.

On managed Mac or Windows fleets it is a normal application install and behaves like one. It ships with its own copy of Godot inside the bundle, so there is no second engine install to manage and no separate Godot version to keep in step across a lab.

Storage is local. Each project is an ordinary Godot project in a folder, which means it lives wherever the student profile lives. On roaming profiles or heavily quota-limited home drives, that is worth sizing before rollout rather than after.

Building requires an internet connection, and this is not a soft requirement with a degraded mode behind it. Director 1, asset generation and world data all come over the network. If the connection is unavailable, students cannot build. They can still play what they have already built, because the game runs locally on the bundled Godot.

School networks are the specific risk here, because they are filtered, proxied and shared thirty ways at once. The honest advice is to trial it on one machine, on the actual school network, during a busy period, before committing a scheme of work to it. That single test tells you more than any specification sheet.

There is no offline mode and there is not going to be one. Saying otherwise would set a school up for a bad lesson.

This is the part that fits schools least well. There is no site licence, no seat pricing, no education tier and no volume arrangement. The plans are individual: a free plan, Indie at $10 a month and Pro at $50. Paid plans buy more usage of the AI and generation, not additional software.

In practice that means a school either runs a cohort on the free plan and works within the usage it provides, or budgets per student on an individual plan. Neither is the procurement shape schools normally want, and pretending otherwise on a landing page would waste somebody's afternoon.

Accounts are individual accounts. There is no admin console, no class roster and no centralised management of student accounts.

A subject that is usually gated behind programming becomes accessible to a whole cohort rather than the four students who were already writing code at home. Because Director 1 writes the GDScript, a student's work is world building, systems design and judgement, and those are the parts of game development worth a term.

The output is a real Godot project, on open-source software, that the student owns and keeps. Nothing about the work is trapped in a subscription. A student who leaves the school, or leaves the tool, leaves with a project that still opens.

And the loop is fast enough to be taught in periods rather than in projects. A student builds, plays, decides it is wrong and changes it inside one lesson, which is the thing that makes design teachable at all.