Start Building

Your 2D action game has levels, combat, save data, and solid performance. Before you ship, you need to catch bugs and tune the experience. In this lesson you will plan testing and quality assurance (QA): what to test, how to run playtests, how to track bugs, and how to balance difficulty and feedback so the game feels fair and stable.

By the end you will have a simple test plan, a way to record and fix issues, and at least one round of playtesting done (yourself or with others).

1. What to Test

Focus on the things that break the experience or make the game unfair:

  • Core loop: Start game, play a level, die or win, restart or continue. Does the save/load work? Do levels load correctly?
  • Controls and feel: Movement, jump, attack, and menus. Any input that does not respond or feels wrong.
  • Combat and difficulty: Can the player beat the first level without luck? Are enemies too cheap or too easy? Does the player understand what hurts them?
  • UI and feedback: Health, score, and HUD update correctly. Menus and buttons work. No missing text or broken layout.
  • Edge cases: Fall off the level, die at the same time as an enemy, quit during save, run out of ammo or health. The game should not crash or corrupt save data.
  • Target platforms: If you ship on desktop and mobile, test on both. Resolution, aspect ratio, and input (touch vs keyboard) can behave differently.

Write a short test checklist (one list per build or version) so you do not forget critical paths.

2. Playtesting

Solo playtest: Play through the game from start to finish. Note every bug, confusing moment, or unfair death. Do not fix as you go; write them down and fix in a batch so you see the full picture.

External playtest: Give a build to a friend or a small group. Watch them play (or ask for a short written or verbal report). Where do they get stuck? What do they misunderstand? Do they find bugs you did not? Fresh eyes catch UX and balance issues that you miss.

Structured feedback: Ask a few concrete questions: "Was the first level too hard, too easy, or about right?" "Did you understand how to attack?" "Did anything break or feel broken?" Keep the list short so testers actually answer.

3. Bug Tracking

You do not need a heavy tool. A spreadsheet or markdown file is enough:

  • Short description (e.g. "Player falls through floor in level 2 near the left pit").
  • Steps to reproduce (what you did right before it happened).
  • Severity: Critical (crash, data loss), Major (feature broken), Minor (cosmetic or rare).
  • Status: Open, In progress, Fixed, Won't fix.

Fix critical and major bugs before release. Triage minor ones; some can ship as known issues if they are rare and documented.

Verification: After fixing, retest the exact steps to confirm the bug is gone and that you did not introduce a new one (regression).

4. Balance and Tuning

Use playtest feedback to tune:

  • Difficulty: Adjust enemy health, damage, or count; player health or damage; checkpoint placement. Small changes (e.g. 10–20% more player health) can make a level feel fair.
  • Pacing: If a level feels long or repetitive, shorten it or add a checkpoint. If the opening is slow, tighten the first minute.
  • Feedback: If players do not notice they are taking damage or that they picked up an item, add clearer UI, sound, or screen effects.

Keep notes on what you changed so you can revert if a later test feels worse.

5. Stability and Regression

Before each release build:

  • Run through the main path (start to first win or game over) at least once.
  • Test save and load (save, quit, reopen, continue).
  • Test critical buttons (Play, Restart, Quit, Options if you have them).

If you have automated tests (e.g. Godot unit tests or small scripted scenes), run them before packaging. For many small projects, manual testing plus a short checklist is enough.

6. Checklist and Sign-Off

  • [ ] Test plan or checklist written.
  • [ ] At least one full playthrough (solo or with tester) completed.
  • [ ] Bugs logged and critical/major issues fixed.
  • [ ] Balance and feedback tuned from playtest feedback.
  • [ ] Save/load and main menu tested.
  • [ ] Build run on target platform(s) and no showstopper bugs.

When the checklist is done and you are happy with stability and feel, you are ready for Lesson 14: Export and Platform Preparation (building for Steam, Itch.io, or other stores).

Mini-Challenge

Play your game from a cold start to a win or game over. Write down every bug and every moment that felt confusing or unfair. Fix the top three issues and play again to confirm they are resolved.

Recap and Next Step

You planned what to test, ran playtests, tracked bugs, and tuned balance and feedback. QA is iterative: test, fix, test again. A small but stable and fun build beats a large, buggy one.

In Lesson 14 you will focus on Export and Platform Preparation: configuring Godot export presets, preparing store pages, and building for your target platforms so you can ship your game.

For more on QA and playtesting, see our game testing and help content. Found this useful? Bookmark the course and share your build with the community.