MilSim

MilSim is a modular command-and-control simulation built around a boundary that most strategy games remove: the player cannot see objective battlefield state.

The player acts as a platoon commander, issues orders to squads, and makes decisions from reports that arrive late, contain limited observations, and become stale as the simulation continues. The defining mechanic is the gap between what is happening and what the commander currently believes is happening.

The project began as a headless simulation core, then developed into a complete text-mode first playable, a JSON scenario system, and a local browser prototype with an interactive tactical map.

Conventional strategy games usually provide near-perfect awareness. Friendly and enemy positions are visible, information updates immediately, and an order can be evaluated against the true state of the map.

MilSim treats that access as the main design problem.

The simulation owns a complete objective state: real unit positions, hidden contacts, terrain, orders, and events. The player never receives that state directly. A Role View Layer produces a separate commander projection containing only authorized units, known positions, delivered reports, observation times, and confidence.

An enemy in objective state has an internal entity identity. In the commander's picture it appears as a contact track with a different identifier. The marker therefore means that something was observed at a location at a particular time, not that an enemy is known to be there now.

This distinction turns uncertainty from visual decoration into a system rule. A correct decision can be based on information that was accurate when observed and wrong by the time it arrives.

The first technical risk was the information model, not graphics. Development therefore started with a deterministic C# and .NET 10 core independent of any client.

The architecture separates objective simulation, player commands, automated scenario execution, tests, and presentation across reusable modules. CLI, headless runner, and browser client all operate on the same domain rules instead of implementing their own versions of movement, detection, reporting, or scoring.

The command path is explicit:

Simulation time advances through discrete ticks rather than wall-clock time. Events receive ordered sequence numbers, and the same initial state with the same commands produces the same result. This makes complete playthroughs reproducible and allows failures to be tested without rendering a screen.

The accepted text-mode MVP uses a deliberately small scenario: one platoon commander controls three squads on a 20 by 20 grid. The player receives a briefing, inspects the current commander picture, plans movement, issues an order, advances time, receives contact reports, and completes the mission with scoring, debrief, and objective replay.

Reports have their own lifecycle:

Observation time, creation time, planned delivery, and actual receipt are stored separately. The interface can therefore show not only a reported position but also the age and status of the information.

The CLI exposes the complete game loop through commands for briefing, objectives, status, map, route preview, movement, time advancement, report inbox, order history, summary, debrief, and replay. Tutorial guidance, contextual next steps, a legend, a built-in demo, scenario listing, and an automated MVP check make the simulation playable without reading the codebase.

The first movement model grew into terrain-aware planning. Open ground, roads, rough terrain, and blocked cells affect travel time, route validity, visibility, and detection probability.

Route preview calculates estimated arrival without changing simulation state. Waypoint orders validate a complete multi-leg route before submission and automatically issue the next leg after a squad reaches a waypoint. Blocked terrain interrupts line of sight, while rough terrain makes a contact harder to detect.

Scenarios moved from hardcoded setup into validated JSON. A scenario defines map size, starting units, hidden contacts, terrain, objectives, hints, and recommended progression. Three bundled scenarios cover the basic delayed-report loop, terrain reconnaissance, and line-of-sight behavior.

Because scenario data, domain rules, and client presentation are separate, new missions can be authored without changing the simulation core.

The text-mode release proved the command loop, but it did not prove that a new player could understand the system without learning a CLI. The next vertical slice introduced a local ASP.NET Core service and browser client.

The browser provides scenario selection, session management, an interactive tactical grid, squad selection, destination selection, route preview, movement controls, tick controls, mission progress, report inbox, order history, summary, and debrief.

Early versions exposed too much console structure and hid important goals below the map. Playtesting moved the current mission state and next action into the primary view, added fit-to-view and zoom controls, made friendly markers selectable, clarified movement actions, and separated current results from history.

The visual map still consumes the Role View. It does not receive objective enemy positions and hide them with CSS. The same information boundary applies regardless of whether the client is text or graphical.

Several boundaries keep the simulation honest.

Objective DTOs and player-facing DTOs are separate. Truth-leak tests reject internal enemy identities, objective replay data, and unrestricted simulation state from player responses. Command authority is validated before an order enters the simulation. Incoming information updates the commander projection only after its report has been delivered.

The event log supports both deterministic replay and after-action analysis. The player can compare the decisions made from available information with the objective sequence of events without giving the live command view access to that truth.

This architecture is useful beyond one military game. The same distinction between objective state and role-limited perception appears in incident response, logistics, operations tooling, agent evaluation, and any decision system where data arrives late or through an authority boundary.

The clean committed baseline was freshly verified on 2026-09-13. All 143 automated tests passed. The web project built successfully, both browser JavaScript files passed syntax checks, and the HTTP smoke test created a session, loaded all three bundled scenarios, and returned the expected 400-cell map.

The accepted release is First Playable MVP v1. It covers the complete text-mode command loop, while the browser GUI remains implemented but under review.

Current development explores engagement orders, combat outcomes, richer contact states, range and line-of-sight rules, military symbols, and obstacle-avoiding pathfinding. These experiments are not represented as released capability. A fresh run of the unaccepted working tree produced 151 tests with 140 passing and 11 known failures around the changing route, contact, and CLI behavior; the verified committed baseline remains green.

MilSim does not yet include enemy AI, multiplayer, save and load, a scenario editor, a mature weapons, casualty, or morale model, electronic interference, packaging, or public deployment.

I defined the product concept and MVP boundary, designed the domain and information model, implemented the simulation core, CLI, scenario system, and browser prototype, and built the automated and end-to-end verification around them.

The work combines product design, system architecture, C# and .NET development, browser UX, test design, playtesting, backlog management, and architecture documentation. Each iteration was organized as a vertical slice that had to add a testable part of the command experience rather than only another technical abstraction.

MilSim demonstrates the path from an abstract mechanic to a working decision system: objective state remains protected, uncertainty has explicit structure, several clients share one deterministic core, and every public claim is bounded by reproducible evidence.