GAME 1303 — Instructor Course Guide

Introduction to Game Design & Development
Collin College · Media Arts · Animation & Game Art
Section 001 — Unity 6.x · Section 002 — Unreal Engine 5.8
Fall 2026 · Tuesdays 9:00 AM – 1:50 PM · 16 weeks

Contents

1. What this course is trying to do
2. The shape of the semester
3. Running a class period
4. The ten exercises — what each is really teaching
5. The six milestones — running critique
6. The two Canvas assignments
7. Grading
8. Week-by-week teaching notes
9. Pitfalls — first-time Unity students
10. Pitfalls — first-time Unreal students
11. Pitfalls that have nothing to do with the engine
12. Track-specific notes
13. Lab management
14. Before the semester starts
15. Materials inventory

1. What this course is trying to do

The course produces one finished, published game per student in sixteen weeks, built in a professional engine, using art the student made.

That's the deliverable. The educational goal underneath it is narrower and more important:

Students should leave able to make a design decision, defend it in specific terms, and cut what isn't working.

Almost everything in the course structure serves that sentence. The exercises are graded half on implementation and half on a defended decision. Every exercise ends with a subtraction rather than an addition. The milestones ask "why" as often as "does it work."

Why this structure replaced the previous one

The previous version ran a guided mini-game tutorial followed by four numbered projects. The failure modes were consistent:

The one thing to protect

If you change nothing else, keep this: exercises are graded half on a written, defended decision. That half-point is the entire difference between a course that teaches software and a course that teaches design. Students will initially write "I made it feel good." Reject it, cheerfully, every time, and by Week 6 they will be writing "I dropped speed to 6.5 because 8 overshot my platforms."

2. The shape of the semester

Sixteen weeks alternating between exercise weeks and milestone weeks.

The dependency chain

Exercises are placed the week before the milestone they feed. This is deliberate and it is the load-bearing part of the schedule — if you reorder anything, preserve these:

Ex 2 The Verb ────┐
                  ├──▶ Milestone 2  Core Game Mechanic   (Wk 5)
Ex 3 Rules ───────┘

Ex 5 Space & Pace ───▶ Milestone 3  Level Map            (Wk 8)

Ex 7 Screen Flow ────▶ Milestone 4  Screen Layout        (Wk 11)

Ex 10 Test & Iterate ▶ Milestone 5  Game Build           (Wk 15)

A student who does the exercise on their own project rather than a sandbox has already done most of the milestone. Say this out loud, repeatedly. The ones who treat exercises as throwaway homework do the work twice.

Why pitches are in Week 2

Three reasons, in order of importance:

1. You find out what's in the room before you commit lecture time. If nobody pitches narrative, you spend less time on dialogue systems. If four people pitch VR, you build a comfort unit into Week 12 and reserve headsets early.
2. Students hear each other's ideas early enough to be influenced. Week 2 pitches produce cross-pollination; Week 6 pitches produce defensiveness.
3. Scope gets challenged while changing course is still free. A student who pitches an MMO in Week 2 has thirteen weeks to become a student making a small good thing.

The cost is that Week 1 has to carry both a full exercise and pitch prep. It's tight but it works, because Ex 1 is genuinely a 75-minute exercise and pitch prep is homework.

3. Running a class period

Every week is the same three blocks. The consistency matters more than the specific timings — students stop asking what's happening today.

Lecture

Pair the design idea with its implementation in the same session. "Here's what game feel is" followed a week later by "here's how to add particles" doesn't stick; the two have to arrive together.

Keep it to 60 minutes of content in a 75-minute block. You will lose fifteen minutes a week to questions, a projector, and someone's engine update, and if you planned for 75 you will be cutting the end of every lecture.

Show, don't slide. Run the editor live. Break something on purpose and fix it in front of them — watching an instructor read an error message calmly is more useful than any slide about error handling.

Exercise

The exercise files have numbered steps and checkpoints. Use the checkpoints as sync points: call them out loud ("everyone should be at Checkpoint 2 — hands up if you're not") and you'll catch the stuck students at ten-minute intervals instead of at the end.

The exercises are timed to finish inside 75 minutes for a student of average speed with no disasters. Expect roughly:

• 20% finish early — the exercise files have an If you finish early section for exactly this
• 60% finish on time
• 20% need lab time to finish

