1. Every shared game still needs one owner
The owner creates the game and is responsible for its settings, participant list, and long-term session record. Other invited players may update scores, but the game should count against only the owner’s session allowance. This keeps ownership predictable even when several accounts can see the same scoreboard.
Display the owner inside the game when invited players are present. The label can stay subtle, but it answers an important question: who can make final decisions about access, settings, ending, or resetting the game?
2. Use an invite to connect an account to its player
An invite code should do more than copy a game. When someone joins, their account player is added to the existing game and the same session becomes visible in their account. From that point, score updates can move between devices in real time.
Treat the code like temporary access information. Rotate it after removing an invited player, or generate a new one when the owner no longer wants an older code to work. A removed person should not be able to rejoin with a code they already know.
Ask permission before automatically adding their account to a new game. If they disabled automatic invitations, start without them and share a new code from the active game.
3. Score access and game management are different
An invited player normally needs permission to update scores; that is the purpose of shared scorekeeping. Changing the target, timer, teams, participant list, or completion state is a broader responsibility. Keep those actions owner-only unless the owner explicitly allows invited players to manage the game.
- Score access: add or remove points during play.
- Management access: change settings, reset the score, manage players, or end the game.
The control should describe this distinction clearly. A label such as “Allow invited players to change settings, end, or reset” is less ambiguous than “Allow invited players to manage,” which can sound as if score updates are disabled too.
4. Keep invited identities distinct from local players
A saved player and an invited account can have the same display name while representing different people. Use a link or invite marker so the group can see which player remains connected to an account. Add a numbered suffix when identical names need to coexist inside one game.
If both entries represent the same person, merge deliberately. The interface should show which player stays, where this game’s score history moves, and which account receives the statistics. Do not silently replace a saved identity simply because the names match.
“John” saved in the owner’s roster is local to that owner. “John” who joined by code is connected to another account. They may look identical, but only the invited identity can see the shared game and receive its result automatically.
5. A shared history should show who changed the score
Each history entry should record the affected player, score change, resulting total, time, and the account player who made the update. “Updated by You” is useful on the current device; other devices should show the updater’s actual name and avatar.
Keep attribution after an invited player leaves. Their removal should stop future access, not erase who made earlier changes. Historical attribution is especially important when a large correction or final point changes the winner.
6. Removing a player must remove access immediately
When the owner removes an invited account player, that game should disappear from the removed person’s account and their device should receive a clear notice. Targeted real-time notification is better than waiting for periodic polling because it closes the permission window quickly.
If the group wants to play together again, share the new code or use an automatic invitation only when that account allows it. Previous participation can make future setup faster, but it should never override a person’s current sharing preference.