Elective · Computer
Video Game Design and Coding
Middle 6–8, High School 9–12 · PLECK original · 180 lessons
PLECK original. This course was written for this school.
This is a PLECK elective for teens with no programming background. The loaded lessons use Godot Standard 4.7.2, GDScript, and the Compatibility renderer. The editor is a free download from the Godot Engine project. No account and no purchase are required. Headless Godot 4.7.2 passed 106 checks on the supplied scaffolds, including collision, jumping, collection, restart, spawning, dialogue, AI, grid, pause, timers, malformed JSON saves, and a saved file read by a second process. That check used a Dummy audio driver and a short original WAV. It did not look at the visual editor, play sound through speakers, export a browser build, or try signed-in submission. The desk stores a typed note, a screenshot, and one https address to a private project. It does not run a student's upload, open a zip, or treat a video as the program. This is not HTML, CSS, and JavaScript. Looking at this page does not enroll a student, and finishing a lesson does not add a transcript credit.
Learning outcomes
- Follow the assigned design or programming steps in Godot Standard 4.7.2.
- Show editable source with a private https address, notes, or a screenshot.
- Keep a demo recording separate from the source file.
PLECK lessons
Original PLECK lessons for Video Game Design and Coding. Godot Standard 4.7.2-stable, GDScript, and the Compatibility renderer: a free download with no account and no purchase. Headless Godot 4.7.2.stable.official ran 106 assertions on all 24 scaffolds, including collision, jumping, collection, restart, spawning, dialogue, AI, grid, pause, timers, malformed JSON saves, and cross-process persistence. Audio was the Dummy driver plus a synthetic WAV, not a speaker test. The visual editor, browser export, and signed-in submission were not part of that run. This is not HTML, CSS, and JavaScript.
12 units · 180 lessons. A parent assigns one lesson at a time and chooses the due date. Opening a lesson does not enroll anyone.
Editor setup
Headless Godot 4.7.2.stable.official passed 106 assertions on all 24 scaffolds. The audio driver was Dummy, with a short original WAV. That does not test the visual editor, speaker loudness, a browser export, or signed-in submission.
No public publishing, chat, telemetry, online multiplayer, real name entry or third-party account is required. Use fictional names and anonymous tester codes. Recordings are optional and private.
- Guardian checks the official download page and approves an appropriate platform download. Choose Standard for the machine architecture, not .NET, a preview build or an unrelated mirror. The verified course target is 4.7.2-stable; record any different version and retest recipes before use.
- Extract the downloaded archive and launch the editor. Godot is self-contained; no paid license, store account or online profile is required. Follow normal operating-system security checks; do not bypass a warning for an untrusted download.
- In Project Manager choose Create/New, use a local folder and Compatibility renderer. Select GDScript for scripts and the GDScript tab when reading docs, not C#.
- Set Project Settings > Display > Window > Size viewport width 640 and height 360 (use the settings search if panels differ). Keep initial world parents at position zero, rotation zero and scale one. Use CanvasLayer for HUD.
- Create scenes with exact node names specified in each recipe. Attach a single script per root. Save scenes with .tscn and scripts with .gd. Run Current Scene to test a lab; set the actual game World scene as Main Scene for full project play.
- Create Input Map actions move_left, move_right, move_up, move_down; bind A/Left, D/Right, W/Up, S/Down using physical key events. Add jump bound to Space for the platformer. Keep built-in UI navigation actions. Named actions are case-sensitive.
- Name 2D physics layers Player (1), Walls (2), Pickups (3), Hazards (4). Use editor layer boxes. Player layer1/mask2; solid walls layer2/mask1; pickup areas layer3/mask1; hazard areas layer4/mask1. Add Player to the player group.
- Keep projects, original art/audio, test notes and dated backup ZIPs organized. Include project.godot, all scenes/scripts/assets in source ZIPs, omit .godot cache and unrelated private files. Restore-test snapshots in separate folders.
- Local editor play is the required no-account submission/test pathway. Export is optional; matching free export templates must be approved/downloaded before use. Do not install anything on the user’s computers automatically.
- If a version mismatch or editor error appears, use built-in class help and the official stable docs to check the named API. Record the actual editor version. Pause publication if a scaffold does not run; do not pretend native execution was verified.
Do not claim direct ZIP/audio/video uploading works until the cloud agent verifies support. A private HTTPS link must resolve to a downloadable source ZIP with teacher access; never require a public account or public hosting. If no approved private transfer is available, accept local/printed hand-in plus inspect source locally and mark programming evidence awaiting transfer rather than accepting video alone.
Original course tap, a short WAV. Copy it into the Godot audio folder. The native check used a Dummy driver, not speakers.
Pocket Orchard starter, as text files. The desk does not offer a project zip.
1. Play, paper, and first programs
Suggested weeks 1–3. A parent still chooses each due date.
Week 1 packetWeek 2 packetWeek 3 packet
- 1. A goal the player can understand
- 2. Model a turn before using a computer
- 3. Iterate a paper prototype
- 4. Create a private development workspace
- 5. Set up the free editor and record a baseline
- 6. Print a first event
- 7. Use names and types that explain the game
- 8. Calculate resources and clamp boundaries
- 9. Branch on a legal decision
- 10. Repeat a known number of steps
- 11. Draw a visible actor in a coordinate system
- 12. Instance a scene twice
- 13. Map actions rather than hardcoding keys
- 14. Move by speed times elapsed time
- 15. Keep movement inside a usable playfield
2. Movement, collisions, and collection
Suggested weeks 4–6. A parent still chooses each due date.
Week 4 packetWeek 5 packetWeek 6 packet
- 16. Replace free motion with a physics body
- 17. Build walls that agree with their artwork
- 18. Read layers and masks as questions
- 19. Diagnose a collision systematically
- 20. Design an orchard route with fair clearance
- 21. Detect an overlap without blocking movement
- 22. Protect an event from being counted twice
- 23. Let the level own the score
- 24. Make feedback readable in a HUD
- 25. Finish and restart a small playable game
- 26. Refactor repeated feedback
- 27. Balance speed with a controlled experiment
- 28. Create an original optional route
- 29. Observe a private playtest
- 30. Submit Pocket Orchard with evidence
3. Arcade systems and a complete game loop
Suggested weeks 7–9. A parent still chooses each due date.
Week 7 packetWeek 8 packetWeek 9 packet
- 31. Define the Meteor Mail loop
- 32. Animate a falling hazard
- 33. Spawn on a Timer event
- 34. Cap resource use and test a long run
- 35. Connect spawned hazard events
- 36. Track lives with a minimum
- 37. Model explicit phases
- 38. End a timed round deliberately
- 39. Restart every piece of round state
- 40. Create a playable Meteor Mail checkpoint
- 41. Add a cooldown without hiding the rule
- 42. Constrain randomness for a fair challenge
- 43. Tune difficulty as data
- 44. Play without relying on one sense
- 45. Explain and assess the arcade game
4. Narrative, interfaces, and logic puzzles
Suggested weeks 10–12. A parent still chooses each due date.
Week 10 packetWeek 11 packetWeek 12 packet
- 46. Map a small branching story
- 47. Build a readable dialogue interface
- 48. Store story content as data
- 49. Connect choices without duplicate handlers
- 50. Navigate the story with a keyboard
- 51. Turn a story condition into Boolean logic
- 52. Exhaust a small truth table
- 53. Give an item once and remember it
- 54. Reveal a puzzle through feedback
- 55. Validate the puzzle graph
- 56. Write choices that communicate intent
- 57. Test text at different sizes
- 58. Separate decisions from presentation
- 59. Evaluate a narrative playtest
- 60. Submit Archive Lantern
5. Platforming and level design
Suggested weeks 13–15. A parent still chooses each due date.
Week 13 packetWeek 14 packetWeek 15 packet
- 61. Understand platform coordinates and acceleration
- 62. Implement a grounded jump
- 63. Tune a reachable gap
- 64. Build a readable three-jump route
- 65. Reset safely after a fall
- 66. Activate a midpoint checkpoint
- 67. Keep the next action visible
- 68. Make collision feedback trustworthy
- 69. Offer a documented assist option
- 70. Add a distinct goal state
- 71. Measure a difficulty curve
- 72. Diagnose a jump bug by category
- 73. Explain the motion model without memorizing code
- 74. Run a fresh-player route test
- 75. Submit Relay Runner
6. Midyear playable capstone
Suggested weeks 16–18. A parent still chooses each due date.
Week 16 packetWeek 17 packetWeek 18 packet
- 76. Pitch a one-room remix
- 77. Write acceptance before implementation
- 78. Plan ownership and signal flow
- 79. Build the smallest playable slice
- 80. Review scope using evidence
- 81. Complete the core mechanic
- 82. Implement the central challenge fairly
- 83. Make state visible and controls discoverable
- 84. Make a complete replay loop
- 85. Freeze features and build a test candidate
- 86. Run a structured capstone playtest
- 87. Triage and repair the most important defect
- 88. Explain one system from input to output
- 89. Submit the midyear playable capstone
- 90. Reflect and choose the next skill
7. Art, audio, accessibility, and responsible design
Suggested weeks 19–21. A parent still chooses each due date.
Week 19 packetWeek 20 packetWeek 21 packet
- 91. Create an asset and rights inventory
- 92. Design consistent visual categories
- 93. Make an original scalable icon
- 94. Animate feedback without changing physics
- 95. Organize visual assets for maintainability
- 96. Plan purposeful sounds
- 97. Import a short original audio file
- 98. Add mute that really stops playback
- 99. Synchronize sound with a validated event
- 100. Test audio activation and quiet play
- 101. Audit barriers instead of labeling a game accessible
- 102. Make keyboard focus visible and complete
- 103. Offer comfort settings with honest behavior
- 104. Remove manipulative and privacy-invasive patterns
- 105. Release an accessibility revision privately
8. Data, inventory, and reliable local saves
Suggested weeks 22–24. A parent still chooses each due date.
Week 22 packetWeek 23 packetWeek 24 packet
- 106. Model a tiny resource adventure
- 107. Use a dictionary as an inventory
- 108. Make a two-resource purchase atomic
- 109. Render inventory from data
- 110. Integrate Seed Station without saving yet
- 111. Separate project files from saved progress
- 112. Write a small best-score save
- 113. Validate before trusting loaded values
- 114. Restore a safe checkpoint and inventory
- 115. Test missing and damaged saves safely
- 116. Define New Game versus Continue
- 117. Add a versioned schema change deliberately
- 118. Audit conservation of resources
- 119. Explain browser save limitations and local backup
- 120. Submit Seed Station with a save audit
9. Enemy behavior and procedural challenges
Suggested weeks 25–27. A parent still chooses each due date.
Week 25 packetWeek 26 packetWeek 27 packet
- 121. Plan readable enemy behavior
- 122. Implement a bounded patrol
- 123. Add distance-based detection
- 124. Use hysteresis to avoid flickering states
- 125. Integrate a fair guard challenge
- 126. Represent a room as a grid
- 127. Generate reproducible variation
- 128. Guarantee a route before adding obstacles
- 129. Create physics walls from grid data
- 130. Regenerate without leaking old objects
- 131. Reserve space for both player and guard
- 132. Bound enemy and update costs
- 133. Test procedural edge seeds and state transitions
- 134. Explain the limits of the AI and generator
- 135. Submit Garden Patrol
10. Engineering and final capstone planning
Suggested weeks 28–30. A parent still chooses each due date.
Week 28 packetWeek 29 packetWeek 30 packet
- 136. Write tests before a small rule change
- 137. Choose boundaries and representative cases
- 138. Read an error from the first useful cause
- 139. Refactor without breaking a tested contract
- 140. Restore a version and bisect a regression manually
- 141. Choose a final game worth finishing
- 142. Write a final testable feature contract
- 143. Design the data and node architecture
- 144. Identify risks and prototype the hardest part
- 145. Plan work in dependency order
- 146. Create the final project baseline
- 147. Implement the final player action
- 148. Prototype the richer system in isolation
- 149. Integrate the first final-game slice
- 150. Review the slice and lock the minimum scope
11. Final capstone production
Suggested weeks 31–33. A parent still chooses each due date.
Week 31 packetWeek 32 packetWeek 33 packet
- 151. Harden input and boundary behavior
- 152. Complete the central rule set
- 153. Complete a fair challenge and recovery path
- 154. Complete progress and end-state feedback
- 155. Run the core production regression
- 156. Finish the richer system’s data model
- 157. Finish ordinary richer-system behavior
- 158. Harden failure and boundary paths
- 159. Reconcile restart and persistence policies
- 160. Complete a content-ready integrated build
- 161. Build the promised content sequence
- 162. Replace placeholders with original coherent assets
- 163. Finish comfort controls and clear instructions
- 164. Freeze the alpha and inventory known issues
- 165. Perform a full alpha regression
12. Testing, release, and portfolio reflection
Suggested weeks 34–36. A parent still chooses each due date.
Week 34 packetWeek 35 packetWeek 36 packet
- 166. Prepare a privacy-respecting beta test
- 167. Observe beta play without leading the player
- 168. Rank beta findings by impact
- 169. Repair focused defects and prove the change
- 170. Create release candidate one
- 171. Package source so another person can inspect it
- 172. Understand optional native export
- 173. Test optional web export accurately
- 174. Audit licensing, privacy and submission safety
- 175. Run the final release gate
- 176. Prepare a concise playable demonstration
- 177. Defend the code with predictions
- 178. Evaluate design using playtest evidence
- 179. Assemble a private portfolio and self-assessment
- 180. Submit and plan a responsible next step
Materials
Every source on this page is free to open.
- Godot 4.7.2 stable archive
Free open-source game editor. This course targets Godot Standard 4.7.2, GDScript, and the Compatibility renderer. No account is required. PLECK is not affiliated with Godot.
- Godot step by step
Free open-source game editor. This course targets Godot Standard 4.7.2, GDScript, and the Compatibility renderer. No account is required. PLECK is not affiliated with Godot.
- Your first 2D game
Free open-source game editor. This course targets Godot Standard 4.7.2, GDScript, and the Compatibility renderer. No account is required. PLECK is not affiliated with Godot.
- Saving games
Free open-source game editor. This course targets Godot Standard 4.7.2, GDScript, and the Compatibility renderer. No account is required. PLECK is not affiliated with Godot.
- Exporting for the Web
Free open-source game editor. This course targets Godot Standard 4.7.2, GDScript, and the Compatibility renderer. No account is required. PLECK is not affiliated with Godot.
Lessons
This course page has 180 daily lessons. A family sets the pace.
How credit is earned
This is practice, not a transcript credit and not an official score. A parent can still count the hours. Looking at the catalog does not enroll a student.
Grade bands: Middle 6–8, High School 9–12.
Enroll a student
Enrollment stays inside a family account. This page does not show grades, notes, or other families.