The commander system is currently in design and interface prototyping. That makes it a useful devlog subject: the important work right now is deciding where the system belongs and which decisions it should create before final progression numbers are attached.
Two places, two responsibilities
The current design direction splits commander management between the capital and the selected army. A future capital Keep would own the roster: recruiting or unlocking leaders, inspecting traits, improving personal equipment and seeing which commander is assigned where. The Keep roster does not exist in live campaign state yet.
The proposed Army Camp view owns assignment context. It shows the commander leading that force, a primary benefit and actions to assign or edit the leader. This prevents the Keep from asking the player to choose an army while working on personal progression, and it prevents the army panel from becoming a complete character-management screen.
Why the boundary matters
Lane Wars already asks the player to manage unit types, levels, wounds, reinforcement timing, supply and stances. A commander layer can easily overwhelm that structure or duplicate it. Keeping roster management in the Keep and assignment in Camp lets each screen answer one clear question.
- At the Keep: who is available, what are their traits and what can be improved?
- At the army: who leads this force and what practical benefit does that provide now?
What the prototype actually contains
The implemented artifact is an Army panel inside the UI test scene. Its Camp tab contains separate Field Camp and Commander cards. Both cards can show a level through stars and one short benefit. The Commander card switches between an empty Assign state and an assigned Edit state, with removal intentionally kept inside the edit flow.
The data in that screen is mock data. Commander identity, levels and benefits are not saved to an army, and the actions do not yet recruit, assign or improve a live campaign commander. Equipment and traits remain broad design topics rather than a finalized slot system.
Design principle: commanders amplify a plan; they do not replace the soldiers carrying it out.
Designing the mobile interaction first
The Camp prototype is built at the same mobile-focused reference size as the other army tabs. It keeps the commander's primary benefit and one large action readable without turning the army inspector into a dense character sheet.
Dedicated commander artwork does not exist yet, so the prototype deliberately uses a player-colored soldier preview. This keeps work moving on layout, scaling, readable labels and interaction states without pretending placeholder art is final.
What is not decided yet
Persistent commander state, recruitment rules, the final trait pool, experience gain, costs and any equipment model remain open. Those choices need the campaign and battle economy to be stable enough to judge them. It would be easy to invent impressive bonuses now and spend months undoing their effect on every other system.
The next step is connecting the prototype to persistent commander data and testing a deliberately small set of benefits. If players can explain why they assigned a particular leader to a particular army, the system is doing useful strategic work.