That last 20% is fine and expected. Late exercises earn the Implementation point only, so there's a real cost without it being punitive.

Lab

Circulate. Do not sit down. Once you sit, the confident students come to you and the stuck ones don't.

The most useful lab intervention is not fixing the bug. It's:

"Show me what you expected to happen."

Half the time they find it themselves mid-sentence. The other half you've learned what they actually misunderstand, which is rarely what the bug looks like.

The 10-minute rule: tell students at the start of the semester that if they're stuck for ten minutes with no progress, they must ask. Left alone, a beginner will burn ninety minutes on a missing checkbox and conclude they're bad at this.

4. The ten exercises — what each is really teaching

Each exercise is 2 points: 1 Implementation + 1 Design decision. Full detail in exercises/, both engines.

Notes on the ones that give trouble

Ex 1 — First Playable. The real content is project setup. Students want to skip the folder structure. Don't let them: in Week 13, when their project has 400 assets, this is the only reason they can find anything. Also make them build on day one — a one-sprite project is the cheapest possible time to discover that packaging is slow and surprising.

Ex 2 — The Verb. The subtraction test (set move speed to 0 and see if the course is still completable) is the graded core, and about a third of students skip it and lose the point. Call it out in the exercise block. When it fails — when the course is still completable — that is the exercise working, not the student failing.

Ex 3 — Rules & States. The five-minute paper state diagram feels like busywork to students and prevents about half the trigger bugs you'd otherwise debug in lab. Enforce it. Also note that "no failure" is a legitimate consequence and scores full marks if argued — puzzle and narrative students should genuinely consider it.

