700 NPCs · repeated 60 FPS reference
All three full-gameplay confirmation runs satisfied the benchmark's frame-time and sustained-stability rules. The worst run's overall frame p95 was 13.09 ms.
The results at a glance
725–750 NPCs · transition zone
First sustained frame-time crossings occurred at 750, 725, and 750 NPCs. The 725 result was intermittent; only two gameplay confirmations reached 750.
1,000 NPCs · observed, not 60 FPS qualified
A discovery run reached 1,000 NPCs with working behavior and no reported functional errors, but its overall frame p95 was 23.13 ms.
1,037,427 matched operations
Across eight primary continuous ramps, completed work orders matched recorded effects. The tests reported no failed orders, invalid states, or exceptions.
Test machine: Intel Core i7-13700K, NVIDIA RTX 3080 Ti, 64 GB RAM, Windows 11 Pro, Unity 6000.6.0f1, Mono Windows x64 standalone player, 1280×720.
Why we ran this test
NPCs that merely stand in a scene are not a useful measure of a work-scheduling system. We wanted to observe many agents performing independently varied jobs as the population increased without resetting the simulation or erasing their work history.
The test began at 24 NPCs and added more to the same running environment. Workers followed varied schedules, traveled to destinations, used resources, recovered from interruptions, and completed jobs. Every registered NPC was evaluated on each engine tick in this deliberately intensive configuration.
We measured two configurations: F, full gameplay, with Unity NavMesh movement, simple capsule characters, and procedural animation; and S, scheduling diagnostic, which substituted simplified logical movement and removed rendering/animation work. They are different workloads, not interchangeable measurements of navigation overhead.
What happened as the population grew?
The charts preserve the measured progression rather than presenting one invented continuous run. Each independently started run is shown on its own elapsed-time scale. Insertion, settling, and settled measurements are distinguished.
Chart key: Orange marks insertion; grey marks settling; blue marks full-gameplay observations; purple marks scheduling-diagnostic observations.
Key measured populations
Values below are the worst full-interval p95 among qualifying runs at that population, not an average across modes. Reference stability also requires that no run have three consecutive late 10-second windows above the limit.
| Configuration | NPCs | Qualifying runs | Worst frame p95 | 60 FPS reference status |
|---|---|---|---|---|
| Full gameplay (F) | 700 | 3 of 3 | 13.09 ms | Stable in all 3 |
| Full gameplay (F) | 725 | 3 of 3 | 16.12 ms | Intermittent late-window crossing |
| Full gameplay (F) | 750 | 2 of 2 reached | 19.26 ms | Crossing observed; no 3-run claim |
| Full gameplay (F) | 1,000 | 1 discovery | 23.13 ms | Above reference; exploratory only |
| Scheduling diagnostic (S) | 725 | 3 of 3 | 13.89 ms | Stable in all 3 |
| Scheduling diagnostic (S) | 750 | 3 of 3 | 17.06 ms | Crossing in all 3 |
Download aggregate results (CSV) Explore time-series observations (CSV) · Read the detailed findings
What we learned
The work system remained functionally correct in the tested runs. The measured transition was primarily a performance threshold. It does not establish that the plugin stops functioning at 750 NPCs.
Processing cost grows with workload and time. CPU engine/facade timing was the leading measured cost. Examination of retained work-order history identified one plausible contributor to increasing overhead as a session ages. Its exclusive causal contribution has not been proven, and no optimization is claimed in this B1 report.
Performance depends on the game around the plugin. Character models, animation, rendering, world simulation, physics, developer-provided jobs, pathfinding, hardware, and runtime configuration can all change the practical result. This study used a deliberately simple environment, not a production game or MMO deployment.
Methodology and limitations
Each qualifying population interval used 60 seconds of settling followed by 120 seconds of measurement. We required three complete independent confirmations for repeated-stability claims. A 60 FPS reference corresponds to 16.67 ms; the study also monitored 10-second p95 windows and next-update responsiveness. Runs affected by Editor/report activity were excluded from repeated stability claims. Failed or incomplete observations remain disclosed in the accompanying data.
The environment was a 320 m workyard with simple capsule actors and a fixed arrangement of work locations. Resources replenished immediately, so scarce-resource competition was not tested. These NPCs followed independently varied deterministic routines; the benchmark does not claim full autonomous game AI. The 30 FPS functional and critical breaking points were not established. Long-term stability at a fixed population, other hardware, other backends, and a complete game workload were not qualified.
Some memory/CPU/GPU and allocation counters were unavailable. The engine timing includes game-defined callbacks and is not an isolated measurement of a single plugin method. Hardware and history conditions must accompany any comparison.
Bottom line: On this specific Windows test system and workload, 700 NPCs repeatedly met the 60 FPS reference. The live growth test identified a performance transition around 725–750 NPCs and provides a reproducible starting point for future optimization. It is not a universal NPC-capacity guarantee or a commercial-release certification.