Frontline Command

PROJECT 03 · EARLY GAME CONCEPT

Frontline Command

Build, defend and decide when to advance.

COMMAND · ARMY · STRATEGIC
Single-player real-time strategy / PC / Proposed session: 6–8 minutes

Lead a small fictional force, collect resources and build a compact base. Balance defence and expansion before committing to an attack on the rival headquarters.

01 / The player experience

You are a commander responsible for a base and a small group of units. Resources are limited, so every new building or unit delays another opportunity. A clear view of the battlefield matters as much as army size.

Player goal: Protect your headquarters and destroy the rival headquarters.
Emotional goal: Feel that a victory follows from a clear plan and a well-timed decision.

Real-world visual research

Photographs inform the visual organisation of this fictional game: distinguish headquarters, vehicle spaces and support buildings at a glance.

02 / Core gameplay loop

Gather → Build → Train → Scout → Defend or advance → Reinvest

• Gather: A worker collects one resource type and returns it to the headquarters.
• Build: Place a barracks to unlock combat units or a tower to protect the base.
• Command: Click or drag to select; right-click to move or attack; use a visible stop button to cancel an order.
• Scout: Explore a small map. Fog of war hides areas outside unit vision.
• Choose: Spend on a stronger economy, a defensive structure or a mobile force.

Planned unit roles: Worker — economy; scout — fast vision; guard — slower, stronger defence. Distinct silhouettes and labels make roles visible without relying on colour alone.

Consequences: Over-expansion leaves the headquarters exposed. Attacking too early loses units; waiting too long lets the opponent grow. Headquarters health reaching zero ends the match.

03 / A moment worth presenting

You have 100 credits. A tower costs 80, a scout costs 40 and a guard costs 60. The next enemy wave is announced, but the rival base has not yet been explored.

Audience prompt: “Would you build the tower, or train a scout and a guard?”

Design question: Can a tiny set of units create different viable strategies? These example costs are starting values for testing, not final balance.

04 / First playable scope

• One compact map with two headquarters and a central route.
• One resource type, three unit roles and two buildable structures.
• Selection, movement, basic combat, fog of war and health feedback.
• One scripted opponent with clearly signalled waves; victory, defeat and restart.

Later possibilities: More maps, smarter opponents and optional unit upgrades. Multiplayer and large armies sit outside the first prototype.

Development plan

1. Week 1 — Control: Greybox the map; implement selection, movement and basic pathfinding.
2. Week 2 — Economy: Add gathering, construction, training and the three unit roles.
3. Week 3 — Match: Add enemy waves, combat feedback and end states; test with five players.

Main development risk: Unit navigation and simultaneous systems can expand quickly. Use a small map, low unit count and simple enemy scripts to keep testing manageable.

Playtest targets: Four of five players can gather, build and issue an order after a short tutorial; players recognise each unit’s purpose; at least two opening plans can win after balancing. No playtests have been completed yet.

Research next: Study how OpenRA presents selection, production queues and fog of war. Translate those observations into a much smaller fictional strategy game.

05 / Presentation notes

Suggested delivery: 2 minutes — pitch 20s, visual references 20s, resource decision 40s, prototype plan 40s.

Status: concept proposal. Rules, costs and milestones are provisional. Three real-world photographs and one existing-game screenshot are used; no AI-generated imagery.