Ex 4 — Juice It. The single highest-return exercise in the course. Two things to police: they must record the "before" clip first (in forty minutes they'll have lost all perspective), and their movement values must not change. Students will want to fix the mechanic while they're in there; the exercise is proving that feel is feedback, not physics, and changing values destroys the demonstration.

Ex 6 — Story in the World. The 60-word cap does the teaching. Students will ask if it's a hard limit. It is. The stranger test at the end — where they ask one person "what happened in this room?" and write down the exact words — routinely produces better story than the student's own premise, and the notes template invites them to keep the tester's version.

Ex 7 — Screen Flow. Insist they do this on their own game, not a sandbox. It's the difference between the Week 11 milestone being done and being started. Also: this is where students discover uGUI tutorials on YouTube don't match UI Toolkit. Warn them in lecture and point them at the helper GameUI.uxml.

Ex 9 — Curves & Locks. The graph must be drawn before tuning, and students will do it after unless you collect it. Consider having them photograph the graph and show you before they open the engine.

Ex 10 — Test & Iterate. The hardest exercise to run and the most valuable. Students cannot stay silent. Prepare them: "you will want to help within forty seconds; every time you don't, you learn something." Have them sit slightly behind the tester with a pen in hand — a physical task makes silence much easier.

Requires a running build. Students without one cannot do the exercise. Flag this in Week 13 twice.

5. The six milestones — running critique

Running the pitch session (Week 2)

Use a visible timer. Project it. At 3:00 you stop them mid-sentence — do it to the first person and the remaining fifteen will land on time.

Sixteen students at five minutes each is 80 minutes, which does not fit the exercise block. Options: run pitches across the lecture and exercise blocks, or split into two rooms. Budget more time than seems necessary; the Q&A is where the value is.

Model the Q&A on the first pitch. Ask the questions you want the class to ask: What does the player actually do? What happens when they fail? What are you not building? By the fourth pitch they'll be asking those themselves.

Take notes on tracks and genres. You'll use them to weight the rest of the semester.

Running a critique session (Weeks 5, 8, 11)

Format that works in the 75-minute block for ~16 students:

1. Student demos for 2 minutes while talking through one decision they made
2. Two classmates each name one thing that works and one question
3. You add one thing, and one thing only

Cap your own feedback at one item. A student who leaves with six things to fix fixes none of them. Pick the highest-leverage one and let the rest go.

The Week 5 scope conversation

Week 5 is designated as the last week a student can change their game without a conversation. Use it. If the core mechanic doesn't exist by Week 5, that's real information — usually that the concept is heavier than it looked at pitch.

Have the conversation that day. Cutting scope in Week 5 is design. Cutting it in Week 11 is triage. Cutting it in Week 14 is damage control.

Week 15 — the big one

25 points, more than every exercise combined. Grade it on what a player experiences, not effort or intent. The completeness criterion is 8 of the 25 and is the one to protect — say this repeatedly from Week 13 on:

A short, simple game a stranger can finish scores higher than an ambitious one that stops at the second room.

Give explicit permission to cut. Students believe cutting is failure; in this course it is the graded skill.

Week 16 — post mortem

Nothing is graded on whether the game succeeded. Say this before the first presentation and mean it — otherwise you get sixteen defensive victory laps instead of sixteen honest accounts.

The strongest post mortems name a decision and follow it to its consequence. Model this by asking one follow-up: "What did that cost you?"

6. The two Canvas assignments

Both are homework, not class time.

One Sheet (Wk 4, 5 pts). One page, one side. The hard part is the hook, and the format constraint is the teaching. A two-page one sheet loses the format point automatically — hold that line, or by Week 13 you'll be reading fifteen-page ones.

Game Design Doc (Wk 13, 10 pts). Graded on accuracy, not ambition — a short document that precisely describes a small finished game outscores a long one describing features that never got built.

Tell students in Week 4 to open the file with the ten headings and nothing under them, then spend ten minutes after every class filling in what they decided that day. The ones who do this hand in an accurate document; the ones who don't write it the night before and it reads as a plan rather than a record, which costs the two accuracy points every time.

The asset list (section 7) is the most-missed two points in the course, and it's also how the originality policy is checked. Anything unlisted is treated as uncredited.

7. Grading

The distribution

A ≥ 90 · B ≥ 80 · C ≥ 70 · D ≥ 60 · F < 60

Grading exercises fast

Two criteria, each met or not met. No partial credit within a criterion. This is deliberate — it makes twenty submissions gradeable in about thirty minutes and removes the negotiation.

Implementation (1 pt): open the build. Does it run? Does the required feature work? Any console errors? That's it — under a minute per student.

Design decision (1 pt): read the notes file. You are looking for numbers and a named trade-off.

Calibration

The distinguishing question: does the writing name something they rejected? A decision with no discarded alternative is a default.

Be consistent from Week 1. If you award the point for "it feels good" in Week 1, you will read "it feels good" for fifteen weeks.

Grading milestones

Budget roughly:

For the Week 15 build, play it as a stranger would. Don't use knowledge you have from watching it develop. If you have to remember how the controls work, a player wouldn't have known.

The checklist

checklists/ contains a 10-tab workbook and a markdown version, with every rubric criterion as a checkbox. Point students at the relevant tab in the "before class" section of each weekly page — it's already linked there. The Every Build tab catches the project-folder-instead-of-build failure that makes work ungradeable.

Handling the common grade dispute

"I worked really hard on this."

They usually did. The rubrics grade the artifact, not the effort, and the honest answer is that the two aren't the same — a student who spent thirty hours on character animation and has no win state has a real problem that more hours won't fix. Say it kindly and early, ideally in Week 5, not in Week 15.

8. Week-by-week teaching notes

Brief notes on what to emphasize and what tends to go wrong. Full detail in weeks/.

Wk 1 — First Playable. Half the room will have installation problems. Have the installers on a USB stick. Emphasize: not a cloud-synced folder; save the scene; build today. Assign pitch prep as homework and be explicit that it's live next week.

Wk 2 — Game Pitches. Timer visible. Model the Q&A. Take notes on tracks. Expect at least two students to have pitched something four times too large — book them for lab conversations rather than correcting them publicly.

Wk 3 — The Verb. The six-verb menu means six different sets of setup problems in one room. Circulate by verb — group the shooters together and solve their projectile lifetime issue once.

Wk 4 — Rules & States. One Sheet due tonight; remind them at the start, not the end. Enforce the paper state diagram.

Wk 5 — Core Game Mechanic. First real "bring a build" checkpoint. Some students will bring a project folder despite everything. Let that cost the point once — it doesn't happen twice. This is the scope conversation week.

Wk 6 — Juice It. Best day of the semester. Make sure they record "before" first. Expect the room to get loud.

Wk 7 — Space & Pace. Actual paper for the beat chart. Unity: the Composite Collider step is the one they'll skip and then debug for an hour. Unreal: grid snapping on, before anything else.

Wk 8 — Level Map. Check that levels genuinely require the core mechanic. Most don't on the first attempt — it's the most common miss on this milestone.

Wk 9 — Story in the World. Enforce the 60 words. Run the stranger tests as a round-robin — everyone tests the person two seats over.

Wk 10 — Screen Flow. They must use their own project. Unity students will find uGUI tutorials that don't apply; warn them in lecture.

Wk 11 — Screen Layout. Have them navigate the whole flow live, including the paths they haven't tested. Dead-end buttons surface here or in Week 15, and here is cheaper.

Wk 12 — Point of View. VR build targets lock this week. Reserve headsets. Cinemachine install eats fifteen minutes if they didn't do it beforehand.

Wk 13 — GDD + Curves & Locks. The most important lab session of the semester: make everyone build. Whatever state their game is in. Every problem the first build surfaces is a problem they now have two weeks to fix instead of two hours.

Wk 14 — Test & Iterate. Round-robin the testers. Police the silence. Also the last week to cut scope meaningfully — have that conversation with anyone whose game isn't finishable.

Wk 15 — Game Build. Some students will still be uploading during class. That's fine, and expected. Watch for the ones who aren't uploading — that's the real signal.

Wk 16 — Post Mortem. Set the tone with the first presentation: honest, specific, and not a defence. Sixteen post mortems in an afternoon is the densest design education in the program.

9. Pitfalls — first-time Unity students

Setup and project hygiene

The Input System

Physics and colliders

Sprites and rendering

Editor behaviour that confuses beginners

Performance

Students will Instantiate and Destroy hundreds of objects per second and then report that "Unity is slow." Ex 9 introduces ObjectPool for exactly this. Watch for it earlier in shooter projects.

10. Pitfalls — first-time Unreal students

Setup and machine reality

Enhanced Input

Blueprint

Collision

Packaging

Scale

Unreal's world unit is 1 cm and a default character is ~180 units tall. Students building 2D or top-down games routinely build doorways at 100 units and can't work out why everything feels cramped. Establish scale in Week 1 against the character, not against the viewport.

Version control

Blueprints are binary. They do not merge. Two students editing the same Blueprint produces a conflict that can only be resolved by one of them losing work. For solo projects this is fine; mention it if anyone collaborates.

11. Pitfalls that have nothing to do with the engine

These cost more grades than every technical issue combined.

1. Scope

The single biggest cause of failure in this course. Signs, in order of severity:

• Cannot describe the game in one sentence
• Core mechanic still doesn't exist in Week 5
• Asset list has more than ~20 unique items
• Planning multiplayer, procedural generation, or an inventory system

Intervene at pitch, again at Week 5, again at Week 13. Cutting is the graded skill and students believe it's failure — you have to say otherwise repeatedly and mean it.

2. The art time black hole

A student spends Weeks 6–9 making character animations for a game whose core mechanic still isn't tuned. Art is visible progress and feels productive, which is exactly why it's dangerous.

Rule of thumb worth stating in Week 5: freeze art until the mechanic is locked. Placeholder rectangles all the way to Week 10 is a perfectly good semester.

3. Building late

Almost every catastrophe in Week 15 is a student whose first build was that morning. The first build of any project surfaces problems that never appear in the editor: missing references, broken paths, WebGL-incompatible code, wrong input bindings, maps not in the packaging list.

Countermeasures already in the materials: build in Week 1, build again in Week 13, and Ex 10 requires a running build.

4. No backups

"My drive failed" arrives at least once a semester. Version control is taught in Week 2; enforce it by asking to see a repo during the Week 5 milestone.

5. Tutorial-following without transfer

A student completes a twelve-hour YouTube series and cannot apply any of it to their own project, because they learned a sequence of clicks rather than a concept. The exercise structure is designed against this — small isolated builds followed by application in lab — but watch for the student whose project looks exactly like a well-known tutorial.

6. The Week 12 restart

Someone will decide in Week 12 that their game is bad and start over. This is almost always a mistake and almost always driven by comparison with a classmate. Redirect to cutting rather than restarting: the existing project plus aggressive cuts will ship; a new project started in Week 12 will not.

7. The disappearing student

A student misses Weeks 6–9 and reappears in Week 10 asking how to catch up. Attendance drops one absence, so by Week 10 they've lost 3 attendance points and 8 exercise points — 11 of 100 — before any project work. The honest conversation is about what grade is still reachable and whether a smaller game is the right call.

8. AI-generated code they can't debug

Students will paste in generated scripts. The course policy permits it with disclosure, and the practical problem isn't ethics — it's that they can't fix it when it breaks, and it will break.

The useful framing: you have to be able to explain every line you ship. During critique, ask a student to walk you through one function of their choosing. That's usually sufficient.

12. Track-specific notes

13. Lab management

Circulating

Start at the far corner and work inward. The students who most need help sit furthest from the door and never raise a hand.

Ask "show me what you expected to happen" rather than "what's wrong." Beginners describe symptoms; the gap between expectation and behaviour is where the misunderstanding is.

The fast students

Roughly 20% finish exercises early. The exercise files each have an If you finish early section — point at it rather than inventing tasks. Better still, pair them with someone stuck: explaining is the fastest way to consolidate, and it doubles your floor coverage.

The stuck students

The 10-minute rule, stated in Week 1 and repeated: stuck for ten minutes with no progress means ask. Beginners will otherwise burn ninety minutes on a missing checkbox and conclude they aren't cut out for this.

When you do help, fix it with them, narrating what you're checking and why. The order you check things in is itself the lesson.

Managing two engines in one program

If both sections run in the same lab, the helper libraries are deliberately API-parallel — GameStateManager / BP_GameState, TriggerZone / BP_TriggerZone — so the design vocabulary is identical across sections and only the implementation differs. You can teach the design half of any lecture once.

14. Before the semester starts

• Build the Unity helper package — copy HelperScripts/Assets/GAME1303/ into a project, verify it compiles, export as HelperScripts.unitypackage. See HelperScripts/README.md
• Build the Unreal helper pack — follow HelperBlueprints/BLUEPRINT_BUILD_GUIDE.md. Budget a full day, and build in the order given
• Record placeholder_character.png and 3–4 placeholder sound effects into the helper packs
• Fill the syllabus placeholders: your name, Collin email, office hours, and the college's standard statements
• Verify engine versions installed on every lab machine, and check free disk space (Unreal needs ~100 GB per active student)
• Turn off Nanite and Lumen defaults on lab Unreal installs
• Reserve or confirm the VR headsets — Quest 2 and Cosmos Elite — and set up a checkout process
• Create the Canvas modules: one per week, each linking its weekly page
• Upload the helper packages to Canvas → Files → HelperScripts
• Print the checklist workbook — students will use the paper version more than the digital one
• Set up an itch.io account and walk through publishing once yourself, so you can demo it in Week 15
• Confirm the Fall 2026 academic calendar against the schedule dates

15. Materials inventory

course/
  INSTRUCTOR_GUIDE.md              this document
  GAME1303_syllabus.md             master document — structure, schedule, grading, policies
  course-schedule.md               Canvas page
  grade-sheet.md                   Canvas page
  project-tracks.md                Canvas page — 2D / Puzzle / Narrative / 3D / VR
  helper-scripts.md                Canvas page — the library contract

  weeks/          16 files         week-01.md … week-16.md
  exercises/      20 files         10 exercises × Unity and Unreal
  milestones/      6 files         pitch, mechanic, level map, screens, build, post mortem
  assignments/     2 files         one sheet, game design doc
  checklists/      2 files         markdown page + 10-tab printable workbook

  HelperScripts/                   Unity 6.x source — 22 C# files + UXML/USS + README
  HelperBlueprints/                Unreal build guide — 29 assets specified

  2026_Fall_GAME1303_schedule.xlsx     Unity and Unreal tabs, print to PDF
  2026_Fall_GAME1303_gradesheet.xlsx   live formulas, auto letter grade
  2026_Fall_GAME1303_checklist.xlsx    10 printable one-page tabs

Everything cross-references. Weekly pages link exercises, milestones, and the checklist; exercises reference helper scripts by exact field name; milestones reference the checklist tab. If you change a point value or a helper script field, search the folder for it — the materials assume consistency.

Questions, corrections, and things that broke in practice are worth writing down as you go. The most valuable version of this document is the one with a semester of your own marginal notes in it.