01
Pilot one class
Start with a single teacher, a known group of students, and private project creation while staff learns the workflow.
Access stays narrow and projects begin private.
For Schools
Bring AI game building into school without losing oversight.
Gamecoder is structured for school rollout: students learn through planning, coding, testing, and revision while teachers stay visible to the work and publishing begins from a private-first model.
Private by default
Teacher-guided publishing
Signed-in showcase today
Rollout Path
A school decision page should show how adoption actually unfolds.
This is not a jump from idea to open publishing. The better path is staged: pilot, classroom use, supervised sharing, then broader policy decisions once the school is comfortable.
02
Guide the making
Students move from prompt to playable game in the browser while teachers review progress and keep the room visible.
Planning, coding, testing, and revision stay teacher-visible.
03
Approve sharing
Publishing becomes a supervised step with sign-in requirements and oversight still attached to the work.
Teachers and admins keep moderation context on published work.
04
Set school policy
Any broader visibility decision happens after the pilot, as a school choice, rather than as a product default.
Visibility expands by policy, not by assumption.
Outcome
What students gain
The product stays grounded in making, not passive prompting, so AI becomes part of a real classroom workflow.
Prompting connected to planning and revision
Real code edits and game logic changes in the browser
Fast testing loops without local setup
A clearer path from idea to playable project
Outcome
What schools control
The operating model is built to keep visibility, moderation, and rollout decisions legible to adults.
Private-first starting point for student work
Teacher and admin oversight around publishing
Signed-in sharing instead of open-by-default exposure
Deliberate policy decisions before broader visibility
Role View
The same product should answer different school roles clearly.
The page should work for the principal who approves the pilot, the teacher who runs it, the student who learns through it, and the IT lead who needs the operating model to stay legible.
Principal
Sees the operating model quickly: private start, supervised sharing, and a clear pilot path before expansion.
Review the default rollout
Understand where policy choices sit
Approve a calm first implementation
Teacher
Runs the classroom experience, monitors student projects, and stays in the loop when work moves toward sharing.
Guide students through planning and revision
Review work before it travels further
Keep publishing inside school context
Student
Builds a real game, learns with iteration, and shares work inside the boundaries the school has chosen.
Plan a game with AI help
Edit scenes and code directly
Test work in a browser-based studio
IT / Ops
Gets a product story that is easier to vet because visibility and rollout assumptions are explicit.
Start with a bounded deployment
See how access is granted
Confirm that policy is not bypassed by defaults
Policy Matrix
The product story is stronger when policy questions are explicit.
Instead of hiding trust behind generic feature cards, spell out the default stance: who sees work, who guides sharing, how AI is used, and what remains a school-level choice.
Who can see student projects
School
Projects begin private and signed-in sharing stays the present default.
Teacher
Teachers review progress and understand when work is moving toward publication.
Student
Students can build and revise without starting from public exposure.
Who approves sharing
School
The school can define how publishing should be used before any broader rollout.
Teacher
Teachers remain part of the supervised publishing path.
Student
Sharing happens inside the classroom model rather than as a one-click public default.
How AI is used in class
School
The product is framed around literacy through making, not passive generation.
Teacher
Teachers can keep AI use tied to planning, coding, and revision.
Student
Students still build, test, debug, and iterate on the final game.
What happens after a pilot
School
Expansion decisions are made by policy once the school is ready.
Teacher
The classroom workflow can be validated before widening access.
Student
Students get a stable experience while adults decide what opens next.
Next Step
Start with one pilot class and keep the rollout legible.
The strongest first move is usually narrow: one teacher, one bounded rollout, clear publishing expectations, and a trust model the school can explain before it expands.