Lunastadt Devlog: How the Enemy Command Chain Works
https://youtu.be/mglYbeb1MmU
One of the most important systems inside Lunastadt: The Invasion from the Moon is the enemy command chain.
The enemy does not operate as a simple scripted RTS bot. It does not merely pick the nearest city and send tanks forward forever. Instead, Lunastadt uses a layered command structure designed to behave more like an artificial military staff.
At the top of that structure is the Enemy General — a large language model acting as the strategic mind of the invasion.
Below the General are scanner systems, command interpreters, operational commanders, unit command systems, and individual battlefield units. Each layer has a specific role. Together, they create an enemy force that can observe the battlefield, form intentions, issue orders, execute operations, learn from failure, and continue pushing the invasion forward.
The command chain works like this:
Battlefield State ↓ EnemyGeneralScanner ↓ EnemyGeneralBrain / Large Language Model ↓ EnemyGeneralCommandInterpreter ↓ EnemyCommander ↓ UnitCommandSystem ↓ Individual Units ↓ Battlefield Results ↓ General Memory ↓ Next Strategic Decision The Scanner: The General’s Eyes
The first layer of the system is the EnemyGeneralScanner.
This script acts as the General’s battlefield intelligence system. It scans cities, military bases, ownership states, nearby forces, target distances, and the current state of the front.
The scanner does not move units. It does not launch attacks. It does not directly change the game state.
Its purpose is to answer the questions a commander would need answered before making a decision:
Where are our forces?
What cities do we control?
What bases do we control?
What does the enemy still hold?
Which enemy targets are closest?
Which targets are weak?
Which targets are capturable?
Which Lunastadt-controlled cities or bases have enough forces to launch an attack?
The scanner then prepares a battlefield briefing for the Enemy General. This briefing includes target candidates, launch origins, nearby forces, and strategic opportunities.
In simple terms:
The scanner gives the General eyes.
The Enemy General: The Strategic Mind
The EnemyGeneralBrain is the strategic layer of the invasion.
This is where the large language model enters the system. The Brain builds a detailed battlefield prompt and sends it to the local LLM. The LLM then responds with a strategic assessment, choosing future objectives for the invasion.
The General is not directly controlling each tank. It is not clicking units around the map. Its role is higher level.
It thinks in terms of objectives:
Capture this city.
Secure this military base.
Expand from this captured region.
Avoid repeating a failed assault.
Press the attack while momentum is positive.
Consolidate if the front is collapsing.
This gives the enemy a command personality. The General is not just running a math formula. It is reading the war like a commander and deciding what matters next.
Strategic Memory: The War Diary
One of the most important parts of the General system is memory.
The Enemy General does not see the battlefield as a brand-new snapshot every time it thinks. It maintains a persistent war diary across think cycles.
That memory tracks things like:
Previously issued orders
Targets currently pending
Operations in progress
Captured objectives
Failed attacks
Retreats
Repeated attempts against the same target
Cities or bases lost back to the player
Overall campaign momentum
This prevents the General from behaving like a forgetful script. If an attack fails, that failure can appear in the next strategic prompt. If a city is captured, it becomes part of the General’s victory record. If Lunastadt loses territory, the General can recognize that the front is under pressure.
This creates a feedback loop:
The General gives an order. The Commander tries to execute it. The battlefield produces a result. The result is reported back to the General. The General remembers. The next decision is made with that memory included. That loop is what makes the enemy command chain feel alive.
The LLM’s Role
The large language model functions as the actual strategic voice of the Enemy General.
It receives a structured briefing containing battlefield conditions, current territory, available forces, active operations, failed targets, recent victories, and recent retreats.
From that information, it writes a strategic assessment.
The LLM might decide to push aggressively toward a nearby city, capture a weakened military base, consolidate after losses, or choose multiple targets to overwhelm the defender.
The LLM is not expected to know Unity code. It does not need to understand every internal class or method. It simply acts as the General Staff: reading the situation and issuing strategic intent.
In Lunastadt, that distinction matters.
The LLM decides what should happen.
The rest of the command chain decides how to make it happen inside the simulation.
The Interpreter: Turning Language Into Orders
Once the Enemy General produces a written assessment, that text is passed to the EnemyGeneralCommandInterpreter.
This is the layer between natural language and game logic.
The interpreter reads the General’s assessment and tries to extract actionable objectives. Ideally, the General provides a structured block such as a future intent section, including the target, objective type, origin, and risk.
If the output is not perfectly structured, the interpreter can still fall back to scanning broader primary and secondary objective sections.
This gives the system flexibility. The LLM can write like a commander, while the interpreter looks for the operational meaning inside that text.
For example, the General might write:
PRIMARY OBJECTIVE: 1. CAPTURECITY: Dayton The interpreter turns that into a structured command:
Objective Type: Capture City Target: Dayton Origin: Auto-selected by Commander The interpreter also performs basic safety checks. It avoids duplicate active operations, rejects malformed placeholder targets, respects injection cooldowns, and hands real game-state validation to the EnemyCommander.
In simple terms:
The interpreter gives the General’s language discipline.
The EnemyCommander: The Operational Executor
The EnemyCommander is where strategy becomes military action.
This is the system that receives the General’s objectives and decides whether those objectives can actually be executed. It resolves target names, finds valid cities or bases, selects launch origins, checks available forces, gathers units, and launches operations.
The Commander is responsible for operational behavior such as:
Planning attacks
Launching operations
Gathering tanks and anti-air
Assigning aircraft
Moving units to staging points
Starting assaults
Capturing cities
Capturing bases
Retreating when operations fail
Garrisoning captured territory
Producing reinforcements
Defending owned territory
Expanding from newly captured locations
The Commander can receive direct General objectives, but it also has autonomous invasion behavior. This means the invasion can continue spreading even between General think cycles.
One of the strongest parts of the system is the General Objective Queue. The LLM General can name multiple targets, and the Commander can work through those objectives over time. If an objective temporarily fails because there are not enough tanks or a launch origin is not ready, it can be retried later instead of being lost completely.
This turns the General from a single-shot order giver into a strategic director.
Operation Phases
Once the Commander accepts an objective, it launches an operation.
An operation can move through several phases:
Staging Assault Occupying Consolidating Retreating Finished During staging, units move into position.
During assault, tanks and aircraft attack the objective.
During occupation, forces attempt to secure the target.
During consolidation, the captured city or base becomes part of the invasion network.
During retreat, surviving forces pull back after failure.
During finished, the operation is removed from active command.
The Commander can also perform direct assaults against nearby targets. If a target is close enough, the system can skip the long staging process and begin the assault immediately. This helps nearby city-to-city fighting feel faster and more natural.
The UnitCommandSystem: The Hands of the Army
At the bottom of the command hierarchy is the UnitCommandSystem.
The EnemyCommander decides what operation should happen, but the UnitCommandSystem is what actually sends movement and attack orders to the units.
This includes units such as:
Tank battalions
Anti-air batteries
Fighter squadrons
Bomber squadrons
Hypersonic fighters
The UnitCommandSystem allows the Commander to issue standardized orders instead of directly manipulating every unit script by hand.
Movement orders are used for staging, garrisoning, retreating, and positioning.
Attack orders are used during assault phases.
This separation is important because it keeps the system organized:
The General chooses objectives.
The Interpreter translates intent.
The Commander plans operations.
The UnitCommandSystem moves the pieces.
The units carry out the battle.
Feedback: The Chain Reports Back Upward
The command chain does not stop once units move.
When an operation launches, captures a target, or retreats, that information is reported back to the EnemyGeneralBrain.
The General’s memory then updates:
A launched operation becomes active.
A captured city becomes a victory.
A retreat becomes a failure or warning.
A lost city becomes a strategic setback.
A repeated failed attack becomes a known problem.
The next time the LLM thinks, those facts are included in the prompt.
This creates the core loop of the invasion:
Observe Decide Translate Execute Report Remember Decide Again That is the heart of the enemy command system.
Why This Matters
Most RTS enemies are scripted. They follow build orders, attack timers, behavior trees, or scoring systems.
Lunastadt still uses scoring and game logic, but it adds something above that: a strategic language model that can read the campaign and issue intent.
The result is not just an enemy that attacks.
It is an enemy that appears to command.
The player is not simply fighting units. The player is fighting an artificial command structure.
There is a General watching the map.
There is an interpreter converting orders.
There is a commander launching operations.
There are units carrying those orders into the battlefield.
There is memory.
There is momentum.
There is consequence.
And then the invasion thinks again.
Final Summary
Lunastadt’s enemy command chain is built as a true hierarchy. The scanner observes the battlefield and prepares intelligence. The Enemy General, powered by a large language model, reads that briefing along with its war diary and decides strategic objectives. The command interpreter converts the General’s written intent into structured game orders. The EnemyCommander validates those orders, gathers forces, launches operations, and routes movement and attack commands through the UnitCommandSystem. As battles resolve, captures, retreats, and failures are reported back to the General’s memory, allowing the LLM to make its next decision with knowledge of what happened before.
Or, put more simply:
The scanner gives the enemy eyes.
The LLM General gives it intent.
The interpreter gives it language discipline.
The Commander gives it operational control.
The UnitCommandSystem gives it hands.
The battlefield gives it consequences.
Then those consequences return as memory, and the invasion thinks again.
For more information or gameplay updates see our social TikTok :
https://www.tiktok.com/@black_sail_studio
-Sean 6-10-2026
#AIPoweredGames #devlog #ExperimentalGameAI #gaming #IndieDevlog #RealTimeStrategy #TacticalCommandSystem #UnityGame #videoGames #warGame #WarSimulation
Les Escrimousses
Silicium
Franzoar
LeTomPouetDuJdR
Black Sail Studio
Le Bottin des Jeux Linux
FitGirl Repacks [Unofficial]
Le rôliste numérique
