I think there is a **very productive design analogy between RTS games and multi-UAV GCS**, but I would not copy an RTS literally. The key insight is: > **An RTS doesn't make the player control 50 units individually. It gives the player mechanisms for turning many low-level entities into a few high-level, cognitively manageable objects.** That is exactly the problem you're describing with 5 operators / 50 UAVs. Modern multi-vehicle systems are already moving toward this direction: for example, SolGCS describes multiple operators seeing/commanding the same vehicles with conflict resolution, while ARA's MPMS emphasizes multi-asset orchestration from one screen. ([sol.one][1]) I would build your GCS around that philosophy. --- # 1. Don't design a "drone control application" Design a **mission operating system**. This distinction is extremely important. A conventional GCS thinks: > Vehicle → telemetry → vehicle controls → mission Your next-generation GCS could think: > **Mission → Tasks → Groups → Vehicles → Autonomy** The operator shouldn't normally think: > "I need to command UAV #37." They should think: > "I need this group of 8 aircraft to search this area." And the system figures out which vehicles should execute it. That is much closer to an RTS. --- # 2. The RTS concept I would steal first: hierarchical selection Look at how games such as Blizzard Entertainment's StarCraft II handle units. You can select: * one unit * multiple units * a control group * all units of a type * units satisfying some condition StarCraft II also supports control groups, adding/removing units from groups, queued commands and cycling through subgroups. ([Blizzard News][2])  Your GCS could have the same concept, but **much more powerful**. ### Example You have: **50 UAVs** Instead of presenting 50 independent objects: ```text UAV-001 UAV-002 UAV-003 ... UAV-050 ``` the operator sees: ```text ALPHA 12 × ISR UAV Status: GREEN Task: Area Search Coverage: 64% BRAVO 10 × ISR UAV Status: GREEN Task: Route Recon CHARLIE 8 × Relay UAV Status: GREEN Task: Communications DELTA 20 × Mixed UAV Status: AMBER Task: Reserve ``` Then: **Click ALPHA → control the group.** Expand ALPHA → individual aircraft. This is essentially **zooming through levels of abstraction**. --- # 3. Think of the UI as a "semantic zoom" This might be one of the most important concepts for your design team. At maximum zoom-out: ```text ┌──────────────────────┐ │ MISSION │ └──────────┬───────────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ ALPHA BRAVO CHARLIE 12 10 8 ``` Zoom in: ```text ALPHA ┌───────────┼───────────┐ ▼ ▼ ▼ A-01 A-02 A-03 ``` Zoom further: ```text A-01 ┌──────┼──────┐ │ │ │ Flight Nav Payload ``` The same object changes representation depending on zoom. At fleet level: **ALPHA — 12 aircraft — healthy** At group level: **12 aircraft / formation / task / coverage** At vehicle level: **battery / GPS / flight mode / link / telemetry** At engineering level: **parameters / sensors / actuator status** This is much better than permanently putting 50 vehicles on screen. --- # 4. Your most important RTS feature: "control groups" Supreme Commander is particularly interesting for you. It lets players assign units to numbered groups, recall groups, add units to groups, select units by type, etc. ([supcom.fandom.com][3]) But you can go much further. Instead of: > Ctrl+1 = UAVs 1–8 allow: > **Group = semantic query** For example: ### Group: "Northern Search" ```text Members: aircraft where: type = ISR region = NORTH readiness > 80% ``` Now when UAV-07 fails: ```text Northern Search 12 → 11 vehicles ``` and another suitable aircraft can automatically join. That's a huge conceptual improvement over traditional RTS control groups. The group becomes a **mission entity**, not merely a collection of vehicle IDs. --- # 5. Separate "selection" from "ownership" This is where real-world GCS needs to diverge from games. In an RTS: > I select unit → I own the command. In a real multi-operator system, you need: > I select unit → I am requesting authority to command it. That's essential for your 5-operator scenario. Imagine: ```text UAV-17 │ ┌─────────┴─────────┐ │ │ Operator A Operator B viewing viewing ``` Both can see it. But only one has **command authority**. You could introduce something analogous to an RTS "selection state": ### Grey **Observed** ### Blue **Selected** ### Purple **Requested** ### Green **Command authority** ### Amber **Command conflict** ### Red **Command unavailable** That makes multi-operator collaboration visually obvious. --- # 6. Use "command leases" I think this could become a defining feature of your system. Instead of permanently assigning vehicles to operators: ```text Operator 1 owns UAV 1–10 Operator 2 owns UAV 11–20 ``` use temporary **command leases**. Example: > Operator A selects Group ALPHA. System: ```text ALPHA Command lease: Operator A Expires: 02:34 Observers: Operator B Operator C ``` Operator B can request the lease: ```text Operator B REQUEST CONTROL Reason: Emergency intervention ``` Operator A sees: > **Operator B requests command authority for ALPHA** Then: **Accept / Reject / Transfer** You could also allow predefined authority policies: ```text Mission Commander ↓ Group Commander ↓ Vehicle Operator ↓ Vehicle ``` This gives you the multiplayer RTS feeling without creating dangerous command ambiguity. --- # 7. Make the map the primary workspace I'd strongly resist designing the application as: ```text Top: toolbar Left: vehicle tree Center: map Right: telemetry Bottom: controls ``` That's basically a traditional GCS. Instead: ## The map should be the operating canvas. Everything should exist spatially. Something like: ```text ┌──────────────────────────────────────────────────────────┐ │ MISSION HEALTH 48/50 ALERTS 2 USERS 5 │ ├──────────────────────────────────────────────────────────┤ │ │ │ ╭──────── SEARCH AREA ────────╮ │ │ │ │ │ │ ● ● ● ● ● │ │ │ ALPHA │ │ │ ● ● ● ● │ │ │ ▲ │ │ BRAVO → → → → → │ │ │ │ │ │ ├──────────────────────────────────────────────────────────┤ │ ALPHA 12 UAV │ SEARCH │ 82% │ GREEN │ OP: ALEX │ └──────────────────────────────────────────────────────────┘ ``` The bottom panel becomes a **contextual command bar**. Select nothing → mission controls. Select group → group controls. Select vehicle → vehicle controls. Select task → task controls. This is very close to modern RTS design. --- # 8. Steal "drag-select" This sounds trivial, but it is enormously powerful. RTS: > Drag rectangle → select 15 units. Your GCS: > Drag rectangle → select all suitable vehicles in geographical area. Then: ```text 27 vehicles selected TYPE ☑ ISR 14 ☑ Relay 7 ☑ Transport 6 STATUS ☑ Ready 25 ☐ Warning 2 ``` Then you can turn the selection into: **Create Group** or **Assign Task** or **Add to Existing Group** This is much faster than clicking individual vehicles. --- # 9. But add "smart selection" This is where you can surpass games. Imagine a command palette: > **Select all available ISR aircraft within 20 km of Area A with >60% battery** Result: ```text 8 vehicles selected ``` Or: > **Select aircraft currently assigned to Northern Search** Or: > **Select vehicles with degraded navigation** Or: > **Select vehicles that can reach Task Bravo within 12 minutes** This is basically **SQL for operators**, but expressed naturally. You could provide both: ### Natural language > Select available search aircraft near Bravo. and: ### Structured filter ```text Type: ISR Availability: Available Distance: <20 km Battery: >60% Task: None ``` This could be one of the biggest UX differentiators. --- # 10. Steal "queued orders" from RTS games This is another huge one. StarCraft II and Company of Heroes both use queued commands. ([Blizzard News][2]) Instead of: > Go here. You can construct: ```text Task A ↓ Transit ↓ Search Area A ↓ Return ↓ Recharge ↓ Task B ``` For your GCS, make this **first-class**. Visually: ```text ALPHA [Transit] ↓ [Search Area A] ↓ [Loiter] ↓ [Return] ↓ [Recharge] ``` The operator manipulates the **mission graph**, rather than individual flight-controller commands. --- # 11. Introduce "task objects" This is probably the architectural concept I'd put at the center of the product. A vehicle should not be the primary object. A **Task** should be. For example: ```text TASK-143 Type: Area Search Priority: High Area: ████████████ Required: 4 aircraft Assigned: ALPHA / 4 Progress: 63% Health: GREEN ``` Then the fleet is a resource pool. ```text Task ↓ Requirements ↓ Assignment ↓ Vehicle allocation ↓ Execution ``` This allows your software to dynamically substitute vehicles. If UAV-03 becomes unavailable: ```text UAV-03 ↓ UNAVAILABLE Task engine: ↓ find replacement UAV-19 ↓ ASSIGNED ``` The operator doesn't need to manually rebuild everything. --- # 12. Think "Squads", not "fleets" Games have discovered something important: Humans are bad at managing 50 independent objects. Humans are much better at managing: **5–7 meaningful groups.** So your 50 UAVs should probably become something like: ```text ┌──────────────────────────────┐ │ ALPHA 12 ● GREEN │ │ BRAVO 8 ● GREEN │ │ CHARLIE 10 ● AMBER │ │ DELTA 12 ● GREEN │ │ RESERVE 8 ● GREEN │ └──────────────────────────────┘ ``` Five operators can then divide responsibility at the **task/group level**, not aircraft level. --- # 13. Borrow from Total War The Total War series is particularly interesting because it handles large numbers of units while preserving a relatively understandable tactical picture. One excellent concept is the **unit card / army card**. You could have: ```text ┌──────────────────────────────────────────────┐ │ ALPHA │ │ │ │ [●][●][●][●][●][●][●][●][●][●][●][●] │ │ │ │ 12 UAVs SEARCH 64% COMPLETE │ └──────────────────────────────────────────────┘ ``` Each little icon represents an aircraft. Click one: ```text UAV-17 ``` Click the group: ```text ALPHA ``` Click the mission: ```text SEARCH NORTH ``` Three different levels, one UI. That is **excellent cognitive compression**. --- # 14. Borrow from Homeworld for 3D spatial relationships Homeworld is worth studying for a different reason. The units exist in genuinely 3D space, so its interface has to communicate: * relative position * formation * heading * altitude * spatial relationships Your UAV system has exactly this problem. Don't show: ```text UAV 17 Lat: ... Lon: ... Alt: 147m Heading: 283° ``` as the primary representation. Show: ```text ↗ ● UAV-17 / / 147m / ● UAV-18 ``` and allow the numeric values to appear when needed. **Spatial cognition first. Numbers second.** --- # 15. Steal Supreme Commander's "strategic zoom" This is probably my **#1 game to study** for your project. Supreme Commander was designed around very large numbers of units and gave players extensive selection/grouping mechanisms. ([supcom.fandom.com][3]) Your equivalent could be: ### Level 1 — Strategic ```text Entire operating area 50 UAV 5 groups 7 tasks 3 alerts ``` ### Level 2 — Operational ```text Northern sector ALPHA BRAVO TASK 17 TASK 19 ``` ### Level 3 — Tactical ```text ALPHA UAV-01 UAV-02 UAV-03 ... ``` ### Level 4 — Vehicle ```text UAV-03 flight status navigation battery link payload etc. ``` ### Level 5 — Engineering ```text flight controller parameters sensors actuators logs configuration ``` **The same application should support all five levels without feeling like five different applications.** --- # 16. Introduce an "RTS command vocabulary" You could deliberately standardize a small number of high-level verbs. For example: ### Navigate ```text MOVE ROUTE FOLLOW RETURN HOLD ``` ### Observe ```text SEARCH SCAN TRACK MONITOR ``` ### Formation ```text JOIN SPLIT FORM REPOSITION ``` ### Mission ```text ASSIGN REASSIGN PAUSE RESUME CANCEL ``` ### Fleet ```text GROUP UNGROUP TRANSFER REQUEST RELEASE ``` The operator learns a **small vocabulary** instead of learning hundreds of vehicle-specific controls. --- # 17. Use "intent previews" This is where real-world GCS should improve upon games. In an RTS: > Click → command happens. For real vehicles: > Click → system previews what will happen. For example: ```text ┌───────────────────────────────────────┐ │ ASSIGN TASK │ │ │ │ 6 vehicles selected │ │ │ │ Estimated completion: 18 min │ │ Required battery reserve: OK │ │ Route conflicts: NONE │ │ Geofence conflicts: NONE │ │ Vehicle compatibility: 6/6 │ │ │ │ [CANCEL] [CONFIRM] │ └───────────────────────────────────────┘ ``` That is the **safety equivalent of an RTS command preview**. --- # 18. Make the system explain *why* it rejects a command Don't do: > ❌ Command rejected. Do: > **Cannot assign UAV-23** ```text Reason: Insufficient energy reserve Current: 43% Estimated requirement: 51% Alternatives: [UAV-19] [UAV-27] [UAV-31] ``` This is a massive UX improvement. The GCS becomes a **co-pilot rather than a form validator**. --- # 19. Multi-operator collaboration should feel like multiplayer This is perhaps your biggest opportunity. Imagine five operators logged into the same mission: ```text MISSION: ALPHA 👤 Alex Commanding: ALPHA 👤 Sara Commanding: BRAVO 👤 David Planning 👤 Maria Monitoring 👤 Ken Engineering ``` Everyone sees the same world. If Alex selects ALPHA: Everyone can see: ```text ALPHA COMMAND: ALEX ``` If Sara is planning: ```text BRAVO PLAN EDIT: SARA ``` If David changes a task: ```text TASK 23 Edited by David 12 sec ago ``` You essentially want **Google Docs + an RTS + a GCS**. That is a very compelling product direction. --- # 20. Treat mission plans like collaborative documents This is a major architectural implication. Don't make the mission: ```text mission.json ``` that one computer owns. Instead think: ```text Mission │ ├── Tasks ├── Groups ├── Assignments ├── Constraints ├── Operators ├── Permissions ├── State ├── History └── Events ``` Then every GCS workstation is a **client of shared mission state**. Operator A can plan. Operator B can monitor. Operator C can modify a task. Operator D can operate a particular group. Operator E can handle vehicle configuration. Everyone sees the same authoritative state. --- # 21. You need an event model, not just shared telemetry I'd strongly recommend thinking in terms of: ```text EVENT Operator A: "Assign Group ALPHA to Task 17" ↓ Mission service ↓ Validate ↓ Reserve resources ↓ Publish event ↓ All clients update ``` rather than: ```text GCS A → UAV GCS B → UAV GCS C → UAV ``` This becomes much easier to reason about when five operators are working simultaneously. The multi-user/multi-vehicle research literature has explored networked multiple ground stations and centralized/decentralized/hybrid mission planning, which is conceptually aligned with this architecture. ([chasemurray.com][4]) --- # 22. Build an "attention management" system This may be even more important than the map. The operator cannot watch 50 UAVs. So the system needs to determine: > **What deserves the operator's attention right now?** For example: ```text ATTENTION 🔴 UAV-27 navigation degraded 🟠 ALPHA task behind schedule 🟠 BRAVO approaching constraint 🟢 47 vehicles nominal ``` Not: ```text UAV-01 telemetry... UAV-02 telemetry... UAV-03 telemetry... ... ``` You want **exception-based operations**. Normal things disappear into the background. Abnormal things rise to the surface. --- # 23. Make the fleet visually "alive" Games do this extremely well. Don't make aircraft icons static. Their visualization should communicate: * direction * velocity * task * health * connectivity * group * attention state * trajectory * future intent For example: ```text ╭────── planned route │ │ ● │ ↗ │ ↗ ●───→ ``` And groups could have subtle visual identities. Not overly colorful arcade graphics — **information-rich tactical graphics**. --- # 24. But don't copy the "game HUD" This is an important warning. A common mistake would be: > "Let's make a military-looking game UI." That usually means: * dark background * neon green * tons of icons * radar * glowing circles * tiny text * dozens of panels That can look cool and be terrible to operate. Your goal should instead be: > **game-grade interaction model + aviation-grade information hierarchy** Not: > game aesthetics. --- # 25. One particularly interesting idea: "command stack" Imagine the operator selects 12 UAVs and gets: ```text ALPHA / 12 CURRENT ──────────────────── SEARCH AREA A NEXT ──────────────────── RETURN QUEUED ──────────────────── RECHARGE SEARCH AREA B ``` The operator can manipulate this like a task queue. Drag: ```text SEARCH A RETURN SEARCH B ``` into: ```text SEARCH A SEARCH B RETURN ``` This is much easier to understand than editing waypoint lists. --- # 26. Add "formation as a first-class object" Games such as Supreme Commander expose formation movement and queued commands for groups. ([supcom.fandom.com][3]) For your system, don't make formation a hidden parameter. Make it visible: ```text ALPHA ● ● ● ● ● ● ● FORMATION [ GRID ] [ LINE ] [ COLUMN ] [ CUSTOM ] ``` Then the operator changes the **group relationship**, rather than individually manipulating vehicles. For real-world systems, obviously keep vehicle-specific safety/operational constraints authoritative; the formation UI should express intent, not bypass those constraints. --- # 27. Create "roles" inside groups Suppose you have: ```text ALPHA — 12 UAVs ``` Don't necessarily make all 12 equivalent. The group could contain: ```text LEAD 1 SCOUT 4 RELAY 2 SEARCH 4 RESERVE 1 ``` The UI represents **roles**, not just vehicles. If one aircraft fails: ```text RELAY 2 → 1 Replacement available: UAV-38 ``` This is much closer to how a human thinks about a coordinated system. --- # 28. Think of autonomy as the game's "AI" The most important design question is: > **What should the operator have to do manually?** The answer should be: as little as possible. The GCS should handle: * resource allocation * vehicle selection * route generation * task reassignment * constraint checking * health monitoring * conflict detection * synchronization * status summarization The operator handles: * intent * priorities * approvals * exceptions * high-level decisions That's the real leap from "50 drones controlled by 5 people" to something that can actually scale. A current commercial example, SolGCS, explicitly describes fleet-scale monitoring/control, multi-pilot collaboration and automated path computation for groups of UAVs. ([sol.one][1]) --- # 29. My proposed information architecture I'd seriously prototype something along these lines: ```text MISSION │ ┌─────────────┼─────────────┐ │ │ │ TASKS FLEET USERS │ │ │ ┌────┴────┐ ┌───┴────┐ ┌───┴────┐ │ │ │ │ │ │ Task A Task B Group A B Operator 1 2 │ ┌─────┼─────┐ │ │ │ UAV1 UAV2 UAV3 ``` And the main UI: ```text ┌────────────────────────────────────────────────────────────┐ │ MISSION FLEET 48/50 ALERTS 3 USERS 5 │ ├────────────────────────────────────────────────────────────┤ │ │ │ MAP │ │ │ │ [ALPHA] ● ● ● │ │ ● ● │ │ │ │ [BRAVO] ● ● ● ● │ │ │ │ [TASK 17] │ │ │ ├────────────────────────────────────────────────────────────┤ │ SELECTED: ALPHA │ │ 12 VEHICLES │ SEARCH │ 82% │ OP: ALEX │ │ │ │ [TASK] [MOVE] [HOLD] [GROUP] [TRANSFER] [DETAILS] │ └────────────────────────────────────────────────────────────┘ ``` The UI stays extremely simple until the user asks for complexity. --- # 30. The three-layer UI I would prototype first ### Layer 1 — Strategic **"What's happening?"** ```text Fleet health Mission progress Tasks Alerts Operators Groups ``` ### Layer 2 — Operational **"What needs to happen?"** ```text Select group Assign task Modify task Reassign resources Resolve conflicts ``` ### Layer 3 — Vehicle **"What is this machine doing?"** ```text Telemetry Flight status Navigation Payload Health Logs Configuration ``` The mistake I'd avoid is exposing Layer 3 all the time. --- # 31. Games I'd put on your team's research list I'd actually have the UX team **play these, not merely look at screenshots**. | Game | What to study | | ------------------------------------------- | ------------------------------------------------------------------------------ | | **Supreme Commander / Forged Alliance** | ⭐ Strategic zoom, huge fleet management, control groups, multi-unit commands | | **StarCraft II** | Selection, hotkeys, control groups, command queues, extremely fast interaction | | **Company of Heroes 2** | Squad abstraction, contextual commands, tactical map, unit cards | | **Homeworld Remastered** | 3D spatial management, formations, fleet organization | | **Total War: Warhammer III** | Massive unit-card organization, army hierarchy, tactical/strategic layers | | **Command & Conquer: Generals / Zero Hour** | Fast RTS interaction and simple command vocabulary | | **Ashes of the Singularity** | Very large numbers of units and hierarchical control | | **Beyond All Reason** | Massive-scale unit control, groups, strategic zoom | | **Planetary Annihilation** | Extremely large-scale strategic management and multi-planet abstraction | | **Anno 1800** | Complex systems presented through understandable hierarchical UI | | **Oxygen Not Included** | Exception/attention management and system visualization | | **Frostpunk** | Information prioritization and communicating system state | | **FTL** | Managing multiple simultaneous problems with limited attention | | **XCOM 2** | Clear tactical information hierarchy and action confirmation | | **Door Kickers 2** | Planning → execution separation and visual task sequencing | If you only have time for **five**, I'd choose: ### 1. Supreme Commander ### 2. StarCraft II ### 3. Company of Heroes ### 4. Homeworld ### 5. Total War Those five cover most of the interaction patterns you're interested in. --- # 32. And there's a very interesting "bonus game": Factorio I would absolutely have someone on the team study Factorio. Not because of its RTS combat. Because of its **automation philosophy**. The fundamental question in Factorio is: > "Why am I manually doing this repeatedly when I can define a system that does it for me?" That's exactly the question your GCS should ask. Instead of: > "Operator, tell UAV 23 to do X." you want: > "Operator, define what outcome you want." Then the system handles the repetitive orchestration. --- # 33. Another surprisingly useful reference: Dwarf Fortress Again, not for aesthetics. For **information density and hierarchical abstraction**. A complex world can contain thousands of entities, but the user doesn't need to interact with all of them simultaneously. That's precisely the problem with 50+ vehicles. --- # 34. The ultimate design principle I'd put this on the wall of your UX team's room: > ### **Don't make the operator control 50 vehicles.** > > ### **Make the operator control 5 intentions.** > > ### **Make the system turn those intentions into 50 vehicle behaviors.** That's the difference between a conventional GCS and what you're describing. The current generation is already demonstrating pieces of this direction: fleet-oriented GCS products emphasize common mission views, multi-operator collaboration, vehicle-agnostic orchestration and centralized/decentralized autonomy. ([ARA][5]) Your opportunity is to combine that with the **interaction design maturity of RTS games**. --- ## If I were designing the product from scratch I'd make these **10 concepts foundational**: 1. **Mission** — the shared workspace. 2. **Task** — what needs to happen. 3. **Group** — a semantic collection of vehicles. 4. **Vehicle** — the physical asset. 5. **Role** — what a vehicle contributes to a group. 6. **Operator** — human identity and authority. 7. **Command lease** — temporary authority over an object. 8. **Intent** — high-level desired behavior. 9. **Constraint** — what the system must never violate. 10. **Event/history** — who changed what and why. Then build the UI around: **Select → Inspect → Assign → Preview → Confirm → Observe → Exception → Reassign** rather than: **Click UAV → open panel → change parameter → click save → repeat 50 times.** That, in my opinion, is the real lesson to take from RTS games. And there's a potentially excellent product vision hidden in your question: **a "multiplayer RTS" interaction model sitting on top of a rigorous shared mission/state/authority architecture**, where the game-like part makes complexity comprehensible but the underlying system remains deterministic, auditable, constraint-aware, and safety-first. [1]: https://www.sol.one/gcs?utm_source=chatgpt.com "Sol Ground Control Station" [2]: https://news.blizzard.com/en-us/article/6640645/game-guide-simplified-controls?utm_source=chatgpt.com "Game Guide: Simplified Controls — StarCraft II — Blizzard News" [3]: https://supcom.fandom.com/wiki/Controls?utm_source=chatgpt.com "Controls | Supreme Commander Wiki | Fandom" [4]: https://www.chasemurray.com/research/multi-user-multi-vehicle-mission-control-m3c/?utm_source=chatgpt.com "Multi-user Multi-vehicle Mission Control (M3C) | Chase Murray | UAVs and Operations Research" [5]: https://www.ara.com/mpms/?utm_source=chatgpt.com "MPMS - ARA"