Session 08 → Session 12

From AI Studio prompt to a reviewable educational game

Use Google AI Studio Build mode for a bounded implementation slice. Use Firebase or Google Workspace only when the learning purpose requires persistence, collaboration, or instructor review. Use Playwright to verify the public artifact, not to bypass account permissions.

Open Google AI Studio ↗ · Return to the student completion guide

01 · Start with the learning claim

Write the build brief before the AI prompt.

AI Studio can generate a polished surface very quickly. Your brief prevents the surface from becoming the assessment. Copy the five fields below from D1–D3 before you open Build mode.

Editorial illustration of a learner moving from a game prototype and loop diagram to playtest evidence and a submitted folder.
Build the smallest loop first, then preserve the reasoning and evidence that make it reviewable.

Learner

One learner group, one setting, one access condition.

Example: 7th-grade pairs on shared Chromebooks in a 40-minute class.

Target behavior

One observable verb with a condition and a criterion.

Example: predict and revise a trajectory using mass, distance, and vector direction.

Loop

Predict → act → feedback → revise. Keep the first build to five minutes.

Example: choose an angle, launch, inspect the miss, change one variable, retry.

Evidence

What trace would let an instructor inspect the claim?

Example: input angle, target state, outcome, feedback viewed, and revision choice.
Rule: If the learner can win without doing the target thinking, the prompt is not ready. Tighten the mechanic before adding more art, levels, or AI behavior.

02 · Prompt sequence

Use three prompts, not one giant “make my game” request.

Prompt A · scaffold

Generate the smallest slice

Ask for a runnable web prototype with named states and one core decision.

Prompt B · inspect

Make behavior observable

Ask the agent to expose state, feedback, and learner choices without inventing outcome data.

Prompt C · revise

Change one learning risk

Feed in a real observation and request one evidence-linked revision.

Prompt D · handoff

Prepare the submission

Ask for a file map, public preview instructions, and a provenance summary. Review every line yourself.

Copy/paste game-design prompt

Build a five-minute educational game prototype from this design brief.

Learner: 7th-grade pairs on shared Chromebooks.
Target behavior: learners predict and revise projectile trajectories using
mass, distance, and vector direction.
Loop: predict → choose angle and speed → launch → inspect feedback → revise.
Evidence to expose: chosen angle, chosen speed, target state, hit/miss,
feedback viewed, and the variable changed on the next attempt.

Requirements:
- Use a small web game with keyboard and pointer controls.
- Keep the state machine explicit: Start, Predict, Act, Feedback, Revise, End.
- Make the feedback explain the relevant variable; do not only show a score.
- Add a visible "what changed?" revision note after a miss.
- Include an accessible reset button and a text alternative for important feedback.
- Keep all learner data local to the prototype unless I explicitly request a backend.
- Use placeholder shapes and readable labels before adding visual polish.

Do not:
- claim that the game improves learning;
- invent playtest findings or learner data;
- hide the API key in client-side code;
- add accounts, leaderboards, or analytics that are not needed for this learning claim.

Return:
1. the runnable app;
2. a short file map;
3. the state/event table;
4. the exact changes I should inspect before sharing the preview.

Prompt for a real revision

Observed during a labeled rehearsal: two players changed the color but
could not tell which variable controlled the trajectory. Keep the existing
learning objective. Revise only the feedback state so the changed variable,
the result, and the next actionable choice are visible. Add one test case for
the miss path. Explain which files changed and what evidence I should capture.
Do not write a claim about learning gains.

03 · Optional runtime persistence

Use Firebase when the game needs a learner-owned state or event log.

Keep TeachPlay's enrollment and credential review as the authoritative course path. Add Firebase only for the game runtime when persistence is itself part of the design: resume state, a bounded event trace, or a teacher-facing replay.

Concrete use case

A learner's game stores the last five attempts and the variable changed after each miss. The instructor sees the replay only after the learner submits the packet.

Minimum data model

games/{gameId}
  ownerUid
  objectiveCode
  publicPreviewUrl

games/{gameId}/attempts/{attemptId}
  uid
  state
  input
  outcome
  feedbackViewed
  changedVariable
  createdAt

Web SDK shape

import { initializeApp } from "firebase/app";
import { getAuth, signInAnonymously } from "firebase/auth";
import { getFirestore, addDoc, collection, serverTimestamp } from "firebase/firestore";

const app = initializeApp(firebaseConfig); // public config only; no service-account key
const auth = getAuth(app);
const db = getFirestore(app);
await signInAnonymously(auth);

await addDoc(collection(db, "games", GAME_ID, "attempts"), {
  uid: auth.currentUser.uid,
  state: "feedback",
  input: { angle: 32, speed: 18 },
  outcome: "short",
  feedbackViewed: true,
  changedVariable: "angle",
  createdAt: serverTimestamp()
});

Starter Firestore rule

