--- id: phone-flashlight status: active supersededBy: [] lang: en title: Phone flashlight interactions description: >- Phone flashlight: actions, options, applications and limitations. Complete list from the discussion, with search and sources. intro: >- Author's working classification for designing games and interactions. Options can overlap and combine; the list is not a generally accepted standard or proven exhaustive list. Application examples are conditional unless a specific verifiable observation is indicated nearby. Sources support individual techniques and technical limitations. updatedAt: '2026-10-20' sources: - title: Android API url: >- https://developer.android.com/reference/android/hardware/camera2/CameraManager description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: Android url: >- https://developer.android.com/reference/android/hardware/camera2/CameraManager#turnOnTorchWithStrengthLevel(java.lang.String,int) description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: Apple url: >- https://developer.apple.com/documentation/avfoundation/avcapturedevice/settorchmodeon(level:) description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: W3C Image Capture url: 'https://www.w3.org/TR/image-capture/#dom-mediatrackcapabilities-torch' description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: Description of Android sensors url: >- https://developer.android.com/develop/sensors-and-location/sensors/sensors_overview description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: W3C about flares url: >- https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: maxAvailableTorchLevel url: >- https://developer.apple.com/documentation/avfoundation/avcapturedevice/maxavailabletorchlevel description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: 'W3C: MediaStream Image Capture' url: 'https://www.w3.org/TR/image-capture/' description: >- Primary source for individual techniques; does not confirm the entire author's classification. - title: 'Apple: Getting processed device-motion data' url: >- https://developer.apple.com/documentation/coremotion/getting-processed-device-motion-data description: >- Primary source for individual techniques; does not confirm the entire author's classification. counts: families: 12 branches: 12 variants: 120 url: 'https://gamemechanics.pro/en/mechanics/phone-flashlight/' markdownUrl: 'https://gamemechanics.pro/content/mechanics/en/phone-flashlight.md' license: CC-BY-4.0 codeLicense: MIT attribution: gamemechanics.pro contributors provenance: >- Original editorial design catalog consolidated from project discussions on 2026-10-20. Complete discussion item lists and contextual limitations are preserved; linked primary sources support specific techniques, not the entire classification. English translation was prepared with machine assistance and editorial review. --- # Phone flashlight interactions Author's working classification for designing games and interactions. Options can overlap and combine; the list is not a generally accepted standard or proven exhaustive list. Application examples are conditional unless a specific verifiable observation is indicated nearby. Sources support individual techniques and technical limitations. ## Mechanics catalog ### 1. Light control id: family-control canonicalId: phone-flashlight--family-control url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-control Ways to turn on, change and automatically turn off the flashlight. #### Variants and applications - Switch. Action: Click to turn on; press again to turn off. Application: Inspection of the room, switching game mode, normal lighting. Requirements: Rear LED and app control. Conditions: The application manages its state and checks the availability of the flashlight. - Light when held. Action: Shine while the finger holds the button. Application: Illuminate evidence, support the shield, occupy one of the player's hands. Requirements: Rear LED and app control; Software game rule. Conditions: Press and release events give accurate game input; loss of focus turns off the light... - Single impulse. Action: On command, briefly turn on the flashlight and turn it off automatically. Application: Photo hunting, short disclosure of the scene, confirmation of the action. Requirements: Rear LED and control from the application. Conditions: LED duration and delay vary by device; This is not an accurate laboratory strobe. - Light for a set time. Action: Select the duration of one continuous activation. Application: Secondary inspection, time window of action, household light timer. Requirements: Rear LED and app control. Conditions: Use the application timer, and do not measure time by real brightness. - Delayed activation. Action: Start the countdown to power up. Application: Set the stage, take position for the shadow task, start the round. Requirements: Rear LED and app control. Conditions: When an application goes into the background, the behavior must be checked on the target OS. - Brightness levels. Action: Select low, medium or bright light. Application: Close inspection, glare reduction, selection of gaming impact strength. Requirements: Rear LED and app control; Support brightness adjustment. Conditions: Power control required; the number of levels and actual illumination vary. - Smooth change. Action: Increase or decrease brightness during hold time. Application: Dawn in a miniature theater, setting up a virtual device. Requirements: Rear LED and control from the application; Support brightness adjustment. Conditions: Smoothness limited by available hardware stages; provide a discrete option. - Gesture control. Action: Tilt, turn or moderate shake to turn on the light. Application: Flashlight without searching for a button, imitation of a hand generator. Requirements: Rear LED and control from the application; Motion sensors and calibration. Conditions: Sensors detect the movement of the phone; random gestures need to be weeded out. - Sound control. Action: Turn on by voice command, clap or specified sound. Application: Busy hands, theater team, musical play. Requirements: Rear LED and app control; Microphone for external sound. Conditions: Microphone and recognition required; The loudness of the clap itself does not identify the player. - Automatic switching on by condition. Action: Turn on when it is dark, a recognized tag or a game event. Application: Adaptive inspection, entry into the game area, event light signal. Requirements: Rear LED and control from the application; Environmental sensor or chamber analysis replacing it; Software game rule. Conditions: Darkness requires an accessible sensor or camera; a game event can be purely programmatic. ### 2. Rhythm, time and light codes id: family-timing canonicalId: phone-flashlight--family-timing url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-timing The lights and pauses become a sequence to be created or read. #### Variants and applications - Short and long signal. Action: Transmit two distinguishable types of activation. Application: Binary response, simple commands to a friend, signal training. Requirements: Rear LED and app control. Conditions: The person can read light; The automatic recipient needs a camera or photo sensor. - Code number of inclusions. Action: Transmit the number in separate pulses. Application: Door number, selecting an answer option, indicating the number of items. Requirements: Rear LED and control from the application. Conditions: Separate messages with a long pause so as not to confuse adjacent numbers. - Morse code. Action: Encode characters with dots, dashes and pauses. Application: Spy quest, communication trainer, short phrase exchange. Requirements: Rear LED and app control. Conditions: This is a training or gaming connection, not a guaranteed emergency channel. - Password from durations. Action: Enter a sequence of different holds. Application: Open the virtual lock, repeat the character's knock. Requirements: Rear LED and control from the application; Software game rule. Conditions: Recognize input duration; LED serves as physical confirmation. - Password from pauses. Action: Maintain equal pulses by changing the intervals between them. Application: Secret rhythm, time puzzle, musical phrase. Requirements: Rear LED and app control; Software game rule. Conditions: Estimate intervals with tolerance rather than requiring perfect milliseconds. - Repeat the shown rhythm. Action: The application or partner shows the drawing; the player plays it. Application: Memory game, light “Simon”, learning to count. Requirements: Rear LED and control from the application; Software game rule. Conditions: The original sequence can additionally be shown with text or sound. - Getting on the beat. Action: Turn on the lights at specified moments in the music. Application: Rhythm playing, performance, group score. Requirements: Rear LED and app control; Software game rule. Conditions: Evaluate the command time and separately take into account the delay of the actual light. - Reaction to a signal. Action: Turn on or turn off after a valid signal, ignoring a false one. Application: Training of gaming attention, duel for reaction. Requirements: Rear LED and control from the application; Software game rule. Conditions: The competition requires the same delay and device rules. - Action in a window of time. Action: Keep the light only in the allowed phase of the cycle. Application: Go through a virtual patrol, activate the rotating mechanism. Requirements: Rear LED and control from the application; Software game rule. Conditions: Phases are set by the game; the real flashlight does not detect the patrol. - Delayed playback. Action: Record the light sequence and run it later. Application: Asynchronous riddle, light cue, repeat of the author's drawing. Requirements: Rear LED and control from the application. Conditions: Record commands and intervals; playback does not promise accurate optical synchronization. ### 3. Direction and movement of the phone id: family-movement canonicalId: phone-flashlight--family-movement url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-movement Posture, speed and trajectory turn the phone into a handheld tool. #### Variants and applications - Targeting. Action: Align the direction of the phone with the target. Application: AR pointer, exhibit selection, virtual spotlight. Requirements: Rear LED and app control; Motion sensors and calibration; Camera and spatial tracking; Software game rule. Conditions: Sensors provide orientation; binding to a specific real goal requires tracking or a tag. - Direction hold. Action: Do not move the phone out of the permissible angle for a specified time. Application: Stabilize the signal, study a virtual object, play for accuracy. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: It is possible to evaluate stability relative to the initial pose without recognizing the room. - Tracking a moving target. Action: Rotate the phone after the object. Application: Accompanying a virtual creature, guarding a moving load. Requirements: Rear LED and control from the application; Motion sensors and calibration; Camera and proprietary image analysis; Software game rule. Conditions: The real target requires video tracking; the game itself knows the virtual target... - Search by sector. Action: Consistently illuminate the directions around the initial pose. Application: In-game room scanner, overview of hidden virtual threats. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: Gyroscope needs calibration; it does not confirm that actual surfaces have been inspected. - Outline outline. Action: Swipe the phone along a given line. Application: Drawing a symbol, setting up an antenna, restoring a picture. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: Without a camera, a corner path is recognized, not a line on the wall. - Passage speed control. Action: Pass the light slowly or quickly without leaving the range. Application: Virtual scanning, image “developing”, musical glissando. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: Angular velocity can be estimated by sensors; the speed of the light spot requires the geometry of the scene. - Order of directions. Action: Shine up, down, left and right in the desired order. Application: Spatial password, dance team, ritual. Requirements: Rear LED and app control; Motion sensors and calibration; Software game rule. Conditions: Fix the frame of reference and tolerances before the start of the round. - Rotation around an axis. Action: Rotate the phone like a dial, maintaining the direction. Application: Select a conditional filter, scanner frequency or instrument mode. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: Program mode changes; the actual LED spectrum does not change depending on rotation. - Approaching the surface. Action: Change the distance to the object and the size of the illuminated area. Application: Selecting the scale of the shadow, examining the texture, AR task at a distance. Requirements: Rear LED and control from the application; Prepared props or external sensor; Camera and proprietary image analysis. Conditions: Automatic distance estimation requires a known marker, tracking or depth sensor. - Moving the source to a new point. Action: Move the phone relative to the object, and not just turn it. Application: Study the relief from the other side, get the desired shadow, explore the scene. Requirements: Rear LED and control from the application; Prepared props or external sensor; Camera and spatial tracking. Conditions: The actual displacement can be seen by a person; Coordinates for the game require positional tracking. ### 4. Occlusion and shadows id: family-shadows canonicalId: phone-flashlight--family-shadows url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-shadows The hand, object and screen become part of the optical interaction. #### Variants and applications - Light curtain. Action: Block the light with your palm or a separate card. Application: Manual telegraph, hiding the signal from an opponent, theatrical effect. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: LED does not notice the damper; automatic entry requires separate monitoring. - Adjustment by hole. Action: Change the size of the gap between cards or fingers. Application: Physical light controller, experiment with the shape of the spot. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: Do not consider this to be the measured position of the "slider" without a camera or other sensor. - Closing the camera and LED together. Action: Change the “closed/open” state, blocking the camera area. Application: Tactile switch, conditional gesture of a hidden flashlight. Requirements: Rear LED and control from the application; Camera and proprietary image analysis. Conditions: Camera dimming analysis is only indirectly related to LED occlusion; The geometry of the phones is different. - Shadow silhouettes. Action: Create a recognizable outline with your hand or a figurine. Application: Shadow theatre, guessing an animal, retelling a story. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: Players can evaluate the result themselves; automatic recognition requires a surveillance camera. - Combining the shadow with the sample. Action: Move the object and source so that the shadow matches the outline. Application: Spatial puzzle, silhouette assembly, physics puzzle. Requirements: Rear LED and app control; Prepared props or external sensor; Camera and proprietary image analysis. Conditions: Camera or person evaluates shadow; one gyroscope is not enough... - Shadow scaling. Action: Change the distance between the source, object and surface. Application: Adjust the key to size, show the character's height, study the projection. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: Clarity depends on source size and distance; the beam does not become laser... - Rotate the shadow. Action: Rotate a volumetric object to the desired projection. Application: Recognize an object by silhouette, find a hidden letter, spatial puzzle. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: Prepare objects with truly distinguishable projections. - Assembling a general shade. Action: Combine the shadows of several objects into one sign. Application: Cooperative coat of arms, a puzzle made from scattered parts. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: The geometry must be verified with a physical mockup; the match does not occur automatically. - Shadow corridor. Action: Move the figurine so that its shadow remains within the acceptable area. Application: Board game of dexterity, sheet maze, cooperative challenge. Requirements: Rear LED and app control; Prepared props or external sensor; Camera and proprietary image analysis. Conditions: To calculate the result, you need a camera with a view of the field or a hand-held judge. - Recognition by shadow movement. Action: Identify an object or event by changes in silhouette. Application: Detective scene, guess the action, theatrical riddle. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: This is the player's interpretation; the application may not recognize the real silhouette. ### 5. Reflection, transmission and materials id: family-optics canonicalId: phone-flashlight--family-optics url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-optics The flashlight works with the prepared physical scene. #### Variants and applications - Reflected path. Action: Redirect the light with a mirror to a specified area. Application: Mirror maze, transmitting a signal behind an obstacle. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: LED beam is wide; short distances, screens and visibility checks are needed. - Illumination with sliding light. Action: Direct the light almost along the surface. Application: See relief, embossing, scratches or paper texture. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: This is a visual inspection, not a reliable forensic procedure. - Translucent paper. Action: Shine through a thin sheet or multilayer card. Application: Find a hidden mark, read a pre-prepared puzzle. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: Works only with sufficient light transmission and pattern contrast. - Combining transparent layers. Action: Fold translucent parts and highlight the result. Application: Assemble a card, develop the code from several films. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: Materials and order of layers are checked on a real layout. - Search for a reflective mark. Action: Look for pre-placed reflective elements. Application: Indoor treasure hunt, labeled tabletop map. Requirements: Rear LED and app control; Prepared props or external sensor; Camera and proprietary image analysis. Conditions: Result depends on angle and material; a camera near the LED is often more useful than a side view. - Glare puzzle. Action: Tilt a glossy object until the glare reveals or hides the detail. Application: Secret on a card, task on the viewing angle. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: You cannot promise the same glare for any surface. - Physical color filter. Action: Pass white light through the prepared color material. Application: Selecting a channel on a printed puzzle, changing the atmosphere of a mini-scene. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: You need proven paints and filters; The LED cannot be programmed to have an arbitrary color. - Stencil drawing. Action: Highlight a cut out outline on a nearby surface. Application: Faction sign, mask for shadow task, home theater. Requirements: Rear LED and app control; Prepared props or external sensor. Conditions: Sharp, complex projection will require suitable optics; regular LED not a projector. - An object that glows after being illuminated. Action: Light a suitable photoluminescent prop, then turn it off. Application: Leave a temporary hint, collect a route from markers. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: Efficiency depends on material, spectrum and time; check before choosing mechanics. - Scattering and refraction. Action: Change the pattern of light with a diffuser, prism or other optical part. Application: Caustic pattern, experiment with materials, artistic puzzle. Requirements: Rear LED and control from the application; Prepared props or external sensor. Conditions: The form of the effect depends on the props; use a dry, stable installation. ### 6. Search, camera and augmented reality id: family-camera canonicalId: phone-flashlight--family-camera url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-camera The camera observes the scene; a flashlight helps illuminate it or becomes part of the rule. #### Variants and applications - Illuminated mark. Action: Find and recognize a printed mark when the light is on. Application: Opening content for an item, home quest, museum card. Requirements: Rear LED and control from the application; Camera and proprietary image analysis. Conditions: The tag is read by the camera; Turning on the light does not in itself prove that the beam hit. - Inspection of an object by recognition. Action: Point the camera at the prepared class of objects. Application: Collection catalog, educational object hunt, game inventory. Requirements: Rear LED and control from the application; Camera and proprietary image analysis. Conditions: Recognition and testing on target objects are required; The flashlight does not recognize materials. - Comparison “lights off/on.” Action: Compare two frames of an almost motionless scene. Application: Find a changed area, evaluate the contribution of the backlight, experiment. Requirements: Rear LED and control from the application; Camera and proprietary image analysis. Conditions: Autoexposure and motion distort the difference; need stabilization and control of parameters. - Search by reflection. Action: Use the camera to notice the light response of the prepared object. Application: Find a reflective mark among ordinary ones, localize the target. Requirements: Rear LED and control from the application; Camera and proprietary image analysis; Prepared props or external sensor. Conditions: The algorithm distinguishes the prepared response, and not any valuable or metal object. - Stacked sight. Action: Hold the recognized object in the frame when the LED is on. Application: “Scan” evidence, register a find, read a game sample. Requirements: Rear LED and control from the application; Camera and proprietary image analysis; Software game rule. Conditions: Accumulation is the rule of the game; the real content of an object is not measured this way. - Traces visible only in the application. Action: Show virtual markers when the flashlight is active and the camera is pointed at the area. Application: AR detective, ghost hunting, hidden inscriptions. Requirements: Rear LED and app control; Camera and spatial tracking; Software game rule. Conditions: Traces are drawn by the application; white LED does not show random invisible ink. - Map of surveyed areas. Action: Mark areas where the player pointed the camera with the flashlight on. Application: Search for missed points, explore a virtual room. Requirements: Rear LED and control from the application; Camera and spatial tracking; Software game rule. Conditions: Tracking evaluates the view and does not guarantee actual coverage of each area. - Photo as confirmation. Action: After illumination, take a shot with the desired object or composition. Application: Photo hunt, proof of completion of a quest, collection of finds. Requirements: Rear LED and control from the application; Camera and proprietary image analysis. Conditions: You need a way to check the frame: person, tag or recognition; Photo storage is not necessary. - Glowing beacon in the frame. Action: Observe the LED as a conspicuous point with another camera. Application: Simple light guidance, prop tracking, signal laboratory. Requirements: Rear LED and app control; Camera and proprietary image analysis; Multiple devices/participants; sometimes an observer is enough. Conditions: One point provides limited data; flare, overlap and background interfere with tracking. - Several angles under different light. Action: Shoot a stationary object while moving the source. Application: Texture research, art documentation, relief restoration prototype. Requirements: Rear LED and control from the application; Camera and proprietary image analysis; Prepared props or external sensor; Multiple devices/participants; sometimes an observer is enough. Conditions: Accurate shape restoration requires calibration and algorithm; telephone light not ready 3D scanner. ### 7. Changing the game world id: family-world canonicalId: phone-flashlight--family-world url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-world All effects in this section are software; LED links the action on the screen to the feeling of light in the room. #### Variants and applications - Revealing the hidden. Action: Light makes the virtual layer of information visible. Application: Secret platforms, inscriptions, additional map. Requirements: Rear LED and control from the application; Software game rule. Conditions: Objects exist in the game or AR; real LED does not create a new layer of the object. - Charging an object. Action: Accumulate progress while the light is on or aimed at the target. Application: Charge the beacon, open the door, revive the mechanism. Requirements: Rear LED and control from the application; Software game rule. Conditions: This is virtual energy; The real battery of the device is not charged from the flashlight. - Destruction by light. Action: Reduce the strength of an object under prolonged illumination. Application: Remove virtual mold, destroy the dark shell. Requirements: Rear LED and control from the application; Software game rule. Conditions: No physical destruction is implied by conventional LED. - Restoration with light. Action: Restore the health or condition of a game entity. Application: Heal an ally, return color to the world, repair a virtual object. Requirements: Rear LED and control from the application; Software game rule. Conditions: Treatment applies only to the gaming system. - Growth and development. Action: Lighting promotes the virtual plant or creature to the next stage. Application: Puzzle garden, bridge growing, creature care. Requirements: Back LED and app control; Software game rule. Conditions: The flashlight does not reproduce the actual growth periods of plants using this rule. - Stopping movement. Action: Hold the target motionless while it is illuminated. Application: Freeze the enemy, stop the mechanism, hold the door. Requirements: Rear LED and app control; Software game rule. Conditions: If the actual target is important, an additional camera or tag is needed. - Starting the movement. Action: The illuminated object begins to move or work. Application: Start the elevator, wake up the robot, turn on the conveyor. Requirements: Rear LED and control from the application; Software game rule. Conditions: Real props need a photosensor or other control channel. - Change of state. Action: Translate an object between shapes or modes with light. Application: Solid/transparent, open/closed, ally/enemy. Requirements: Rear LED and app control; Software game rule. Conditions: The rule can be tied to turning on the LED without measuring the actual spot. - Creating a route. Action: Lighting temporarily makes the area passable. Application: Bridge of light, manifested staircase, path for a companion. Requirements: Rear LED and control from the application; Software game rule. Conditions: We are talking about virtual geometry; a physical room does not automatically become a safe route. - Logic "AND/OR/NOT". Action: Combine the illumination of several game targets. Application: The door is open with two active beacons and one extinguished. Requirements: Rear LED and control from the application; Software game rule; Multiple devices/participants; sometimes an observer is enough. Conditions: For real simultaneous purposes, receivers are needed; game logic can be read over the network. ### 8. Creature behavior, stealth and attention id: family-agents canonicalId: phone-flashlight--family-agents url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-agents Light changes the behavior of a virtual opponent or the rules of a matched live game. #### Variants and applications - Scaring away. Action: The illuminated target retreats. Application: Protection from virtual shadows, clearing the passage. Requirements: Rear LED and control from the application; Software game rule. Conditions: Real animals are not predictable game agents. - Luring. Action: The creature moves towards the light. Application: Bring a virtual companion, distract the enemy. Requirements: Rear LED and control from the application; Software game rule. Conditions: The reaction is set by the program or the agreed rules of the participants. - The gaze stops the enemy. Action: The enemy moves only outside the illuminated sector. Application: Horror for the distribution of attention, protection of several directions. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: A sector model is needed; virtual visibility is calculated by the game... - Short stun. Action: The impulse temporarily interrupts the action of the game target. Application: Parrying an attack, creating a window for escape. Requirements: Rear LED and control from the application; Software game rule. Conditions: The effect is virtual; do not direct real impulses into people's eyes. - Revealing the disguise. Action: Under the light, the real type of the creature is visible. Application: Search for the impostor, checking doubles, deduction. Requirements: Rear LED and control from the application; Software game rule. Conditions: For a live game, the role is revealed by a person or an application according to an agreed rule. - Masking by switching off. Action: Turn off the flashlight to reduce game visibility. Application: Stealth, hide and seek according to the rules, transition between shelters. Requirements: Rear LED and control from the application; Software game rule. Conditions: Actual visibility also depends on ambient lighting; it is not removed only from the LED state. - The compromise “I see and give myself away.” Action: Turning on helps exploration, but increases the risk of detection. Application: Horror, object hunting, tactical timing. Requirements: Rear LED and app control; Software game rule. Conditions: Game detection must have a clear rule and feedback. - A distraction aside. Action: Direct the source to another area to divert the agent's attention. Application: Rescue a companion, bypass security, control a crowd of virtual creatures. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: A real “light trail” for an agent requires external observation. - Accompanying an ally. Action: Keep a light on the companion or his path so that he moves forward. Application: Guide the character through the darkness, combine defense and navigation. Requirements: Rear LED and app control; Motion sensors and calibration; Software game rule. Conditions: The game evaluates its goal; tracking a person in a room is a separate task. - Forbidden target. Action: Illuminate useful objects without touching dangerous ones. Application: “Don’t wake a sleeping person”, puzzle for accuracy, test of attention. Requirements: Rear LED and control from the application; Motion sensors and calibration; Software game rule. Conditions: With a wide real beam, accurate target separation may not be possible without shielding. ### 9. Resource, risk and limitations id: family-economy canonicalId: phone-flashlight--family-economy url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-economy Modifiers create a choice of price and when to use the light. #### Variants and applications - Virtual battery. Action: Reduce reserve when the lights are on. Application: Survival, short reconnaissance missions, route planning. Requirements: Rear LED and app control; Software game rule. Conditions: Use a separate game resource; The actual phone discharge does not serve as a fair scale. - Power price. Action: The bright mode consumes the game reserve faster than the weak one. Application: Selecting the virtual viewing range and saving. Requirements: Rear LED and control from the application; Support brightness adjustment; Software game rule. Conditions: Game numbers are set by the designer; hardware levels do not correspond to the same luxes on different phones. - Limited number of pulses. Action: Give the player several activations before replenishment. Application: Photo hunting, scan deficit, decision based on incomplete information. Requirements: Rear LED and control from the application; Software game rule. Conditions: Count successful game commands, taking into account flashlight hardware failure. - Recharge between uses. Action: After the action, maintain a program pause. Application: Tactical parry, rare inspection, command sequence. Requirements: Rear LED and control from the application; Software game rule. Conditions: This is a gaming cooldown; does not require real heating. - The price of continuity. Action: The action is only useful after a long hold. Application: Risky scanning under attack, setting up a beacon. Requirements: Rear LED and control from the application; Software game rule. Conditions: The holding time should be manageable with one hand and should not require maximum light. - Accumulated series price. Action: Consecutive switching on increases the virtual load. Application: Choice between frequent resource search and restoration. Requirements: Rear LED and control from the application; Software game rule. Conditions: Reset and thresholds are set by software; iron temperature is not a game counter. - Exchange visibility for another action. Action: Maintaining the light takes a button, hand or mode. Application: You cannot light and interact with the tool at the same time. Requirements: Rear LED and app control; Software game rule. Conditions: Do not block real system functions; The restriction applies within the game. - Replenishment in a certain zone. Action: Restore game reserves only at stations. Application: Route between shelters, energy delivery, return to base. Requirements: Rear LED and control from the application; Software game rule. Conditions: The station can be virtual or recognized by a tag; This is not a phone charger. - Unstable instrument. Action: The game temporarily limits the light or warns of a failure. Application: Plot tension, repair, selection of a backup. Requirements: Rear LED and control from the application; Software game rule. Conditions: The failure is specified explicitly and should not mask a real hardware failure. - Total light budget. Action: The team has one supply or a limit on the number of active lights. Application: Distribute the roles of scout and guard, joint savings. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough; Software game rule. Conditions: State is synchronized by applications; actual battery consumption remains individual. ### 10. Cooperation, competition and communication id: family-multiplayer canonicalId: phone-flashlight--family-multiplayer url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-multiplayer Several sources, an observer or a separate light receiver appear. #### Variants and applications - Sender and observer. Action: One transmits light, the second reads and acts. Application: Asymmetrical quest, communication through a room window, code training. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough. Conditions: The recipient can be a person; automatic communication requires a camera or photosensor. - Light response-confirmation. Action: The second participant responds after receiving the message. Application: Ping test, shared password, challenge-response sequence. Requirements: Rear LED and app control; Multiple devices/participants; sometimes an observer is enough. Conditions: Devices can exchange data over the network; then light is an interface, not a transmission channel. - Message relay. Action: Everyone receives a drawing and passes it on. Application: Command memory, light “damaged phone”, chain of rooms. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough. Conditions: Reading errors become part of the game if explicitly stated in the rules. - Synchronous activation. Action: Multiple players turn on the lights in an agreed window. Application: Open a shared virtual lock, team rhythm. Requirements: Rear LED and app control; Multiple devices/participants; sometimes an observer is enough; Software game rule. Conditions: For an accurate estimate, use synchronized game clocks and latency tolerances. - Alternation of sources. Action: Players maintain lighting in turns without long pauses. Application: Role transfer, object tracking, general temporary bridge. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough; Software game rule. Conditions: The program can evaluate teams; continuous real light checks external receiver. - Several directions at the same time. Action: Sources illuminate different sides of the same scene. Application: Shadow puzzle, cooperative review, several virtual switches. Requirements: Rear LED and app control; Multiple devices/participants; sometimes an observer is enough; Prepared props or external sensor. Conditions: Design the real scene taking into account wide beams and mutual illumination. - Separated information. Action: One has a map or instructions, the other has a flashlight. Application: “Mineweeper” with a voice navigator, quest with a scout. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough; Software game rule. Conditions: Light gives an executive role; It is not necessary to recognize it by the camera for communication. - Finding the owner of the signal. Action: Match the visible picture with a given participant. Application: Search for a pair, acquaintance in a group, distribution of teams. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough. Conditions: This is a game ID that can be copied; he doesn't provide identification... - Channel blocking. Action: Place an obstacle between the source and receiver according to the rules. Application: Tabletop protection of the beacon, competition for line of sight. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough; Prepared props or external sensor. Conditions: An observer or sensor is required; Do not use the blinding of someone else's camera or person as a target. - Physical props management. Action: Shine on a photo sensor that turns on a separate device. Application: Quest castle, toy robot, interactive model. Requirements: Rear LED and app control; Prepared props or external sensor. Conditions: You need an external photosensor, controller and threshold taking into account external light. ### 11. Feedback, storytelling and atmosphere id: family-feedback canonicalId: phone-flashlight--family-feedback url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-feedback The flashlight becomes an output channel of the application, and not just a tool for the player. #### Variants and applications - Event confirmation. Action: After the action, briefly turn on the light or change its level. Application: Successful scanning, start of the stage, confirmation of the command. Requirements: Rear LED and control from the application. Conditions: Text, sound or vibration are also needed for the player looking at the screen. - Light timer. Action: Change light state as time approaches. Application: Round boundary, player turn, in-app reminder. Requirements: Rear LED and app control. Conditions: Do not expect continuous background work without checking platform conditions. - Conditional indicator of proximity. Action: Change the light pattern when approaching the game target. Application: “Hot-cold”, search for a virtual object. Requirements: Rear LED and control from the application; Software game rule. Conditions: Distance is taken from the game, tags, geolocation or tracking; LED doesn't measure it. - Device mode. Action: Assign game values ​​to different stable states of light. Application: Instrument readiness, alarm, safe zone. Requirements: Rear LED and app control; Software game rule. Conditions: White LED has a limited number of distinguishable states; don't overload the code. - Light in the rhythm of sound. Action: Accompany audio events by turning on or changing brightness. Application: Music installation, plot replica of the device. Requirements: Rear LED and control from the application; Microphone for external sound; Support brightness adjustment. Conditions: You don’t need a microphone for your music; for external, sound and delay analysis is required. - Plot glitch. Action: Turn off or dim the light at the intended moment. Application: Dramatic pause, loss of connection, appearance of a threat. Requirements: Rear LED and control from the application; Software game rule. Conditions: Provide a flicker-free version; Do not substitute this for a system warning. - Light replica of the character. Action: The character responds with the duration or pattern of switching on. Application: Robot companion, silent creature, talking through signals. Requirements: Rear LED and control from the application; Software game rule. Conditions: Answers are interpreted as conventional language, which must first be taught to read. - Lighting the real environment around the scene. Action: Change the light in the room synchronously with the game. Application: Thunderstorm without fast flashes, searching in the dark, scene inspection. Requirements: Rear LED and control from the application; Software game rule. Conditions: One telephone provides local light; The magnitude of the effect depends on the room. - Reproduction of someone else's action. Action: Show transmitted partner commands or recordings with a flashlight. Application: Asynchronous trace, “echo” of the researcher, light score. Requirements: Rear LED and control from the application; Multiple devices/participants; sometimes an observer is enough; Software game rule. Conditions: A distinction must be made between live network input and a pre-recorded sequence. - Channel coordination. Action: Duplicate light with sound, vibration, text or a large indicator. Application: Clear interface for different visual and hearing conditions. Requirements: Rear LED and control from the application; Software game rule. Conditions: The equivalent channel must preserve the meaning and time window of action. ### 12. Creativity, learning and everyday tasks id: family-practice canonicalId: phone-flashlight--family-practice url: https://gamemechanics.pro/en/mechanics/phone-flashlight/#family-practice Independent applications and adjacent options with a screen instead of a rear LED. #### Variants and applications - Local lighting. Action: Direct the light onto the work area and select a convenient angle. Application: Find an object, read the markings, inspect an accessible niche. Requirements: Rear LED and control from the application. Conditions: Range, glare and operating time are tested on a specific phone. - Reading and desk work. Action: Shine light on a page or part while holding the phone in a comfortable position. Application: Reading paper rules, working with a board game, assembling a layout. Requirements: Rear LED and app control; Prepared props or external sensor. Conditions: Requires a stable stand or a free hand; do not block the heat sink. - Photo and video illumination. Action: Use constant light for shooting instead of a short flash. Application: Product photography, stop motion, video communication with a suitable location. Requirements: Rear LED and control from the application; Camera and proprietary image analysis. Conditions: Constant flashlight and photographic flash are different camera modes. - Light painting. Action: Move the turned on LED in front of the camera with a long shutter speed. Application: Inscription with light, trajectory drawing, artistic photography. Requirements: Rear LED and control from the application; Camera and proprietary image analysis; Multiple devices/participants; sometimes an observer is enough. Conditions: You need a separate camera or another phone; The own rear camera does not see its LED directly. - Puppet theater. Action: Use the phone as a stage light for miniatures. Application: Home performance, fairy tale retelling, cut scene prototype. Requirements: Rear LED and app control; Prepared props or external sensor. Conditions: This is a human performance; Recognition of actions by the application is optional. - Optical experiment. Action: Change one variable: distance, angle, material or obstacle. Application: Show shadow, reflection and relative change in illumination. Requirements: Rear LED and app control; Prepared props or external sensor. Conditions: Quantitative conclusions require a calibrated meter; Do not consider the camera a ready-made light meter. - Training light simulator. Action: Perform tasks on code, sequence, counting or coordination. Application: Learn Morse code, repeat rhythms, discuss causality. Requirements: Rear LED and control from the application; Software game rule. Conditions: Improvement in game performance does not demonstrate transfer of skill or overall developmental effect. - Light as a visible indicator. Action: Designate a location or give a pre-agreed signal. Application: Find a participant in a controlled environment, mark a table or prop. Requirements: Rear LED and app control; Multiple devices/participants; sometimes an observer is enough. Conditions: The signal is dependent on visibility and does not replace guaranteed navigation or emergency aid. - Screen as a color source. Action: Show solid color, change brightness or use a physical mask. Application: Color codes, soft lighting of a small scene, filter puzzle. Requirements: Screen; separate alternative to LED; Prepared props or external sensor. Conditions: This is a separate light source with a different geometry and power; the rear LED color does not change. - The screen is like a virtual flashlight. Action: Open part of the screen scene with your finger, tilt or camera. Application: Search for something hidden in the image, simulator, accessible replacement for real light. Requirements: Screen; separate alternative to LED; Software game rule. Conditions: The screen spot is a graphic; it does not illuminate the real object with a narrow beam. ## Implementation requirements ### LED Description: Rear LED and app control ### I Description: Support brightness adjustment ### D Description: Motion sensors and calibration ### TO Description: Camera and proprietary image analysis ### AR Description: Camera and spatial tracking ### R Description: Prepared props or external sensor ### U Description: Multiple devices/participants; sometimes an observer is enough ### WITH Description: Environmental sensor or camera analysis replacing it ### M Description: Microphone for external sound ### IN Description: Software game rule ### E Description: Screen; separate alternative to LED ## 8 combinations for the prototype The scenarios below are provided as examples. They do not describe tested gaming products or testing results. Lighthouse in the dark sea Send a short code and wait for a light response. Each player has their own part of the map. Two participants, button and timers; camera not required. Mechanics: 011, 013, 091, 092, 097 Shadow Archive Select objects and angles to collect symbols for the castle on the wall. Telephone, cards and figures; the result is first assessed by a person. Mechanics: 014, 030, 035, 037, 038 Room with reflections Find the marks under the grazing light, then direct the reflected light to the receiver. Prepared tabletop stage; photo sensor only for automatic final. Mechanics: 041, 042, 045, 100 Night Watchman The light stops virtual creatures, but uses up the supply; turning it off hides the player. One phone and virtual stage; Sensors are only needed for steering control. Mechanics: 073, 076, 077, 081 Expedition for two The scout scans, the navigator reads the instructions; the team shares the lighting budget. Network state exchange; there is no need to recognize real light spots. Mechanics: 055, 087, 090, 097 Score of light Record a calm drawing, distribute the parts and play back with a common start. Timers, general score, wide synchronization tolerances. Mechanics: 017, 020, 094, 109 Traces in the room Recognize printed marks and show virtual traces over them when the flashlight is active. Camera, tags or AR; the white LED serves as a physical link to the action. Mechanics: 051, 056, 057, 061 Optical workshop Change distance and angle; compare shadow, reflection and translucency of materials. One telephone, simple materials and manual observation; quantitative measurements separately. Mechanics: 029, 036, 041, 043, 116 ## What to check before implementation Availability and accessibility of LED. The device may not have a flashlight; a camera or system may temporarily occupy its resources. On Android, control is done through CameraManager, and access conflicts are documented. Android API. Brightness adjustment. Android API 33 adds turnOnTorchWithStrengthLevel, but several levels are only available with appropriate hardware support. AVFoundation has setTorchModeOn(level:); the permissible maximum may be limited by heat. A normalized value does not mean equal physical illumination. Android, Apple. Web implementation. The Image Capture specification describes torch as a property of a video track. It is necessary to check the capabilities of a particular track and the actual behavior of the browser-device connection; The presence of a property in the specification does not promise universal support. W3C Image Capture. Feedback. The light sensor measures the light near the phone itself, the proximity sensor has its own sensitivity zone. They are not universal beam or rear LED occlusion sensors. Description of Android sensors. Camera at the same time as LED. Check the selected camera's API, exposure, autofocus, glare and light availability in the same session. When comparing frames, automatic exposure can hide actual lighting differences. Color, shape and range. A typical flashlight does not have portable control over arbitrary RGB color or image projection. The white LED does not turn into a UV source in software. Stencils, filters and lenses require a physical layout; The laser precision of the beam cannot be assumed. Temporal characteristics. Do not promise precise high-frequency pulses, optical transmission of large data streams, or laboratory strobe without measurements. For a prototype, slow drawings and noticeable pauses are better. Application life cycle. Check permissions, going into the background, screen lock, incoming call, camera opening by another application and hardware failure. The real temperature and charge of the phone should not be turned into a mandatory gaming resource. Comfort and accessibility. Provide for switching off pulses and an equivalent text, sound or vibration channel. Don't ask to shine a light in people's eyes or move in the dark. The WCAG threshold for flashing screen content is not a bright LED safety certification. W3C about flares. Checking the result. First, select the evaluation method: button state, sensors, camera, external receiver or person. Then test one complete cycle of “action → recognition → clear response” on the target device. All ideas in this catalog remain design examples pending such testing. ## How to use the catalog Separate player action, signal recognition, game rule, and feedback. The related variants here preserve the context of application and are not necessarily independent physical primitives. When prototyping, test one rule and failure conditions first. The presence of an API, sensor, or source does not prove that all scenarios work. For devices, test feature availability, calibration, and alternate input on the actual target hardware. ## Sources and examples Sources support particular techniques or methodology, not every family variant. Design examples and mechanic combinations are illustrative. - [Android API](https://developer.android.com/reference/android/hardware/camera2/CameraManager): Primary source for individual techniques; does not confirm the entire author's classification. - [Android](https://developer.android.com/reference/android/hardware/camera2/CameraManager#turnOnTorchWithStrengthLevel(java.lang.String,int)): Primary source for individual techniques; does not confirm the entire author's classification. - [Apple](https://developer.apple.com/documentation/avfoundation/avcapturedevice/settorchmodeon(level:)): Primary source for individual techniques; does not confirm the entire author's classification. - [W3C Image Capture](https://www.w3.org/TR/image-capture/#dom-mediatrackcapabilities-torch): Primary source for individual techniques; does not confirm the entire author's classification. - [Description of Android sensors](https://developer.android.com/develop/sensors-and-location/sensors/sensors_overview): Primary source for individual techniques; does not confirm the entire author's classification. - [W3C about flares](https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html): Primary source for individual techniques; does not confirm the entire author's classification. - [maxAvailableTorchLevel](https://developer.apple.com/documentation/avfoundation/avcapturedevice/maxavailabletorchlevel): Primary source for individual techniques; does not confirm the entire author's classification. - [W3C: MediaStream Image Capture](https://www.w3.org/TR/image-capture/): Primary source for individual techniques; does not confirm the entire author's classification. - [Apple: Getting processed device-motion data](https://developer.apple.com/documentation/coremotion/getting-processed-device-motion-data): Primary source for individual techniques; does not confirm the entire author's classification.