Testing Man 2: What Actually Happens When You Run It
I've spent way too many evenings chasing down why Man 2 Gameplay Test Part 1 behaves differently on three machines in my LAN setup. The process itself is straightforward, but there are enough quirks that you'll waste an afternoon if you don't know what to expect upfront. Let me walk you through how it works and where things fall apart. First, grab the latest build from the official repository. The file is roughly 4.2 gigabytes compressed, and it comes as a self-extracting archive. Extract it to a directory without spaces in the path — I learned that the hard way when my test run failed at 87% with a cryptic permission error that turned out to be nothing more than the installer choking on a folder named "Games Folder (Test)." Rename it to something like C:\Man2Test and you're golden. Once extracted, run the setup executable as administrator. It'll prompt you to verify your Steam credentials or Epic account, depending on which platform you're using. This part is mandatory. Skipping it doesn't work even in offline mode because the test harness needs to register your machine's hardware signature against the test server. I tried running it with a cracked version once. The launcher loaded for about thirty seconds, then threw a null reference exception I'd never seen before. Stick to the legitimate build.
After installation, launch the test client. You'll see a main menu with three options: Run Diagnostic, Start Performance Benchmark, and Review Past Results. Select Run Diagnostic first, every single time. It checks your GPU drivers, VRAM allocation, and shader cache compatibility before committing to a full test run. This step takes about four minutes on a modern rig, ten on older hardware. Don't skip it even if you're confident your system meets the requirements. I skipped it on a machine with updated NVIDIA drivers and got corrupted benchmark output that looked fine on the surface but was actually off by 12% on frame pacing. The diagnostic would have caught a driver version mismatch between 552.86 and 552.89.
Running the Actual Test
When you start a benchmark run, the client loads a pre-rendered sequence that measures frame times, input latency, and thermal throttling behavior across a three-minute gameplay segment. The sequence covers urban navigation, a combat encounter, and a traversal section. Each segment is designed to stress different parts of the pipeline: CPU physics during navigation, GPU rasterization during combat, and draw call volume during traversal. What most people miss is that the benchmark doesn't just measure raw FPS. It generates a frame time graph and a GPU utilization curve that you can export as a CSV. That data is where the real insights live. Looking at the average FPS number alone will mislead you. I once had a friend claim his midrange RTX 4060 Ti handled the test beautifully because the average hit 78 frames. When I asked for the CSV, the frame time graph showed a massive spike at the 2:14 mark where it dropped to 23 frames for nearly two seconds. That was the traversal section hitting a streaming bottleneck — the asset pack hadn't been fully cached after a fresh install. Here's the workaround I use now before every test run: delete the shader cache folder at AppData\Local\Man2Test\Cache\ShaderDB, then run the diagnostic again. Fresh shader compilation on the first run causes a stutter that looks like a performance problem but is really just compilation overhead. After the diagnostic rebuilds the cache, subsequent runs show the actual steady-state numbers. This cuts my retest rate from about one in four to maybe one in twelve.
Get the Full Details
Interpreting the Results
The results screen gives you a letter grade from F to A based on a composite score that weights frame consistency heavier than peak FPS. An A requires maintaining 95th percentile frame times within 16 milliseconds and keeping GPU utilization above 80% for more than 70% of the run without thermal throttling events. A C grade allows 95th percentile between 24 and 32 milliseconds. Most systems that look decent on paper land in the B-to-C range because they can't sustain boost clocks under the sustained load this test applies. The report also includes a compatibility flag section. If your display adapter or audio driver isn't on the validated list, you'll see a yellow warning icon next to those components. This doesn't mean the test failed. It means the developers haven't tested against your specific hardware combination. I ran into this with a Realtek audio driver version 6.0.8918 that caused a periodic audio desync during the combat segment, pulling my composite score down from a B+ to a C-. Swapping to the Windows-provided HD Audio driver eliminated the issue entirely and boosted the score back up without any gameplay changes. One thing the test doesn't cover and you should know about: it measures single-threaded CPU performance in the navigation section but doesn't stress multi-core scaling. If you're running on a Ryzen 9 or Threadripper with uneven core scheduling, the test will pass with flying colors while your actual multiplayer sessions stutter because the game engines thread affinity isn't set correctly. I fixed this by setting the process affinity manually through Task Manager to cores 0 through 7 on an 16-core system and pinning the game thread to the performance cores exclusively. That resolved the multithreaded stuttering that the benchmark never detected.
Common Pitfalls
Don't run the benchmark while other applications are using the GPU, even background apps like Discord overlay or Xbox Game Bar. They introduce enough variable overhead to skew the frame time graphs in ways that make your results look worse than they actually are during clean play. I had to rerun a benchmark twice because I forgot to close RGB control software that was updating lighting profiles in the background, and the first two runs showed a 6% degradation in sustained performance that disappeared on the third clean run. Also, if you're testing on a laptop with hybrid graphics, make sure the power plan is set to Highest Performance and that the benchmark process is explicitly assigned to the dedicated GPU in your graphics settings. Windows defaulting to the iGPU will give you artificially low scores that don't reflect actual capability. The test itself won't stop you from running on the wrong adapter, so that's on you to verify before pressing start. The test client also stores your results locally in a JSON file at AppData\Roaming\Man2Test\Results\. You can use this to compare runs over time or share screenshots of your frame time graphs on forums for troubleshooting. I keep a log of every test run with the corresponding driver version and power plan settings, which has saved me from chasing ghost issues when performance degraded unexpectedly after a routine Windows update.
