BC-0104 · CORE GUIDE
Editorial review 2026-09-26
Who Can Play a Newly Published Build Game?
Newly published Build games initially target age-checked players age 16 or older, with regional exceptions. Creator eligibility and player access are separate questions; a younger creator's access to Build does not establish the same audience for their published game.
Objective
Identify the default player audience without confusing it with creator or private-tester eligibility.
Before you start
- Name the role and public destination involved in the access question.
- Read the current default-audience and regional-exception wording together.
- Keep any broader-audience review status separate from publication status.
Steps
- Classify the question as creator, tester or published-player access.
- Compare the actual restriction with the current audience rule.
- Check the displayed audience or review state through the legitimate creator workflow.
- Record unresolved access details without unnecessary personal information.
- Use the specific audience-review guide when broader access is the goal.
Verification
- The answer names the player audience rather than recycling the creator age requirement.
- Regional exceptions remain attached to the default rule.
- A successful publication is not described as universal access.
- Review eligibility and a completed favorable review remain separate states.
Limitations
- This page cannot inspect a private account or determine an individual's eligibility.
- No age workaround or audience-approval promise is offered.
- The role examples are explanatory scenarios, not tests of real users.
Working notes
Start by identifying whose eligibility you are checking. The account creating the game, a person entering a private test and a player opening the published experience are different roles. Do not move a requirement from one role to another merely because the same account may sometimes perform more than one task.
Separate published state from audience reach. A visible project or reported successful publication is not proof that every intended player can enter. Use the current audience information and the actual access message to understand the observation. A regional exception should not be hidden behind a broad worldwide-access headline.
Treat broader audience evaluation as its own workflow. Meeting an entry condition is not a completed content review, and creator prerequisites remain distinct from game eligibility. Use the dedicated Select guidance for that decision rather than changing the game's description to imply an audience that has not been approved.
Prepare a privacy-conscious access record if the result is confusing. Record the intended public destination, the visible restriction and the task role being checked. Do not collect another person's identity documents, password or private account details to diagnose access, and do not suggest altering age information to bypass a restriction.
Examples
- Role split: creator access asks whether the account can use the creation workflow; private-test access asks about the available invitation route; published-player access asks about the released game's current audience. Keep separate evidence for each column.
- Hypothetical observation: the creator can edit the game, but an intended player sees an age-related restriction at the public destination. This does not by itself show a failed publication or a broken game script.
- Audience review note: current audience / desired audience / documented entry conditions / review status actually shown / remaining restriction. An unsubmitted or pending review is not approval.