MilSim command loop

MilSim is a headless-first C#/.NET command-and-control simulation prototype.

It explores a specific design problem: how a commander makes decisions when they cannot directly see objective reality. The player does not simply inspect the whole map and optimize from perfect information. They receive reports through hierarchy, timing delays, terrain constraints, and role-limited views.

Many tactical games show the player too much.

The interface often becomes an omniscient dashboard. The player sees every unit, every contact, every position, and every consequence immediately. That can be useful for fast play, but it removes a major part of command: acting through incomplete information.

MilSim starts from the opposite question. What happens if the player has to command through reports, delays, uncertainty, and limited perception?

The project separates objective simulation state from the commander's perceived state.

The simulation knows where units are, how terrain affects movement, what contacts exist, and what happens on each tick. The player sees what their role allows them to know through delivered reports, order history, mission context, and debriefs.

This makes the project closer to a command-loop prototype than a normal map game.

The current implementation is a local prototype and first-playable MVP candidate.

The source package identifies these main parts:

Implemented concepts include grid positions, command hierarchy, movement orders, route preview, terrain costs, blocked terrain, line-of-sight checks, delayed contact reports, inbox/order history, objectives, summary, debrief, and replay-style comparison.

The play loop is:

The important part is that the commander's view updates from delivered information, not omniscient truth.

MilSim uses scenario loading to make the command loop repeatable.

The source package names examples such as mvp, ridge-recon, and los-check. These scenarios let the project test movement, line-of-sight, terrain, report delay, and command decisions without rebuilding the simulation setup each time.

The scenario layer also makes the project easier to validate. A scenario can expose whether the mechanics actually create uncertainty, whether reports arrive in useful form, and whether the debrief explains the gap between what happened and what the player knew.

The project is Markdown-primary around documentation, backlog, runbooks, release notes, and decision records.

The source response describes earlier Todoist usage as legacy or archival evidence. Recent work focuses on simplifying the local GUI through direct feedback while keeping the headless simulation core as the foundation.

This matters because the core idea should not depend on a polished interface. The simulation needs to work headlessly first; the GUI should expose and control the same command loop, not replace it with a separate product surface.

MilSim has produced a deterministic simulation core, CLI/headless runner flows, scenario loading, documented automated test history, first-playable MVP candidate documentation, and a local browser GUI prototype.

The public claim should stay conservative: this is a working prototype and vertical slice direction, not a finished game or production training platform.

MilSim should not be presented as production-ready.

It should not claim military training validity, real-world doctrine accuracy, customer adoption, multiplayer, save/load, enemy AI, public hosted availability, 3D visuals, or a mature platform.

The source response also notes that the latest local tests were not freshly rerun for the fact package because the temporary dotnet SDK path was unavailable. Public copy should avoid quoting exact current pass counts until verification is rerun.

The useful pattern is broader than one prototype.

A system can separate objective state from perceived state. It can delay reports, restrict role views, and then compare what really happened with what the actor knew at decision time. That pattern applies to simulation design, game design, agent evaluation, and decision-support interfaces.

This project demonstrates:

MilSim is useful as a Portfolio use-case because it shows a different kind of agent-assisted project: not a website or writing system, but a simulation prototype built around uncertainty, reports, and command decisions.