Chapter 2: Comms, Antennas & Encryption Reads

Created by Sarah Choi (prompt writer using ChatGPT)

Comms, Antennas & Encryption Reads for Unmanned, Drone & AI‑Driven Mecha

In unmanned and AI‑driven mecha, communication is not a supporting system—it is the nervous system. Sensors let a drone perceive, but comms let it coordinate, receive intent, share perception, and remain accountable to command. When you design comms well, autonomy becomes legible: the audience can sense whether a mech is remote‑piloted, semi‑autonomous, swarm‑linked, or fully independent. When you design comms poorly, even a beautiful drone can feel like magic that works only because the script says so.

For concept artists, “encryption reads” and antenna language are exterior tells that communicate trust, sophistication, vulnerability, and doctrine. For production teams, comms design becomes a set of hard points and behaviors: antenna rigs to model and rig, VFX states for transmitting and jamming, gameplay affordances for line‑of‑sight, and narrative beats for loss of link and degraded modes.

Start with doctrine: who talks to whom, and why

Before you draw an antenna, decide the communication doctrine. Unmanned systems usually sit in one of a few patterns.

A hub‑and‑spoke pattern implies a command unit (human or AI) coordinating multiple drones. A mesh network implies swarm behavior where units relay messages among themselves. A satellite/overwatch pattern implies beyond‑line‑of‑sight control and long‑range persistence. A local autonomy pattern implies drones that can operate without constant link, syncing data when available.

These patterns change exterior design. Hub‑and‑spoke designs often feature a prominent relay mast or multiple antennas on the hub unit, while spokes may have smaller, simpler rigs. Mesh networks often show distributed antennas and redundant small nodes. Satellite patterns often include a directional array or high‑gain element. Local autonomy patterns can de‑emphasize antennas and emphasize onboard compute and storage instead.

The “why” matters too. Are they communicating for live control inputs, for sensor fusion, for target sharing, for legal accountability logs, for friend‑foe identification, or for mission updates? The more time‑critical the comms, the more robust and redundant the hardware should look.

Antenna families and what they imply visually

Antenna design is a visual shorthand for capability. Different antenna shapes suggest different behaviors and constraints, even to viewers who don’t know the underlying tech.

Omnidirectional antennas: constant connection

Omnidirectional antennas imply broad coverage and ease of link. Visually, they can read as whips, fins, small stubs, or short masts. They feel like “always on” communication and are common on generalist drones.

Omni antennas are great for storytelling because they can be numerous, inexpensive, and vulnerable. They also imply that the drone doesn’t need precise pointing—it can keep talking while moving aggressively.

Directional antennas: long range and intent

Directional antennas imply longer range, higher bandwidth, or more secure links at the cost of needing to aim. Visually, they read as panels, dishes, horns, or faceted arrays. Directional elements tell the audience “this unit has to point to speak.” That constraint is an excellent design lever.

A drone with a big directional panel suggests command and intelligence roles: relaying data, coordinating, or streaming high‑resolution sensor feeds. It also becomes a gameplay target and a cinematic focal point—rotate the panel to “phone home,” then lose it and the unit becomes isolated.

Conformal antennas: stealth and integration

Conformal antennas are integrated into surfaces rather than sticking out. They read as smooth panel seams, subtle patches, or flush arrays. Conformal design implies a stealth doctrine: fewer protrusions, lower signature, and intentional integration.

For concept artists, conformal antennas are a challenge because they can become invisible. The solution is to create recognizable panel motifs: a repeated “comms tile” shape, a distinct material patch, or a standardized seam language across the faction.

Relay masts and elevated rigs: network leadership

Tall masts and elevated antenna rigs imply the drone is a relay node or leader. Height suggests better line‑of‑sight and larger coverage. This is a strong exterior tell for command drones, battlefield routers, or overwatch units.

A mast can be retractable, which gives you state changes: stowed for travel/stealth, extended for communication. Those states are very production‑friendly: they become animation beats and gameplay tells.

Bandwidth and payload: what the comms must carry

Not all links carry the same kind of information. Control signals require low latency and reliability, but not necessarily massive bandwidth. Sensor streams and mapping data can require enormous bandwidth. Encryption and redundancy can add overhead.

You can imply bandwidth needs through hardware scale and complexity. A tiny antenna cluster suggests basic command and telemetry. A large panel array suggests heavy data transfer—video, lidar maps, sensor fusion. A drone that carries both might show multiple antenna types: small omni nodes for control and coordination plus a directional array for burst data uplinks.

This logic helps avoid arbitrary “antenna decoration.” Each visible element earns its place by implying a communications job.

Encryption reads: how to show security without writing a novel

Encryption is invisible, but it can be made legible through design language and behavior. “Encryption reads” are visual cues that suggest the system is secure, disciplined, and designed for contested environments.

One approach is hardware ritual: guarded access panels, tamper seals, keyed connectors, and protected antenna bases. This implies the system is controlled and audited.

Another approach is behavioral cues: a transmitting state that looks like encoded bursts rather than constant broadcast, or a handshake animation—brief light sequences, synchronized pulses among swarm units, or a “link lock” indicator that changes once the channel is secured.

A third approach is compartmentalization: separate comms modules for different networks—command net, swarm net, emergency beacon. You can show this with distinct antenna groups placed in different zones and labeled with iconography.

These reads are helpful for narrative and gameplay. A jammed secure link feels different from an open broadcast. A compromised unit might flash a warning state, switch to fallback protocols, or reduce transmit power.

Contested environments: jamming, spoofing, and degraded modes

Drone mecha are especially vulnerable to electronic warfare. Your designs can become dramatically richer if you treat comms as a battlefield system rather than a quiet background feature.

