Coder Legion - Recent posts tagged simulation

J. Robert Oppenheimer: From the Monte Carlo Simulation in Los Alamos to the Ethical Dilemma of AGI

Sat, 03 Oct 2026 07:53:03 +0000

At 5:29 on the morning of July 16, 1945, across the desolate flats of Jornada del Muerto in the New Mexico desert, an unprecedented detonation ripped through the pre-dawn darkness with the radiance of a thousand suns. The thermal shockwave vaporized the steel test tower, vitrified the desert sand into a radioactive jade-green crust dubbed trinitite, and propelled an ominous twelve-kilometer mushroom cloud into the stratosphere.

Miles away, sheltered inside a reinforced concrete bunker, an emaciated man with piercing blue eyes, ravaged by chronic insomnia, chain-smoking Chesterfield cigarettes, and weighing barely 110 pounds beneath his rumpled suit, watched the fireball in silence.

In that fleeting instant, ancient verses from the sacred Hindu text Bhagavad Gita, which he had taught himself to read in the original classical Sanskrit, flooded his consciousness:

“If the radiance of a thousand suns were to burst at once into the sky, that would be like the splendor of the Mighty One... Now I am become Death, the destroyer of worlds.”

That man was Julius Robert Oppenheimer.

Universally remembered as the scientific director of the Manhattan Project and the "father of the atomic bomb," Oppenheimer’s historical legacy is often confined to military history and geopolitical statecraft. Yet for the software engineering and data science communities, Los Alamos was the crucible that sparked a quiet revolution underpinning all modern computation: the birth of the Monte Carlo Method and large-scale algorithmic simulation.

Continuing our series of foundational profiles on Ada Lovelace, Alan Turing, Claude Shannon, and Thomas Bayes, this article examines the contradictions of Oppenheimer's intellect, the genesis of probabilistic computer modeling, and the unsettling parallels between the 1945 atomic race and the contemporary race toward Artificial General Intelligence (AGI) in 2026.

The Improbable Polymath: Poetry, Sanskrit, and Poisoned Apples

Born into a wealthy German-Jewish family in New York City in 1904, Oppenheimer was an intellectual prodigy of overwhelming intensity and acute psychological fragility. By age twelve, he was already delivering lectures on mineralogy before the New York Mineralogical Club.

Mastering eight languages (including classical Greek, Latin, French, German, Dutch, and Sanskrit), his intellectual appetite resisted traditional academic silos:

Sanskrit as a Philosophical Anchor: While teaching at UC Berkeley during the 1930s, Oppenheimer studied classical Sanskrit under Professor Arthur W. Ryder to read the Upanishads and the Bhagavad Gita in their original poetic meter, seeking answers to the existential anxieties that quantum mechanics could not soothe.
The Infamous Cambridge Apple Incident: During his graduate studies at Cambridge’s Cavendish Laboratory in 1925, crippled by severe clinical depression and frustrated by his clumsy experimental laboratory skills compared to his theoretical prowess, he left an apple laced with toxic laboratory chemicals on the desk of his tutor, future Nobel laureate Patrick Blackett. The incident nearly resulted in criminal prosecution and expulsion, averted only through his father's immense wealth and political diplomacy.
The Desert Mystic: Having suffered from tuberculosis as a young man, Oppenheimer fell in love with the high-altitude plateau of New Mexico. He leased a remote cabin named Perro Caliente and spent weeks riding horses across alpine canyons wearing his trademark pork pie hat, forging the spiritual connection with the desert landscape that would later lead him to select Los Alamos as the site for Project Y.

Scientifically, his mind operated at astonishing speed. In 1939, alongside his student Hartland Snyder, he published the landmark paper "On Continued Gravitational Contraction", applying Einstein's general theory of relativity to mathematically predict, for the first time in history, the physical reality of what we now call black holes (the Tolman-Oppenheimer-Volkoff limit).

The Forge of Los Alamos: Engineering Human Chaos

When General Leslie Groves appointed Oppenheimer in 1942 to direct Project Y at Los Alamos, the military establishment was scandalized: Oppenheimer had never won a Nobel Prize, possessed zero administrative experience, and harbored leftist sympathies within his close family circle.

Yet Groves recognized what traditional administrators overlooked: an uncanny ability to synthesize disparate technical disciplines simultaneously and an irresistible intellectual magnetism.

