Blog

“The game supports keyboard controls” is not an acceptance criterion. It does not identify the keys, the resulting actions, the game state in which input is valid, or the evidence needed for approval. A testable version is narrower: “While a round is active, pressing the left and right arrow keys moves the player in the corresponding direction, and no movement occurs after the round ends.”

Turning descriptive prose into observable behavior is a core development skill. It gives programmers a concrete implementation target, helps testers separate defects from preferences, and prevents contributors from interpreting the same short specification in different ways.

Separate source facts from implementation decisions

Start by copying every explicit fact from the specification into a requirements worksheet. Do not improve the wording yet. Mark missing details as unresolved instead of silently filling the gaps. A short browser-game description may mention input, objectives, challenge, and expected play time while leaving screen sizes, failure behavior, accessibility, persistence, or performance undefined.

Classify each statement with one of three labels:

• Source requirement: a behavior or constraint stated directly in the specification.
• Derived criterion: a testable condition needed to verify a source requirement.
• Project decision: a choice made by the team because the source does not specify it.

This distinction keeps testing accurate. If a specification says that the arrow keys control movement, a criterion may verify those keys. Adding WASD support could be a useful project decision, but it must not be presented as a source requirement.

Use a repeatable criterion format

A practical acceptance criterion identifies a starting condition, an action or event, and an observable result. The familiar Given–When–Then structure works well, though plain sentences are fine when they retain the same information.

1. Given a known state of the game,
2. when the player acts or a defined event occurs,
3. then the interface or game state produces an observable result.

For example: “Given that the game is paused, when the player presses a movement key, then the player character remains in its current position.” The criterion names the state, stimulus, and outcome. A tester can reproduce it without guessing what “pause works correctly” means.

Keep one principal behavior in each criterion. Combining movement, scoring, sound, pause behavior, and restart logic in one sentence makes failures harder to diagnose. Smaller criteria also map more cleanly to unit tests, browser automation, and manual test cases.

Use disclosed fields to define the requirement set

A concise specification may distribute important behavior across several fields rather than present it as a formal requirements list. Identifying those fields determines which groups belong in the acceptance suite—not just how individual criteria should be phrased.

Ludibre browser-game documentation combines controls, rule summaries, difficulty labels, and session ranges, showing which disclosed fields can become project acceptance criteria. These four fields appear together in this particular source; that does not mean every game catalog or specification follows the same structure.

For this project, the useful action is to create requirement groups for all four disclosed fields instead of extracting only visible controls and winning conditions. Controls and rules often translate directly into functional checks. Difficulty and session range are less readily reduced to binary results, so they need measurable project interpretations or an explicit note that verification remains unresolved. Documentation fields identify testing dimensions, but they do not automatically supply every threshold required to approve a build.

Translate each field without changing its meaning

Controls

Control documentation usually produces the most direct criteria. Record the input, the valid state, the triggered action, and any relevant restriction. Avoid broad statements such as “mouse input is supported.” A stronger version might say: “Given an active round, when the player selects a visible target with the primary pointer button, then that target receives the documented action exactly once.”

Test boundary states as well as the normal path: before the game starts, while it is paused, after success or failure, and when focus leaves the game area. If mobile or assistive input is not mentioned, record it as a product question rather than assuming support or exclusion.

Rule summaries

Rules describe permitted actions, state changes, scoring, success, and failure. Convert each independent rule into at least one positive test and, where useful, one boundary or negative test. If collecting an item increases the score, verify both the triggering collision and the amount added. Also check that merely approaching the item does not alter the score.

A rule summary may leave interactions between mechanics unexplained. A decision table can expose those gaps:

The status column stops an assumption from being mistaken for source evidence.

Difficulty labels

A label such as easy or hard is descriptive, not testable on its own. Do not assign it a universal meaning. Identify the variables that create challenge in this project: speed, available time, number of hazards, opponent behavior, permitted errors, or required precision. The product owner can then approve measurable values.

A useful criterion compares a declared configuration with an observable property: “When hard mode is selected, the hazard movement speed uses the approved hard-mode value.” Deciding whether that value deserves the label may require playtesting rather than a conventional pass-or-fail functional test. Treat configuration verification and player-experience evaluation as separate checks.

Session ranges

A stated session range is not a guaranteed completion time. Player skill, random events, and optional actions can affect duration. Begin by defining a session: one round, a complete run, or the period between starting play and reaching an end state. Then identify which conditions the software controls.

For a timed round, a criterion can verify the timer directly. For an untimed puzzle, an expected range may be better treated as a playtest measure with a defined participant group and task. Record observed completion times without turning a small test into a universal promise.

Add quality constraints beside gameplay behavior

Functional criteria explain what the game does, but a browser project also needs bounded quality checks. Choose thresholds that suit the project and its supported environment instead of copying arbitrary values.

• Compatibility: name the supported browsers, versions, viewport sizes, and input devices.
• Performance: define how load time or frame behavior will be measured, including the device and network conditions.
• Persistence: state whether progress, settings, or scores survive refreshes and new sessions.
• Accessibility: verify documented keyboard operation, focus visibility, labels, contrast requirements, and alternatives to audio-only cues where applicable.
• Security and privacy: validate untrusted input, avoid exposing secrets in client-side code, and collect only the data the project requires.

Security tests must remain within systems you own or are explicitly authorized to assess. Browser developer tools, automated test runners, and proxy tools can support defensive checks in a local or approved test environment. They should not be used to probe unrelated services.

Build traceability into the criteria

Assign every source statement an identifier such as CTRL-01, RULE-03, DIFF-02, or TIME-01. Give each acceptance criterion its own identifier and link it to one or more source statements. The result is a lightweight traceability matrix:

Traceability makes change reviews safer. When a rule changes, the team can find the affected criteria and tests without searching the codebase for related wording. It also reveals source statements with no verification and tests that no longer correspond to a requirement.

Review criteria before implementation

A short review with a developer, tester, and product owner can remove ambiguity before it becomes code. For each criterion, confirm that it is observable, limited to one principal behavior, linked to a source or recorded decision, and executable in a defined environment. Replace subjective terms such as “smooth,” “fast,” “intuitive,” and “challenging” with approved measures or a documented evaluation method.

Resolve the worksheet one row at a time. For CTRL-01, record the supported keys, active and inactive game states, expected position change, and assigned automated browser test. If any cell is unknown, mark it “decision required.” That small label keeps an unverified assumption from entering the build as if it were part of the specification.