The Quick Brown Fox 2: The Silent Hordes
Implementing High-Performance AI at Scale with FSM_API
In our previous article, we introduced the "Quick Brown Fox and Lazy Sleeping Dog" demo. We showed how FSM_API allows you to decouple agent data from behavior, creating a clean architecture where a Fox could detect a Dog, transition to a "Jumping" state, and (hopefully) land safely.
It was a simple, controlled test. But FSM_API isn't just for handling one fox and one dog. It is built for the Singularity.
So, we asked a harder question: What happens when 66,000 agents try to coexist in a rapidly expanding universe?
To answer this, we built "The Gauntlet."
The Setup: A Dynamic Stress Test
We took the exact same FSM definitions from our simple demo—Walking, Jumping, Sleeping, Chasing—and dropped them into a stress-test environment designed to break them.
- The World: An infinitely expanding 1D grid that grows automatically to accommodate population density.
- The Agents: Thousands of "Foxes" traversing the grid and thousands of "Sleeping Dogs" acting as dynamic landmines.
- The Logic: We implemented Spatial Hashing to allow agents to query their neighbors efficiently. Foxes look ahead; if they see a dog, they jump. If they land on a dog, it wakes up. If a dog wakes up, it chases.
This isn't just a benchmark of raw loops; it is a benchmark of state integrity. Every single agent is a fully independent FSM Context running its own logic cycle.
The Results: The "Tip of the Iceberg"
We ran the simulation until the framework hit the limits of a standard development machine (maintaining \~30 FPS). The final snapshot tells a brutal story:
| Metric | Count | Context |
|---|
| Total Agents | 66,000 | A population larger than many real-world towns. |
| Dogs (Hazards) | 19,711 | Nearly 20,000 active threats monitoring the field. |
| Foxes (Dead) | 27,362 | Casualties of "bad luck" RNG (landing on a dog). |
| Foxes (Alive) | 18,927 | The survivors pioneering the edge of the world. |
The "Silent" Stress Test
While the death count is tragic (RIP to the 27,362 foxes who failed their jump checks), the most shocking metric wasn't the carnage—it was the activity level.
At peak load, with nearly 20,000 dogs monitoring the field, only 2 were awake.
Why This Matters for Performance
This "boring" stat is the ultimate proof of the FSM_API's architecture. In a naive implementation, checking 20,000 AI agents for targets usually kills the CPU. But here, the simulation remained playable at 30 FPS because the FSMs efficiently handled the "Idle Load."
- The Hidden Workload: Every single frame, 38,000+ alive agents
are evaluating their Transition Conditions.
- Dogs: "Is anything touching me?"
- Foxes: "Is there a dog in the next cell?"
- Live Action Metrics:
- Active Chases: ~2 to 12 dogs awake at any moment.
- Fleeing Foxes: ~1 to 5 foxes sprinting for their lives.
- Jumps per Frame: ~600 foxes airborne right now.
This creates a self-balancing ecosystem. The API is maintaining the memory and state integrity of 66,000 objects simultaneously, but because the "Sleeping" state logic is lightweight, the system can handle thousands of them for free. However, the system retains the Burst Potential to handle chaos: if a swarm of Foxes lands on a pack of Dogs, those Dogs will wake up, transition to "Chasing," and execute complex logic instantly.
From "Hello World" to "Production Scale"
We went from a simple demo with one fox to managing 66,000 active, logic-driven entities without changing the core FSM definitions.
We aren't just simulating the "action movie" moments of chases and jumps; we are simulating the quiet complexity of a living world. The fact that 19,000 dogs can sleep efficiently while monitoring their surroundings proves that the FSM_API is ready for scale.
What's Next?
We are currently hitting a ceiling around 70,000 agents due to the overhead of string-based state lookups (e.g., checking CurrentState == "Sleeping" thousands of times per frame).
In our next update, we are refactoring the backend to use Integer Hashing. Our early benchmarks suggest this could increase throughput by an order of magnitude.
But we won't stop there. Once we have optimized the micro-operations, we will be "Going Wide"—exploring how to leverage FSM Processing Groups to run massive, parallel simulations across multiple cores.
Stay tuned. The Singularity is getting closer.
Resources & Code:
The FSM Package (Unity Asset Store):
https://assetstore.unity.com/packages/slug/332450
NuGet Package (Non-Unity Core):
https://www.nuget.org/packages/TheSingularityWorkshop.FSM_API
GitHub Repository:
https://github.com/TrentBest/FSM_API
Simple Demos Repository (Run the Stress Test):
https://github.com/TrentBest/SimpleDemos (Clone this repo and run the StressProfiler project to reproduce these numbers.)
Support Our Work:
Patreon Page:
https://www.patreon.com/c/TheSingularityWorkshop
Support Us (PayPal Donation):
https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J
We'd love to hear your thoughts! Please Like this post, Love the code, and Share your feedback or what you've built with the API in the comments.
