Using a game maker in the classroom, honestly

Anything you are considering for a room of students should tell you its constraints before its features, so here they are. Stage Engine is a desktop application for Mac and Windows. It is downloaded and installed on each machine. It is not a web page you open, and there is no version that runs in a locked-down browser tab.

Building requires an internet connection that stays up. Director 1, asset generation and world data all come over the network. If the connection drops mid-lesson, students can still play what they have already built, but they cannot continue building. On a school network that throttles or filters aggressively, that is the thing to test before anything else.

There is no classroom plan, no seat pricing and no site licence. Stage Engine has a free plan, Indie at $10 a month and Pro at $50, and those are individual plans. If you are budgeting for a class you are budgeting per person, or you are running everyone on the free plan and living within the usage it gives.

A session has a shape that fits a period reasonably well, because the slow parts of game development are not in it. Nobody spends the first three lessons on syntax. A student opens the builder, shapes some ground, places water and a character, and says what should happen. Director 1 writes the GDScript into their project. They press play and the game runs locally on their machine.

That means the feedback loop inside one lesson is complete: build, play, decide it is wrong, change it. A student who has never made anything before will have something they can show at the end of the first session. Whether it is good is a separate question, and a better one to spend the term on.

The natural unit of work is a place rather than a genre. Ask for a corridor that feels tense, or a village that feels lived in, and you get design conversations. Ask for a platformer and you get twenty near-identical platformers.

Because the code is written for them, the visible work is world building, systems design and judgement. A student decides how far apart to space the landmarks, how long night lasts, what the player learns in the first thirty seconds. Those decisions are legible, defensible and arguable, which makes them easier to mark than a script that either runs or does not.

They are also decisions the student has to make from playing. This is worth being explicit about with a class: nobody in the room can tell you whether the jump feels right except the person who just played it. Handing the judgement back to the student is the mechanism, not a gap in the tool.

The code is not hidden. It sits in the project as normal GDScript, and a student who wants to read it can. In a class that is meant to teach programming, that is a way in rather than a wall — they read code that already works and that they asked for.

If your machines are Chromebooks, this is not the tool. If your students cannot install software, it is not the tool. If your network cannot be relied on for the length of a lesson, the building half will stall and you will spend the period troubleshooting rather than teaching.

If any of those apply, a browser-based tool is the honest answer, and there are good ones. Being the right tool for a room you cannot deploy in is not something a landing page can arrange.

Where it fits is a room with real Macs or Windows machines, a stable connection, and students who are old enough to manage their own account. In that room it removes the single largest obstacle to a term-long project, which is that most of the term goes on getting anything to run at all.