Milestone 2 — Core Game Mechanic

GAME 1303 · Week 5 — Tuesday, September 22 · Playable build, demoed in class · 5 points


The deliverable

A playable build of your own game in which your primary player verb works and feels intentional.

Not a level. Not a game. One mechanic, in a scene, that a stranger can pick up and use. If your game is about grappling, we grapple. If it's about sliding blocks, we slide blocks. Everything else — art, menus, scoring, levels — is explicitly not required this week.

You demo it live in class during the exercise block, and you submit the build.


Requirements

# Requirement
1 The build runs. Double-click, it opens, it plays. Not an editor-only project.
2 The primary verb works, driven by real input, at least on keyboard and one other device where practical
3 It is tuned. You changed the default values deliberately and can say why
4 No console errors during normal play
5 Placeholder art is fine. Coloured rectangles are fine. Art is not graded this week

Feeding exercises: Ex 2 — The Verb (Wk 3) and Ex 3 — Rules & States (Wk 4). Those exercises are where you build the pieces; this milestone is where you apply them to your own project.


By track

Track What "core mechanic" means here
2D Movement plus the primary verb — jump, dash, shoot, grab, swap
Puzzle One complete solvable puzzle instance. The player can reach a solved state and can reset.
Narrative The primary interaction — choosing, traversing, examining — with at least one branch or response
3D Character movement plus the primary verb, camera adequate to use it
VR The core interaction in-headset — grab, point, teleport — plus your locomotion mode. Must be demonstrated on the headset, not in editor preview.

The tuning conversation

The third requirement is the one that carries the milestone. Come prepared to answer:

What values did you change, and what happened when you changed them?

Concrete answers get full marks:

Default move speed was 5. At 5 it felt sluggish against my jump arc, so I went to 8, but then I overshot every platform. Settled at 6.5 and raised acceleration from 10 to 25 so it reaches speed faster without a higher top speed.

That is the whole skill. Not "I made it faster" — the numbers, and the trade-off you were resolving.

Keep the values in your GDD as you go. Section 2 asks for exactly this.

Suggested starting points to depart from: moveSpeed, acceleration/deceleration, jumpHeight, coyoteTime, jumpBuffer, dashDuration/dashCooldown. See helper-scripts.md.


Submission

Section Build target Notes
001 — Unity 6.x Windows standalone or WebGL Zip the whole build folder, not just the .exe. WebGL: submit an itch.io link.
002 — Unreal 5.8 Windows packaged build Zip the packaged output folder.
VR (either engine) Quest .apk or PC-VR build Also demo live in headset in class

Rubric — 5 points

Criterion Pts Met when
Build runs 1 Submitted build launches and is playable without the editor
Verb implemented 2 The primary mechanic works as pitched, driven by real input
Tuned deliberately 1 Values changed from defaults, with a stated reason and trade-off
Clean run 1 No console errors or broken behavior during a 60-second play

Common failure modes


Scope checkpoint

This is the last week you can change your game without a conversation. If Week 5 arrives and the mechanic doesn't exist, that's real information — usually it means the concept is heavier than it looked at pitch. Come to lab and we will either simplify the mechanic or change the game. Doing that now is cheap. Doing it in Week 11 is not.