Detailed
Reports are written from the actual playthrough, not from memory afterward. I document bugs, confusion, friction, polish issues, and player reactions as they happen.
Sample Report Structure
See what goes into a D Rock Games playtest report.
This page shows the structure and depth of a typical D Rock Games playtest and QA report. Instead of showing a watered-down fake report, this preview explains what each section covers and why it matters.
Every report is personally written by me, Derek Larson, sole owner of D Rock Games LLC. Reports are built to be practical, honest, detailed, and easy for developers to prioritize.
Report Philosophy
Not just notes. A full breakdown of the player experience.
Practical
The goal is to help you decide what matters most. I focus on issues that affect clarity, game feel, first impressions, player trust, and demo readiness.
Developer-Aware
I understand that indie games are built under real constraints. Feedback is direct, but it is meant to help you improve the build, not bury you in vague criticism.
What The Report Includes
Playtest and Quality Assurance Report
Prepared by Derek Larson / D Rock Games LLC
Structure Preview
Report Format
Full Playtest Report Breakdown
The final report is usually delivered as a written document covering the full playthrough, major issues, scoring, priority improvements, and final recommendations.
1. Cover Page
The report begins with a clean cover page showing the game title, developer or studio name, and D Rock Games LLC branding. This makes the report feel like a finished professional deliverable instead of a loose collection of notes.
2. Report Overview
This section explains the purpose of the report and sets expectations. It clarifies that the feedback focuses on player experience, technical stability, UX clarity, performance, presentation, and demo readiness.
3. Game / Test Info
4. At a Glance
This is the quick executive summary. It gives the developer a fast read on the state of the build before they get into the full notes.
Demo Readiness
A direct call on whether the build feels ready for players, festivals, streamers, or Steam traffic.
Wishlist / Keep Playing Reaction
Whether the game made me want to continue, wishlist, or return after improvements.
Biggest Strength
The strongest part of the build, such as concept, visuals, atmosphere, mechanics, or presentation.
Biggest Priority Fix
The one issue I would address first because it has the biggest impact on the player experience.
5. Scoring Wrap-Up
This section gives category scores with short explanations. The numbers are not meant to reduce the game to a score. They are there to help the developer quickly see which areas are strongest and which areas need attention first.
Narrative / Story
Score + Notes
How well the story, premise, setup, dialogue, and world context support the experience.
Gameplay Loop
Score + Notes
Whether the core actions are fun, understandable, repeatable, and strong enough to carry the build.
UI / UX / Player Clarity
Score + Notes
How clearly the game communicates objectives, interactions, menus, prompts, feedback, and player direction.
Controls / Game Feel
Score + Notes
How movement, camera, input response, combat, interaction timing, and general responsiveness feel during play.
Puzzle / Level Design
Score + Notes
How well the layout, puzzle logic, navigation, landmarks, progression, and exploration flow work for a first-time player.
Audio / Atmosphere
Score + Notes
How music, sound effects, ambient audio, UI sounds, and atmosphere support the intended player experience.
Visual Presentation
Score + Notes
How the game looks overall, including style, readability, polish, lighting, animation, effects, and presentation quality.
Performance / Stability
Score + Notes
Whether the build runs smoothly and whether crashes, stutters, bugs, or major technical problems appeared during testing.
Demo Readiness
Score + Notes
Whether the build feels ready to represent the game publicly, especially for festivals, Steam traffic, streamers, or press.
Overall Player Experience
Score + Notes
The overall impression after factoring in fun, clarity, friction, presentation, bugs, and whether I would keep playing.
6. Detailed Gameplay Notes
This is usually the longest and most in-depth section of the report. It is written during the playthrough and covers everything I notice as a first-time player, including small polish issues, major blockers, confusing moments, bugs, UI problems, audio notes, controls, pacing, Steam page feedback, menu impressions, onboarding, settings, and anything that affects player trust.
The goal of this section is not to make the report look long. The goal is to capture the real player experience as it happens. If I get confused, I write down where and why. If an interaction feels wrong, I explain what happened. If something works well, I call that out too.
Feedback on the Steam page, capsule art, short description, trailer, screenshots, genre clarity, player expectations, and whether the page properly sets up the experience.
Notes on first impression, menu clarity, button feedback, hover states, volume defaults, settings behavior, quit prompts, and whether the menu feels polished.
Feedback on graphics settings, audio sliders, accessibility basics, resolution behavior, input options, controller support, and whether settings function as expected.
Notes on tutorials, first objective, control teaching, player direction, early confusion, prompt timing, and whether the player understands what to do without outside explanation.
Detailed observations from the actual play session, including movement, interactions, combat, puzzles, navigation, readability, pacing, frustration points, and player decision-making.
Bugs, collision issues, broken triggers, input problems, camera issues, animation problems, audio cutoffs, UI bugs, progression blockers, soft locks, and anything that makes the build feel unstable.
Broader suggestions that may improve clarity, polish, retention, or player comfort, such as map readability, brightness, feedback, pacing, objective design, or feature expectations.
7. Priority Improvements
After the detailed notes, I pull out the highest-impact fixes. This is where the report becomes easier to act on. Instead of leaving the developer with a giant list, I identify the changes I would prioritize first.
- Critical player experience issues. Problems that may cause players to quit, misunderstand the game, or lose trust in the build.
- Technical or QA problems. Bugs, collisions, input issues, broken interactions, crashes, or problems that make the build feel unstable.
- Clarity and onboarding fixes. Moments where the player needs better direction, stronger prompts, clearer feedback, or better early guidance.
- Polish improvements. Audio, UI, animation, settings, visual feedback, and small changes that make the build feel more complete.
8. What Worked Well
This section highlights the strongest parts of the build. I do not only focus on problems. I point out what already works so the developer knows what to protect, expand, or lean into.
- Strongest gameplay ideas
- Best presentation elements
- Moments that felt fun or memorable
- Systems or choices that already support the game well
9. What Confused Me
This section isolates confusion points. These are often the exact moments where real players stop engaging, get frustrated, or assume something is broken.
- Unclear objectives
- Missed controls or mechanics
- Confusing UI or prompts
- Moments where the game did not explain itself clearly enough
10. Final Thoughts
The report ends with a direct summary of the overall experience. This is where I explain the main strengths, biggest concerns, and what I believe should happen next.
My goal is to be honest without being dismissive. If the build has serious issues, I will say so. If the core idea is strong, I will say that too. The final thoughts section is meant to leave the developer with clarity, direction, and confidence about what to improve next.
Want This For Your Game?
Get detailed feedback before players decide for you.
Send your game details and I’ll personally review the request. If it is a good fit, we’ll confirm the best playtest scope for your build.
Request a Playtest