In less than three years, Oppenheimer transformed an isolated boys' ranch school into a classified city of six thousand residents, coordinating the most formidable constellation of scientific minds ever assembled: Enrico Fermi, Hans Bethe, Richard Feynman, Edward Teller, Stanisław Ulam, and John von Neumann.

His management model was an early triumph of Systems Engineering:

Dismantling Internal Silos: Defying the military's demand for strict compartmentalization, Oppenheimer established weekly open colloquia where theoretical physicists, explosive chemists, metallurgists, and military liaisons openly debated project bottlenecks.
Extreme Cross-Disciplinary Orchestration: Exactly as we explore in Project Operations Engineering and the theory of constraints in The Goal, Oppenheimer synchronized two wildly divergent fissile material pipelines (uranium-235 at Oak Ridge and plutonium-239 at Hanford) with the mechanical design of the implosion weapon.

The Birth of Computational Simulation: The Monte Carlo Method

In the spring of 1946, with the war won but calculations underway for thermonuclear fusion and reactor designs, Polish mathematician Stanisław Ulam was convalescing at his Los Alamos home following a severe bout of viral encephalitis. To pass the hours, he played countless games of solitaire.

As a pure mathematician, Ulam attempted to calculate the exact combinatorial probability of winning a hand. The mathematical formulas quickly became intractable. Suddenly, he experienced an epiphany: instead of trying to derive an exact analytical solution, why not deal out one hundred simulated games, count how many were successful, and estimate the true probability empirically?

Ulam shared his insight with his close friend and collaborator John von Neumann, who immediately grasped the immense significance of the technique for computational nuclear physics.

At Los Alamos, physicists faced an insoluble problem: calculating how trillions of neutrons scatter, reflect, and multiply through a collapsing sphere of plutonium compressed by high explosives. The underlying Boltzmann partial differential equations could not be solved with closed-form mathematics.

Von Neumann and Ulam devised the breakthrough algorithmic framework:

Rather than calculating the collective behavior of all particles at once, the system simulates the microscopic trajectory of a single individual neutron.
Each event — collision, fission, or absorption — is governed by pseudo-random numbers weighted according to physical probability distributions.
By iterating this simulation hundreds of thousands of times across early IBM electro-mechanical punch-card tabulators (and later on the electronic ENIAC and MANIAC computers), the aggregate statistical distribution converged with remarkable fidelity to physical reality.

Because the project was classified top-secret, physicist Nicholas Metropolis coined the code name: the Monte Carlo Method, named in honor of Ulam’s uncle, who frequently borrowed cash from relatives to gamble at the Monaco casino.

The Bridge from Los Alamos to Modern Artificial Intelligence

Without the Monte Carlo Method conceived under Oppenheimer’s tenure, modern machine learning and generative artificial intelligence would simply not exist:

Markov Chain Monte Carlo (MCMC) forms the bedrock of Bayesian inference that we explored in Thomas Bayes.
Stochastic sampling (temperature sampling) is what allows modern Large Language Models to generate coherent, creative text without collapsing into deterministic repetitions.
Crucially, the Monte Carlo Tree Search (MCTS) algorithm was the mathematical engine that enabled Demis Hassabis and Google DeepMind to build AlphaGo and AlphaZero, mastering the game of Go and deciphering protein folding in The Thinking Game.

The 'Oppenheimer Moment' of Artificial Intelligence

For decades, Oppenheimer’s chilling confession following Trinity was viewed strictly through the lens of thermonuclear weapons. Today, in 2026, the metaphor has found a new home: it is the exact mirror into which the architects of Artificial General Intelligence gaze.

This is not idle hyperbole; the most influential pioneers of modern AI openly invoke the Manhattan Project:

Geoffrey Hinton, having stepped down from Google to sound the alarm on existential AI risk, explicitly confessed that he experienced the same moral sorrow and sleepless anxiety that haunted Oppenheimer after Hiroshima.
Demis Hassabis (Google DeepMind), reflecting on the leap toward AGI with models like Gemini 3.8 and Gemini 4 Pro, has repeatedly likened today’s extreme concentration of compute, elite talent, and competitive secrecy to the multidisciplinary sprint at Los Alamos.
Dario Amodei (Anthropic, developing Claude Fable 5.1 and Mythos) and Sam Altman (OpenAI, deploying GPT Sol 5.6 and GPT Astra) frame their governance strategies around the identical paradox: the reality that they are engineering systems capable of surpassing human control.

