Teaching

Approach

I believe students learn to make games and software by making them, and by putting that work in front of other people before it feels finished. My courses run on short cycles of building, testing, and revising. Students produce something small, hand it to a classmate, watch what happens when someone else touches it, and then rebuild with what they learned. This is how production actually works. A feature is never done the first time it runs, and a design is never validated by its author alone. It also shifts what I grade toward the quality of a student's decisions: why this mechanic, why this layout, why this control scheme.

Students arrive in these classes from very different places. Some have been programming since middle school; some have drawn for years and have never opened an engine; some are here because the subject sounded interesting. I try to design assignments with a low floor and a high ceiling, so a beginner can complete the work honestly while a more experienced student still has somewhere to push. My own background in technical art sits between the artistic and technical sides of production, and I lean on that to translate between the two. Artists should understand what their choices cost at runtime, and programmers should understand what makes something feel good to use.

Finally, I try to keep my classroom honest about failure. Most of what we build in a semester will be rough, and the useful skill is learning to read a broken prototype for information rather than treating it as a verdict on the person who made it. I give specific, actionable critique, I expect students to give it to each other, and I ask them to document what they tried and what they would change. My goal is that students leave the course able to start a project without me, evaluate their own work with some accuracy, and keep going after the first version disappoints them.