Input and Events

The goal of this activity is to help students better understand how events work, and how using events differs from the input model that they used in Game Lab. In groups of four, students will model the two different approaches to taking input. By the end of the activity students should understand that the onEvent block sets up a input to watch for events in the background, allowing input handling without explicitly asking each input for a value constantly. The roles for this activity are:

Program: The Program reads the code aloud and performs any actions dictated by the inputs. Inputs 1-3: The Inputs draw cards from the deck, which represent their changing input values.

Version A: Asking for Input

This first version models the Game Lab approach to taking input. In this scenario the Program explicitly asks each input for a value every time the draw loop is run.

Rules for Version A:

• The Program reads each line of code aloud.
• At the beginning of each draw loop, each Input draws a new card from the deck. This represents the current state of that input.
• Whenever the Program reaches an input checking command (inputOne(), inputTwo(), or inputThree()), the Program asks to see that inputs card.
• If the value of the card shown matches the associated conditional, the Program performs the action(s) inside the conditional.

After groups have run the program a few times and seem to understand how it works, have them switch up roles so that each student gets a chance to be the Program.

Version B: Input Events

This time around, instead of constantly asking for input in a loop, the Program will assign each Input an Event to watch for. In the context of this activity, an Event is either a red or black card, but in a program that Event could be a click on a button, movement of the mouse, press of a key, or more. This is a simplified model for the way input is handled in App Lab.

Rules for Version B:

• Each Input draws a card from the deck at a rate of roughly one per second.
• The Program reads each line of code aloud.
• When the Program reaches an onEvent command, they tell the specified Input which Event to watch for, and what the Response should be.
• When assigned an Event, the Input writes down the details in their Events to Watch table.
• Every time an Input draws a card, they check to see if it matches one of the Events in their table. If it does, they tell the Program to perform the Response.

There are a few important simplifications that are made in this model to minimize the number of roles and rules:

• This model implies that Inputs are actually watching for Events on their own. In reality, an Event Handler running in the background watching for the specified event.
• In this model the Input tells the Program what actions to take. In reality, when an Event Handler is triggered, the Program goes to that portion of their code and runs everything in the function.