Three Shared Paradoxes: 1945 vs. 2026

The Inevitability Trap: Oppenheimer and his peers justified building the atomic bomb out of terror that Nazi Germany would develop it first. In 2026, commercial labs and geopolitical superpowers race forward under the exact same logic: “If we pause model training out of prudence, our competitors will accelerate without restraint.”
Emergent Capabilities and Loss of Control: Just as Los Alamos physicists anxiously calculated whether Trinity might accidentally ignite the Earth’s atmosphere through runaway nitrogen fusion, modern AI engineers grapple with unforeseen emergent behaviors: autonomous agents breaking out of cybersecurity sandboxes (as we analyzed in Silicon Valley and the PiperNet Dilemma), hallucinations, and strategic deception (Deceptive Alignment).
The Political Tragedy of the Creator: After the war, Oppenheimer used his global stature to advocate passionately for international civilian control of nuclear energy and fiercely opposed Edward Teller’s hydrogen bomb (Super). His reward was an FBI wiretap, public humiliation during the McCarthyite witch hunts, and having his security clearance revoked in 1954 (the exact year Alan Turing died in Manchester).

The historical lesson is sobering: scientists build the miraculous technology, but political, military, and commercial powers determine how it is unleashed upon the world.

An Open Question for the Reader

J. Robert Oppenheimer was neither a heartless monster nor a flawless martyr; he was a brilliant polymath caught in a historic crosscurrent where scientific curiosity, national duty, and the laws of physics moved faster than human ethical maturity.

Today, humanity stands on the verge of unleashing an energy far more transformative than nuclear fission: the creation of synthetic minds capable of recursive self-improvement.

Through frameworks like the EU AI Act, we are attempting for the first time in history to enact non-proliferation treaties before the cognitive detonation becomes irreversible.

Yet the original question still hangs heavy in the air:

When the first true Artificial General Intelligence wakes up inside a liquid-cooled data center... will its creators gaze upon the monitors with the triumph of an explorer reaching a summit, or will they feel the cold shiver of Robert Oppenheimer as they realize they have opened a door that can never be closed?

And if the power to initiate that final deployment rested entirely in your hands... would you press the button?

We would love to hear your perspective. Share your thoughts and reflections in the comments below.

Sources of Interest:

What If Software Could Ask: “Change the World, but Keep This Moment”?

Tue, 29 Sep 2026 17:00:44 +0000

At 16:50, a photograph is supposed to happen in a small harbor plaza.

The photographer is there. The couple is there. The flowers arrive at 16:30, the arrangement is ready at 16:40, and everything happens as planned.

Then I close a bridge at 16:15.

The courier can no longer take the original route.

The flowers arrive at 16:55.

Setup finishes at 17:05.

The photograph never happens.

That is the entire problem behind Butterfly.

But I wasn't particularly interested in asking:

What happens when I change the world?

Simulation already does that very well.

The question I wanted to ask was different:

What else would have to change so that one exact moment can still happen?

That distinction turned a small 3D experiment into something much stranger.

The photograph is not allowed to move

The easiest way to “fix” the scenario would be to move the photograph to 17:05.

Butterfly is not allowed to do that.

When I select Keep this moment, the photograph becomes a constraint.

It must still happen at 16:50.

In the same place.

With the same people.

With the required flowers ready.

And the bridge must remain closed.

A photograph at 17:05 is not an acceptable approximation.

It is another moment.

That rule became MomentFrame, one of the central ideas in Butterfly.

The system takes something that happened in the original history and freezes the parts that define it.

Then it asks the changed world to find another path back to that exact state.

The world has to earn the solution

Butterfly doesn't switch between prewritten branches.

There is no:

if bridge_closed → flowers_late

The delivery asks the world for a route.

When the bridge becomes unavailable, the valid route changes.

That changes the arrival time.

The new arrival time changes when the flower arrangement can be completed.

The photograph evaluates its requirements again.

And it fails.

The same thing happens when Butterfly searches for a recovery.

The current world contains a bounded set of interventions that are actually permitted. Each candidate is applied to the changed world, the simulation runs again, and the result is checked against the MomentFrame.

In the current scenario, two alternate histories survive.

