Studio / ROBLOX
Whose hint is it? A personal-panel story in Roblox
In a fictional wind workshop, Asya changes her help page and Danya loses his own. Separate personal presentation, shared task progress and server world state before asking for a fix.
Open full-size image ↗A fictional workshop with two different pages #
This is a fictional teaching story about a separate prototype, not player feedback or a report of repairs to our games. Nika imagines a wind workshop where two participants assemble a model wheel together. The shared task has Foundation, Blades and Check stages. The team currently needs the blades. A wheel stands in the room, and each player's help button opens instructions.
Asya, labelled A, reads Attach a blade. Danya, B, has opened Rotate the camera to inspect the joint from the side. Asya turns her page. Danya suddenly receives that same page. He returns to camera help, but Asya's next action replaces his text again. Nika recognizes a boundary problem between two personal choices, rather than an issue with the button's dimensions.
1. A shared goal does not share everything #
In their imagined conversation, Danya asks, “We are building one wheel. Why must I read your line?” Nika has confused working together with reading in unison. Both participants need the shared stage, but each can consult a different hint and close it at a convenient moment.
Her early design used one current team help page value. Every page turn became an update to everyone. That is our chosen fictional cause; a similar symptom in a real project still needs diagnosis. Nika does not blame Roblox for automatically joining panels. She writes the unwanted behaviour precisely: A's input changes B's choice without a shared gameplay reason. Another developer can investigate that statement without guessing what “the interface is broken” actually means.
2. Give three kinds of state separate names #
Nika draws three lines. Personal presentation: whether help is open, which topic is selected and where this participant is reading. Shared progress: the stage of the team's assembly. World state: which parts are actually attached and what the wheel looks like. Rules may connect the latter two, but neither replaces the first.
Asya may read checking instructions early. Reading does not advance the team to Check or attach a blade. Closing a panel does not undo Danya's work either. For each field Nika identifies its owner, change source and readers. Owner here means the state responsibility boundary, not copyright ownership of a panel. The contract table describes this prototype's selected architecture, not universal rules for every cooperative game.
Open full-size image ↗3. PlayerGui identifies the relevant copy #
Roblox describes PlayerGui as a container for a player's interface. StarterGui holds initial elements copied into PlayerGui at the documented character-spawning point. An identical help template can therefore provide each participant with an individual instance, rather than one team reading page.
The container does not repair a mistaken handler. Logic that still broadcasts Asya's chosen topic or edits both copies can produce the unwanted result despite separate instances. Nika distinguishes the appearance template from the current reader's state. Her handover says, “Opening, closing and choosing a topic belong to the person who pressed.” There is no code here and no promise that moving one object solved the problem. A clear contract comes before implementation and verification.
4. Start the corrective contract with ordinary reading #
Nika chooses a simple rule: A opening help shows A's panel only; A changing topics changes A's choice; A closing help leaves B's panel alone. On server S these inputs neither advance assembly nor change parts. In this prototype, personal presentation is locally controlled, without sending every page turn to the team.
This is not a ban on server-side personal data. If a saved preference is later required, design it separately with ownership for the specific player. Persistence is not added in this story. Nika replaces the ambiguous request “update help” with an explicit list of fields each action may change. Another developer receives the boundaries of the proposed fix instead of having to infer whether every input should affect every screen.
| State | Responsibility | Change source | Does not change |
|---|---|---|---|
| Help visibility | Each player’s personal UI | Own open/close input | B’s panel or S’s assembly |
| Topic and reading position | Individual reader | Own selection/scrolling | Another participant’s choice |
| Personal text language | Own player’s presentation | Personal language setting | B’s language or team stage |
| Team task stage | Shared server source | Work under prototype rules | Need not open everyone’s help |
| Attached parts | Server-confirmed world | Permitted gameplay action | Not inferred from a read page |
| Current stage heading | Shared fact shown in personal UI | Current S information | Does not select B’s topic |
5. Both players still need the shared stage #
Nika notices the opposite mistake: ignoring shared progress entirely might leave help describing a finished stage. She retains the server's team-state source. Work genuinely completed according to the prototype's rules changes it; client text displays confirmed information. Next page is not permission to alter the world.
A changed stage should supply both participants with current information, without forcing both into the same topic. In this design the stage heading updates, closed help stays closed, and an applicable reading topic remains selected. A shared fact is not an instruction to turn everybody's page. If client messages are used, choose recipients by the data's meaning: an individual reply differs from a team update. Delivery alone does not establish that the state belongs in the right place.
6. Give outdated help a clear transition #
Asya is reading blade instructions when the team reaches Check. Nika chooses the behaviour beforehand: preserve the personal panel's visibility, show “Stage changed: now Check,” and offer the current topic. Clearly mark old content if it no longer applies. It should not silently masquerade as the current task.
This is a design decision, not an automatic PlayerGui feature. Nika asks that late information be associated with the current stage and selected topic, so an old reply cannot overwrite a newer personal choice. Until implemented, that association is a requirement. Automatically opening everyone's help at every event is unnecessary. Each participant keeps a reading path, while the team receives a clear common fact that can be checked.
7. Accessible help remains personal #
On her sketch Nika labels one area My help and another Team stage. Blue and orange alone cannot communicate that distinction: words identify ownership. The page includes a topic title and an understandable closing action. Larger text must not push those landmarks out of accessible space.
Roblox recommends considering readability, contrast and player preferences, and avoiding meaning conveyed only by sound or colour. These recommendations support presentation without choosing the data owner. Nika plans separate checks for long strings, navigation and closing on the required devices. She claims no ideal size and does not present our diagram as a screenshot of working UI. Personal help is useful when a participant understands both its text and whose actions can change it.
8. Translation changes wording, not the team stage #
In the design, Asya reads Russian and Danya reads English. Different sentence lengths and word orders can describe the same shared stage. An internal stage identifier must not depend on the translated heading. The page's owner does not change with its language either.
Roblox provides localization tools and manual translations. Nika uses them to prepare contextual phrases, not to compare displayed words for game logic. My help and Team stage receive complete translations. Arabic needs direction and mixed-label checks; Chinese needs wrapping review. Automatic translation does not prove that the screen distinguishes personal and shared information. Under our contract, A changing language neither chooses B's language nor advances the assembly. This is a proposed behaviour to verify, not a completed multilingual test.
9. Respawning does not answer the ownership question #
Nika adds A's respawn to the future plan. This version is intended to return A's personal help closed and read the current shared stage again. B continues using B's own panel. That is a selected policy, not a promise about every game's default behaviour.
GUI behaviour when a character spawns involves settings including ResetOnSpawn on LayerCollector, inherited by ScreenGui. Retaining a panel instance and restoring correct content are separate questions. Nika requests inspection of actual hierarchy and settings instead of relying on the deprecated blanket ResetPlayerGuiOnSpawn. We change no settings in someone else's project. A new visit, respawning and closing help remain separate cases; none independently promises retained reading between visits.
10. Leave the observation plan unfilled #
The final sheet starts with A reading Blades, B reading Camera and S holding the Blades stage. Separate cases cover turning a page, closing, closely spaced inputs from both players, changing the shared stage, a late update, respawning and languages. Expectations are defined first; the actual A/B/S cells remain blank.
If a future check finds B changing after A's personal input, record topic, order and shared stage before guessing a code line. Both panels receiving a new stage after genuine shared work may be correct. Never copy the server value into B's observation. The linked two-client guide explains launching separately. This story hands over ownership criteria rather than repeating Studio's buttons, and it cannot certify a prototype that was not run.
| Case / input | Contract expectation | A: actual | B: actual | S: actual |
|---|---|---|---|---|
| A turns pages while A/B read different topics | Only A’s reading changes; S is unchanged | — | — | — |
| A closes while B has help open | A closes; B continues reading | — | — | — |
| A/B choose topics close together | Each retains own choice; record input order | — | — | — |
| Team completes an action for the next stage | Current shared stage shown; personal visibility not forced | — | — | — |
| Old update after newer personal choice | Associate stage/topic; do not overwrite the newer selection | — | — | — |
| A respawns | Under chosen policy A closed; B unaffected; stage current | — | — | — |
| Different A/B languages and long text | Personal/team distinction clear; B language and stage unchanged | — | — | — |
| Read checking instructions early | Reading neither advances assembly nor installs parts | — | — | — |
11. Nika closes the diagram, not the investigation #
In the imagined ending, Asya turns her own page, Danya continues camera help, and reading does not alter the wheel. Nika attaches three state lines, recipient rules, stage-transition behaviour and a blank table to the project brief. This ending pictures the desired outcome; it is not a completed gameplay test.
Implementation remains ahead. Official sources, article text and diagrams were checked, but Studio, public servers and our games were not run. After making the change, a developer must verify the contract with two clients and required devices. The goal stays shared while each participant reads at their own pace. The useful outcome is an exact account of what belongs to a player, what belongs to the team and what the world confirms, rather than one vague help variable.
Original sources
Roblox Creator Hub — PlayerGuiRoblox Creator Hub — StarterGui
Roblox Creator Hub — Client-server runtime
Roblox Creator Hub — Remote events and callbacks
Roblox Creator Hub — LayerCollector / ResetOnSpawn
Roblox Creator Hub — Localization
Roblox Creator Hub — Accessibility guidelines