A robust drone design implies it can handle jamming and interference. Exterior tells for this include antenna redundancy, multiple types of antennas, directional arrays for narrow beams, and protected signal processing modules.

Degraded modes are a storytelling powerhouse. If comms fail, what happens? Does the unit return home, hold position, switch to local autonomy, or become dangerous? The answer should show up in design cues: emergency beacons, local navigation sensors, “safe mode” lights, or physical switches accessible to maintenance crews.

For production, degraded modes can become gameplay states: the drone’s behavior changes, UI changes, and the player can exploit or mitigate the failure.

Line of sight, occlusion, and placement logic

Antenna placement should respect physical occlusion. If your antenna is buried behind heavy armor or blocked by weapon pods, it implies reduced performance unless you show the antenna is conformal and intentionally placed.

A practical placement rule is to place major comms elements high and clear—dorsal spine, shoulders, head mast—so they have better horizon exposure. Place secondary nodes around the body for redundancy. Avoid placing critical antennas in high‑impact zones unless you also show protection.

Placement also communicates role. A stealth assassin drone might keep antennas low and flush. A command node might accept a tall mast because coordination is worth the signature. A swarm micro‑drone might use many small nodes rather than one big one.

Autonomy and comms: what must be local vs networked

One of the most important doctrine decisions is what happens locally and what depends on the network.

Remote‑piloted systems depend heavily on link reliability. They should visually emphasize comms—prominent antennas, high‑gain arrays, relay drones nearby.

Semi‑autonomous systems can tolerate intermittent link. They may emphasize sensors and compute and show comms as burst‑based. You can depict this with antennas that are retractable or that “activate” only at certain times.

Fully autonomous systems may still communicate for coordination and accountability, but they should not look helpless without it. Exterior tells for true autonomy include robust onboard sensing, “brain” modules with cooling, and minimal but redundant comms for updates and status.

These choices make the design feel purposeful and avoid the common trap of giving every drone the same antenna kit.

Swarm communication: a visual language of coordination

Swarm drones are especially interesting because communication is collective behavior. Exterior tells can include small inter‑drone link nodes, optical comms ports, or short‑range transceivers placed to maintain formation.

You can also depict swarm communication through synchronized lighting patterns. If drones pulse together, it implies time sync and shared intent. If a leader drone pulses differently, it implies hierarchy. These are diegetic UX cues for both players and characters in the world.

In production, synchronized patterns can become important readability: players can see when the swarm is coordinated, when it is disrupted, and when it is regrouping.

External status cues: diegetic UX for allies and enemies

Communication state should be readable from the outside because drones operate in teams. A simple set of external indicators can communicate link state: connected, searching, jammed, isolated, or compromised.

This can be done with light bars, small “comms windows,” antenna posture, or moving elements. The key is restraint. Too many lights become noise. A consistent, faction‑wide language becomes a powerful worldbuilding tool.

These cues also help production and gameplay. If a drone’s comms are jammed, show it. If it regains link, show the “handshake” visually. That way the player understands changes without reading text.

Concepting-side deliverables: how to pitch comms clearly

On the concepting side, comms design benefits from a simple, readable package. A top view and side view with antenna placements marked. A small legend for antenna types: omni, directional, relay, emergency beacon. A mode strip showing antenna states: stowed, active, burst transmit, jammed.

If your drone family includes multiple roles, show variations. The scout has minimal comms and emphasizes sensors. The command node has a big relay mast. The stealth striker has conformal antennas and a small directional burst array. These variations teach the audience your doctrine without exposition.

A helpful extra is a “comms silhouette” note: which antenna shapes must remain readable at distance. This prevents LOD or texture decisions from erasing your comms story.

Production-side handoff: what downstream teams will ask for

Production teams will need to know what antennas move, what lights indicate state, what elements can be damaged, and what constitutes a failure. Rigging needs mast extension ranges and panel rotation axes. VFX needs transmission/jamming cues and light patterns. Audio can support comms with chirps, handshake tones, and warning alarms. Gameplay design may need antenna line‑of‑sight constraints, relay mechanics, or hacking targets.

A strong handoff includes: antenna orthos, a state chart for antenna posture and indicator lights, and notes on which comms elements are critical vs redundant. If antenna damage affects autonomy, call that out.

Also consider manufacturability and duplication. If you propose ten different antenna types on one drone, production cost rises. A better approach is a modular antenna kit shared across the faction, with configuration changes per role.

Common mistakes (and fast fixes)

A common mistake is adding antennas as random spikes with no doctrine. Fix it by deciding network pattern and data needs, then selecting antenna families that fit.

Another mistake is making antennas too delicate for a combat drone. Fix it with protection: recessed bases, shutters, armored collars, or sacrificial covers.

Another mistake is forgetting state readability. A drone that is transmitting should look different from a drone that is silent. Fix it with simple external cues: light pattern changes, antenna posture, or a brief handshake animation.

Finally, many designs ignore degraded modes. Fix it by adding an emergency beacon, a fallback local autonomy cue, and a visible “link lost” state.

A repeatable workflow: comms as a behavior system

To design comms consistently, work from behavior. First, define doctrine: hub, mesh, satellite, or local autonomy. Second, define what the link carries: control, sensor streams, coordination, or burst updates. Third, choose antenna families that imply those needs: omni, directional, conformal, relay mast.

Fourth, place antennas for coverage and protection. Fifth, define states and external indicators: stowed, active, burst transmit, jammed, isolated, compromised. Finally, ensure redundancy and degraded modes are visible.

When you do this, comms and encryption become readable without technical exposition. Your unmanned mecha will feel like part of a real operational ecosystem—coordinated, vulnerable, and intelligent—and your exterior tells will give both concepting and production teams a clear, actionable blueprint.