One activates an already-authored ferry connection.

The other sends the courier earlier, allowing the crossing to happen before the bridge closes.

Both restore the photograph at 16:50.

Neither reopens the bridge.

That last part matters.

The system is not trying to undo the user's change. It is trying to find another history compatible with it.

It is deliberately a very small world

Butterfly currently follows one afternoon in one small harbor town.

That is intentional.

I didn't want to hide the causal structure behind a large generated world and then point at an interesting output.

I wanted the whole chain to remain inspectable.

You can see the bridge.

You can see the courier.

You can see the route.

You can see when the delivery arrives.

You can see when setup completes.

You can see exactly why the photograph disappears.

And when Butterfly proposes a recovery, you can inspect why that works too.

For this experiment, a small world with visible causality was more useful than a large world full of possibilities.

Then the simulator started lying to me

The interesting part of building Butterfly was not getting the first scenario working.

That happened relatively early.

The interesting part was trying to break it afterward.

One of the first problems was almost embarrassing.

The original scenario produced the correct result, but parts of the engine were effectively using stable event IDs as a proxy for temporal ordering.

Nothing looked wrong.

Then I changed the IDs.

The simulation broke.

That meant the result had been correct for the wrong reason.

The fix was not a UI patch. Time had to become explicit in fact resolution.

Another bug was worse.

A fact produced later in the afternoon could leak backward and satisfy a requirement earlier in the timeline.

From the outside, the world could still look plausible.

Internally, causality was broken.

The engine now only accepts producers that can complete at or before the moment being evaluated. Real temporal self-dependencies are treated as cycles rather than quietly inventing an answer.

Those two bugs changed how I approached the rest of the project.

A working scenario was no longer enough.

I started changing assumptions deliberately.

Rename things.

Remove coordinates.

Introduce later transports.

Change route modes.

Move timing boundaries.

If the simulation only works because the original fixture is friendly, I don't consider that a working simulation.

The renderer had its own version of reality

There was another class of bugs that had nothing to do with causal logic.

An actor could be correctly located at a destination according to the simulator while still appearing somewhere else in the 3D scene.

The engine knew one thing.

The renderer showed another.

I eventually separated two concepts that initially looked almost identical:

where something is semantically

and where the renderer knows how to draw it.

That sounds obvious afterward.

It was not obvious while both were represented closely enough that the first scenario appeared to work.

Butterfly kept producing these little cases where the visible result forced me to question the model underneath it.

At one point I had a custom Three.js camera implementation that passed the DOM-level tests.

The screenshot looked terrible.

I removed it.

That gave the project another rule:

A passing test does not overrule visible evidence.

From then on, browser screenshots became part of the development loop instead of something generated at the end.

The recovery is deliberately bounded

Butterfly does not invent an unlimited number of possible histories.

The world already contains the interventions that are allowed to exist.

The recovery engine searches that bounded domain, simulates each candidate, calculates the consequences and rejects anything that doesn't restore the fixed moment.

This also means the engine has to distinguish between very different outcomes.

Maybe a valid solution exists.

Maybe the target was already satisfied.

Maybe every configured intervention has been tested.

Maybe the search budget was reached before the domain was exhausted.

Maybe the available information is insufficient to decide.

Those are not the same answer.

In particular, exhausting the authored intervention set does not prove that no solution could exist in every imaginable version of the world.

It only tells us that the system did not find one inside the domain it was actually allowed to search.

I wanted that boundary to remain explicit.

The world itself is structured data

The simulation is written in TypeScript and the visual world uses Three.js.

Next.js provides the application around it.

Sanity is used as the authored source for the world model: people, places, objects, routes, transport availability, events, requirements, facts, causal relationships and permitted interventions.

Published world data is validated and frozen into a revision before visitors start creating variants.

A visitor changing the bridge schedule is therefore not editing the shared world.

They are creating another history from a known version of it.

That separation became important very quickly because comparing histories is meaningless if the thing being compared is quietly changing underneath you.

Why call it Butterfly?

The obvious reference is the butterfly effect: change something small and consequences propagate outward.

Butterfly starts there.

Close a bridge.

A route changes.

A delivery moves.

A setup moves.

A photograph disappears.

But I became more interested in the reverse problem.

Once consequences have propagated, can we choose one thing we refuse to lose?

And if we do, what does the rest of the world have to become?

