five-on-it / packages/missions/src/phone
packages/missions/src/phone
Each player's phone (GAME_DESIGN §7.5), as the mission interpreter keeps it: plain data, deterministic, part of the runtime's state. The phone is an item (phone, in the simulation's common items) the character carries; what it holds are its entries, kept here per player and sent to that player alone: the contacts, the messages (each with the replies it offers, until one is sent), the apps installed, the call log, the waypoint on the minimap and the camera (its built-in app: how many photos it took and what the last one says; the host works out what was in the frame). Without the item the entries stay, out of reach: the phone opens nothing, a call goes unanswered. The phone also shows what the world opens without it: a terminal's screen, a keypad, a conversation face to face.
Contacts, dialogues and apps are a mission's (its contacts, dialogues, apps): a conversation, an app installed and a screen open belong to the mission run that opened them and go when it ends; the contacts and the messages stay (a reply to a message of a run that ended is not offered any more), and so do the calls and the waypoint.
A mission's help line (its helpline, one of its contacts) is always in the phone while it runs and always answers: a call that no dialogue of theirs answers plays the hint of what is under way.
The functions here take a PhoneContext, the runtime's view of the player's step: the mission running, its conditions and actions, its events. Every choice, button and reply is checked when it is picked (its if): the game only checks, and "hacking" is choices, timers and items, never code.