Press#
How much interaction can one button contain?
The hardware budget#
One input. Two states: down, not-down. Plus timing — when it went down, when it came back up, how long between one and the next.
That’s the entire budget for this semester. Nothing else gets added to it.
Most things assume more#
Almost every interactive system you’ve used assumes at least a pair of inputs: one to commit, a second to back out or correct course.
This course removes the second one. On purpose.
What’s left, when there’s only one?
A bicycle bell#
Squeeze it: one ring. Squeeze it again: another ring. The bell does not remember the last squeeze, and it does not stay ringing after your hand leaves it. Each squeeze is its own, separate occurrence.
A press is not a state you’re in. It’s something that already finished happening.
Why that distinction matters here#
Every later week in this course adds something to the plain press — a duration, a release, a rhythm, a memory of earlier presses. All of it sits on top of the same fact: the press itself is instantaneous and leaves nothing behind on its own.
Get this wrong early and every later week gets harder to reason about, not easier.
One button, building#
- press
One button, building#
- press
- hold
- release
- rhythm
One button, building#
- press
- hold
- release
- rhythm
- sequence
- a value that outlives the gesture
- one press, different meanings by context
And everything added after#
- movement
- failure
- a second player
- an input built for someone who can’t time a press themselves
Twelve weeks, one cut at the end#
Week 12 adds nothing new. It’s the one week where the skill is deciding which parts of this list a single finished game actually needs, and leaving the rest out.
So — how much?#
Enough for twelve weeks. Today, just the press.
Next#
The studio session today builds three tiny prototypes from nothing but the press event. Same input, three different jobs.