This is an independent applied QA exercise based only on public information about Bradley the Badger and transferable QA experience. It does not use private builds, internal tools, proprietary documentation, confidential material or any direct involvement with Day 4 Night Studios. All trademarks belong to their respective owners.
Public materials describe Bradley the Badger as a systemic, player-driven action-adventure built around creative interaction tools, traversal, puzzle solving and a strong player-facing identity. This case study uses that public framing to show how I would structure embedded QA support for a similar project: identifying player-facing risks early, validating emergent interactions, protecting progression state, and turning findings into clear, actionable information for design, engineering and production.
Public reference material
This independent QA exercise is inspired by publicly available material about Day 4 Night Studios’ Bradley the Badger. The trailer and official website are included only as public context for the type of systemic action-adventure being discussed.
Official Bradley the Badger trailer, embedded from YouTube as public reference material.
This video is hosted by YouTube. Playing it may allow YouTube/Google to process data according to their own policies.
What this demonstrates
- Risk-based embedded QA thinking that targets where overlapping gameplay systems are most likely to break.
- Progression, persistence and save/load coverage that protects player state across checkpoints, reloads and interruptions.
- Clear, Jira-style defect reporting with reproducible steps and evidence built for fast triage and handoff.
Risk profile
A systemic action-adventure combines character control, traversal, camera behavior, player tools, puzzle logic, objective state and persistence. Risk-based testing should focus on the places where those systems overlap and where a small state mismatch can damage player-facing quality.
- Character control and camera readability: Responsiveness, recovery, framing and target visibility need to hold up in tight spaces, vertical routes, combat pressure and transition-heavy areas.
- Traversal and spatial understanding: Reachability, collision, route readability and environmental feedback must remain clear when players approach spaces from different angles and speeds.
- Systemic player tools and emergent interactions: Player-driven mechanics can create valid but unexpected solutions. QA should test not only intended paths, but also wrong order, wrong target, repeated use, save/reload interruption and boundary cases.
- Puzzle and objective state: Interaction order, trigger timing and objective updates can leave guidance, prompts or progression flags in contradictory states.
- Save/load, checkpoint and progression state: World state, player position, rewards, unlocks and objective progress need to restore consistently after checkpoint restore, reload and interrupted sequences.
- Release regression and build stability: Iterative builds can introduce regressions across traversal, camera, UI/UX validation, scripting, persistence and build verification flows.
What I would test first
The first pass would prioritize high-impact flows that can block progression, hide valid solutions or create misleading player guidance.
Core feel and traversal
Why it matters Movement quality defines trust in a character-driven game and becomes the baseline for every other feature.
What could break Input delay, animation locks, collision gaps, clipping, failed recovery or unclear traversal affordances can make basic play unreliable.
Validation Run focused traversal passes across open spaces, tight routes, slopes, ledges and transitions while varying speed, angle, input timing and recovery states.
Camera and spatial readability
Why it matters Players need a stable view of threats, routes, interactive objects and objective cues before they can make good decisions.
What could break Geometry can occlude the character, framing can drift, target visibility can fail or the camera can recover too late after transitions.
Validation Check occlusion, camera collision, target visibility and recovery in dense spaces, puzzles, combat-adjacent moments and rapid direction changes.
Systemic interaction and puzzle logic
Why it matters Player tools and environmental rules should support valid emergent solutions without corrupting puzzle or objective state.
What could break Prompts can conflict, triggers can duplicate or fail, repeated actions can break state, or valid alternate solutions can look invalid.
Validation Test intended and non-linear orders, wrong targets, repeated use, boundary cases, interrupted actions and save/reload during interaction changes.
Objective flow and narrative state
Why it matters Story beats, objectives and UI guidance need to stay aligned so players understand the next meaningful action.
What could break Objectives, markers, prompts or dialogue state can become stale after cutscenes, backtracking, interruption, checkpoint restore or reload.
Validation Track objective state through each beat, interrupt transitions where possible, revisit completed areas and compare HUD, world cues and journal state.
Save/load and progression state
Why it matters Persistence failures can turn a recoverable issue into lost progress, blocked progression or a release-readiness risk.
What could break Position, rewards, unlocks, objective flags, puzzle state or world changes can diverge after reload, checkpoint restore or build updates.
Validation Run save/load testing around objectives, rewards, ability use, area transitions and off-path choices, then regression-test fixes against nearby states.
Example QA charters
Exploratory testing should be structured around specific risks, evidence goals and production decisions, not treated as random free play.
Movement, Camera and Traversal Readability
Goal Confirm the character remains controllable and readable across representative spaces.
Focus Input response, animation recovery, collision, route clarity, camera framing and occlusion.
Potential risks Lost orientation, clipping, unreadable routes, blocked movement and camera recovery failures.
Interaction Order and Puzzle State
Goal Find state issues caused by non-linear or repeated player actions.
Focus Prompt priority, trigger timing, systemic tools, alternate solutions, interruption and repeated use.
Potential risks Duplicated triggers, stale prompts, invalid state, missed rewards and unrecoverable puzzle setups.
Objective Flow After Story Beats
Goal Verify objectives, UI guidance and world state stay aligned after narrative transitions.
Focus Story beats, cutscenes, backtracking, markers, journal state, dialogue state and interrupted sequences.
Potential risks Stale objectives, misleading guidance, perceived blockers and unclear next steps.
Save/Load Around Progression Changes
Goal Stress persistence when progression state changes or is interrupted.
Focus Checkpoint restore, reload, objective flags, player position, rewards, unlocks and nearby world state.
Potential risks Lost progress, state mismatch, reverted unlocks, broken prompts and hard-to-reproduce regressions.
Sample QA artifact · Sample bug report
Interaction prompt persists after objective state changes
Hypothetical, illustrative defect report structured for Jira-style triage and clear evidence handoff.
- Build / Platform
- Hypothetical PC build
- Severity
- Medium
- Priority
- Medium
- Repro rate
- 5/5
- Player impact
- Misleading prompt may cause dead interaction and perceived progression break.
- Steps
- 1. Complete objective A. 2. Trigger the cutscene or transition that starts objective B. 3. Return to the previous objective location. 4. Observe the interaction prompt.
- Observed
- The previous interaction prompt remains visible, but no valid interaction occurs.
- Expected
- The prompt should be removed, disabled or replaced after the objective state changes.
- QA note
- This should be regression-tested against objective transitions, save/load, checkpoint restore and reload from nearby states.
How this maps to my QA background
This approach reflects the type of QA work I focus on professionally: Senior Game QA, Embedded DevQA, iterative build validation, gameplay systems testing, UI/UX feedback, progression risk, regression coverage and clear evidence handoff for development teams.
Reporting and communication
Defect reporting should give design, engineering and production enough context to make a fast, confident decision.
- Record build, platform, input method, location, account or save state, reproduction steps and repro rate.
- Separate observed result, expected result and player impact so routing is clear.
- Flag whether the finding is a technical defect, UI/UX validation issue, design risk or regression coverage candidate.
- Attach video, screenshots or save-state evidence when timing, camera state, objective state or persistence is part of the defect.
The handoff should reduce ambiguity, support prioritization and make follow-up validation easier in later builds.
Regression and release-readiness value
A practical regression backbone keeps iterative builds focused on the flows most likely to break before a release.
- Run build verification and smoke checks on boot, input, core loop, objective flow, save/load and recently changed high-risk systems.
- Focus regression coverage on changed systems, adjacent dependencies and known player-facing risk areas.
- Perform fix verification against the original symptom, nearby states and likely side effects.
- Track known issues with status, player impact, workaround, owner, release risk and escalation needs.
The output is a clear release-readiness view: what passed, what remains uncertain and which risks need action before they become blockers.
In summary
This case study demonstrates a practical embedded QA mindset: identify risk early, test beyond the happy path, separate technical defects from UX and design risks, provide clear evidence, and help the team make confident decisions before issues become release blockers.