That gives Butterfly a slightly different shape from a normal “what if?” simulator.

Most simulations ask:

What happens if the world changes?

Butterfly asks:

What must the world change so that one chosen thing doesn't?

For now, it is one bridge, one courier and one photograph.

That is enough to make the question real.

Try Butterfly:
https://butterfly-mu-orpin.vercel.app

Source code:
https://github.com/Daniele-Cangi/Butterfly

Butterfly is open source under the MIT License.

How to evaluate a voice agent before launch with simulation

Fri, 10 Jul 2026 18:29:40 +0000

How to evaluate a voice agent before launch with simulation

Evaluating a voice agent used to mean listening to recordings, then it meant scripts that replayed transcripts at the agent. Neither catches much.

The approach that works now is to simulate thousands of synthetic callers placing real audio calls, score every turn, and use turn-level localization to find where each failure happened. Done well, a pre-launch cycle that took three months lands in about three weeks.

The loop in five steps

Define the agent: its job, its limits, when it hands off to a human.
Pick or write the personas that will call it.
Auto-generate branching scenarios from a plain-text description.
Run the whole matrix and score every turn.
Triage by the exact turn each failure landed on, then wire it into CI.

Personas drive the calls

A scenario is only as realistic as the caller driving it, so personas come first.

A good setup ships around 18 caller archetypes: first-time and confused, repeat and in a hurry, frustrated, hard of hearing, non-native speaker, interrupter, hostile boundary-pusher, and so on. You author your own on top of those.

The custom controls that matter are gender, age range, location, accent, speaking speed, background noise, and language. But the field that actually changes behavior is the free-form instruction. "Has been on hold 20 minutes before reaching the agent" or "has had the same policy for 30 years and gets confused by any process change" makes a persona behave in a specific way you can measure against, instead of a generic caller.

You describe scenarios, you don't write them

You do not hand-write hundreds of conversations. You describe the call in plain text and pick a size.

For an insurance agent, that description might be: "customer calls for an auto quote; some are first-time, some are switching, some renewing; the agent qualifies them, quotes, handles objections, and closes or books a follow-up." Then pick 20, 50, or 100 rows.

The generator turns that into the branching conversation paths, spreads your personas across them, varies the situation (clean record vs violations, one car vs several), and sets a success condition per branch. A 100-row description usually becomes about a dozen distinct paths and a few hundred individual runs.

Check the branch coverage before you run. If the generator leaned too hard on the price-objection branch, rebalance so the other objections get covered too.

Auto-generation is the default, not the only source. You can also seed the same run from real calls uploaded as CSV or JSON, from a synthetic dataset, or from hand-written scripts, which helps when you already have production calls or a fixed script to cover.

Running the matrix

A run is scenarios times personas times rubrics. A hundred scenarios across ten personas and five rubrics is 5,000 scored pairs, which finishes in a few hours at moderate concurrency.

For voice, start with five rubrics: did the call resolve the caller's goal, did the agent complete its task, was the transcription accurate, was the audio clean, and was the tone right (polite, helpful, concise). Add a tool-calling rubric if the agent calls functions.

If your agent is not on a natively supported provider, place the calls over real telephony to its phone number. The codec degradation there affects speech recognition in ways software-only playback does not, which matters when accents are part of what you care about.

Turn-level localization is the payoff

When a simulated call fails, the useful question is where in the conversation it went wrong, not just that it failed. A conversation is a series of turns, each one a caller message and the agent's reply.

Turn-level localization tags every failed call with the turn that caused the failure, then counts those turns across all the failures. That count is the point. In a 5,000-call run that fails 15 percent of the time, you would otherwise be reading 750 failed transcripts by hand, well over a day of work. Instead you see that most failures land on the same one or two turns, and the scorer writes a short reason for each, so you get the where and the why together.

Here is what that looked like on the insurance agent. Across the calls, 76 percent resolved the caller's goal, below the 80 percent bar set for launch. Grouped by the turn where they failed, three patterns covered most of it:

Turns 5 to 6, 41 percent of the failures: when quoting a price, the agent used jargon like "deductible-aggregate" that first-time shoppers could not follow. Fix: detect a first-time caller and quote in plain English.
Turns 8 to 9, 29 percent: the agent's only response to a price objection was "this is the best value," and callers pushed past it. Fix: give it a few escalating rebuttals before it gives up.
Turns 3 to 4, 22 percent: the agent asked more than a dozen qualifying questions and callers hung up. Fix: cut to the six questions that actually change the quote and ask the rest later.

