What Is an Interactive Game? Separate Playback Controls from In-Game Actions
Pausing, selecting a key tag and submitting a claim all use buttons, but involve different kinds of participation. A fictional station lost-property case uses input, rules and feedback to distinguish controlling viewing from acting within the game.

Introduction
For this series, an interactive game means that players act within a work, the work processes those actions according to rules, and it gives perceptible responses. This is not a single, mutually exclusive game category. We focus on narrative scenes to explain this kind of participation.
First ask: what did this click change?
To distinguish playback control from an in-game action, examine what changed. Pausing or adjusting volume usually changes the viewing process. Submitting evidence, using an item or choosing a reply may enter the work’s rules, affecting what characters can do and what happens next. A button’s shape cannot make that judgment for you.
“Interactive game” can be a broad working term, but it is not a standard category with uniform boundaries, independent of other games. Most games already involve interaction. This series mainly uses narrative examples, but the method also applies to action and puzzle games: jumping is processed by collision rules, and a puzzle by placement rules. Dialogue options are not required.
Do not call every clickable webpage a game either. Expanding menus and changing product images also have input and feedback. To understand a work’s gameplay, keep asking what players pursue, which actions they can take and what limits those actions. Input, rules and feedback are observation tools; their presence alone does not prove something is a game.
Consider story presentation separately. Live action, text and illustration describe expressive material; choices, dragging and timed operations describe participation; retrieving an item is a goal; claim conditions and attempt limits are rules. These layers can combine without forcing them into a mutually exclusive classification table.
A fictional case: reclaim an old suitcase at a station
The following original fictional case was designed for explanation. It is not a real user case, tested result or existing product feature. Its claim process serves only to explain gameplay.
Traveler Xiao Lan arrives at lost property hoping to recover an old suitcase. Her claim slip lists a triangular key tag and a white scratch on the lid. Triangular and round tags lie on the counter. Players can inspect the slip, select a tag, examine the case the attendant brings over, then select a case feature and submit the claim.
Rules are stated in advance: inspecting and selecting are unlimited; every submission uses one verification attempt, with two attempts in total. Both submitted tag shape and case feature must match the slip to recover the case. If neither of the two submissions matches, the round ends without recovery.
Three clicks operate at different levels. Pause stops the image; Xiao Lan has not asked the attendant to wait. Selecting the triangular tag changes the current selection, and the attendant turns the corresponding case toward her. “Submit claim” checks the information combination and decides whether to return the case or subtract an attempt. Using a mouse for all three does not make them the same kind of participation.
The real player task is to find and submit matching information, not finish playing the video. Even if the same final shot depicts returning the case, earlier observation and verification can still form gameplay.
A three-step interaction record: describe an operation fully
For an unfamiliar work, select one specific operation and fill this table. Do not write only “I chose an option”; describe the action it represents.
| Step | Question to record | Blank sentence pattern |
|---|---|---|
| 1. Input | What instruction did I issue? | Through..., I requested... |
| 2. Rules | How did the work process it? | When..., ...is allowed; otherwise... |
| 3. Feedback | What change told me the result? | I saw...; next I can... |
Then add “Did this mainly affect viewing, an in-game state, or is it still uncertain?” Allowing uncertainty is more reliable than guessing from a button label.
For pause: I asked the media player to stop playback; it stopped advancing the image; I saw a still image and could resume later. Without other evidence, this is viewing control, not “Xiao Lan obtained more time to claim the case.”
For submission: I requested verification of a triangular tag and white scratch; the work checked whether both matched; the attendant returned the case and the round’s goal was complete. The input has become an action recognized by the rules.
You can record observations without seeing internal code, but separate observation from inference. “Attempts went from two to one” is visible feedback. Without later evidence, “The attendant permanently remembered my mistake” remains unknown. Feedback may be delayed; a click not immediately changing the image does not mean it has no effect.
Walk through once, then see how failure occurs
Xiao Lan reads the slip’s triangular tag and white scratch. After the player selects the triangular tag, the attendant brings a locked old case with the lid scratch visible. No claim has been submitted, so two attempts remain. Select the white scratch and submit: both conditions match and the case is returned.
Inspecting the slip first changes the player’s knowledge; adding a separate “read” state value is unnecessary. Selecting a tag changes the object awaiting verification; only submission triggers the judgment. Separating them explains why “seen,” “selected” and “completed” are not interchangeable.
Try another path: select the round tag and submit the white scratch. The shape mismatch causes rejection and leaves one attempt. Switching to triangular and submitting the correct feature can still achieve the goal; another mismatched combination fails the round. The second attempt makes correction after failure a concrete action.
Another design might remove the attempt cost and only flag mismatch, allowing continuous comparison. It might instead remove directly displayed feature options and require rotating the case first. The former reduces trial-and-error pressure; the latter emphasizes finding clues. They change the challenge without requiring a different story-medium label first.
Conversely, if round and triangular submissions always immediately return the same case, do not claim shape verification occurs. A choice may still express attitude or change one line, but describe its actual effect. Do not call a decorative response decisive for success or failure.
Three boundaries against overreading interaction
First, playback controls can become gameplay. If another investigation game requires reversing footage to find clues, reverse playback may participate in solving it. Ordinary pause does not thereby automatically become character action. Judge how the specific rules use it.
Second, ending count is not the degree of interactivity. Even with only recovery and non-recovery outcomes, the station case can involve observation, selection and correction. Conversely, several ending entries that simply select clips do not establish complex gameplay.
Third, nonlinear narrative and games need not coincide completely. The official Twine website introduces interactive nonlinear stories and simple creation without code. This shows stories can offer different reading paths, but cannot establish a specific work’s goals, challenges or rules.
Next time you see “interactive game,” choose one button, complete the three-step record and state the player’s goal. If you can describe only playback progress, provisionally identify viewing control. If you can explain how actions are accepted, processed against conditions and answered, you have found an interactive element worth experiencing further.