match /games/{gameId}/attempts/{attemptId} {
  allow create: if request.auth != null
    && request.resource.data.uid == request.auth.uid
    && request.resource.data.keys().hasOnly([
      "uid", "state", "input", "outcome",
      "feedbackViewed", "changedVariable", "createdAt"
    ]);
  allow read: if request.auth != null
    && resource.data.uid == request.auth.uid;
  allow update, delete: if false;
}
Do not ship a debug token or service-account key. Use Firebase Authentication and Security Rules for learner-owned data, App Check when you need abuse protection, and keep instructor exports behind a server or protected Workspace flow. The Playwright test environment needs a separate private debug-token strategy if App Check is enforced.

04 · Instructor collaboration

Use Google Workspace for review, not as a secret database.

Google Sheets, Forms, Drive, and Docs are useful when the instructor needs a shared review queue or a human-readable handoff. Prefer the narrowest OAuth scope, such as drive.file, and submit only a sanitized summary or a link to the artifact.

Example: playtest sheet

Columns: learner pseudonym, game URL, attempt count, observed breakdown, evidence link, revision decision, reviewer status. No raw student names or unconsented recordings.

Example: Drive packet

Create one folder per learner submission, share it with the instructor group, and put the README, preview URL, screenshots, recording, provenance log, and revision log inside.

Small Apps Script receiver

function doPost(e) {
  const body = JSON.parse(e.postData.contents);
  const safe = [
    body.learnerPseudonym,
    body.gameUrl,
    body.observedBreakdown,
    body.revisionDecision,
    new Date()
  ];
  SpreadsheetApp
    .openById(PropertiesService.getScriptProperties().getProperty("REVIEW_SHEET_ID"))
    .getSheetByName("Playtest review")
    .appendRow(safe);
  return ContentService
    .createTextOutput(JSON.stringify({ ok: true }))
    .setMimeType(ContentService.MimeType.JSON);
}

For a production Workspace integration, deploy the receiver to the intended domain, validate the caller, keep the sheet ID in script properties, and do not accept arbitrary Drive IDs from the browser.

05 · Visual production

Use Higgsfield for purposeful visual assets, not evidence substitution.

Use Higgsfield when the game needs a short concept clip, character motion, or scene reference that helps learners communicate the intended interaction. Keep the asset prompt and license/usage note in the AI provenance log. A generated clip can illustrate a mechanic; it cannot replace a real playtest or prove a learning outcome.

Create a 10-second, 16:9 instructional game-loop reference clip.
Show one learner prediction, one visible action, a clear feedback change,
and a deliberate revision. Use abstract geometric game elements, no logos,
no student faces, no readable text, and no outcome claims. Keep the camera
steady and make the changed variable visually obvious. This clip is a
concept reference for a prototype, not a record of learner performance.

06 · Verify the public artifact

Playwright checks the shared game after AI Studio, not the private editor.

After publishing or exporting the game, set GAME_URL to the public preview. The test below checks the first interaction, captures a screenshot, and fails on uncaught page errors. Add project-specific locators for the actual state machine.

import { test, expect } from "@playwright/test";

const gameUrl = process.env.GAME_URL;
test.skip(!gameUrl, "Set GAME_URL to the learner's public game preview");

test("public game exposes the learning loop", async ({ page }) => {
  const errors = [];
  page.on("pageerror", (error) => errors.push(error.message));
  await page.goto(gameUrl, { waitUntil: "domcontentloaded" });
  await expect(page.getByRole("main")).toBeVisible();
  await expect(page.getByRole("button", { name: /start|begin|play/i })).toBeVisible();
  await page.getByRole("button", { name: /start|begin|play/i }).click();
  await expect(page.locator("[data-state]")).toHaveAttribute("data-state", /predict|act/i);
  await page.screenshot({ path: "output/playwright/ai-studio-game-preview.png", fullPage: true });
  expect(errors).toEqual([]);
});
Submission evidence: keep the Playwright screenshot, the public URL, the test result, and the exact build/revision prompt together. If the game needs authentication, provide a safe demo route or reviewer account; never place a learner password or API key in the repository.

07 · Final handoff

Submit a packet an instructor can inspect in ten minutes.

Four-panel visual showing a playable game preview, design crosswalk, playtest observation, and revision record connected in a submission packet.
Keep the artifact, design logic, observed playtest, and revision decision together.
  1. Live artifact: public preview URL and exported GitHub URL, if available.
  2. Design argument: D2 crosswalk plus the exact Google AI Studio prompts that changed the build.
  3. Evidence: two or three screenshots, a short captioned recording, Playwright verification result, and playtest notes.
  4. Governance: Firebase rules or Workspace sharing boundary, AI provenance, generated-asset note, and known limits.
  5. Revision: one observed trace, one decision, one changed file or game behavior, and the next test.

Open the TeachPlay submission portfolio ↗ · Instructor computational-artifact review ↗

08 · Source links

Use the provider documentation as the implementation boundary.

These links are the approved starting points for the examples above. Provider behavior, quotas, and scopes can change; record the version and date in the learner's provenance log.