Audience: first-time through experienced game makers. Structure: one course with an eight-week beginner path and two six-week project paths for intermediate and advanced learners. Start at the level you can demonstrate; you do not have to complete all 20 weeks. Pace: three 45–60 minute sessions weekly plus an optional playtest. Cost path: Godot and self-made/appropriately licensed assets; an AI assistant is optional, and no paid API is required. This is a learning course, not a promise of commercial readiness or an official credential.
What you will learn
By the end of the beginner path, you can define a manageable core loop, build scenes and scripted interactions, choose whether to use AI as a design/debugging collaborator while keeping human control of decisions, test and revise with people, and export a playable build. The intermediate path adds modular systems and controlled iteration; the advanced path adds an evaluated AI-related game behavior with a fallback and documented constraints. Godot's official Getting Started, first 2D game, and export guide anchor the engine workflow. The three-path schedule and checkpoints below are this course's proposed learning design, not Godot requirements.
For the beginner path, choose one bounded project: for example, a one-screen game in which a player moves, collects three objects, avoids one hazard, and reaches a visible win or retry state. Keep the first version to one level, one primary mechanic, keyboard input, and simple placeholder art. Expand only after it works.
Choose your starting path
- Beginner: start here if you cannot yet build and export a small Godot game independently. Entry evidence: a concept card is enough; no coding background is required. Outcome: one playable, human-tested 2D game with a README and an AI-use record (or a clear “none used” note).
- Intermediate: start here if you can show a Godot 2D project with player input, a win/lose state, a restart path, and an exported build that runs outside the editor. Outcome: extend that game with a modular mechanic, testable feedback/accessibility improvements, and an evidence-based iteration report.
- Advanced: start here if you can show an editable Godot project with separable systems, a repeatable playtest, and a documented build. Outcome: prototype and evaluate one AI-related game behavior, with a safe deterministic fallback, documented failure modes, and a reproducible release candidate. A remote generative API is optional, not the definition of this level.
If you can meet most but not all entry evidence, review the exact beginner/intermediate week that supplies the gap. These are self-placement guides, not admissions rules.
Prerequisites and setup
You need a computer that can run the installed Godot version, a keyboard or usable alternate input, permission to save local project files, and a way to test an exported build. Prior programming or AI subscriptions are not required for the beginner path. Intermediate and advanced entry evidence is listed above. If your device cannot export to the preferred platform, choose a supported target and record the constraint.
- Install the current stable Godot release from Godot and open the official Getting Started documentation for the version installed. Use GDScript in this course so examples stay consistent.
- Create a project folder and a simple change log. Keep a copy of the last working version after each session; Git is optional.
- Decide whether to use an AI assistant. If yes, keep an AI decision log: date, prompt/purpose, output used or rejected, what you checked, and asset/license provenance. If not, record “none used”; no AI prompt or rejected AI suggestion is required. Never paste credentials, other people's private information, or unlicensed material into a prompt. Test generated code locally and explain it in your own words before keeping it.
- Make a one-page concept card: player action, goal, obstacle, feedback, win/lose state, audience, and what will be intentionally omitted. A person should be able to understand the loop without knowing your engine.
AI collaboration protocol: Human first (define experience and constraints) → AI middle (ask for alternatives, pseudocode, or bug hypotheses) → human last (inspect, implement, playtest, revise, attribute). Useful prompt: “Here is my intended 2D collect-and-avoid loop and this short error message. Offer two possible causes, one test for each, and explain the tradeoff. Do not rewrite the whole project.” Verify every suggestion against Godot's versioned docs and actual behavior. If not using AI, perform the same design/review steps with your own notes.
Each session, 45–60 minutes
- 5 min: open the last working build and state one observable goal.
- 10 min: study the linked official documentation or inspect a tiny example.
- 25–35 min: make one change and test it immediately. Save a working checkpoint.
- 5–10 min: log what changed, one bug or question, any AI assistance, and the next smallest step.
- Once a week, ask one other person to attempt the game without coaching. Watch where they hesitate; do not interpret silence as success.
Beginner path: eight-week sequence
| Week | Lesson and hands-on exercise | Evidence/checkpoint |
|---|---|---|
| 1: scope and engine literacy | Follow Godot Getting Started. Create a project, scene and visible player placeholder. Draw the concept card. Ask an AI assistant, if used, for three core-loop options and reject any requiring extra systems before the first playable. | Someone can explain the game goal from the card; project opens without errors; an AI decision log begins if AI is used, otherwise “none used” is recorded. |
| 2: player verbs | Work through the relevant parts of first 2D game. Add movement with input actions and a visible boundary. Change one value at a time and observe its effect. | Player responds to input, cannot leave the intended play area, and you can identify which script or node controls movement. |
| 3: goal, obstacle, and state | Add one collectible and one hazard or timer. Use signals/collision as appropriate to your project. Show a clear win state and a retry path. Before accepting AI code, trace what event triggers each state change. | A three-minute self-test demonstrates start → action → win or fail → retry without editor intervention. |
| 4: feedback and accessibility basics | Add readable on-screen controls, visible feedback for collection/damage, a pause/retry path, and alternatives to color-only cues. Test with sound off and at two window sizes. Run a keyboard-only path through start, gameplay action, win/fail, pause and retry; confirm visible focus on UI controls where present. Test a remap or alternate-input path where feasible, and record unsupported remapping as a limitation. Use simple high-contrast placeholders before polishing. | A new player can identify the goal and feedback without relying on audio or color alone. A recorded keyboard-only test shows start/play/win-or-fail/pause/retry and visible UI focus where applicable, with any input limitation documented. This is a course-designed check, not a guarantee that the whole game is accessible. |
| 5: deliberate iteration, with or without AI | Pick one real issue from a playtest. Write a bug report: expected, observed, steps to reproduce. If using AI, ask it for hypotheses and record which ideas you accept or reject; otherwise generate hypotheses yourself or with a peer. Test the smallest hypothesis and log the result. | One reproducible issue is fixed, with a before/after observation, an explanation of the code or scene change, and a hypothesis-test record. |
| 6: assets, attribution, and feel | Replace only the placeholders that most affect comprehension. Make assets yourself or use assets whose terms permit the intended use; record source and license. Tune one interaction by comparing two versions with a human tester. AI-generated assets, if used, still need provenance and a human quality check. | Asset list has provenance; tester can tell player, target, hazard and success/failure states apart. |
| 7: playtesting and scope control | Run two short observed playtests with people who did not build the game. Ask “What were you trying to do?” and “Where did you pause?” Record behavior, not just opinions. Prioritize one high-impact fix and defer nice-to-have features. | Playtest notes identify at least two observations, one chosen fix, one deferred idea, and the reason for the choice. |
| 8: release candidate and reflection | Follow Godot's export documentation for one target platform and test the exported build on a suitable machine. Create a one-page README with controls, goal, credits, known limits, and an AI-use statement (including “none used” if applicable). | Exported game launches, core loop works outside the editor, README and AI-use statement exist, and you can name the next iteration. |
Intermediate path: six weeks of modular iteration
Use the beginner game or another small Godot project meeting the intermediate entry evidence. The goal is not a bigger content list; it is a game whose behavior can be changed and tested without breaking unrelated systems.
| Week | Objective and exercise | Evidence/checkpoint |
|---|---|---|
| I1: audit and player question | Run the current exported build. Make a system map (input, state, feedback, restart) and observe one player. Choose a single question such as “Does the risk/reward decision feel legible?” Ask AI, if used, for alternative hypotheses, then select one test yourself. | Baseline build, system map, observation and a testable question. |
| I2: modular mechanic | Add one mechanic in a separate scene/script or clearly bounded component. Define its inputs, outputs and failure behavior before coding. If using AI, compare its suggested structure with what you can explain and maintain; otherwise compare two self- or peer-generated structures and justify your choice. | Old loop still works; new mechanic can be enabled/disabled or isolated for testing; learner explains its interface. |
| I3: state and feedback | Make success/failure transitions explicit and add feedback that distinguishes at least two states without color or sound alone. Test one keyboard-only route through start, play, pause, win/fail and retry; check visible UI focus where applicable and document remap/alternate-input options or limits. Repeat with sound off and without relying on color. | A novice tester can say what state they are in and recover from failure without editor help. The test log records the keyboard-only and sound-off/non-color checks, plus any failures. |
| I4: test matrix | Build a small matrix of normal, boundary and failure cases, including a quick restart and an unexpected input sequence. If using AI, ask it for missing cases, not a verdict; otherwise ask a peer or review the matrix yourself. Run the cases on an exported build and record observed results. | At least six named cases with pass/fail observations and one reproducible bug report or justified “none found.” |
| I5: controlled playtest | Compare two versions differing in one gameplay or feedback decision. Observe two players without prompting and ask what they tried to do. Keep a short rationale for which version to retain. | Two comparable builds/previews, observations and a chosen revision tied to evidence. |
| I6: release and teach-back | Export a release candidate, README and updated asset/AI-use record (or “none used” note). Explain the system map to another learner, including one rejected AI suggestion if AI was used, or one rejected self/peer design hypothesis if not. | Playable exported build, reproducible test matrix, source/AI-use statement and a three-minute teach-back. |
Advanced path: six weeks of evaluated AI-related game behavior
Choose one bounded behavior: for example, an opponent that adapts using transparent state/rules, a director that adjusts encounter pacing, or a dialogue system with a scripted fallback. A remote generative service is optional. Begin with deterministic behavior so the game remains playable when a model is unavailable, slow, costly or inappropriate. Never send private playtest data or credentials to a service without authorization.
| Week | Objective and exercise | Evidence/checkpoint |
|---|---|---|
| A1: design brief and baseline | Define player experience, what “AI” changes, inputs/outputs, boundaries and one measurable success signal (such as fewer confusing encounters, not a promised engagement gain). Record a baseline of the non-AI version. | One-page brief, baseline build and explicit non-goals. |
| A2: behavior contract and fallback | Specify allowed inputs, valid outputs, timeout/error behavior and a deterministic fallback. Prototype the mechanic with rules or test doubles before connecting any model. | The fallback supports the full core loop; failure can be demonstrated on demand. |
| A3: integration and observability | Integrate one AI-related behavior behind a separable interface. Log only non-sensitive events needed to debug it. If using a remote model, record cost/latency limits and document what is sent. If any code or content is AI-generated, have a human review it. | Three reproducible scenarios show normal, edge and failure behavior; the game remains operable offline or without the model. |
| A4: evaluation against baseline | Run the same short tasks on baseline and new versions with two testers or repeatable self-tests. Record behavior, confusion and failure cases. Do not claim a general improvement from a tiny sample. | Comparison table with observations, limitations and one decision to keep/revise/remove the mechanic. |
| A5: accessibility and safeguards | Check readable instructions and a route around unpredictable content. Run one keyboard-only route through start, play, pause, win/fail and retry, including visible UI focus where applicable; repeat with sound off and without relying on color. Record failures and unsupported remapping. Review asset rights, disclosure and data handling. | A test log shows the keyboard-only and sound-off/non-color results, documented failures and remaining accessibility limits, alongside asset/data decisions. |
| A6: reproducible handoff | Export and test the build outside the editor. Provide README, architecture diagram or system map, fallback demo, test matrix, asset provenance, an AI-use statement (or “none used” note), and a concise case study of decisions. | Another person can run the build, trigger the fallback, understand the AI behavior's limits and see what the evidence supports. |
The intermediate and advanced paths use Godot's Getting Started and export guide as version-matched references. Their structure, sample sizes, checkpoints and ethical design constraints are proposed course pedagogy, not official Godot requirements.
Assessment without invented grades
For the beginner path at weeks 2, 4, 6 and 8, and for the intermediate/advanced paths at weeks 2, 4 and 6, use a three-part check: playable behavior, explanation, and evidence. Mark each works / partly works / not yet and write one concrete next action. A checkpoint passes when the behavior can be shown in a build, the learner can explain the relevant system, and a test or log supports the claim. This is a course-designed formative check, not a credential or university rubric.
Capstone evidence and formative rubric
Keep as evidence in your own learning portfolio, not as an ASU course submission: the exported build, editable project, README, test/playtest notes, and an AI/asset decision log (or an explicit note that no AI was used). For beginner work, the build demonstrates the core loop; for intermediate work, it demonstrates a modular change and comparative test; for advanced work, it demonstrates the AI-related behavior, deterministic fallback and evaluation against a baseline.
Use each criterion as 0 = not yet evidenced, 1 = partly evidenced, 2 = demonstrated with observable evidence. This is an optional self/peer feedback scale, not an official grade. A reasonable revision target is at least 6/8 with no missing criterion; if below that, revise the weakest criterion rather than adding new features.
| Criterion | 0: not yet | 1: partly | 2: demonstrated |
|---|---|---|---|
| Playable behavior | Core loop or required path feature cannot be shown | Works only with editor help or has a blocking failure | Exported build demonstrates the path's required behavior and recovery/fallback |
| Explanation and AI accountability | System decisions or AI use are unexplained | Some decisions, prompts or checks are logged but gaps remain | Learner explains the relevant system, checks and records AI use/rejection if any (or notes none used), and documents asset provenance |
| Testing and revision | No repeatable observation | One test or player comment without a linked change | Reproducible test/playtest evidence supports a specific revision; advanced path compares a baseline |
| Access and handoff | Controls, feedback or files prevent a reviewer from trying it | Main route is usable but instructions, input path or files have gaps | README, controls, keyboard/alternate-input notes, non-color/audio-only feedback and project files let another person try and understand it |
Review accessibility with actual users where possible; a “2” means the listed checks were evidenced, not that the game is universally accessible. Evaluate design decisions and reproducibility, not the cost of tools or artistic polish.
If stuck: cut the game to one screen and one interaction; open a known-working checkpoint; reproduce the error; compare the specific node/script with version-matched docs; ask for a narrow hypothesis. If the AI answer invents an API, discard it. If playtesting reveals confusion, improve instructions/feedback before adding mechanics.
Optional stretch after a completed path: a second level, procedural variation, or another mechanic. A live AI API introduces cost, privacy, latency and failure modes; prototype the mechanic with deterministic local behavior first.
Source and authorship note
Engine facts and workflow: Godot Getting Started, Your First 2D Game, Export. The three entry paths, weekly pacing, human-first AI protocol, playtest prompts, checkpoints and rubric are Akari's proposed pedagogy. They should not be described as official Godot or ASU policy.