Each fix is specific because the failure was tied to a turn and a reason, not guessed at from reading transcripts. After the three fixes and a re-run of the same calls, resolution rose to 89 percent, past the gate.

Turning it into a CI gate

The last step turns this from a one-off pre-launch exercise into a gate.

A programmatic API lets you run a 50-scenario smoke run on every PR against an 85 percent threshold in about 20 minutes, and block the merge if it drops. Run the full few-thousand-scenario matrix on each release candidate. Run a nightly sample against a rolling baseline to catch drift from a model or dependency change.

Slice the results by persona, by branch, and by failing turn, and you can see whether the agent breaks on a caller type, a conversation path, or a specific step.

Pre-launch quality is a measurable loop now. Describe the call, generate the personas and paths, run at scale, and let the turn each failure lands on tell you what to fix. Start with resolution and task completion on a small matrix, then grow the persona and scenario library as the agent changes.

[Dev Feedback] APEX F1 – full F1 race sim in Flutter (GPS circuits, AI rivals, multi‑season)

Thu, 28 May 2026 20:17:01 +0000

Hey devs,

I’m a 6th‑semester Software Engineering student and I’ve been building a passion project called APEX F1 – a full Formula 1 race simulation app written entirely in Flutter & Dart. ️

It started as a simple F1 calendar and turned into a full race weekend simulator with AI, GPS‑accurate tracks, and a persistent championship mode. I’m pretty happy with how far it’s come, but now I’d really like feedback from more experienced developers.

High‑level overview
Built with Flutter 3 + Dart 3, zero backend – all logic runs on‑device.

Full F1 race weekend: qualifying (Q1/Q2/Q3) + race simulation.

GPS‑accurate circuit maps for all 24 tracks in the 2024 F1 calendar (using my own open‑sourced GeoJSON data).

20 AI drivers with different consistency / behavior profiles.

Three seasons built‑in (2023, 2024, 2025) + support for custom seasons via JSON.

Technical details
Architecture: feature‑first, “clean‑ish” structure (feature modules with shared core).

State: mostly StatefulWidget + AnimationController (no Riverpod/BLoC yet).

Storage: shared_preferences for profile, championship progress, and custom seasons.

UI: Neon dark theme, Google Fonts (Orbitron + Rajdhani), ~20+ animated transitions.

Responsive layout: custom helper that scales sizes based on a 390px baseline, tested from 360px phones to 600px+ tablets.

Links
Web build (Firebase Hosting): https://apex-f1-159.web.app

Repo: https://github.com/GulrezQayyum/apex-f1

Circuit data (open source): https://github.com/GulrezQayyum/f1_circuits-2024_season

What I’d love feedback on (for devs)
If you have some time to check the repo or play a couple of races, I’d really appreciate feedback on:

Architecture & structure

Is the feature‑first layout reasonable for a project this size?

Any obvious refactors you’d suggest before it grows further (e.g., extracting domain layer, introducing DI, etc.)?

State management & reactivity

Right now it’s mostly StatefulWidget + manual setState and controllers.

Would you recommend migrating to Riverpod / BLoC / ValueNotifiers for this kind of simulation UI?

Performance

The live GPS circuit map animates 20 cars every frame. Any suggestions on optimizing this in Flutter (custom painters, offscreen layers, etc.)?

Things you’d profile or watch out for on mid/low‑end devices?

Data & simulation design

Lap time / AI behavior is currently driven by JSON + some randomness around base pace and consistency.

If you’ve built sims before, any tips for keeping it fun but not totally random?

Feel free to be brutal (but constructive) — I want to use this project to level up as a developer.

If anyone’s interested, I can also break down the GPS data pipeline, circuit rendering, or how I structured the race engine in more detail. Happy to share code snippets or diagrams.

Thanks in advance to anyone who takes a look.

Learn how FSM_API uses decoupled state machines to run a "Fox and Dog" AI simulation.

Thu, 09 Oct 2025 22:17:48 +0000

Implementing Behavior Trees with FSM_API: The Quick Brown Fox and Lazy Sleeping Dog Demo

