Turn content rules into a checklist
Write constraints that can be checked. A room may need one entrance, one exit, a reachable key, no blocked corridor, and a maximum of two new hazards. Dialogue might need to fit a visible text box and use the same name for a recurring character. An item description can be checked for a stated effect that matches the effect players observe. Keep subjective goals such as “mysterious tone” separate from structural rules like “the exit must be reachable.”
Check content in context, not only in a document
Put text into its real interface and test wrapping, contrast, timing, and interruption. A correct instruction can still be unusable if it disappears before a player can read it or is covered by a control. Confirm that subtitles or labels stay associated with the event they describe. If a room names a blue switch, verify that the object is visibly distinguishable and that interacting with it performs the promised action.
Questions about testing generated game content
Can generated game text be approved without playtesting?
No. Text should be reviewed in context, and any instruction, clue, or item claim that affects play should be checked against the behavior players encounter.
How do I test whether a generated level is solvable?
Check that the required route connects entrance to exit and then play through it using the intended controls. Visual inspection alone may miss blocked paths or misleading clues.