Reaction-Time Game

The finish line

What you will build

The project records five valid trials in milliseconds, flags early key presses, and displays average, best, and range.

Before you build

Materials, tools, and safety

Reuse-material cost: $0-$3 with reused materials. Supervision: Adult help recommended for sharp or heated tools.

Build it

Step-by-step instructions

1. Step 1

   Plan the states

   Define ready, waiting, cue, response, false start, and summary.

   Draw a state flow.

2. Step 2

   Build the cue

   Create a large high-contrast circle that starts hidden.

   Add plain text instructions outside the sprite.

3. Step 3

   Reset results

   Clear the list, set trial to 0, and set best to a high value.

   Require the spacebar to be released.

   Builder checkpoint: After reset results, the first subassembly should stay aligned when handled gently.

4. Step 4

   Create random wait

   Choose 2-5 seconds and start waiting.

   Check for an early space press during the wait.

   Watch for: If this stage binds or drifts, inspect duplicate key state before adding more parts.

5. Step 5

   Handle false starts

   Show a false-start message and repeat the same trial number.

   Wait for full key release.

6. Step 6

   Measure response

   Show cue, reset timer, wait for space, and store timer × 1000.

   Hide cue immediately.

   Builder checkpoint: After measure response, operate the build slowly and confirm that reaction-time statistics begins without binding.

7. Step 7

   Repeat five trials

   Add each valid result to the list and update best.

   Give a short rest.

8. Step 8

   Calculate summary

   Sum list values, divide by five, and find maximum minus minimum.

   Display units as milliseconds.

   Builder checkpoint: At the final checkpoint, The project records five valid trials in milliseconds, flags early key presses, and displays average, best, and range.

See the engineering

Why it works

Input

spacebar press after a visual cue

Output

reaction-time statistics

Motion

human event-to-measured software interval

Energy losses

screen refresh, keyboard latency, anticipation, duplicate key state

when green flag clicked
delete all of [results]
set [trial] to 0
set [best] to 99999
hide [Cue]
repeat until <(trial) = 5>
  wait until <not <key [space] pressed?>>
  say [Ready...] for 0.5 seconds
  set [waitTime] to (pick random 20 to 50) / 10
  reset timer
  set [falseStart] to 0
  repeat until <<(timer) > (waitTime)> or <key [space] pressed?>>
  end
  if <key [space] pressed?> then
    set [falseStart] to 1
    say [False start — release and try again] for 1 seconds
  else
    show [Cue]
    reset timer
    wait until <key [space] pressed?>
    set [reactionMs] to (round ((timer) * 1000))
    add (reactionMs) to [results]
    if <(reactionMs) < (best)> then set [best] to (reactionMs)
    change [trial] by 1
    hide [Cue]
    wait until <not <key [space] pressed?>>
    wait 0.5 seconds
  end
end
set [total] to 0
set [index] to 1
repeat (length of [results])
  change [total] by (item (index) of [results])
  change [index] by 1
end
set [average] to (total) / (length of [results])
say (join [Average ms: ] (average)) for 3 seconds

Make it behave

Test, troubleshoot, and tune

Keep experimenting

Try another version

Build together

Classroom and access options

Reflect on the design

1. How did cue mode change the measured result?
2. Where did screen refresh affect the build most strongly?
3. What evidence shows that randomized event timing explains the motion?
4. Which change would improve reaction-time statistics without creating a new problem?