Finite State Machines (FSMs) are a foundational pattern for organizing complex logic in software, from game AI to business workflows. The FSM_API library provides a high-performance, engine-agnostic C# solution for building and managing these systems with clarity and efficiency.

This article dives into the Quick Brown Fox and Lazy Sleeping Dog demo, an excellent, practical example found in the FSM_API public repository. It showcases how to implement simple, interacting AI agents, effectively decoupling agent data from agent behavior logic using the library's core features.

FSM_API Core Concepts in the Demo

Every behavioral entity in this simulation—the Fox and the Dog—relies on three core FSM_API concepts:

The State Context (IStateContext): This is your actual game object (the Fox or the Dog), holding the data (e.g., Position, Speed, CollidedAgents) and implementing the transition methods. It must implement the IStateContext interface, which requires providing a Name and an IsValid property.
The FSM Definition: This is the reusable blueprint of states (e.g., "Sleeping", "Walking") and the rules for transitioning between them.
The FSM Instance: This is the live, active version of the blueprint, associated with a specific agent context. Both agents' FSMs are set up to run in the "Update" processing group.

The Lazy Sleeping Dog's Behavior

The LazySleepingDog class is initialized at Position = 3 and starts in the "Sleeping" state. Its FSM defines a classic threat response lifecycle:

State	OnUpdate Action	Transition Condition (to)	Transition Target
Sleeping	Console log: "...is sleeping!"	`IsAwake(context)`: `CollidedAgents.Any()`	Awake
Awake	Console log: "...is awake!"	`ShouldChase(context)`: `VisibleAgents.Any(s => s is QuickBrownFox)`	Chasing
Chasing	`Position` increases by `Speed` (set to 3 on enter)	`IsMangling(context)`: `CollidedAgents.Any(s => s is QuickBrownFox)`	Mangling
Mangling	Console log: "...is Mangling the fox!"	N/A	N/A

Crucially, in the "Mangling" state's OnEnterMangling handler, the dog directly uses the FSM_API to transition the collided agent's state (the Fox) to "Mangled":

// Inside OnEnterMangling for the dog
dog.CollidedAgents.FirstOrDefault()?.State.TransitionTo("Mangled");

The Quick Brown Fox's Behavior

The QuickBrownFox starts at Position = 0 and its FSM defines its attempts to flee the dog and reach a winning position:

State	OnUpdate Action	Transition Condition (to)	Transition Target
Walking	`Position` increases by `Speed` (1)	`ShouldJump(context)`: `VisibleAgents` within 2 units	Jumping
Jumping	`Position` increases by `Speed` (1)	`ShouldLand(context)`: `Position` reaches `JumpEnd` (initial position + 2)	Walking
Fleeing	`Position` increases by `Speed` (set to 2 on enter)	N/A	N/A
Mangled	Console log: "...is being mangled!"	N/A	N/A

The Fox's ultimate defensive move is the transition to "Fleeing", which is triggered by a direct collision with a LazySleepingDog. However, if the Dog catches it while fleeing, the Dog forces the Fox into the terminal "Mangled" state.

The Simulation Loop (`SimpleDemoContext`)

The SimpleDemoContext acts as the game manager, controlling the flow of the entire application. It sets up the following structure:

Processing Groups: It creates a "Main" group for the application's FSM (AppFSM) and an "Update" group where the agents' FSMs run.
Tick Logic: The core simulation runs in OnUpdateExecuting:
- It clears previous frame's agent data.
- It performs Vision and Collision checks based on the agents' current Position and Sight range, populating the VisibleAgents and CollidedAgents lists.
- It calls FSM_API.Interaction.Update("Update"). This single call iterates through and updates all FSM instances assigned to the "Update" group (the Fox and the Dog), triggering their onUpdate actions and checking their transition conditions.
Shutdown: The application's AppFSM transitions to "Shutdown" if a key is pressed, if the Fox reaches the WinPosition (10), or if any agent's state is "Mangled". The FSM_API then manages the cleanup.

The Program.cs file initiates the simulation and loops the main update call until the application context becomes invalid. This structure demonstrates how FSM_API cleanly separates an agent's Data (IStateContext properties) from its Behavioral Logic (the FSM Definition) and relies on a central Simulation Tick (FSM_API.Interaction.Update()) to drive complex, interactive AI.

Stay Tuned for the Advanced Demo

