Start Building

Your FPS has gameplay, multiplayer, and graphics in place; the next step is testing and quality assurance so it runs reliably and feels good before you invite beta players. This lesson covers how to test systematically: playtesting for feel and bugs, performance and stability checks, and a simple QA checklist you can run before beta and launch.

By the end you will have a clear testing workflow, a checklist for core FPS systems, and a plan for catching critical bugs and performance issues early.

Why testing matters for FPS

In an FPS, small bugs can ruin the experience: shots that do not register, movement that glitches through walls, or frame hitches during combat. QA is not just "playing the game"; it is methodically verifying that movement, combat, AI, UI, and performance meet a bar you define. Doing this before beta saves time and keeps feedback focused on design and balance instead of broken features.

Pro tip: Test on your minimum-spec target machine (or a build that matches it). If it runs well there, it will scale up; the reverse is not true.

Step 1: Define your quality bar

Before testing, decide what "good enough" means for your project.

  1. Performance

    • Target frame rate (e.g. 60 FPS at 1080p on minimum spec).
    • Acceptable load times and memory usage.
    • No sustained hitches or freezes during combat.

  2. Stability

    • No crashes in normal play (e.g. 30-minute session).
    • No progression blockers (e.g. stuck in geometry, unable to complete a level).
    • Multiplayer: no desync or drop-outs under normal conditions.

  3. Core loop

    • Movement, shooting, and damage feel correct and consistent.
    • AI and encounters behave as intended.
    • UI and HUD show correct information and do not block gameplay.

Write these down in a short quality bar document so you and any testers know what to check.

Step 2: Playtest for feel and obvious bugs

Structured playtesting catches both "something feels off" and clear bugs.

  1. Movement and controls

    • Walk, sprint, crouch, jump on flat ground, slopes, and edges.
    • Check for getting stuck, sliding, or clipping through geometry.
    • Verify look sensitivity and keybindings (including gamepad if supported).

  2. Combat

    • Fire weapons in single-player and (if applicable) multiplayer.
    • Confirm hits register, damage is applied, and feedback (effects, sound, UI) is correct.
    • Test edge cases: shooting through thin walls, at very long range, or during lag.

  3. AI and encounters

    • Run through key encounters; confirm enemies spawn, patrol, and react.
    • Check that difficulty and pacing match your intent (e.g. no trivial or impossible fights).

  4. UI and flow

    • Menus, HUD, and in-game prompts (e.g. objectives, pickups).
    • Ensure nothing is missing, misaligned, or blocking the view in critical moments.

Keep a bug list (spreadsheet or tool) with: short description, steps to reproduce, severity (critical / major / minor), and status. Fix critical and major issues before beta.

Step 3: Performance and stability checks

Use Unreal’s tools and a repeatable pass to catch regressions.

  1. Profiling

    • Session Frontend or Unreal Insights: capture a typical play session (movement, combat, several encounters).
    • Look for GPU or CPU spikes, long frame times, and heavy draw calls or ticks.
    • Compare before and after big changes so you do not ship a performance regression.

  2. Stress and duration

    • Play for at least 30 minutes (or your target session length).
    • Visit multiple levels or areas; trigger lots of combat and effects.
    • Watch for memory growth, slowdown over time, or crashes.

  3. Multiplayer (if applicable)

    • Test with 2+ clients; verify movement, shooting, and damage stay in sync.
    • Try different network conditions (e.g. high latency) if possible.
    • Confirm host migration or reconnection does not leave the game in a bad state.

Common mistake: Only testing on a high-end machine. Always run a pass on minimum-spec (or equivalent) before calling the build "ready for beta."

Step 4: Build a QA checklist

A short, repeatable checklist makes sure nothing is skipped.

Suggested FPS QA checklist:

  • [ ] Movement: No stuck or clipping; sprint/crouch/jump work on slopes and edges.
  • [ ] Weapons: All weapons fire and deal damage; ammo and reload behave correctly.
  • [ ] AI: Enemies spawn and react; no obvious pathfinding or behavior bugs.
  • [ ] UI/HUD: Health, ammo, crosshair, and objectives display correctly.
  • [ ] Performance: Meets target FPS on minimum-spec; no sustained hitches in combat.
  • [ ] Stability: No crash in a 30-minute session; no progression blockers.
  • [ ] Multiplayer (if applicable): 2+ players can play; no major desync or drop-outs.
  • [ ] Settings: Key graphics and input options work and persist.

Run this checklist on every candidate build before beta or release. Add or remove items to match your game.

Step 5: Automate what you can

Automation does not replace playtesting but can catch regressions quickly.

  1. Unit tests (optional)

    • If you have critical logic in C++ or Blueprint (e.g. damage formulas, inventory), consider simple unit tests so changes do not break them silently.

  2. Automated performance

    • Use Unreal’s built-in performance tests or a short automated run (e.g. fixed path through a level) and record frame time and memory.
    • Compare runs before and after changes to spot regressions.

  3. Smoke tests

    • A "smoke" pass: launch game, load main level, move, shoot, open menu, exit. If that fails, do not spend time on deeper QA until it is fixed.

Even a small amount of automation (e.g. one smoke run per build) helps keep the baseline stable.

Troubleshooting

Game crashes after a few minutes

  • Use the crash reporter and call stack; fix the top frames first. Common causes: null pointers, out-of-bounds access, or runaway loops. Check recent changes in that code path.

FPS drops in specific areas

  • Profile that area: too many lights, overlapping effects, or expensive AI can cause spikes. Reduce draw calls, LODs, or script cost as needed.

Multiplayer desync

Testers find "feel" issues but no clear bug

  • Capture video and compare with a reference (e.g. a game you consider tight). Tweak input response, animation timing, or feedback (camera, sound, VFX) in small steps and re-test.

Mini challenge – QA pass

Before moving to beta testing:

  • [ ] Write down your quality bar (performance, stability, core loop) in a few bullet points.
  • [ ] Run through the QA checklist above (or your version) on the current build and log any failures.
  • [ ] Fix at least one critical or major bug if you found any.
  • [ ] Do one 30-minute stability run on your minimum-spec target (or closest available).

Recap and next steps

You defined a quality bar, ran playtests for feel and bugs, used profiling and stress tests for performance and stability, and set up a QA checklist and light automation to keep the build in shape. With this in place, your FPS is in a good position for beta testing and community feedback, which is the focus of the next lesson.

For more on Unreal testing, see Unreal Engine Testing and Optimization. For performance, revisit Lesson 12: Performance Optimization & Scalability.

Frequently asked questions

How much testing is enough before beta?
At minimum: no critical bugs, core loop (movement, combat, AI, UI) working, and performance and stability meeting your quality bar on minimum-spec. More passes and testers reduce risk.

Should I use a bug tracker?
Yes, even a simple spreadsheet helps. For teams, tools like Jira, Linear, or GitHub Issues keep bugs from getting lost and let you prioritize.

What if I am a solo dev?
Run the QA checklist yourself on every release candidate; ask a friend or two to play for 30 minutes and report the top three issues. That already catches many problems before wider beta.

How do I test multiplayer without a second machine?
Use Play → Number of Players in the editor to run multiple windows; one is the listen server. For more realistic tests, use two machines on the same network when you can.

Found this useful? Bookmark it and run your first full QA pass before inviting beta testers.