Dohun Wi · Software Engineer · Simulation & Runtime Systems

From virtual worlds to the physical one.

I follow one question through game worlds, runtime systems, AI workflows, and simulation: how do rules, state, and interaction become behavior?

SimulationRuntime SystemsPhysical AI
Follow the question ↓

01 · Wonder

Before I wanted to build worlds, I wanted to understand one.

I once wanted to become an astrophysicist. What stayed with me was not space itself, but the idea that complex worlds could emerge from a small set of underlying laws. Software gave me another way to follow that question.

  1. 01Observe a world
  2. 02Trace its rules
  3. 03Build with them

02 · Agency

What happens when rules can answer back?

I began by writing rules of my own.

Mystic Forest · First complete world

Rules became something I could feel.

Finite-state behavior, timing, camera, audio, and hit feedback taught me that a rule matters only when its consequence can be felt.
Mystic Forest case study

Mystic Forest → Lucid Knight

Movement. State. Combat. Feedback.

Moving from 2D to 3D multiplied the interactions between those systems. Character motion, boss behavior, runtime state, and feedback now had to remain coherent together.
Lucid Knight case study

03 · Tension

Making a world run was no longer enough.

As interactions multiplied, intuition stopped being enough. I wanted to explain why the world behaved as it did, where it slowed down, and how it failed—and to prove that a change actually improved it.

RecordRepeatable runIsolateOne causeChangeOne systemVerifySame conditions

Evidence

Behavior became something to explain.

For Lucid Knight, I built a measurement loop: establish a baseline, isolate one bottleneck, change one system, then repeat the same release-build route to verify the result.

94 FPS → 152 FPSAverage FPS
11.1 ms → 6.9 msAverage frame time
454 B → 190 BGC allocation / frame
Lucid Knight release-build performance comparison
Measured under documented, repeatable build conditions.
Inspect the measurement loop

04 · Boundaries

When a system can decide, what must remain explicit?

Measurement helped me explain deterministic behavior. But now, behavior was no longer entirely written by hand.
ObserveReasonValidateApproveRecover

The judgment could remain probabilistic. State, tools, approval, and recovery could not remain implicit. I encoded those boundaries so the system’s actions could still be tested, challenged, and revised.

View technical case study

05 · Convergence

The question became physical.

Game runtimes taught me to measure behavior. AI workflows taught me to bound it. In terrain-sim, both lessons shaped the architecture of a physics simulation: a standalone C++ core owns state and physics, while its consumers interact through explicit contracts.

01Rules became physics.C++20 core · terrain generation · erosion · rigid-body state

02Boundaries defined ownership.Headless core · pybind11 · evaluation contract · replay boundary

03Evidence decided what changed next.GoogleTest · compiler reports · reproducible benchmarks

Same-seed terrain before erosion, after thermal erosion, and after hydraulic erosion
One seed · three stages · terrain and erosion owned by the C++20 core
Inspect the system boundary

Evidence · challenged

The system ran. The evidence still challenged it.

Tests revealed what rendered output could not. Measurement rejected the hypothesis intuition preferred. Together, they narrowed what I could claim—and determined what I changed next.

Correctness

A world that runs can still be wrong.

Boundary sampling exposed a false gradient outside the grid; regression tests now protect interior interpolation.
Fixed
Boundary gradient
Protected
Interpolation
Known limit
CCD gap

Performance

The first hypothesis failed. The measurement did not.

When the pull-model experiment ran slower, compiler reports exposed the real barrier: an out-of-line heightmap accessor.2962 µs → 2369 µsNative combined workload · 20.0% lower mean runtime
Follow the evidence in the case study

Rules become behavior

Not a renderer demo. A world I can question.

The core simulates. The evaluation layer runs the controller and records the result. Unity makes one trajectory observable—without owning or recomputing it.

pybind11 · deterministic evaluation · trajectory contract · Unity replay

  1. 01C++ coreOwn terrain, state, and physics
  2. 02Evaluation contractRun, classify, and record trajectories
  3. 03Unity replayVisualize a recorded result in Unity
Inspect the replay boundary

Case studies

Follow the evidence.

Detailed architecture, decisions, measurements, tests, and limitations.

01terrain-simC++ simulation core · correctness · performance · replayRead case study →02Lucid KnightProfiling · optimization · measured verificationRead case study →03AI systemsRetrieval · validation · approval · recoveryRead case study →04Mystic ForestState-driven combat · game feelRead supporting case →

06 · Direction

  1. 01 · DesignBehavior begins with rules.
  2. 02 · ProofTrust begins with evidence.
  3. 03 · ControlAutonomy depends on boundaries.

The question leaves the screen.

The closer software gets to reality,
the less room there is for behavior
we cannot explain.

My direction is simulation and runtime engineering for intelligent machines in the physical world—systems whose state and failures remain observable, testable, and trustworthy. So far, I have applied this discipline in game runtimes, AI workflows, and simulation. The next test is whether the same discipline holds when the loop closes through real hardware.

That means, concretely:

01 · What I bring

Real-time state and feedback · measured profiling · explicit workflow boundaries · a tested, standalone C++20 simulation core

02 · What I am deepening

Modern C++ · numerical methods · correctness · performance instrumentation · concurrency · Linux systems

03 · Where I am going

Simulation and runtime engineering for robotics · embedded systems · digital twins · physical AI