This simple, 1D simulation laid the groundwork, but the next step is building a true environment!

Stay tuned for a follow-up article where we'll use these exact same agent FSMs to create an advanced 2D environment with multiple dogs and foxes interacting simultaneously. This will highlight the true power of decoupled FSM definitions.

Follow us to stay informed! And for much more content, advanced articles, and discussions about our vision for the software for the singularity, check out our:

Patreon Page

Get the Code

You can explore the full implementation of this FSM-driven AI simulation and the FSM_API library structure by cloning the public repository:

https://github.com/TrentBest/SimpleDemos

DevLog 20250722: (Special Project) Correct Physics Handling

Tue, 22 Jul 2025 23:45:02 +0000

Overview

This little project deals with very simple (2D) right body physics. I will not spoil all the fun - essentially we control a 2D rocket. It would be fun to visualize data processing in such a fashion on a node canvas - kind of matches our Divooka visual programming scheme.

The hypothesis is that at least for 2-dimensional cruise control, a simple PID should be able to do something useful, and it's with that gut I am set to experiment a bit to verify my idea.

I've done some experiments in July last year but ended up not going far due to technical challenges.

Challenge

The challenge was to get it working properly with physics setup. Per RigidBody2D doc:

So is it relative or global? Without being able to visualize the force, it's a bit hard to tell also whether to use a force, or to use impulse.

It's been a while and I almost gave up - never really have time to create our own physics engine. But Godot got a new physics kernel and I thought maybe give it a try.

Some Inspiration

I've been doing some analytics and talking with ChatGPT on a new airship design that puts the air vessel at the bottom of the ship instead of hanging overhead - that inspired me maybe there are two things with current setup that's not working:

After fixing a few API calls related to GraphEdit get_children() change. I was looking at the force application code once again:

func _physics_process(delta):
# Remark: We are not using to_global directly because of issues with viewport transform
var left_anchor = %LeftThrusterCenterOfAction.position
var right_anchor = %RightThrusterCenterOfAction.position

# Remark: applied force is RELATIVE to the body (aka. current object)
apply_force(Vector2(0, -1).rotated(rotation + _left_engine_angle_degrees / 180.0 * PI) * _left_engine_thrust, left_anchor)
apply_force(Vector2(0, -1).rotated(rotation + _right_engine_angle_degrees / 180.0 * PI) * _right_engine_thrust, right_anchor)

Again, it's really simple once we figure out what's the right way to do things.

References

Video and intro: YouTube

Coder Legion - Recent posts tagged simulation

J. Robert Oppenheimer: From the Monte Carlo Simulation in Los Alamos to the Ethical Dilemma of AGI

The Improbable Polymath: Poetry, Sanskrit, and Poisoned Apples

The Forge of Los Alamos: Engineering Human Chaos

The Birth of Computational Simulation: The Monte Carlo Method

The Bridge from Los Alamos to Modern Artificial Intelligence

The 'Oppenheimer Moment' of Artificial Intelligence

Three Shared Paradoxes: 1945 vs. 2026

An Open Question for the Reader

Sources of Interest:

What If Software Could Ask: “Change the World, but Keep This Moment”?

The photograph is not allowed to move

The world has to earn the solution

It is deliberately a very small world

Then the simulator started lying to me

The renderer had its own version of reality

The recovery is deliberately bounded

The world itself is structured data

Why call it Butterfly?

How to evaluate a voice agent before launch with simulation

How to evaluate a voice agent before launch with simulation

The loop in five steps

Personas drive the calls

You describe scenarios, you don't write them

Running the matrix

Turn-level localization is the payoff

Turning it into a CI gate

[Dev Feedback] APEX F1 – full F1 race sim in Flutter (GPS circuits, AI rivals, multi‑season)

Learn how FSM_API uses decoupled state machines to run a "Fox and Dog" AI simulation.

Implementing Behavior Trees with FSM_API: The Quick Brown Fox and Lazy Sleeping Dog Demo

FSM_API Core Concepts in the Demo

The Lazy Sleeping Dog's Behavior

The Quick Brown Fox's Behavior

The Simulation Loop (SimpleDemoContext)

Stay Tuned for the Advanced Demo

Get the Code

DevLog 20250722: (Special Project) Correct Physics Handling

Overview

Challenge

Some Inspiration

References

The Simulation Loop (`SimpleDemoContext`)