Functional Testing of Gameplay Systems
What this domain tests
This domain tests whether you can verify that gameplay systems produce correct, persistent, and observable outcomes across normal and edge conditions: combat, inventory, quests, progression, economy, UI, save and load, and AI.
Core rules
- Define an oracle before testing: design document, accepted behavior, prior build, or platform requirement.
- Test system interfaces, not just screens: inventory capacity against loot drops, quest state against save and load, currency against purchases.
- State persistence is functional: save, quit, reload, and platform suspend or resume must not duplicate or lose items, progress, or currency.
- Exercise negative and adversarial paths: full inventory, zero health, maximum level, duplicate item IDs, and clock changes.
- Debug and cheat commands help reach states quickly, but confirm the retail acquisition path as well.
- Verify the underlying state, not only the UI text that describes it.
Worked example
A quest rewards a sword when the player's inventory is full. The design says the reward should go to overflow mail and the quest should complete. Actual behavior: the quest completes and the item disappears. The oracle is the economy design, and the failure is a reward-grant state transition, not a UI bug. The tester saves and reloads before and after turn-in to confirm the item is truly lost rather than hidden. The reasoning: system testing follows the item through inventory, quest state, and persistence.
Traps
Testing only the happy path; calling random outcomes bugs without checking rates or seeds; verifying UI strings instead of inventory state; ignoring save and load; using debug commands and never testing the retail path; missing economy duplication through stacking or mail.