BC-0098 · CORE GUIDE
Editorial review 2026-09-26
Roblox Build Playtest Checklist
Use a playtest checklist that records expected and observed behavior for normal play, invalid actions, failure and retry. Keep result fields blank until inspected, and attach every observation to the version and input method actually tested.
Objective
Maintain a version-specific gameplay regression checklist with honest coverage.
Before you start
- Identify the candidate version and intended input method.
- Write the game's success, failure and retention rules.
- Prepare result fields without automatic completion marks.
Steps
- Check whether the opening communicates a usable goal.
- Exercise the required controls and inspect their feedback.
- Try both valid progress and an action that should not count.
- Reach failure and completion through meaningful state changes.
- Retry from relevant outcomes and compare restored state.
- Record defects, uncertainty and untested contexts, then assign the next verification action.
Verification
- Each completed row contains an actual observation linked to a version.
- Invalid actions and repeated triggers have been considered, not only successful play.
- Reset checks follow progress rather than merely reopening an untouched scene.
- Device and tester familiarity limits remain visible.
- A later revision receives its own relevant regression observations.
Limitations
- This is a proposed checklist, not evidence that a generated game passed testing.
- It does not verify private account settings, publishing approval or every device.
- Specialized systems need additional checks beyond the core interaction matrix.
Working notes
Begin with the route through the game, not a prefilled pass list. Identify the opening goal, necessary controls, meaningful progress event and ending. For each, write the visible outcome you expect. Add invalid or incomplete-objective cases so the checklist does not only confirm the path you already know how to complete.
Test state transitions across attempts. A collectible that works from a fresh start may remain absent after failure. An outcome panel may block controls after retry. Run a meaningful sequence through progress, failure and another attempt to reveal stale state that isolated checks can miss.
Record coverage boundaries alongside results. A mouse inspection does not confirm touch comfort, and a familiar creator's run does not establish first-use understanding. Use not checked for unavailable conditions. Keep access to the testing surface separate from the behavior observed after entering it.
When the candidate changes, rerun the checks affected by that change and the nearby protected behaviors. Retain the earlier report as history instead of silently carrying its passes into the new version. A completed worksheet is a local test record, not a publishing approval or a comprehensive security review.
Examples
- Blank row format: version—fill; input method—fill; starting state—fill; action—fill; expected visible result—fill before running; observed result—fill afterward; decision—pass, defect, unclear or not checked; follow-up—record if needed.
- Sequence row: from a fresh attempt, approach the exit without the required parcel; then collect it, fail and retry; finally attempt a valid delivery. Record whether completion, carrying and collectible state follow the intended rules at each stage.
- Revision coverage example: a layout change near the depot requires checking route reachability, arrival feedback and retry location. Keep unrelated untested devices marked untested; do not expand a successful route check into an all-device pass.