1513 lines
31 KiB
Plaintext
1513 lines
31 KiB
Plaintext
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" |