From 2ff9a53681ccd3e2aec1c5d2a4ec990f616e76d1 Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Wed, 15 Jul 2026 01:23:06 +0100 Subject: [PATCH] Separate Starbridge design from roadmap residue --- Aetheria/Brainstorming/Vault Cleanup/index.md | 7 + .../Game Design/Aetheria Client and Modes.md | 439 +---- .../Aetheria Starbridge Promo Art Prompt.md | 725 +------- Aetheria/Game Design/Aetheria Starbridge.md | 1485 +---------------- Aetheria/Game Design/index.md | 70 +- 5 files changed, 217 insertions(+), 2509 deletions(-) diff --git a/Aetheria/Brainstorming/Vault Cleanup/index.md b/Aetheria/Brainstorming/Vault Cleanup/index.md index 5be5b32..2518b8d 100644 --- a/Aetheria/Brainstorming/Vault Cleanup/index.md +++ b/Aetheria/Brainstorming/Vault Cleanup/index.md @@ -44,6 +44,13 @@ Brevity is an invariant. Every paragraph must own a necessary claim. Every claim ## Verification Ledger +### Wave 19 + +- The public game-design cluster fell from 18,699 to 4,445 words. The index now owns navigation and status, `Aetheria Client and Modes.md` owns the candidate shell and durable continuity boundaries, `Aetheria Starbridge.md` owns the playable session concept, and the key-art brief owns one production composition. +- Starbridge is consistently a developed draft GDD: concept-stage, not shipped, and not a release roadmap. Its compact proof retains asymmetric roles, pilot refusal, support work, heat, salvage, recovery, construction, scenario provenance, visible authority, success tests, and unresolved shared decisions. +- Arena, Conquest, persistent-world play, and the reset loop are historical hypotheses or design ancestry rather than current commitments. Monetization, generation pipelines, prompt revision history, exhaustive catalogs, and unversioned protocol claims were cut rather than moved into new owners. +- Clueless/Loremaster pressure separated setting truth, game-design choice, and implementation evidence. Soul repaired status inflation, ownership-of-people language, optional Barracks leakage, two broken section anchors, and missing non-canon art metadata; links, frontmatter, table, callout, and asset checks passed. + ### Wave 18 - `README.md` now separates shared owner notes, finished story authority, and developmental material while retaining the repository map and shared-engine commands. A local claim becomes shared canon only when its owner note incorporates it. diff --git a/Aetheria/Game Design/Aetheria Client and Modes.md b/Aetheria/Game Design/Aetheria Client and Modes.md index 1e0f740..0242fa9 100644 --- a/Aetheria/Game Design/Aetheria Client and Modes.md +++ b/Aetheria/Game Design/Aetheria Client and Modes.md @@ -1,401 +1,64 @@ --- title: "Aetheria Client and Modes" -description: "The Aetheria desktop client is the cross-mode shell: Hangar, parties, Verse selection, Starbridge sessions, Arena downtime, and seasonal Conquest campaigns." +description: "Concept specification for Aetheria's cross-mode shell, shared player continuity, and runtime boundaries." --- # Aetheria Client and Modes -Aetheria is not a single queue with a prettier launcher. It is the shell around -multiple playable proofs of the same underlying simulation: player-owned -loadouts, typed Verse state, ship mastery, faction pressure, economic -consequence, and role-specific clients looking into one shared machine. +> **Status: concept specification, not a release roadmap.** [[Aetheria Starbridge|Starbridge]] has a developed draft GDD. Arena, Conquest, and the persistent world are historical hypotheses. Their presence here does not establish sequence, funding, availability, or release. -The desktop Aetheria app should be the player's durable home. It starts -Starbridge sessions, advertises coming modes, manages parties, selects the -active Verse, launches Unity pilot clients with the correct session target, and -keeps the command-facing surfaces available when a player is acting as -commander. It is also the place where the Hangar lives, because the Hangar cuts -across every mode. +The Aetheria client is the proposed durable home around multiple playable views of one simulation. It should manage identity, parties, sessions, shared player possessions, and recovery when a role-specific runtime disconnects. A mode may change the immediate rules without quietly becoming the owner of the player's account or equipment. -## Product Spine +## Shell Responsibilities -The product spine is: +The desktop client should own the cross-mode surfaces: -1. **Aetheria client**: the shell, account surface, party surface, Hangar, mode - selection, Verse selection, reconnect surface, and commander-capable desktop - UI. -2. **Aetheria: Starbridge**: the first public co-op mode, built around one RTS - commander and one to four Unity pilots defending a station through waves. -3. **Arena**: the controlled competitive environment for proving - witness-authoritative quorum consensus under real player pressure. -4. **Conquest**: the seasonal campaign layer for territory, faction struggle, - economic movement, logistics, community warfare, and broader simulation - experiments. This is where Profits Rising corporation-management gameplay - is introduced and developed season by season. -5. **Persistent world**: the later synthesis, after the smaller vessels have - proven sync, loadouts, economy, territory, and faction consequence. - -The launcher should not present these as equal buttons in a buffet. Multiplayer -queues are an ecosystem. Aetheria should concentrate attention around the mode -that currently serves the health of the product and the experiment being run. - -## The Hangar - -The Hangar is the player's continuity layer. - -Modes rotate, seasons end, experiments change, and scenario rules mutate. The -ship collection persists. Players continue unlocking hulls, equipment, -cockpits, support gear, cosmetics, presets, and build identities from the -Aetheria client. A ship mastered in Starbridge can be brought into Arena. A -Conquest season can make a faction's logistics valuable without making that -ship stop being the player's ship. - -The rule: - -> A ship is persistent. A mode decides how that ship is contextualized. - -Starbridge can apply run-local quality scaling, recovered technologies, -temporary station stock, and boss loot because it is a rogue-lite adjacent -co-op scenario. Arena should show the build as it was meant to be seen: no -Starbridge quality scaling, no run-local distortion, no flattening every ship -into an embarrassed average. Matchmaking balances teams by danger level instead -of pretending all builds are equal. - -The Hangar should be a shared Eve/CultUI surface over typed player state, not a -menu owned by one runtime. The desktop client, website, Unity client, future -companion surfaces, operator tools, and compact TUI views should lower the same -composition graph where the user's context permits it. Storefront purchases, -season rewards, and scenario unlocks may add entitlement or inventory -documents; the Hangar remains the projection over player-owned ships and -equipment. - -## Commander Progression - -The commander needs a progression layer as sticky as pilot loadout -customization. It cannot simply be a persistent station loadout. Scenario -authorship must remain intact: the scenario owns starting station equipment, -available technologies, salvage ecology, faction mix, wave shape, boss loot, -and infrastructure constraints. - -The commander progression rule: - -> Scenarios own nouns. Commanders own the operating language. - -Commander progression candidates should be judged by whether they create real -identity, mastery, and buildcraft without smuggling forbidden station assets -into a scenario. - -### Barracks V1 - -The V1 commander progression target is the **Barracks**. - -The Hangar stores machines. The Barracks stores people and minds. Pilots tune -ships and loadouts. Commanders build a bridge crew, put that crew under -pressure, and live with what the pressure does to them. - -The emotional model is closer to Darkest Dungeon than a collectible card game. -Every run puts command staff against the grindstone. They gain skill, -procedures, bonds, familiarity with pilots, and enemy-pattern memory. They also -accumulate stress, injuries, burnout, trauma, moral damage, faction pressure, -firmware scars, illegal habits, and strange command fixations. - -The V1 presentation should stay contained: - -- roster cards and staff dossiers; -- active bridge slots; -- recovery, treatment, and training slots; -- relationship and conflict summaries; -- after-action changes; -- staff-linked procedures and automation; -- no animated portraits; -- no walk-around RimWorld-style barracks simulation. - -The most important visual outcome is not seeing staff wander around. It is -seeing staff change. - -### Staff Roles - -Command staff should affect how the commander operates the scenario's provided -station, not which station nouns exist. They can modify warnings, procedures, -automation, resource handling, and emergency options while the scenario still -owns equipment, salvage, technology, and enemy pressure. - -Candidate staff roles: - -- thermal officer; -- fabrication lead; -- drone marshal; -- fire-control officer; -- quartermaster; -- rescue coordinator; -- signal/witness officer; -- faction liaison; -- morale/comms officer; -- neuromorphic or ship-self advisor; -- illegal firmware specialist. - -Staff do not need to be only ordinary humans. Aetheria can include trained -officers, faction specialists, embodied ship-selves, advisory firmware, -compliance engines, damaged station minds, and other legal or illegal minds -allowed onto the command side of the war table. - -### Stress, Growth, And Decay - -Staff progression should create attachment and hesitation. - -After runs, staff can gain: - -- XP and promotions; -- new or improved procedures; -- better enemy/faction familiarity; -- bonds with other staff; -- bonds with specific pilots or ships; -- commendations and titles; -- faction credentials; -- black-box insights. - -Staff can also suffer: - -- acute stress; -- fatigue and leave requirements; -- heat trauma; -- overclock addiction; -- radiator dread; -- rescue obsession; -- salvage fixation; -- witness compulsion; -- illegal firmware dependence; -- faction loyalty drift; -- contempt for cautious or reckless commanders; -- rivalry with another staff member; -- refusal to work a specific scenario class; -- breakdown, retirement, or loss. - -This is the commander's risk economy. Pilots bring hulls back scorched. -Commanders bring minds back altered. - -### Generated Interactions - -The Barracks should use a limited authored pool of releasable characters, with -live interactions procedurally generated from character state, run history, -relationships, scenario pressure, and faction context. - -Ghostlight, VoidBot, and Epiphany persona turns can generate staff interactions -as structured narrative events rather than freeform noise. The generated layer -should know the character's stable identity, current stress, relationships, -recent failures, recent saves, faction background, and available event type. -It should output bounded dialogue, relationship changes, event flags, and -operator-facing summaries that the game can store as typed state. - -Weksa vocals can give these interactions voice once the text event is accepted -and bounded. Voice should reinforce staff presence without requiring animated -portraits or a full barracks life sim. - -Generated outputs must be cached as content artifacts. Persona turns, accepted -dialogue, Weksa voicing, and possible Vili acting or gesture data should not be -recomputed every time a player opens the Barracks. Weksa interlingua tends to -carry gesture information, so the cache should be able to store text, vocal -performance, timing, expression, gesture intent, provenance, and the state keys -that produced the event. - -This gives the live service a sane cost curve. Early players can expensively -"discover" fresh staff interactions when a character, scenario, relationship, -or trauma state has not been seen before. As the cache fills, common situations -resolve to existing artifacts and only noteworthy state changes need new model -work. The Barracks should feel alive without turning every hover, debrief, or -minor stress tick into a model call. - -The cache key should include enough typed context to preserve continuity: - -- character id and variant; -- event type; -- scenario id and faction context; -- relevant run facts; -- current stress, injuries, scars, and traits; -- relationships and bonds involved; -- language, voice, and presentation policy; -- model/prompt/pipeline version. - -Cached artifacts may be reused exactly, remixed through bounded templates, or -invalidated when character state crosses a meaningful threshold. The important -rule is that generation happens at moments of narrative consequence, not as a -constant renderer dependency. - -V1 should treat generated interactions as authored-bounded events: - -- post-run debriefs; -- stress breaks; -- bond formation; -- rivalry escalation; -- staff requesting leave; -- staff refusing or demanding assignment; -- procedure discovery; -- faction contact; -- black-box confession; -- memorial or recovery moments. - -The generation system must serve continuity. Characters are not disposable -text fountains. Their state changes should persist, be inspectable, and affect -future runs. - -### Character Release Model - -Aetheria can release a limited pool of command staff over time in a -gacha-style cadence: named officers, specialists, firmware advisors, faction -liaisons, illegal contractors, and strange command minds. The collection pull -is real, but the design should avoid making the commander role depend on -predatory availability or opaque power chasing. - -Safer release principles: - -- every commander has a competent baseline staff; -- premium or rare staff create style, story, and specialization, not mandatory - access to basic command competence; -- scenario completion, seasons, faction reputation, and achievements can unlock - staff alongside any monetized channel; -- staff power is legible through role, stress profile, procedures, and - compatibility rather than hidden rarity math; -- duplicate pulls, if used, should become training, memories, cosmetics, or - safe progression currency rather than a slot-machine cliff. - -The product can borrow the release cadence and excitement of character -collection without designing the Barracks as a little extraction engine in a -hat. - -### Shelved: Real-Time Command Deck - -The real-time command deck remains a viable alternate or later procedure layer, -but it is not the V1 commander progression target. - -In that model, the commander has a deck, hand, draw pile, cooldown pile, and -cadence-based draw. Cards install equipment, upgrade equipment, deploy drones -and turrets, activate item behaviors, trigger procedures, and spend emergency -protocols. The scenario contributes part of the deck so scenario authorship -remains intact. - -The four-resource model remains useful even without cards: - -- **Power**: electrical capacity, routing, shields, sensors, weapon systems, - drone charging, and immediate station activity. -- **Mass**: salvage, material throughput, structure, ammunition, replacement - parts, and physical installation. -- **Heat**: thermal capacity, cooling budget, radiator availability, - overclocking, fabrication haste, and emergency thermal debt. -- **Cognition**: command bandwidth, staff attention, signal clarity, Verse - authority, operator focus, predictive modeling, witness activity, and the - stranger Aetheria-specific forms of semantic or neuromorphic strain. - -Cards may come back later as staff-authored procedures, emergency protocol -bundles, or rig-like command scripts. For V1, the sticky sentence is: - -> Pilots build ships. Commanders build crews. - -## Starbridge - -Starbridge is the co-op product wedge. It is always understandable: - -- one player commands the base; -- other players fly ships; -- the team survives waves; -- bosses drop technologies; -- the station lets players dock, refit, exchange equipment, and recover. - -Starbridge proves mixed-runtime cooperation without requiring the whole world -to be alive. The commander can remain in the Aetheria desktop UI. Pilots launch -into Unity clients that already know which Verse, session, role, and player -identity to connect to. - -Starbridge is also the friendly on-ramp for persistent loadout attachment. It -lets players love a ship while the run still changes around them. - -## Arena - -Arena is the consensus crucible. - -To players, Arena is competitive ship combat. Internally, it is where Aetheria -masters witness-authoritative quorum consensus in a controlled environment: - -- small maps; -- known player counts; -- constrained match duration; -- clear loadout entry; -- adversarial player intent; -- replayable combat facts; -- witness roles; -- prediction and reconciliation pressure; -- disconnect and reconnect handling; -- evidence for anti-cheat and dispute resolution. - -Arena should be the downtime competitive activity when Conquest is not live. -Its purpose is not to become the always-available deathmatch gravity well that -starves every richer mode. Its purpose is to keep pilots sharp, generate useful -combat data, and harden consensus under conditions that are small enough to -understand. - -Arena uses persistent Hangar builds without Starbridge run scaling. Danger -level matchmaking should balance teams around the real threat of the assembled -ships rather than making customization cosmetic. - -## Conquest - -Conquest is the halfway point to a persistent world. - -It lets Aetheria simulate broader economic shifts, factional struggles, -territorial pressure, logistics, stockpiles, industry, and strategic objectives -without requiring every sector to be active all the time. The world does not -need to breathe at full resolution everywhere. It can pulse through campaigns, -fronts, windows, and resolved aftermath. - -Conquest should run in seasons. Each season is an experiment: - -- which faction pressures matter; -- how territory changes hands; -- how markets and production react; -- which logistics constraints create good play; -- how player corporations or clans coordinate; -- how much world-state persistence creates drama without becoming homework. - -These seasons are the current development path for **Profits Rising** gameplay. -Players may control corporations ranging from inherited small operations to -stealth startups and larger producers, managing blueprints, licenses, supply -chains, manufacturing, transport, labor, contracts, and market position in -support of community warfare. The corporation layer should grow through real -seasonal pressures rather than appearing all at once as a detached management -game. - -The long-term destination remains synthesis: corporation-scale Profits Rising -play and embodied Terminus-style play inhabiting the same persistent economy. -Starbridge establishes shared combat and command infrastructure; Conquest -seasons progressively establish the logistics, economic, territorial, and -organizational machinery needed for that merger. - -When Conquest is active, it should be the PvP focus. If a low-friction -deathmatch queue is available at the same time, many players will choose the -short dopamine path and the strategic campaign will wither. Aetheria should not -fragment its own playerbase just to look feature-rich. Arena exists for -downtime. Conquest owns the war window. - -## Client Responsibilities - -The Aetheria desktop client should own the cross-mode surfaces: - -- home/front page; - account and profile identity; -- party state and invites; -- active Verse selection and diagnostics; -- reconnect and crash recovery; -- Hangar; -- Starbridge scenario/session entry; -- Arena matchmaking and recent-match context; -- Conquest season map and campaign status; -- settings that apply across runtimes. +- party state, invitations, and role selection; +- session creation, joining, and reconnect; +- settings shared across runtimes; +- the Hangar and commander continuity surfaces; +- launch context for role-specific clients. -Unity should own the pilot cockpit runtime: flight, combat presentation, -effects, input, audio, docking transitions, and ship/escape-pod embodiment. -Unity should not own the product shell. It should launch with the session -contract it needs and then connect to typed CultMesh state. +The shell should show only experiences that actually exist in the connected environment. It may advertise developed or future modes separately, but an aspirational design must not masquerade as a playable queue. -The daemon owns game truth. The desktop client and Unity client are -role-specific views into typed Verse state. That is the architectural fantasy -and the product fantasy saying the same thing without having to apologize to -each other. +## Hangar + +The Hangar is the player's machine-continuity surface. It contains owned ships, equipment, saved loadouts, component access, cosmetics, names, and the maintenance state that persists beyond one scenario. Modes consume approved loadouts and may apply their own starting conditions, temporary stock, damage, or normalization. They do not fork the inventory. + +The invariant is: + +> Player inventory and loadout state have one durable owner. Every client and mode is a view or bounded consumer of that state. + +This prevents a website inventory, desktop inventory, pilot inventory, and scenario inventory from becoming four accounts that reconcile only after somebody loses a ship. Renderer caches and scene objects may represent equipment without becoming durable truth. + +Starbridge can contextualize a ship through scenario stock, recovered technology, repairs, and run-local pressure. A future competitive mode might validate the same assembly under different entry rules. Persistent ownership defines which machine the player has built; the mode defines what that machine may bring into the current problem. + +## Commander Continuity + +Commanders need continuity comparable to a pilot's attachment to a ship, but they should not carry a custom station into every scenario. The scenario owns its base, starting equipment, available technology, salvage ecology, enemies, and infrastructure constraints. The commander owns an operating history. + +The current Barracks concept represents that history through a bounded bridge crew. A small roster of officers, specialists, or advisory minds can affect warnings, procedures, automation, resource handling, and emergency options without adding forbidden station equipment. Staff may gain experience, working relationships, stress, injury, leave requirements, or refusal after runs. Those changes should remain inspectable and consequential rather than becoming disposable flavor text. + +The compact rule is: + +> Scenarios own the available machinery. Commander continuity owns the roster relationships and operating practices carried between scenarios. + +Barracks is one candidate progression design. Its exact roster, presentation, and rules are unresolved and are not client architecture. + +## Mode Status + +| Mode | Status | Relationship to the client | +| --- | --- | --- | +| [[Aetheria Starbridge|Starbridge]] | **Developed draft GDD** | Asymmetric cooperative defense. A shell could form the party, select roles and scenario, expose continuity context, and recover from disconnects. | +| **Arena** | **Historical hypothesis** | A bounded competitive environment proposed to test persistent ship builds, matchmaking, records, and reconciliation. | +| **Conquest** | **Historical hypothesis** | Seasonal campaigns proposed to test territory, logistics, production, faction pressure, and community warfare. | +| **Persistent world** | **Historical hypothesis** | The older ambition to join embodied and corporation-scale play in one persistent context. | + +These modes need not coexist or appear in this order. A mode earns promotion through a playable proof and an explicit decision, not by surviving in a planning document. + +## Runtime Boundaries + +The implementation invariant is narrower than any particular runtime split: every consequential state change has one named authority, and every client is either that authority or a bounded requester and view. Docking, inventory transfer, equipment changes, rewards, and post-session persistence must commit through their durable owner rather than scene-local state. + +The boundary should remain visible enough to diagnose. A player who reconnects should be able to learn which session they are joining, which role they hold, which loadout was accepted, and whether an action is pending, rejected, or committed. The client is not merely a launcher. It is the place where several runtimes remain one intelligible product without becoming several competing truths. diff --git a/Aetheria/Game Design/Aetheria Starbridge Promo Art Prompt.md b/Aetheria/Game Design/Aetheria Starbridge Promo Art Prompt.md index 3fce352..da59ee9 100644 --- a/Aetheria/Game Design/Aetheria Starbridge Promo Art Prompt.md +++ b/Aetheria/Game Design/Aetheria Starbridge Promo Art Prompt.md @@ -1,702 +1,73 @@ -# Aetheria: Starbridge Promo Art Prompt +--- +title: "Aetheria: Starbridge Key-Art Brief" +description: "Production artifact; non-canon visual brief for Starbridge promotional art." +--- -Date: 2026-06-24 +# Aetheria: Starbridge Key-Art Brief -Use case: ads-marketing +> [!note] Production artifact +> This brief directs promotional image production. It is not setting canon, a gameplay specification, or evidence of implementation. Where it conflicts with the current [[Aetheria Starbridge|Starbridge game design document]] or worldbuilding owner notes, those sources prevail. -Asset type: Starbridge promo splash art / website hero image +## Asset And Delivery -Input image: use the provided Aetheria screenshot as structural reference, not -merely mood. The nebula forms gravitational terrain: a luminous blue-white -volumetric surface like an ocean of space-clouds. Resources, debris, ships, -stations, missiles, and combat activity cluster along or just above this nebular -surface. Larger celestial bodies float above the surface. The battlefield should -feel like it takes place at the playable boundary of the nebula, not in empty -black deep space. +Create a cinematic panoramic hero image for **Aetheria: Starbridge**, suitable for the website, store capsules, and wide promotional crops. Preserve the central defensive relationship when cropping: station rim below, four defenders across the middle, and attackers pressing inward from the far field. Keep important ships and effects away from the extreme edges so narrower crops do not reverse or erase the scene. -Primary request: Create splashy matte-painting promo art for Aetheria: -Starbridge. An Aeronautics Unlimited frontier station is under siege by pirate -forces on the surface of a blue-white nebular gravity terrain. The station is -under fire, shields are catching laser impacts, incoming missile swarms are -being shredded by point-defense cannons, and multiple pirate combat roles are -actively attacking the station and its defenders. +The adopted reference image is [`starbridge-promo-outward-panorama.png`](../media/aetheria/starbridge-promo-outward-panorama.png). Use it as the current composition reference, not as independent evidence for lore or mechanics. -Scene/backdrop: a luminous blue-white nebula forms a rolling gravitational -terrain surface across the lower two-thirds of the image, with darker ridges and -bright cloud valleys. Asteroid resources and debris float at the surface. A -small icy moon or pale celestial body floats above the terrain in the upper -middle distance, echoing the reference image. +## Visual Promise -Main station: a large Aeronautics Unlimited frontier station sits slightly right -of center, hovering just above the nebular surface. It has clean industrial -modular architecture: docking arms, radiator wings, shield emitter pylons, -point-defense turret clusters, a central fabrication core, and repair/service -bays. It is visibly under siege but still functioning. +The image must communicate the cooperative concept in one glance: one station, four distinct player ships, and a siege that requires different jobs. The viewer is perched above the station looking outward across a luminous battlefield. Defenders form a readable protective line. Enemy movement and fire converge inward. Every vector must answer the basic question of who is protecting whom. -Four defending player ships, explicitly placed and differentiated: +## Camera And Composition -1. DPS ship A: sleek red-and-white interceptor in the lower left foreground, - knife-like triangular profile, bright engine flare, banking upward across the - nebula surface while firing twin blue-white laser streams into a pirate - fighter pack. -2. DPS ship B: heavier gunship in the upper right near the station shield, broad - forward cannons and missile pods, launching a salvo diagonally outward into - the incoming horde while its nose points away from the station. -3. Tank ship: bulky armored shield ship directly in front of the station on the - left side of the shield perimeter, slab armor, large glowing frontal shield - projector, intentionally absorbing a concentrated red-orange laser barrage. - Its projected shield bubble overlaps the station shield and visibly deflects - or refracts several beams. -4. Support ship: compact utility/service craft below the station near a damaged - radiator wing, with articulated repair arms and glowing cyan coolant beam. It - is tethered to the station module with one repair beam and a second cooling - beam, venting white-blue heat mist away from the damaged section. +Use a wide-angle camera above and slightly behind the station, looking outward rather than straight down. The station core sits below the camera and outside the frame. Only its upper rim occupies the bottom foreground: shield emitters, point-defense turrets, docking-arm tips, radiator edges, service gantries, and glowing industrial infrastructure. -Enemy combatants, explicitly placed and acting: +Beyond that rim, a curved shield perimeter crosses the middle band. Arrange four medium-sized defender ships along it in a loose diamond, all oriented outward. The far field is blue-white nebular gravitational terrain with asteroid resources, debris, and attackers moving along its surface. A small pale moon in the upper middle distance provides scale and depth. -1. Pirate missile boats: three wedge-shaped pirate craft on the far right edge - of the nebula terrain, launching dense curved missile swarms toward the - station. Their launch racks glow orange, and fresh missile trails arc across - the image toward point-defense fire. -2. Pirate laser raiders: a tight pack of small fast ships on the far left border - skimming the nebula surface, firing red-orange beam volleys at the tank ship - and station shields. Several beams visibly splash, bend, or reflect off the - overlapping cyan shields. -3. Boarding pod carriers: two ugly armored carrier craft in the lower right - midground releasing small boarding pods or breach drones toward the station's - docking arms. The pods form a dotted line of hot engine sparks approaching - the shield boundary. -4. Torpedo bomber: one larger pirate bomber above the nebular surface near the - upper left, lining up a heavy torpedo run on the station fabrication core - while DPS ship B's missile salvo streaks toward it. -5. Jammer corvette: a spindly pirate support vessel at the far upper right, - projecting faint red interference rings toward the station sensor mast, while - station point-defense tracers try to punch through the interference. -6. Salvage skiffs: two small pirate skiffs near the lower edge trying to tow - wreckage or resource fragments away from the battlefield, giving DPS ship A a - clear target cluster. +Focal hierarchy: -Combat action: laser volleys splash across semi-transparent cyan station -shields, with some beams partially absorbed and reflected as bright refracted -streaks. Dense swarms of incoming missiles arc toward the station from the -pirate missile boats. Station point-defense cannons fire rapid white tracer -streams, detonating missiles into small bright explosions before impact. -Boarding pods attempt to cross the shield boundary near docking arms. The jammer -corvette creates visible interference around the sensor mast. Debris and -resources drift along the nebula surface. +1. The station rim and shield arc establish what must survive. +2. Four bright, distinct defenders establish asymmetric cooperation. +3. Darker pirate groups outside the perimeter establish inward pressure. +4. Weapon, shield, repair, and movement effects explain the battle without becoming visual static. -Style/medium: high-end cinematic sci-fi matte painting, key art, painterly -realism, dramatic scale, dense but readable battlefield composition, no UI, no -text. +## Defender Roles -Composition/framing: wide landscape hero image. Nebula terrain sweeps from -bottom left to upper right like a playable surface. Station is the focal point -slightly right of center. DPS A in lower left foreground attacking skiffs and -raiders, tank between station and left-side laser fire, support below station at -damaged radiator, DPS B upper right pushing outward against bomber and missile -boats. Pirate missile boats occupy far right, laser raiders far left, boarding -pod carriers lower right, torpedo bomber upper left, jammer corvette upper -right, salvage skiffs lower edge. Missile trails, shield arcs, boarding pod -paths, and point-defense tracers lead the eye back to the station. Leave -atmospheric negative space near the upper left for possible website copy, but -include no text. +- **Interceptor — lower left:** a sleek red-and-white triangular craft banking outward. Twin blue-white lasers strike raiders on the left approach. +- **Shield defender — left center:** a bulky slab-armored ship between the station and the heaviest fire. Its cyan frontal shield faces outward and catches red-orange beams before they reach the base. +- **Gunship — upper right:** a heavier craft with broad cannons and missile pods, firing outward at bombers and missile boats. +- **Support craft — lower right:** a compact utility vessel near a damaged radiator edge. Articulated repair arms, one cyan repair beam, and one pale coolant beam reach back toward the station while white-blue heat mist vents away. It must read as servicing the base, never firing on it. -Lighting/mood: intense blue-white nebula backlight, cold cyan shields and -coolant beams, hot red-orange pirate impacts, white point-defense flashes, -desperate but heroic co-op defense energy. +## Enemy Pressure And Motion -Color palette: cold luminous blues, cyan shields, white nebula haze, steel-gray -AU station, red-orange impact accents and pirate engine glows, small red/white -accents on DPS A. +Pirate forces remain outside the shield perimeter. Use several readable silhouettes rather than a catalogue of equal-detail ships: fast laser raiders on the left, wedge-shaped missile boats on the right, a distant torpedo bomber, and armored carriers releasing boarding pods toward the docking arms. Optional salvage skiffs may pull wreckage away at the outer edge. -Materials/textures: industrial station plating, glassy shield refraction, -heat-scarred turret barrels, missile plasma trails, repair/cooling beams, -asteroid debris, volumetric nebula clouds, ragged pirate armor plating, scorched -missile racks, flickering jammer rings. +Enemy beams, missiles, pods, and interference effects travel inward. Defender lasers, missiles, shields, and point-defense tracers face outward. Turret tracers originate from the station rim and intercept incoming swarms. Repair and coolant beams angle back toward station infrastructure and remain visually distinct from weapons. No defender weapon line points into the station. -Constraints: no text, no logos, no watermark, no readable cockpit UI, no single -huge human figure, no Star Wars/Star Trek styling, no fantasy magic. The four -player ships must be visibly distinct by silhouette, location, and action -exactly as described. Enemy ships must not be a generic horde: show their -specific attacks and battlefield jobs. +## Terrain, Palette, And Materials -## Revision: Protective Defender Formation +The nebula is gravitational terrain, not a decorative skybox: a luminous blue-white volumetric surface resembling an ocean of space-clouds. Ships, wreckage, resources, missiles, and combat cluster along or just above its playable boundary. Larger celestial bodies float above it. -Use case: ads-marketing +Use cold luminous blues, cyan shields, white haze, and steel-gray station plating, interrupted by red-orange pirate engines and impacts. The interceptor may carry restrained red-and-white accents. Materials should feel industrial and worked: heat-scarred turret barrels, radiator fins, service gantries, glassy shield refraction, missile plasma trails, scorched pirate armor, asteroid debris, and turbulent volumetric cloud. -Asset type: Starbridge promo splash art / website hero image +Render as high-end cinematic science-fiction matte painting with painterly realism, dramatic scale, and dense but legible action. The mood is desperate, competent cooperation rather than effortless triumph. -Input image: use the provided Aetheria screenshot as structural reference, not -merely mood. The nebula forms gravitational terrain: a luminous blue-white -volumetric surface like an ocean of space-clouds. Resources, debris, ships, -stations, missiles, and combat activity cluster along or just above this nebular -surface. Larger celestial bodies float above the surface. The battlefield should -feel like it takes place at the playable boundary of the nebula, not in empty -black deep space. +## Must Preserve -Primary request: Create splashy matte-painting promo art for Aetheria: -Starbridge. An Aeronautics Unlimited frontier station is being defended by four -player ships arranged protectively around it while pirate forces attack from the -outer edges of the nebular terrain. The defenders should clearly form a -protective perimeter around the station, facing outward. They must not look like -they are attacking the station. +- outward-looking camera above the station; +- only the station's upper rim visible along the bottom; +- four defenders with immediately distinct roles; +- attackers and attack origins outside the perimeter; +- inward enemy pressure and outward defensive response; +- nebular terrain functioning as the battlefield surface; +- a composition that survives wide promotional crops. -Scene/backdrop: a luminous blue-white nebula forms a rolling gravitational -terrain surface across the lower two-thirds of the image, with darker ridges and -bright cloud valleys. Asteroid resources and debris float at the surface. A -small icy moon or pale celestial body floats above the terrain in the upper -middle distance, echoing the reference image. +## Must Avoid -Main station: a large Aeronautics Unlimited frontier station sits at the center -of the defensive composition, hovering just above the nebular surface. It has -clean industrial modular architecture: docking arms, radiator wings, shield -emitter pylons, point-defense turret clusters, a central fabrication core, and -repair/service bays. It is visibly under siege but still functioning. - -Defensive arrangement: the four player ships form a protective diamond/ring -around the station, each ship oriented outward toward incoming enemies. Their -weapon fire, shields, repair beams, and movement arcs all point away from the -station or along its perimeter. Enemy fire and missiles come inward from the -outside edges toward the station and the defender ring. - -Four defending player ships, explicitly placed and differentiated: - -1. DPS ship A: sleek red-and-white interceptor in the lower left foreground - outside the station shield, knife-like triangular profile, bright engine - flare, nose pointed away from the station toward incoming pirate skiffs. It - banks along the nebula surface while firing twin blue-white laser streams - outward into a pirate fighter pack. -2. DPS ship B: heavier gunship above and to the right of the station, broad - forward cannons and missile pods, parked just outside the shield perimeter - with its nose pointed outward. It launches a missile salvo away from the - station toward a torpedo bomber and missile boats at the far edge. -3. Tank ship: bulky armored shield ship on the left-front side of the station - perimeter, between the station and the heaviest incoming laser fire. It has - slab armor and a large glowing frontal shield projector facing outward. Its - shield bubble overlaps the station shield, intercepting and refracting - red-orange laser volleys before they reach the base. -4. Support ship: compact utility/service craft below and slightly behind the - station, tucked inside the defender ring near a damaged radiator wing. It has - articulated repair arms and glowing cyan coolant beams tethered to the - station module. It is not attacking the station; it is clearly repairing and - cooling it, venting white-blue heat mist away from the damaged section. - -Enemy combatants, explicitly placed and acting from outside the defender ring: - -1. Pirate missile boats: three wedge-shaped pirate craft on the far right edge - of the nebula terrain, launching dense curved missile swarms inward toward - the station. Their launch racks glow orange, and fresh missile trails arc - toward station point-defense fire. -2. Pirate laser raiders: a tight pack of small fast ships on the far left border - skimming the nebula surface, firing red-orange beam volleys inward at the - tank ship and station shields. Several beams visibly splash, bend, or reflect - off the overlapping cyan shields. -3. Boarding pod carriers: two ugly armored carrier craft in the lower right - midground releasing small boarding pods or breach drones inward toward the - station's docking arms. The pods form a dotted line of hot engine sparks - approaching the shield boundary. -4. Torpedo bomber: one larger pirate bomber above the nebular surface near the - upper left edge, lining up a heavy torpedo run toward the station fabrication - core while DPS ship B's missile salvo streaks outward to intercept it. -5. Jammer corvette: a spindly pirate support vessel at the far upper right, - projecting faint red interference rings inward toward the station sensor - mast, while station point-defense tracers try to punch through the - interference. -6. Salvage skiffs: two small pirate skiffs near the lower edge trying to tow - wreckage or resource fragments away from the battlefield, while DPS ship A - peels outward to stop them. - -Combat action: laser volleys splash across semi-transparent cyan station -shields, with some beams partially absorbed and reflected as bright refracted -streaks. Dense swarms of incoming missiles arc inward toward the station from -the pirate missile boats. Station point-defense cannons fire rapid white tracer -streams outward, detonating missiles into small bright explosions before impact. -Boarding pods attempt to cross the shield boundary near docking arms. The jammer -corvette creates visible interference around the sensor mast. Debris and -resources drift along the nebula surface. - -Style/medium: high-end cinematic sci-fi matte painting, key art, painterly -realism, dramatic scale, dense but readable battlefield composition, no UI, no -text. - -Composition/framing: wide landscape hero image. Nebula terrain sweeps from -bottom left to upper right like a playable surface. Station is central and -protected. The four player ships form a visible defensive diamond around the -station: DPS A lower left facing outward, tank left-front blocking incoming -fire, support below/behind station repairing a radiator, DPS B upper right -facing outward. Pirate missile boats occupy far right, laser raiders far left, -boarding pod carriers lower right, torpedo bomber upper left, jammer corvette -upper right, salvage skiffs lower edge. Missile trails, enemy laser beams, -boarding pod paths, and jammer rings travel inward from the outer edges, while -defender fire, shields, point-defense tracers, and repair beams show the crew -protecting the station. Leave atmospheric negative space near the upper left for -possible website copy, but include no text. - -Lighting/mood: intense blue-white nebula backlight, cold cyan shields and -coolant beams, hot red-orange pirate impacts, white point-defense flashes, -desperate but heroic co-op defense energy. - -Color palette: cold luminous blues, cyan shields, white nebula haze, steel-gray -AU station, red-orange impact accents and pirate engine glows, small red/white -accents on DPS A. - -Materials/textures: industrial station plating, glassy shield refraction, -heat-scarred turret barrels, missile plasma trails, repair/cooling beams, -asteroid debris, volumetric nebula clouds, ragged pirate armor plating, scorched -missile racks, flickering jammer rings. - -Constraints: no text, no logos, no watermark, no readable cockpit UI, no single -huge human figure, no Star Wars/Star Trek styling, no fantasy magic. The four -player ships must visibly protect the station from outside threats. Enemy attack -vectors must clearly come from the outer perimeter inward. Defender weapons -should point outward or along the perimeter, never into the station. Enemy ships -must not be a generic horde: show their specific attacks and battlefield jobs. - -## Revision: Panoramic Overhead Base-Core Camera - -Use case: ads-marketing - -Asset type: Starbridge promo splash art / panoramic website hero image - -Input image: use the provided Aetheria screenshot as structural reference, not -merely mood. The nebula forms gravitational terrain: a luminous blue-white -volumetric surface like an ocean of space-clouds. Resources, debris, ships, -stations, missiles, and combat activity cluster along or just above this nebular -surface. Larger celestial bodies float above the surface. The battlefield should -feel like it takes place at the playable boundary of the nebula, not in empty -black deep space. - -Camera and format: panoramic wide-angle layout from a high camera above the -station, looking down over the core of the base and outward across the nebular -terrain. The bottom third of the screen is occupied by a wide-angle view of the -station core and inner base structures, as if the viewer is hovering above the -base looking out toward the incoming attack. The composition must feel like a -deliberate panorama: broad horizontal battlefield, layered depth from bottom -foreground station core to midground defender ring to distant pirate borders, -clear left-to-right sweep of action. - -Primary request: Create splashy matte-painting promo art for Aetheria: -Starbridge. An Aeronautics Unlimited frontier station is being defended by four -player ships arranged protectively around it while pirate forces attack from the -outer edges of the nebular terrain. The defenders should clearly form a -protective perimeter around the station, facing outward. They must not look like -they are attacking the station. - -Scene/backdrop: a luminous blue-white nebula forms a rolling gravitational -terrain surface across the middle and far distance, with darker ridges and -bright cloud valleys. Asteroid resources and debris float at the surface. A -small icy moon or pale celestial body floats above the terrain in the upper -middle distance, echoing the reference image. - -Main station and base core: the Aeronautics Unlimited station fills the bottom -foreground as a wide, readable base-core view. Show the central fabrication -core, docking arms, radiator wings, shield emitter pylons, point-defense turret -clusters, repair/service bays, cargo trusses, and glowing infrastructure from -above. The station extends upward into the midground, but the bottom of the -image should clearly be the base interior/core area, not empty space. The -station is visibly under siege but still functioning. - -Defensive arrangement: the four player ships form a protective diamond/ring -around the station perimeter in the midground, each ship oriented outward toward -incoming enemies. Their weapon fire, shields, repair beams, and movement arcs -all point away from the station or along its perimeter. Enemy fire and missiles -come inward from the outside edges toward the station and defender ring. - -Four defending player ships, explicitly placed and differentiated: - -1. DPS ship A: sleek red-and-white interceptor in the lower-left/mid-left - perimeter just beyond the base core, knife-like triangular profile, bright - engine flare, nose pointed outward toward incoming pirate skiffs. It banks - along the nebula surface while firing twin blue-white laser streams outward - into a pirate fighter pack. -2. DPS ship B: heavier gunship above and to the right of the station perimeter, - broad forward cannons and missile pods, parked just outside the shield with - its nose pointed outward. It launches a missile salvo away from the station - toward a torpedo bomber and missile boats at the far edge. -3. Tank ship: bulky armored shield ship on the left-front side of the station - perimeter, between the station and the heaviest incoming laser fire. It has - slab armor and a large glowing frontal shield projector facing outward. Its - shield bubble overlaps the station shield, intercepting and refracting - red-orange laser volleys before they reach the base core. -4. Support ship: compact utility/service craft above the lower station core, - close to a damaged radiator wing or service bay, with articulated repair arms - and glowing cyan coolant beams tethered to the station module. It is clearly - repairing and cooling the station, venting white-blue heat mist away from the - damaged section. - -Enemy combatants, explicitly placed and acting from outside the defender ring: - -1. Pirate missile boats: three wedge-shaped pirate craft on the far right edge - of the nebula terrain, launching dense curved missile swarms inward toward - the station. Their launch racks glow orange, and fresh missile trails arc - toward station point-defense fire. -2. Pirate laser raiders: a tight pack of small fast ships on the far left border - skimming the nebula surface, firing red-orange beam volleys inward at the - tank ship and station shields. Several beams visibly splash, bend, or reflect - off the overlapping cyan shields. -3. Boarding pod carriers: two ugly armored carrier craft in the lower-right - midground outside the base perimeter, releasing small boarding pods or breach - drones inward toward the station's docking arms. The pods form a dotted line - of hot engine sparks approaching the shield boundary. -4. Torpedo bomber: one larger pirate bomber above the nebular surface near the - upper-left edge, lining up a heavy torpedo run toward the station fabrication - core while DPS ship B's missile salvo streaks outward to intercept it. -5. Jammer corvette: a spindly pirate support vessel at the far upper right, - projecting faint red interference rings inward toward the station sensor - mast, while station point-defense tracers try to punch through the - interference. -6. Salvage skiffs: two small pirate skiffs near the lower-left outer perimeter - trying to tow wreckage or resource fragments away from the battlefield, while - DPS ship A peels outward to stop them. - -Combat action: laser volleys splash across semi-transparent cyan station -shields, with some beams partially absorbed and reflected as bright refracted -streaks. Dense swarms of incoming missiles arc inward toward the station from -the pirate missile boats. Station point-defense cannons fire rapid white tracer -streams outward from the bottom-foreground base core and perimeter turrets, -detonating missiles into small bright explosions before impact. Boarding pods -attempt to cross the shield boundary near docking arms. The jammer corvette -creates visible interference around the sensor mast. Debris and resources drift -along the nebula surface. - -Style/medium: high-end cinematic sci-fi matte painting, key art, painterly -realism, dramatic scale, dense but readable battlefield composition, no UI, no -text. - -Composition/framing: panoramic wide landscape hero image. High oblique -top-down camera above the station core. Bottom third: wide-angle view of the -station core, fabrication hub, service bays, docking arms, and point-defense -turrets. Middle third: shield perimeter and four defending ships in a protective -ring facing outward. Top and far edges: nebular gravitational terrain and pirate -attackers pressing inward from left, right, and upper distance. Missile trails, -enemy laser beams, boarding pod paths, and jammer rings travel inward from the -outer edges, while defender fire, shields, point-defense tracers, and repair -beams show the crew protecting the station. Leave atmospheric negative space in -the upper-left sky/nebula region for possible website copy, but include no text. - -Lighting/mood: intense blue-white nebula backlight, cold cyan shields and -coolant beams, hot red-orange pirate impacts, white point-defense flashes, -desperate but heroic co-op defense energy. - -Color palette: cold luminous blues, cyan shields, white nebula haze, steel-gray -AU station, red-orange impact accents and pirate engine glows, small red/white -accents on DPS A. - -Materials/textures: industrial station plating seen from above, glassy shield -refraction, heat-scarred turret barrels, missile plasma trails, repair/cooling -beams, asteroid debris, volumetric nebula clouds, ragged pirate armor plating, -scorched missile racks, flickering jammer rings. - -Constraints: no text, no logos, no watermark, no readable cockpit UI, no single -huge human figure, no Star Wars/Star Trek styling, no fantasy magic. The camera -must be above the base with the bottom of the screen occupied by a wide-angle -view of the station core. The four player ships must visibly protect the station -from outside threats. Enemy attack vectors must clearly come from the outer -perimeter inward. Defender weapons should point outward or along the perimeter, -never into the station. Enemy ships must not be a generic horde: show their -specific attacks and battlefield jobs. - -## Generated Panorama Analysis - -The generated overhead panorama is directionally strong: - -- the base core occupies the bottom foreground; -- the nebula reads as a luminous gravitational terrain surface rather than empty - space; -- missiles, point defense, shields, and enemy pressure create a good broad - battle rhythm; -- the station is large enough to anchor the image. - -The main weakness is allegiance and vector clarity. Several large ships on the -right read as attackers, while the defending player ships do not form an -unambiguous protective ring. The image needs more deliberate screen-space -composition: station core in fixed bottom coordinates, four defenders locked to -named perimeter positions, and enemy groups placed outside that ring with attack -vectors aimed inward. - -## Revision: Manual Panoramic Composition Map - -Use case: ads-marketing - -Asset type: Starbridge promo splash art / panoramic website hero image - -Canvas model: treat the image as a 100-by-100 composition grid. `x=0` is the -left edge, `x=100` is the right edge, `y=0` is the top edge, and `y=100` is the -bottom edge. Compose the image as a deliberate panorama from a high oblique -camera above the base, looking down and outward across the nebular terrain. - -Input image: use the provided Aetheria screenshot as structural reference, not -merely mood. The nebula forms gravitational terrain: a luminous blue-white -volumetric surface like an ocean of space-clouds. Resources, debris, ships, -stations, missiles, and combat activity cluster along or just above this nebular -surface. Larger celestial bodies float above the surface. The battlefield should -feel like it takes place at the playable boundary of the nebula, not in empty -black deep space. - -Camera and format: panoramic wide-angle key art, high oblique top-down camera. -The bottom third is a wide-angle view of the station core and inner base -structures. The middle third is the shield perimeter and defending player -formation. The upper third and far left/right edges are the enemy approach -zones. The composition must read from bottom foreground base core, through -midground defender ring, to distant pirate attack borders. - -Primary request: Create splashy matte-painting promo art for Aetheria: -Starbridge. An Aeronautics Unlimited frontier station is being defended by four -player ships arranged protectively around it while pirate forces attack from the -outer edges of the nebular terrain. The defenders must clearly face outward and -protect the station. They must not look like they are attacking the station. - -Absolute composition map: - -- **Station core / base foreground**: occupies `x=24-76`, `y=58-100`. The - central fabrication core is at `x=50`, `y=75`. Large visible decks, service - bays, cargo trusses, docking arms, radiator panels, and point-defense turrets - fill the bottom foreground. The base should feel like the viewer is hovering - above its core. -- **Station shield perimeter**: visible cyan oval/arc centered around `x=50`, - `y=57`, spanning roughly `x=18-82`, `y=34-82`. The shield is thinner at the - top, stronger and brighter where incoming fire hits on the left and right. -- **Nebular gravitational terrain**: fills the entire background beyond the - station, especially `x=0-100`, `y=0-65`, with rolling blue-white ridges and - bright cloud valleys. The nebula surface should flow diagonally from - `x=0,y=58` toward `x=100,y=22`. -- **Celestial body**: small pale icy moon at `x=53`, `y=12`, above the nebula - terrain and behind the battle. - -Four defending player ships, locked to positions: - -1. **DPS ship A / interceptor**: located at `x=19`, `y=64`, just outside the - lower-left shield arc. Sleek red-and-white triangular interceptor, nose - pointed outward toward `x=5`, `y=55`. It fires twin blue-white laser streams - outward-left into pirate skiffs and laser raiders. Its engine trail curves - along the station perimeter, showing it is patrolling the ring. -2. **Tank ship / shield defender**: located at `x=34`, `y=48`, left-front of - the station, directly between the station core and the left enemy approach. - Bulky slab-armored ship, nose pointed outward toward `x=7`, `y=42`. It - projects a large cyan frontal shield facing left, overlapping the station - shield. Red-orange enemy laser beams strike this shield and refract away from - the base. -3. **DPS ship B / gunship**: located at `x=68`, `y=42`, upper-right perimeter. - Heavier gunship with broad cannons and missile pods, nose pointed outward - toward `x=88`, `y=26`. It launches a missile salvo outward-right toward the - torpedo bomber and missile boats. Its missiles must travel away from the - station, not toward it. -4. **Support ship / repair-cooling craft**: located at `x=66`, `y=70`, inside - the lower-right shield perimeter near a damaged radiator wing at `x=61`, - `y=78`. Compact utility ship with articulated repair arms. One cyan repair - beam and one paler coolant beam connect from the support ship to the damaged - station module. White-blue heat mist vents away from the module toward - `x=74`, `y=67`. - -Enemy combatants, locked outside the defender ring: - -1. **Pirate laser raiders**: small fast ships in three packs at `x=2-16`, - `y=36-59`. They skim along the nebula surface and fire red-orange beams - inward-right toward the tank ship at `x=34`, `y=48`. No raider crosses inside - the shield perimeter. -2. **Pirate missile boats**: three wedge-shaped craft at `x=86-98`, `y=34-61`. - They launch dense curved missile swarms inward-left toward the station shield - and point-defense turrets. Missile trails start at the right edge and bend - toward `x=58`, `y=55`. -3. **Boarding pod carriers**: two armored carriers at `x=82-93`, `y=67-80`. - They release a dotted stream of small boarding pods toward docking arms at - `x=68`, `y=72`. Pods travel inward-left but stop visually at the shield - boundary. -4. **Torpedo bomber**: one larger pirate bomber at `x=18`, `y=20`, above the - nebular surface. It aims a heavy torpedo diagonally down-right toward the - station fabrication core at `x=50`, `y=75`, while DPS ship B's missiles - streak outward to intercept it. -5. **Jammer corvette**: spindly pirate support vessel at `x=82`, `y=14`. It - projects faint red interference rings diagonally inward toward the station - sensor mast at `x=52`, `y=52`. -6. **Salvage skiffs**: two tiny pirate utility craft at `x=6-14`, `y=76-86`, - towing asteroid/resource fragments away from the lower-left perimeter. DPS - ship A is visibly turning outward to stop them. - -Projectile and motion vectors: - -- Enemy fire always travels from the outside edges inward toward the station or - defender ring. -- Defender fire always travels outward from the station perimeter toward enemy - groups. -- Point-defense tracers originate from base turrets at `x=42-66`, `y=58-78` and - shoot upward/right and upward/left into incoming missiles. -- The brightest shield impacts happen at `x=31`, `y=48` on the tank shield and - `x=72`, `y=56` on the station shield. -- No major defender weapon line should point into the base core. - -Visual hierarchy: - -1. Station core and shield perimeter are the largest readable forms. -2. Four defender ships are medium-sized, bright, and cleanly colored with cyan - friendly effects. -3. Enemy ships are smaller or darker, with ragged silhouettes and red-orange - effects, except for the torpedo bomber and jammer corvette which are larger - but clearly outside the perimeter. -4. Missile trails, laser beams, point-defense tracers, repair beams, and shield - arcs must guide the eye back to the station without making the defenders look - hostile to it. - -Style/medium: high-end cinematic sci-fi matte painting, key art, painterly -realism, dramatic scale, dense but readable battlefield composition, no UI, no -text. - -Lighting/mood: intense blue-white nebula backlight, cold cyan shields and -coolant beams, hot red-orange pirate impacts, white point-defense flashes, -desperate but heroic co-op defense energy. - -Color palette: cold luminous blues, cyan shields, white nebula haze, steel-gray -AU station, red-orange impact accents and pirate engine glows, small red/white -accents on DPS A. - -Materials/textures: industrial station plating seen from above, glassy shield -refraction, heat-scarred turret barrels, missile plasma trails, repair/cooling -beams, asteroid debris, volumetric nebula clouds, ragged pirate armor plating, -scorched missile racks, flickering jammer rings. - -Constraints: no text, no logos, no watermark, no readable cockpit UI, no single -huge human figure, no Star Wars/Star Trek styling, no fantasy magic. Keep the -camera above the base. Keep the bottom third occupied by the station core. Keep -the four player ships arranged protectively around the station, facing outward. -Place all enemy groups outside the shield perimeter. Make every attack vector -and defensive action legible in the panorama. - -## Revision: Outward-Looking Panorama From Above Station - -Use case: ads-marketing - -Asset type: Starbridge promo splash art / panoramic website hero image - -Input image: use the provided Aetheria screenshot as structural reference, not -merely mood. The nebula forms gravitational terrain: a luminous blue-white -volumetric surface like an ocean of space-clouds. Resources, debris, ships, -stations, missiles, and combat activity cluster along or just above this nebular -surface. Larger celestial bodies float above the surface. The battlefield should -feel like it takes place at the playable boundary of the nebula, not in empty -black deep space. - -Camera and format: panoramic wide-angle key art from a camera positioned above -the station, looking outward across the battlefield rather than straight down. -The station core is below and slightly behind the camera, mostly out of sight. -Only the upper rim of the base, shield projectors, turrets, docking arms, -radiator edges, and service structures are visible along the bottom foreground. -The viewer should feel perched above the base looking out over its defensive -perimeter toward the incoming pirates. - -Primary request: Create splashy matte-painting promo art for Aetheria: -Starbridge. An Aeronautics Unlimited frontier station is being defended by four -player ships arranged protectively around its visible upper perimeter while -pirate forces attack from the outer edges of the nebular terrain. The defenders -must clearly face outward and protect the station. They must not look like they -are attacking the station. - -Composition: - -- **Bottom foreground**: the upper edge of the station fills the bottom band of - the panorama. Show only the visible rim of the base: shield emitter pylons, - point-defense turrets, docking-arm tips, radiator edges, service gantries, and - glowing infrastructure. The actual base core is below the camera and out of - frame. -- **Middle band**: the station shield perimeter arcs across the image, just - beyond the foreground base rim. Four defending player ships form a clear - protective diamond along this perimeter, all oriented outward. -- **Far field**: the blue-white nebular gravitational terrain stretches outward - from the station into the distance, with asteroid resources and debris - floating at the surface. Pirate attackers occupy the far left, far right, - upper-left, upper-right, and lower side approach lanes outside the defender - ring. -- **Sky/depth marker**: a small pale icy moon or celestial body floats above the - nebular terrain in the upper middle distance, giving scale and echoing the - provided reference. - -Four defending player ships: - -1. **DPS ship A / interceptor**: lower-left perimeter, just beyond the visible - base rim and outside the shield arc. Sleek red-and-white triangular - interceptor, banking outward along the nebula surface. It fires twin - blue-white laser streams away from the station into pirate skiffs and laser - raiders on the left approach. -2. **Tank ship / shield defender**: left-center perimeter, between the station - and the heaviest incoming laser fire. Bulky slab-armored ship with a large - cyan frontal shield facing outward. Its shield overlaps the station shield, - catching red-orange beams before they reach the visible base rim. -3. **DPS ship B / gunship**: upper-right perimeter, outside the shield arc. - Heavier gunship with broad cannons and missile pods, nose pointed outward - toward the right and upper-right approaches. It launches missiles away from - the station toward a torpedo bomber and missile boats. -4. **Support ship / repair-cooling craft**: lower-right perimeter, close to a - damaged radiator edge on the visible base rim. Compact utility craft with - articulated repair arms. One cyan repair beam and one pale coolant beam reach - down and back toward the damaged station edge, while white-blue heat mist - vents away from the base. It must read as servicing the station, not attacking - it. - -Enemy combatants: - -1. **Pirate laser raiders**: far left approach, small fast ships skimming the - nebula surface. They fire red-orange beam volleys inward toward the tank ship - and station shield. -2. **Pirate missile boats**: far right approach, wedge-shaped craft launching - dense curved missile swarms inward toward the station. Missile trails arc - across the panorama and are intercepted by point defense. -3. **Boarding pod carriers**: lower-right outer approach, ugly armored carriers - releasing small boarding pods inward toward the station's docking arms. The - pods form a dotted trail of hot engine sparks approaching the shield - boundary. -4. **Torpedo bomber**: upper-left distance above the nebular surface, lining up - a heavy torpedo run toward the station below the camera. DPS ship B's missile - salvo streaks outward to intercept it. -5. **Jammer corvette**: upper-right distance, spindly pirate support vessel - projecting faint red interference rings inward toward the station sensor mast - and shield perimeter. -6. **Salvage skiffs**: lower-left outer edge, small pirate utility craft trying - to tow wreckage or resource fragments away from the battlefield while DPS - ship A peels outward to stop them. - -Projectile and motion vectors: - -- Enemy fire, missiles, boarding pods, and jammer rings travel inward from the - outer approaches toward the station perimeter. -- Defender lasers, missiles, point-defense tracers, and shield faces point - outward from the station perimeter toward enemy groups. -- Point-defense tracers originate from turrets along the bottom foreground base - rim and streak outward into incoming missile swarms. -- Repair and coolant beams from the support ship angle down/back toward the - damaged station edge, visually distinct from weapons. -- No defender weapon line points into the base. - -Visual hierarchy: - -1. The visible station rim and shield perimeter anchor the bottom foreground. -2. The four defender ships are bright, medium-sized, and arranged as a protective - perimeter. -3. Enemy ships are darker, ragged, and outside the perimeter, with red-orange - effects. -4. Missile trails, laser beams, point-defense tracers, repair beams, shield - impacts, and jammer rings guide the eye across the panoramic battlefield - without confusing who is defending whom. - -Style/medium: high-end cinematic sci-fi matte painting, key art, painterly -realism, dramatic scale, dense but readable battlefield composition, no UI, no -text. - -Lighting/mood: intense blue-white nebula backlight, cold cyan shields and -coolant beams, hot red-orange pirate impacts, white point-defense flashes, -desperate but heroic co-op defense energy. - -Color palette: cold luminous blues, cyan shields, white nebula haze, steel-gray -AU station, red-orange impact accents and pirate engine glows, small red/white -accents on DPS A. - -Materials/textures: industrial station plating seen from above and behind, -glassy shield refraction, heat-scarred turret barrels, missile plasma trails, -repair/cooling beams, asteroid debris, volumetric nebula clouds, ragged pirate -armor plating, scorched missile racks, flickering jammer rings. - -Constraints: no text, no logos, no watermark, no readable cockpit UI, no single -huge human figure, no Star Wars/Star Trek styling, no fantasy magic. Do not show -the entire station core as a top-down map; the core is below the camera and out -of sight. Show only the upper rim of the base along the bottom foreground. Keep -the four player ships arranged protectively around the station perimeter, facing -outward. Place all enemy groups outside the shield perimeter. Make every attack -vector and defensive action legible in the panorama. +- top-down map composition or a fully visible station core; +- defenders appearing to attack the station; +- ambiguous projectile directions; +- empty black space replacing the nebular surface; +- one hero ship overwhelming the cooperative formation; +- UI, text, logos, watermarks, or readable cockpit displays; +- giant human figures, fantasy spell effects, or recognizable franchise styling. diff --git a/Aetheria/Game Design/Aetheria Starbridge.md b/Aetheria/Game Design/Aetheria Starbridge.md index 781e4e4..ebeb8b7 100644 --- a/Aetheria/Game Design/Aetheria Starbridge.md +++ b/Aetheria/Game Design/Aetheria Starbridge.md @@ -1,1476 +1,169 @@ --- title: "Aetheria: Starbridge" -description: "Asymmetric 2-5 player co-op: one RTS operator commands the base while pilots fly ships, manage heat, recover technology, and survive escalating waves through shared Verse state." +description: "A draft asymmetric co-op defense design: one station commander and several pilots operating the same war machine." --- # Aetheria: Starbridge -Game Design Document +> **Status:** Developed draft GDD; concept-stage, not shipped or a release roadmap. Existing code supplies design evidence, not proof of the loop described here. -Date: 2026-06-24 - -
- Aetheria: Starbridge promo art showing an Aeronautics Unlimited station defended from pirate attack across blue-white nebular terrain. -

Starbridge as a co-op siege line: the station rim below the camera, defenders holding the perimeter, and pirate pressure advancing across Aetheria's luminous gravitational terrain.

-
- -## High Concept - -**Aetheria: Starbridge** is a 2-5 player cooperative defense game about a small -frontier base surviving escalating waves of attack through asymmetric teamwork. - -One player commands the base from an RTS interface: routing power, expanding -infrastructure, fabricating weapons, assigning drones, deploying turrets, and -reading the whole battlefield as a strategic map. The other players fly -individual ships in the Unity client, fighting attackers directly, recovering -salvage, anchoring field structures, and making the urgent close-range saves the -commander cannot make from the chair. - -The result is a simple game with a clean silhouette: - -> One base. One crew. One player sees the whole war. The others are in it. - -## Market Pitch - -Starbridge is built for friend groups, not isolated individual fantasies. Its -central market promise is that the group already contains different kinds of -players, and the game finally makes that social shape useful. - -The pitch: - -> The co-op space defense game for the friend who wants to build the base and -> the friends who want to fly out and save it. - -The RTS role is not a burden assigned to a random public-match stranger. It is a -place for the friend who already likes strategy, logistics, tower defense, -factory planning, or commander play. The pilot roles are for the friends who -want movement, combat, salvage, repair, cooling, and clutch field execution. - -This makes the design unusual without making it illegible: - -- one player commands the base; -- the others fly ships; -- everyone defends the same position; -- waves end in boss technology recovery; -- the team refits, upgrades, and unlocks the next scenario together. - -The audience is the co-op group chat: three to five people looking for a game -where different tastes can become a crew instead of a compromise. Starbridge -should market itself less as an RTS/FPS hybrid for genre purists and more as an -asymmetric co-op defense game for mixed-skill, mixed-preference friend groups. - -## Design Intent - -Aetheria has long wanted two different kinds of players to struggle together in -the same universe: the player who loves systems, economy, construction, and -command, and the player who wants thrust, weapons, heat, dodging, and risk. See -[[Playable Layers]] for the larger design problem Starbridge is cutting into. -**Starbridge** turns that ambition into a readable first release. - -The game should be easy to understand in five minutes: - -- The base must survive. -- The RTS player builds and directs. -- The pilots fight and recover resources. -- The wave gets worse. -- Communication wins. - -The innovation comes from the way those roles depend on one another. The RTS -player is not a spectator, and the pilots are not units. Each side owns -information, agency, and failure modes the others cannot replace. - -## Relationship To Aetheria Systems - -Starbridge is the short-session co-op proof of Aetheria's larger design stack. -It should not invent a separate class game, economy, or combat model for the -sake of convenience. It should compress existing Aetheria pressures into a -smaller arena where their relationships become easier to read. - -Starbridge is a mode inside the broader [[Aetheria Client and Modes|Aetheria client]], -not the whole client. The desktop app starts or joins Starbridge -sessions, carries party and Verse context, exposes the shared Hangar, and can -remain open as the commander UI. Pilot players launch into Unity clients that -already know which Verse, session, role, and player identity to connect to. - -Core inheritance: - -- [[Design Pillars]]: the game must make heat, repair, risk, labor, and survival - feel material rather than decorative. -- [[Playable Layers]]: the RTS operator and pilots are two distances from the - same crisis, not two unrelated clients sharing a scoreboard. -- [[Action RPG Layer]]: ship feel, tactical combat, salvage, docking, and - loadout pressure come from cockpit-scale Aetheria. -- [[Corporate Strategy Layer]]: infrastructure, production, research recovery, - station stock, and base defense come from strategy-scale Aetheria. -- [[Ship-shape and Up to Specs]]: ships are hulls, hardpoints, heat budgets, - cargo compromises, docking options, and manufacturer doctrine. -- [[Heat, Stealth, and Detection]]: thermal support is not healing by another - name. It is heat debt management under fire. -- [[Economy and Production]]: every weapon, drone, support module, and station - stock item should have production history, quality, and maintenance - implications. -- [[Progression, Claims, and Consequence]]: recovery, wreck claims, station - exposure, drones, and equipment access should all leave material traces. -- [[Persistent Universe and Reset Loop]]: repeated runs should feel like a - scoped expression of Aetheria's larger reset logic: selective carryover, - knowledge, changed baselines, and another attempt under pressure. -- [[Implementation Signals]]: the active game repo already points toward typed - state, behavior-driven equipment, cargo, docking, heat, and shared - simulation; Starbridge should use that direction rather than route around it. - -## Subtitle Rationale - -**Starbridge** is the working subtitle for this release because it names the -cooperative fantasy without colliding with the darker identity of -[[End of the Line|Terminus]] or [[Call of the Void|L'Appel du Vide]]. - -It suggests: - -- a bridge crew split across different interfaces; -- a base that connects ships, infrastructure, and territory; -- the act of holding a fragile crossing point in hostile space; -- the architectural role of Verse as the shared state bridge between clients. +**Aetheria: Starbridge is a 2–5 player asymmetric co-op defense game where one player operates a vulnerable space station from an RTS interface while one to four pilots fly ships in real time, surviving escalating attacks through communication, construction, thermal control, salvage, and repair.** ## Target Experience -The ideal session feels like a cooperative crisis room. +Starbridge makes several players inhabit different parts of one tactical problem. The commander sees infrastructure, reserves, threats, and failure chains. Pilots feel distance, momentum, incoming fire, local visibility, and the time required to reach anything the commander has marked. Neither view is complete. -The RTS player sees bomber vectors, failing shield nodes, fabrication queues, -drone availability, turret coverage, and salvage flow. The pilots see incoming -fire, hull alarms, missile trails, vulnerable enemies, thermal spikes, repair -opportunities, and physical openings the map cannot fully express. +A good session should produce requests rather than orders: cool the eastern radiator before fabrication stalls; intercept the bomber before it reaches torpedo range; recover a pod before the next wave. Players should disagree about priority because they possess different information and risk different assets, then discover whether their coordination was good enough. -The best moments sound like: - -- "Hold north for ten seconds. I can get the shield back." -- "Mark that bomber. I have a targeting window." -- "Do not chase the scouts. I need salvage at the fabricator." -- "I am dropping a turret frame. Someone anchor it." -- "Your reactor is cooking. Dock or get a coolant beam on you." -- "Drone swarm is live. Lead it through the breach." - -Communication is not flavor. It is the main interaction surface between two -different games occupying one battlefield. +The defended station is not scenery. It fabricates, senses, shields, cools, repairs, launches, stores, and gives damaged ships somewhere to return. Pilots extend its reach; the commander turns their salvage and attention into continued capacity. Victory should feel like keeping a complicated workplace alive under attack, not clearing enemies from a neutral arena. ## Design Pillars -### 1. Asymmetric Clarity +### Asymmetric Clarity -Every player should understand their job at a glance. - -The RTS player owns the base, logistics, and tactical infrastructure. Pilots own -their ships, local combat, salvage recovery, and close field interaction. When a -system crosses that boundary, the game should make the handoff visible and -useful. - -### 2. One Shared War Machine - -The base is not a static health bar. It is a living machine made of power, -sensors, fabrication, defense, repair, launch capacity, and station stock. When -part of it is damaged, the whole team should feel the change. - -### 3. Communication As Mechanics - -The game should create concrete reasons to talk. It should reward quick, -specific, legible coordination rather than vague callouts or constant chatter. - -### 4. Tactical Readability Before Content Volume - -The first release should have few enemy types, few structures, and few pilot -abilities. Each element must have a strong silhouette, obvious counterplay, and a -clear place in the cooperative loop. - -### 5. Authority As Fantasy - -The Verse authority model should support the game fantasy directly. The RTS -runtime naturally authors base and tactical infrastructure. Pilot runtimes -naturally author responsive ship claims. Short-lived leases can allow local -close-combat response without turning every client into a hidden global -authority. That makes the networking model an expression of [[Playable Layers]], -not just transport plumbing. - -## Player Roles - -### RTS Player: The Chair - -The RTS player acts as the base commander, logistics officer, engineer, and -tactical systems operator. This role is a small-session expression of -[[Corporate Strategy Layer]]: infrastructure and production decisions become -conditions the pilots have to survive physically. - -Primary responsibilities: - -- maintain base power and shields; -- place and upgrade infrastructure; -- fabricate weapons, drones, and consumables; -- deploy and retask turrets, drones, mines, and decoys; -- identify wave composition and attack vectors; -- mark priority targets and field objectives; -- allocate scarce support abilities; -- keep pilots supplied, repaired, and directed. - -The RTS player should be busy but not frantic. Their challenge is attention -management: seeing more than anyone else, while still depending on pilots to -touch the battlefield. - -Core RTS verbs: - -- build; -- route; -- repair; -- fabricate; -- deploy; -- mark; -- overclock; -- assign; -- lease; -- call down. - -### Ship Players: The Pilots - -Pilots fly individual ships in the Unity client. They are the fast, embodied -response layer of the team. Their verbs come from [[Action RPG Layer]] and -[[Ship-shape and Up to Specs]]: the ship on screen is still a working object, -not a class portrait with engines painted on. - -Primary responsibilities: - -- intercept attackers before they reach the base; -- destroy or disable priority targets; -- recover salvage from dangerous locations; -- anchor construction ghosts placed by the RTS player; -- cool overheated ships, turrets, and base systems when equipped for thermal - support; -- repair exposed systems when equipped with repair gear; -- escort drones and supply pods; -- dock at the station to switch ships, change loadouts, and draw from station - stock; -- kite enemies through kill zones; -- survive long enough for the base machine to adapt. - -Pilots should feel powerful, vulnerable, and physically present. They are not -generic RTS units. Their moment-to-moment skill matters. - -Core pilot verbs: - -- thrust; -- dodge; -- shoot; -- boost; -- mark; -- salvage; -- anchor; -- cool; -- repair; -- dock; -- refit; -- escort; -- lure; -- cover. - -## Core Game Loop - -1. The team enters a defense session around a frontier base. -2. The RTS player reviews the base, resources, and incoming wave forecast. -3. Pilots launch and take positions. -4. Attackers arrive along readable lanes, vectors, or threat clouds. -5. Pilots fight, intercept, salvage, and perform field interactions. -6. The RTS player spends salvage and power to build, repair, fabricate, and - deploy support. -7. The wave creates a crisis the team must solve through coordination. -8. The wave boss is defeated and yields recovered technology choices. -9. The team survives, stabilizes, upgrades, refits, and prepares for the next - wave. -10. The session ends in victory after a final wave or defeat when the base - falls. - -Target first-release session length: **20-30 minutes**. - -## Session Pacing - -Starbridge should be tuned around graceful failure. The game should not collapse -the first time one role underperforms. A completely undefended base can survive a -few waves on passive resilience, starter systems, and forgiving enemy pacing. A -good commander or a good crew can carry the team roughly halfway. Finishing a -run requires everyone doing their jobs. - -The pacing goal: - -- **Opening waves**: teach the shape of the game. The base can absorb mistakes, - pilots can learn movement and salvage, and the commander can learn power, - stock, and build tools without instantly dooming the team. -- **Early pressure**: either side can compensate. Strong pilots can intercept - threats and recover salvage while a new commander learns. A strong commander - can stabilize weak pilots with turret placement, repair reserves, drones, and - clear priorities. -- **Middle waves**: the team begins to feel role dependency. Salvage flow, - station refits, support gear, thermal debt, and build timing start to matter - together rather than separately. -- **Late waves**: no single role can carry. Pilots need a prepared base, - commander support, and sensible recovered technologies. The commander needs - pilots to execute dangerous objectives, recover key salvage, cool overheated - systems, and repair exposed modules. -- **Finale**: the run asks whether the group became a crew. Victory should feel - earned through division of labor, not raw damage output. - -This protects the friend-group fantasy. Nobody should feel that inviting the -strategy friend creates homework, and nobody should feel that a new pilot turns -the session into a tutorial hostage situation. The game welcomes uneven skill, -then gradually makes coordination necessary. - -## Match Structure +Commander and pilot interfaces expose different work without hiding the shared state that connects it. A pilot can see where cooling, repair, docking, salvage, or interception is physically possible. The commander can see why those actions matter to station survival. Role differences should create coordination, not an information tax that requires one player to narrate the whole UI aloud. -### Lobby +### One Shared War Machine -Players choose roles before launch: +Power, heat, fabrication, defenses, ships, salvage, and support equipment are parts of one operating system. A choice in one layer must create legible consequences elsewhere. Rushing fabrication may consume power and thermal margin. A pilot carrying coolant gear sacrifices another loadout opportunity. Salvage left outside the perimeter is unavailable for repairs. The station and ships should never feel like separate games sharing a scoreboard. -- 1 RTS player required; -- 1-4 pilots supported; -- difficulty selected by the group; -- base loadout preset selected by the RTS player or host. +### Communication Without Command Custody -### Pre-Wave Build Window +The commander allocates station resources, places structures, exposes priorities, marks targets, and requests support. The commander does not author pilot movement or seize a pilot's ship. Pilots decide whether, when, and how to answer. They may refuse a task because their route is unsafe, their ship cannot perform it, they judge another threat more urgent, or they simply disagree. -The RTS player has a short planning phase. Pilots can launch, scout, practice -movement, or take early field positions. The planning phase should remain short -enough that the game does not become a lobby simulator. +Refusal must remain playable rather than becoming sabotage by definition. Marks should convey purpose and urgency without turning into compulsory waypoints. The resulting social contract is cooperation among roles with bounded authority, not one player treating the others as cursor-operated units. -### Combat Wave +### Support Changes Outcomes -Enemies attack the base and its outer systems. The RTS player commands the base -machine while pilots fight in real time. Each wave should culminate in a -readable boss or command unit whose defeat ends the wave and produces the run's -next technology recovery choice. +Cooling, repair, rescue, sensing, hauling, anchoring, and target marking must be capable of saving a run. They should require position, timing, equipment, and exposure rather than becoming passive auras. Combat ships also need reasons to protect support work, and support pilots need tactical decisions beyond following the most damaged health bar. -### Stabilization Window +### Readable Pressure Before Content Volume -After a wave, the team has a brief recovery period. Damaged structures can be -repaired, wreckage can be converted, upgrades can be selected, and pilots can -dock to switch ships or exchange equipment with the station's stock. The team -also chooses from randomized technologies recovered from the defeated wave boss. +The first useful Starbridge proof needs a small vocabulary with strong interactions. Players should understand which attack is arriving, what system is failing, what intervention remains possible, and why the group lost. More factions, ships, structures, and technology are valuable only after the basic pressure is readable. -### Finale +## Player Roles And Contract -The last wave should combine multiple learned pressures: bombers, siege craft, -skirmishers, and breach threats arriving with enough timing offset that the team -must triage rather than simply win a damage race. +### Station Commander -## Battlefield +The commander operates the station map and its constrained reserves. Their work includes routing power, managing heat debt, scheduling fabrication, placing or restoring infrastructure, assigning automated defenses, exposing sensor information, marking priorities, and choosing where scarce salvage is committed. -The first map should be one readable combat space, not a content buffet. +The commander owns station actions, not the pilots. A construction request can project a site into space, but a pilot chooses whether to anchor it. A rescue priority can identify a pod, but it cannot redirect a ship already screening a bomber. Commander mastery comes from making the situation intelligible, preserving options, and asking for work the team can physically perform. -Recommended first map: +### Pilots -- central base with exposed shield nodes and fabrication core; -- three major approach lanes; -- asteroid cover fields that matter to pilots; -- outer salvage zones that tempt risky flights; -- limited buildable hardpoints; -- long-range threat space for siege enemies; -- clear visual distinction between safe interior, contested perimeter, and - dangerous exterior. +Pilots fly persistent or scenario-provided ships through the local battlefield. They fight, scout, haul salvage, recover pods, cool or repair station systems, anchor construction, change equipment while docked, and contest threats beyond the station's direct reach. -The RTS view should simplify the space into tactical information. The pilot view -should make the same space feel physical, fast, and hazardous. +Pilots own their movement and immediate tactical commitments. Loadout creates opportunity costs: a ship equipped for coolant transfer, towing, field repair, or sensing gives up space or performance elsewhere. Support remains a choice with visible value, not an assumed obligation imposed by matchmaking role. -## Base Systems +### Shared Decisions -The base is the team's shared body. +Some decisions do not yet have a settled owner. Recovered technologies, contested station stock, and scarce replacement ships may affect the whole run while being acquired by one pilot or exposed through the command interface. Whether these use commander selection, pilot possession, group vote, first claim, or a contextual rule remains an open design decision. The final mechanism must show who decides and permit disagreement without freezing the session. -First-release systems: +## Session Loop -- **Core Integrity**: if the core dies, the match is lost. -- **Power Grid**: structures need power; overloads create short-term strength - and long-term risk. -- **Shield Nodes**: directional defensive systems that create obvious defense - priorities. -- **Fabricator**: converts salvage into deployables, repairs, ammunition, and - field replacements through the [[Economy and Production]] grammar of inputs, - quality, and maintenance. -- **Sensor Array**: improves wave prediction, enemy reveal, and target marking. -- **Launch/Service Bay**: survival pod recovery, respawn, repair, rearm, docked - ship selection, and pilot support. +### Briefing And Loadout -Damage should be readable. If the shield node is failing, everyone should know -where and why. +The group selects a scenario and sees the defended site's purpose, starting condition, known attackers, environmental pressure, and immediate objective. Pilots choose ships and equipment within scenario constraints. The commander reviews station systems and available procedures. The briefing should reveal enough provenance to make the attack specific without solving later surprises. -## RTS Build Set +### Build Window -The first release should start with a small, expressive build set. +The commander spends limited stock on initial infrastructure, defense, sensing, or fabrication. Pilots launch, inspect the perimeter, collect nearby resources, test routes, and anchor projected structures. Preparation is short enough that incomplete knowledge and imperfect coverage remain part of the run. -### Power Node +### Attack Wave -Extends or stabilizes the base grid. Vulnerable but essential. +Enemies pressure several systems at once. Fast craft test interception, siege units create deadlines, missile or boarding threats demand point defense, and salvage-oriented attackers may exploit wrecks rather than merely damage the core. The commander tracks the station-wide pattern while pilots act inside local geometry and travel time. -### Turret +### Stabilization -Reliable area defense. Strong against predictable attackers, weak if isolated or -unpowered. +The surviving group recovers pods and wreckage, repairs or replaces equipment, vents accumulated heat, restores station functions, and chooses how to spend recovered technology or salvage. Stabilization is not a risk-free shop screen: remaining threats, damaged routes, limited docking space, and the next-wave clock can preserve urgency. -### Missile Rack +### Escalation And Finale -Consumes fabricated ammunition for burst anti-bomber or anti-siege defense. +Later waves recombine known pressures, introduce command units, and attack the team's established habits. A finale should test the infrastructure and relationships built during the run rather than introduce an unrelated boss grammar. Victory preserves the defended objective and records a legible aftermath; defeat should identify the chain of failures that reached the station. -### Repair Drone Bay +## The Shared War Machine -Produces repair drones that can be assigned to structures or escorted by pilots. +### Station Capacity -### Shield Projector +The station converts reserves into tactical capacity through power, shielding, sensing, defense, fabrication, cooling, docking, and repair. This is a functional vocabulary, not a promised catalog. -Creates directional resilience. Strong when supported, expensive when neglected. +Three pressures organize the first prototype: -### Sensor Mast +- **Power** runs active systems and makes simultaneous demand visible. +- **Mass** represents salvage, ammunition, parts, and fabrication stock. +- **Heat** limits sustained activity and turns overclocking into shared debt. -Improves detection, wave previews, target locks, and commander map fidelity. +Heat is the most distinctive shared pressure. Weapons, shields, fabrication, damage, and overclocking can consume thermal margin. Radiators expose vulnerable infrastructure. Pilots may carry coolant or help vent a threatened system, buying time at the cost of position and loadout. Heat should create spatial work and tactical deadlines, not merely fill another bar. -### Decoy Beacon +### Salvage And Recovery -Pulls certain enemies off critical infrastructure, allowing pilots to exploit -pathing or create kill zones. +Destroyed enemies and structures leave recoverable mass, components, records, or technologies. Salvage has a location, travel cost, and claim on pilot attention. The commander may need it for immediate repair while a pilot sees an exposed technology worth risking the ship to retrieve. Enemy doctrine can also target wreckage, turning recovery into a contested objective. -## Ships, Loadouts, And Support Gear +Ship destruction should usually produce a survival pod rather than remove the player from the session. Another pilot or station system can recover the pod; replacement craft depend on available stock and docking capacity. Loss therefore damages group resources and position while creating rescue work. It should hurt without converting one mistake into spectator mode. -Starbridge should use Aetheria's existing ship and loadout identity rather than -flattening pilots into fixed hero classes. Ships have hulls, hardpoints, -equipment, cargo, thermal behavior, docking state, and station-facing inventory. -This is the [[Ship-shape and Up to Specs]] doctrine in co-op form. The first -release should make that system readable without exposing all of its long-term -complexity at once. +### Construction And Field Support -Pilots can dock at the station between waves, or during combat if they accept -the time and positioning risk. While docked, a pilot can: +The commander projects a construction ghost from available station plans. A pilot reaches the site and holds or performs an anchoring action while exposed. The station then commits mass, power, and fabrication time. This keeps RTS placement tied to physical space and gives pilots agency over whether a proposed site is reachable. -- switch to another available ship; -- exchange equipped gear with station stock; -- restock consumables and ammunition; -- install thermal support equipment; -- install repair equipment; -- restore a saved or preset loadout when the required stock exists. +Repair, coolant transfer, towing, sensing, and rescue follow the same rule: the capability must be equipped, the target must be reachable, and the action should expose the ship to a meaningful tradeoff. Automation can assist routine work without erasing the player decisions that make support a role. -The station's stock is a team resource and a miniature -[[Economy and Production]] surface. A coolant projector sitting in storage is -not helping anyone until a pilot chooses to give up another hardpoint for it. -This makes support an equipment commitment rather than a passive role label. - -Station stock should eventually carry quality and provenance: - -- mass-produced emergency gear with poor thermal margins; -- recovered boss technology that enters the stock pool for this run; -- premium manufactured components with better durability or performance curves; -- scarce support modules whose presence changes team composition decisions. - -### Persistent Hangar - -Starbridge should treat persistent ship ownership as build-shape access, not -raw match power. A player may bring a personally unlocked hull and loadout into -a scenario because those components define a known assembly graph: hardpoints, -gear families, thermal topology, firmware assumptions, repair interfaces, and -manufacturer doctrine. The scenario can normalize the starting quality of those -components without erasing the player's chosen ship identity. The pilot still -arrives in the shape of their dream machine. The run decides how good that -machine becomes today. - -This works because Aetheria items are blueprint assemblies, not flat loot. A -laser, coolant beam, reactor, or shield can contain crafted assemblies that are -themselves blueprint instances. Enemy salvage, station stock, and recovered -boss technology may share subassemblies with a player's own gear even when the -finished item blueprints are different. Tearing down a wreck can therefore -recover a higher-quality focusing lattice, capacitor bank, coolant collar, -regulator, or other compatible assembly that upgrades the player's item if the -interfaces and maintenance constraints match. - -The live-service rule is: - -> Persistent unlocks define what shapes the player can field. Run economy -> defines how good those shapes become under fire. - -Owning a component grants practical maintenance and fabrication access to that -component lineage during a scenario. It does not grant universal research -mastery. A crew still needs salvage, station tooling, time, and compatible -inputs to repair or upgrade the assembly, but they do not need a separate tech -unlock merely to understand the object they brought with them. - -The persistent hangar is therefore the player's long-term collection and -expression surface. It can contain: - -- unlocked hulls; -- unlocked gear families; -- owned component patterns; -- saved loadout shapes; -- manufacturer variants; -- cosmetic liveries, decals, bay dressing, titles, and other identity pieces; -- convenience unlocks that reduce friction without increasing match power. - -The hangar is not owned by Starbridge. It is an Eve/CultUI CRUD surface over -central player state, especially player inventory, unlocks, entitlements, -component patterns, cosmetics, and saved loadout documents. Starbridge consumes -approved loadout shapes from that player state and applies scenario -normalization. A future PvP mode, route mode, web companion, or account -management surface should consume the same hangar state rather than inventing a -parallel inventory. - -Hangar authority: - -- owner: typed central player inventory and unlock state; -- surface: Eve/CultUI hangar composition lowered into game, web, native, or TUI - clients; -- commands: inspect, equip, unequip, rename, save loadout, apply livery, - compare assemblies, dismantle, queue repair, and fabricate when a station or - service context allows it; -- non-owners: Starbridge sessions, Unity scene objects, websites, storefront - entitlements, matchmaking, cinematic hangar rooms, and renderer-local caches. - -The same hangar should be usable from the website and from inside the game. -The website can host the exact customization surface the pilot later uses in -the Unity client because both are lowerings of the same Eve graph and command -surface. That is a product promise and an architecture constraint: no duplicate -web inventory, no delayed synchronization as design policy, and no renderer -becoming the secret owner of player loadouts because it had the prettiest room. - -The hangar should support the MechWarrior-style pleasure of owning, naming, -tuning, and showing off a personal machine without letting ownership purchase a -win. A veteran can bring a strange or expensive topology into an early scenario, -but the starting component quality can be normalized to that scenario's -baseline. Their advantage is build identity, assembly access, familiarity, and -more possible upgrade paths during the run, not raw starting damage. - -Starbridge should permit audacious loadouts, then let scenario pressure and -squad priorities judge them. If a pilot brings an overbuilt, overheated, -under-supported, supply-hungry, or otherwise despicable machine, the game -should not need a pre-match rules cop to forbid it. The loadout enters the -mission in normalized form, performs according to its actual compromises, and -the crew decides how much attention, coolant, repair, salvage, and commander -support it deserves. If the build cannot justify its appetite, the pilot can be -left to eject, pod home, and return in something more reasonable. - -That failure can become a social moment instead of a balance scandal. A player -who brings a precious, expensive, aggressively personalized ship may still end -up begging the squad to escort them back into contested space to salvage their -beautiful mistake. The squad is not only pricing the wreck against the -opportunity cost of a rescue. They are judging player/build fit: whether this -pilot actually has the skill, discipline, and communication habits to fly that -elite topology under pressure, or whether the team would be better served by -the same player docking into a basic support ship with two useful buttons. This -makes attachment playable: ownership can create stories, obligations, jokes, -skill audits, and rescue drama without becoming purchased dominance. - -Deep metagame knowledge will create copied "meta" builds. That is expected and -healthy as long as the build's operating doctrine remains visible in play. A -copied elite ship should demand understanding: heat rhythm, thermal and power -modes, cooling circuit setup, engagement range, retreat timing, support -dependency, ammo and salvage appetite, target priority, and recovery plan. A -player can copy the loadout and the configuration, but they still have to know -when to be in which mode. If the pilot does not understand the machine, the -squad should be able to tell from battlefield behavior rather than from a -scolding UI badge. They will see the pilot out of position, consuming too much -coolant, wasting commander attention, losing rare assemblies, frying themselves -by firing more guns than they can cool, or using a precision tool like a brick -with decals. - -The anti-pay-to-win rule is: - -> A premium build can be bought or copied. Competence cannot. - -This makes monetization safer. Paid or accelerated unlocks can expand the -player's collection, expression, loadout convenience, and access to alternate -build shapes, while gameplay-affecting power remains governed by scenario -normalization, salvage, station fabrication, and team execution. The live -service can sell beautiful hangars and faster access to toys. It should not -sell completed victories wearing a ship skin. - -### Thermal Support - -Thermal support means providing cooling services to ships, drones, turrets, and -base systems. It should be expressed through gear that must be mounted on the -supporting ship. This is [[Heat, Stealth, and Detection]] as cooperative labor: -one player takes on the work of moving someone else's heat debt. - -Thermal support is also anti-capture play. Some enemies should try to win by -forcing ejection rather than by destroying hulls outright: disabling radiators, -overloading control systems, and attaching remora-style drones that push heat -into ships until the pilot has to abandon the craft. A support pilot counters -that win condition by stabilizing cockpit temperature, buying safe firing time, -burning off hostile heat debt, or cooling a ship long enough for the pilot to -dock instead of eject. - -Candidate thermal support gear: - -- **Coolant Beam**: transfers or dissipates heat from an allied target while - the pilot holds contact. -- **Radiator Pod**: deploys a temporary cooling field that helps nearby allies - shed heat. -- **Thermal Sink Canister**: consumes a limited charge to absorb a burst of heat - from a critical ally or structure. -- **Heat Pump Lance**: pulls heat out of one target and dumps it into the - support ship's own thermal system, creating risk for the rescuer. -- **Thermal Scrubber Burst**: clears hostile heat-transfer effects from a - friendly ship, turret, or station module before they cascade. - -Thermal support should create strong positioning decisions. A pilot cooling an -overclocked turret or overheated bomber interceptor is doing something valuable, -vulnerable, and visibly different from shooting. - -### Repair Support - -Repair support means restoring damaged hulls, drones, turrets, and exposed base -modules. It should also come from equipped gear, not from every ship having a -universal repair button. In Aetheria terms, repair is not mercy dust. It is -maintenance access, parts availability, time under threat, and a claim on the -team's limited station stock. - -Candidate repair gear: - -- **Patch Beam**: sustained hull or module repair with range and exposure risk. -- **Repair Drone Rack**: launches limited drones that perform repairs while the - pilot protects or escorts them. -- **Nanite Foam Charge**: short-range burst repair for emergencies. -- **Tow Clamp**: helps recover disabled ships or drones to the station's service - radius. - -Repair support should be powerful but interruptible. The pilot who brings repair -gear has sacrificed damage, speed, cargo, cooling, or utility capacity to do so. - -## Pilot Ship Kit - -The first pilot kit should be straightforward, but it should still be built from -ship equipment. - -Recommended baseline combat loadout: - -- primary weapon; -- boost; -- dodge or roll; -- missile or special weapon; -- interaction tool for salvage, anchoring, docking, and objective actions; -- target mark. - -Recommended baseline support substitutions: - -- replace a weapon or special slot with thermal support gear; -- replace a utility slot with repair support gear; -- carry fewer offensive consumables in exchange for service charges, repair - drones, coolant canisters, or spare parts. - -The first release does not need a large ship roster. It does need enough loadout -agency that one pilot can say, "I will dock and come back with cooling," and -have that choice matter immediately. - -## Shared Mechanics - -### Salvage - -Destroyed enemies drop salvage. Pilots must recover it physically or escort -collection drones. The RTS player spends salvage on structures, repairs, drones, -and munitions. - -Salvage is the main bridge between pilot risk and RTS agency. It should inherit -the spirit of [[Progression, Claims, and Consequence]]: wreck recovery takes -time, exposes the recovering ship, and may force the team to decide whether a -component, material cache, or boss technology is worth the danger. - -### Survival Pods - -Pilot ships should carry auto-eject survival pods. A pilot can trigger ejection -at any time, and catastrophic ship failure should trigger it automatically when -the pod system is still functional. - -The survival pod should be represented as a proxy ship with a fixed loadout -determined by the ship's cockpit item. In fiction and in camera language, the -cockpit the player sees is ejected whole as a module. The player does not -teleport into an abstract escape object; their view tears free from the failing -hull, carrying the cockpit module into the field as a small, limited, -recoverable craft. - -The cockpit item therefore defines the pod's emergency capabilities: - -- minimal thrusters; -- emergency beacon; -- short-range comms; -- limited sensors; -- small self-defense gun or flare/countermeasure behavior if supported; -- no lawful combat role; -- no cargo or support-service capacity beyond survival. - -Escape pods can carry small guns, but those guns exist for wildlife, -microdrone, debris, or desperate proximity defense after ejection. They are not -legitimate combat craft. Using a pod as a combatant is a war crime because the -entire survival norm depends on everyone treating pods as protected objects. The -reason pirates, station guns, and player ships generally do not target pods is -that pods are not supposed to affect the battle. - -This keeps ship loss material without making it terminal. Losing a ship costs -the team hull value, equipment access, cargo, field position, recovery time, and -possibly whatever wreck claim the attackers or scenario rules create. It does -not remove a player from the session or force them to spectate while the crew -continues without them. - -The survival loop: +## Scenarios And Provenance -1. Pilot ejects manually or through automatic catastrophic-loss protection. -2. The cockpit module separates from the hull and becomes the pilot's proxy ship - with the cockpit item's fixed pod loadout. -3. The pod becomes a vulnerable recoverable object in the field. -4. The Launch/Service Bay can recall, recover, or receive the pod depending on - distance, threat, and scenario rules. -5. The pilot returns through an available ship, replacement hull, or repaired - docked craft. -6. The lost ship becomes an economic and tactical setback, not a player-state - failure. +A Starbridge scenario is a bounded remix of six elements: -This follows the design pressure in [[Progression, Claims, and Consequence]]: -failure leaves wreckage, claim risk, repair cost, and station exposure behind. -The person survives. The balance sheet does not. +1. a defended site with a material purpose; +2. its starting infrastructure, stock, and damage; +3. an environment that shapes movement, sensing, or heat; +4. attackers with a production history and tactical doctrine; +5. a wave or objective structure that tests particular dependencies; +6. recovered technology and an aftermath tied to what occurred. -Survival pods also make loadout experimentation socially safe. A pilot can test -an audacious hangar build without the team being forced to subsidize it for the -entire match. If the ship proves too hot, too fragile, too slow, too greedy for -ammo, or too dependent on support the squad needs elsewhere, the battlefield -can answer. The crew may choose to save it, abandon it, tow it later, or spend -their attention on the base instead. The pilot pods back to the Launch/Service -Bay and refits into a better answer. +Faction provenance should change play. An attacker shaped by thermal engineering should pressure cooling and yield different recoveries from raiders seeking intact hulls, automated siege machines, or an unknown probe ecology. The GDD does not select a canonical first attacker. Named setting factions may support later scenarios only after their owner notes justify the doctrine, motive, location, and technology being used. -Docking and refit are therefore the correction primitive for bad theory. The -game should let players learn from the shape of their ship under pressure, -change the shape, and rejoin the war. A failed loadout should create a -recoverable tactical and economic setback, not a scolding modal, a queue dodge, -or a permanent player-state failure. +Representative enemy jobs include scouts that expose weak routes, skirmishers that screen heavier units, bombers or siege craft that create deadlines, boarding or breach units that attack internal function, missile platforms that test interception, and recovery units that steal wrecks. These are mechanical roles, not a committed roster. -Wreck recovery should require visible squad judgment. If the lost ship is -valuable, exotic, sentimental, or full of rare assemblies, rescuing it can be a -real objective that competes with base defense, salvage flow, and wave timing. -The pilot may plead for an escort. The crew may agree, bargain, laugh, refuse, -or make the recovery conditional on better decisions next wave: refit simpler, -bring support gear, stop chasing scouts, fly near the base, or prove the elite -machine is more than a costume. The system should give them a meaningful reason -to talk about competence, role fit, and trust without needing a matchmaking -score to say the quiet part out loud. +The environment should also be playable. Aetheria's luminous nebulae can form gravitational terrain: ridges, valleys, currents, and surfaces that shape approach vectors and visibility rather than serving as wallpaper. Other scenarios may use debris, station geometry, weather, or orbital relationships, provided the terrain remains readable to both interfaces. -Thermal capture enemies sharpen this loop. If a pilot ejects because hostile -heat pressure made the cockpit unsafe, the pod remains protected and the ship -becomes a contested prize. Enemy remorae can switch from heating to cooling once -the pod clears, preserving the hull for capture. The team can answer by killing -the remorae, towing the derelict, cooling it for re-entry, or deliberately -scuttling the wreck before attackers claim it. +## Progression And Continuity -### Construction Ghosts +Within a run, recovered technologies can alter structures, equipment, automation, or operating limits. Choices should create visible divergence without requiring a large permanent tech tree. Exceptional recoveries should reflect the defeated system's provenance and the risk required to obtain them. -The RTS player can place a projected structure in valid field space. A pilot -must fly to the location and anchor it before it becomes real. +Between runs, Starbridge may hand bounded results to the broader [[Aetheria Client and Modes|Aetheria client]]. The [[Aetheria Client and Modes#Hangar|Hangar]] may retain ships, equipment, presets, and cosmetic identity. [[Aetheria Client and Modes#Commander Continuity|Commander continuity]] may retain roster relationships, stress, scars, refusals, and learned procedures. Neither continuity system is required to prove the core session loop, and this document does not promise implementation order. -This creates a direct cooperation loop: +Persistence must not make scenarios decorative. A veteran player may bring identity and options, but the defended site still owns its material constraints. Likewise, staff progression should change command decisions rather than exist only as flavor generated after a match. -RTS player identifies need -> pilot takes risk -> base gains new capability. +## Presentation Invariants -Construction should remain grounded in [[Corporate Strategy Layer]] and -[[Economy and Production]]. A turret frame is not magic terrain paint. It is a -fabricated object, powered through the grid, anchored by a pilot, and maintained -afterward. +The commander interface is map-first and operational. Power, heat, shields, fabrication, incoming vectors, pilot position, build sites, and damaged systems must be readable without digging through decorative panels. Warnings should point to the affected place and explain the threatened function. -### Target Marks +The pilot HUD preserves the physical act of flying. It prioritizes ship and thermal state, objective, marked threats, base direction, nearby support opportunities, docking or salvage prompts, and spatial warnings. It should not become a miniature RTS display. -Pilots and the RTS player can both mark targets, but marks mean different -things depending on source. +Art should communicate industrial survival in luminous deep space. Structures need legible functions; ships and enemy jobs need distinct silhouettes; shields, coolant, repair, construction, and attack vectors need different visual languages. Spectacle serves tactical reading. The nebular surface should carry depth and motion without hiding threats. -Pilot marks are local, urgent, and line-of-sight grounded. RTS marks are -strategic, sensor-backed, and can route turrets, drones, or missiles. +Audio carries role-specific information. Command audio emphasizes system completion, power or shield failure, fabrication, and wave direction. Pilot audio emphasizes engine strain, thermal danger, impact direction, locks, support tools, and commander marks. Shared events—core breach, bomber arrival, shield collapse, pod launch, final escalation—should be recognizable to the whole group. -### Drone Leashing +## State Authority Invariant -The RTS player deploys drones. Pilots can lead or shape drone behavior by flying -through command rings, escort paths, or leash zones. +Every consequential action must have one visible authority boundary. The commander decides station allocation and station-system commands. Each pilot decides ship movement and chosen actions. Shared inventory, docking, recovery, and technology decisions require an explicit session authority rather than competing client-local truths. -### Overclock, Cool, And Vent +This is a design invariant, not a networking prescription. Any implementation must make its actual authority map and failure behavior inspectable. An action that lacks authority should fail visibly rather than rely on later reconciliation to hide split ownership. -The RTS player can overclock a turret, shield node, or fabricator. Overclocking -creates heat or instability. A pilot with the right equipment can cool, vent, or -reset the system if they can reach it under fire. A pilot without that equipment -can still defend the area, anchor emergency structures, or return to the station -to refit. +## Success Tests -This should create a natural triangle: +The concept earns further production work if a small prototype can demonstrate that: -RTS overclocks a system -> heat becomes a tactical debt -> support-equipped -pilot pays that debt in the field. +- new players can identify the station's immediate danger and their role in answering it; +- commander and pilots remain meaningfully occupied without performing the same work through different cameras; +- pilots can refuse or redirect requests without the interface treating refusal as loss of control; +- cooling, repair, rescue, hauling, sensing, or construction can prevent defeat as decisively as direct damage; +- ship loss creates recoverable tactical and resource pressure rather than prolonged spectator time; +- in-run technology choices make two sessions diverge in ways the group can explain; +- groups lose through readable failures in coverage, heat, resources, travel time, or coordination rather than opaque rules; +- shared actions resolve under one visible authority boundary without inventory or station state splitting between clients. -### Authority Leases +## Open Decisions -Some combat moments benefit from giving a pilot temporary local response -authority over a narrow subject, such as close defense around a shield node or a -hostile engaged at knife range. - -In game terms, this can appear as: - -- close-defense permission; -- local drone reaction envelope; -- temporary countermeasure control; -- emergency repair autonomy; -- boosted target resolution near the pilot. - -In Verse terms, this should map to bounded interest leases rather than -hardcoded client privilege. - -## Enemy Roster - -The first release should ship with five enemy archetypes. - -### Scouts - -Fast, fragile attackers that probe defenses and create distraction. - -Player lesson: do not overcommit heavy resources to light threats. - -### Skirmishers - -Pilot-pressure enemies that chase, harass, and disrupt salvage recovery. - -Player lesson: pilots need cover, not just objectives. - -### Bombers - -Slow, obvious, dangerous base killers. - -Player lesson: priority targeting and interception matter. - -### Siege Craft - -Long-range attackers that punish a passive defense. - -Player lesson: pilots must leave the comfort of the base perimeter. - -### Breach Drones - -Small enemies that attach to shield nodes, power nodes, or the core and force -close defense or repair interaction. - -Player lesson: not every threat is solved by damage alone. - -## Difficulty And Scaling - -Difficulty should scale through composition, timing, and pressure layering, not -just health inflation. - -The campaign curve should follow the same carry philosophy as session pacing: -roles are individually sufficient early, partially sufficient in the middle, and -intentionally insufficient alone by the end. - -Early waves teach one problem at a time: - -- intercept fast targets; -- recover salvage; -- defend a shield node; -- stop a bomber; -- push out to kill siege craft. - -Later waves combine problems: - -- bombers arrive while skirmishers pin pilots; -- siege craft force an outward push while breach drones attack the base; -- scouts reveal weak points before a heavy wave; -- salvage drops in risky zones just before the team needs resources. - -Each wave should end with a boss or command unit that embodies the wave's main -lesson. The boss does not need to be large every time, but it should be -recognizable as the thing that resolves the wave and drops recovered technology. - -Candidate boss roles: - -- **Scout Captain**: fast target that exposes weak base coverage before dying. -- **Siege Carrier**: launches standoff threats until pilots push out. -- **Thermal Warden**: overheats defenses and makes cooling support matter. -- **Remora Matron**: launches attachment drones that force pilots into - thermal-capture counterplay. -- **Breach Mother**: spawns attachment drones that force close defense. -- **Bomber Frame**: slow final threat that tests priority fire and missile - economy. - -## Progression - -Progression should be rogue-lite adjacent. Each session should feel like a -distinct run because the team discovers different technologies, adapts to -different recovered options, and invests persistent score currency between runs. -This is the compact-session cousin of [[Persistent Universe and Reset Loop]]: -not total continuity, not disposable attempts, but selective carryover that -changes future pressure. - -### In-Session Technology Recovery - -At the end of each wave, the boss drops a randomized set of recovered -technologies. The team chooses one or more, depending on difficulty and run -length. These technologies change the shape of the current session only. - -Recovered technology should feel like research salvage, not a magical level-up -screen. The team is pulling a usable pattern, prototype module, hostile -subsystem, fabrication technique, or field calibration out of the boss wreck and -forcing the base to digest it quickly. That ties the reward loop back to -[[Economy and Production]] and the research pressure described in -[[Corporate Strategy Layer]]. - -Recovered technologies should be concrete enough to change behavior: - -- stronger turret tracking; -- cheaper repair drones; -- improved pilot boost recharge near the base; -- faster construction anchoring; -- larger salvage collection radius; -- better sensor prediction; -- expanded station stock; -- improved coolant efficiency; -- faster dock refit service; -- emergency core shield once per match. - -Additional recovered technology examples: - -- missile racks gain a small area burst; -- coolant beams can chain to one nearby ally; -- repair drones gain armor while escorted; -- sensor masts reveal the next boss modifier; -- fabricator queues one emergency item for free after a shield collapse; -- pilots vent heat faster while inside the base shield; -- decoy beacons pull bomber locks for a short window; -- station stock gains one random support module. - -The randomization should create adaptation, not chaos. The offered technologies -must be legible, limited in number, and tied to systems the team already -understands. - -### Meta-Progression - -Every run awards a persistent currency based on in-game score. This currency can -be invested into modest percentage boosts that tune the team's long-term -baseline without replacing skill, coordination, or in-session decisions. - -Meta-progression also feeds the persistent hangar. Players should be able to -unlock hulls, gear families, component patterns, manufacturer variants, saved -loadout conveniences, and cosmetic identity pieces over time. These unlocks -expand the shapes a player can bring into a scenario, but scenario -normalization and in-run fabrication determine the starting quality and realized -power of those shapes. - -Meta-progression also feeds the Barracks, the commander-side progression -surface described in [[Aetheria Client and Modes]]. The Hangar stores machines. -The Barracks stores people and minds. A commander should not bring a custom -station into every scenario, because the scenario owns the base, stock, -technology, salvage ecology, and faction pressure. Instead, the commander -builds a bridge crew: thermal officers, fabrication leads, drone marshals, -fire-control officers, quartermasters, rescue coordinators, signal/witness -officers, faction liaisons, and stranger advisory minds. - -The bridge crew changes how the commander operates the scenario's provided -station: - -- warnings surface earlier or with better context; -- automation behaves differently; -- emergency procedures become available; -- resource handling becomes cleaner or riskier; -- drones, salvage, rescue, fabrication, shields, and fire control gain - staff-shaped priorities; -- post-run analysis produces better black-box lessons. - -The bridge crew does not replace the scenario's equipment list, starting -station, or loot table. It is the commander's build without stealing authorship -from the episode. - -Fictionally, this currency can represent post-run analysis, recovered data, -operator certification, manufacturing credit, or sponsor confidence. The exact -name can come later. The important design constraint is that it behaves like -selective carryover from [[Persistent Universe and Reset Loop]], not a license to -flatten the early game into homework. - -Score inputs can include: - -- wave reached; -- final victory; -- base integrity remaining; -- pilots recovered or revived; -- salvage collected; -- structures saved; -- boss clear speed; -- support contribution through cooling and repair; -- difficulty modifier. - -Meta-progression should focus on balance elements that feel good to improve in -small percentages: - -- base core integrity; -- shield recharge rate; -- turret tracking speed; -- repair efficiency; -- coolant efficiency; -- salvage conversion rate; -- station stock quality; -- dock refit speed; -- pilot boost recharge; -- starting fabrication reserve; -- staff recovery speed; -- staff training efficiency; -- black-box analysis yield; -- bridge roster capacity or flexibility within strict limits. - -The first release should keep these boosts shallow and transparent. The goal is -to make every run feel productive, not to make early runs feel intentionally -underpowered. - -Completing the game should also unlock the next scenario. Scenario unlocks are -the content-progression spine: a crew survives one authored co-op crisis, earns -score currency and account investment, then opens the next crisis with a -different starting shape. - -Each scenario defines: - -- starting base configuration; -- initial station stock and ship availability; -- starting technology availability; -- wave structure and boss sequence; -- faction mix attacking the base; -- faction-specific loot table and recovered technology pool; -- narrative premise and post-run consequence. - -The scenario may also define staff pressure: recommended roles, stress -modifiers, factional frictions, special debrief hooks, and risks to particular -staff archetypes. A Cryonix thermal trial should not merely alter the loot -table; it should also make thermal officers matter and leave some of them -different afterward. - -The faction mix matters mechanically. A [[Worldbuilding/Pre-Elysium/Factions/Powers/Major/Zhestokost|Zhestokost]] -attack should drop different hardware, pressure different defenses, and reward -different recovery choices than a [[Worldbuilding/Pre-Elysium/Factions/Powers/Major/Cryonix|Cryonix]] -raid, a pirate siege, autonomous probes, or alien-aligned machines. The scenario -is therefore not just a map label. It is a controlled remix of production -history, hostile doctrine, and reward ecology. - -This gives Starbridge an episodic release model. New scenarios can arrive as a -steady stream of co-op episodes: compact authored premises, bounded mechanical -twists, new faction mixes, and new recovered technology pools that groups can -work through together without requiring a whole new campaign architecture every -time. - -### Seasons And Scenario Access - -Starbridge can organize new scenarios into seasons. A season is a coherent -bundle of co-op episodes, faction pressure, recovered technology pools, hangar -identity rewards, and toolchain practice for delivering more cinematic and -interactive narrative through the game's existing systems. - -The first shipped game should include a small set of standard scenarios that -prove breadth and depth before the live cadence begins. Those launch scenarios -should test the core grammar: base defense, salvage pressure, thermal and -repair support, outward pushes, boss technology recovery, and the ability for a -crew to lose for legible tactical reasons. Later seasons should add authored -scenarios that reuse and extend the same scenario grammar rather than becoming -bespoke content coffins. - -Access policy: - -- the current season may be premium; -- current-season scenarios may also be available as individual purchases; -- the season pass bundles the current season's scenarios with cosmetics, - hangar identity rewards, convenience rewards, and supporter value; -- when a season is no longer current, its gameplay scenarios move into the - earnable archive; -- archived scenarios can be unlocked through play using earned currency, - progression milestones, reputation, or another humane in-game path; -- cosmetics, titles, liveries, bay dressing, and supporter identity rewards may - remain premium or season-specific when that does not affect gameplay access; -- gameplay-affecting scenarios should not be permanent missed-content ransom. - -Squad access should be contagious. If any player in the group has a scenario -unlocked, the whole squad can launch and play it together. Scenario access is -checked at squad launch, not as a per-player gate that splits friends at the -door. Ownership still matters: it can grant hosting access, solo queue access, -season-pass rewards, supporter cosmetics, convenience rewards, and direct -progression claims. But the co-op fantasy takes priority over entitlement -accounting. - -Players who guest into a scenario through a squadmate should still receive -normal run rewards and should be able to make progress toward earning that -scenario for themselves once it is archived. Current-season premium ownership -can decide which account-level claims, cosmetics, or season-track rewards are -available immediately, but it should not prevent friends from playing the -mission together. - -Monetization doctrine: - -> Starbridge sells time, freshness, expression, convenience, and support for the -> ongoing service. It does not permanently sell access to the war. - -This keeps the open-source posture coherent. The code can be open, older -gameplay scenarios can become earnable, and the official live service can still -charge for Steam convenience, current-season access, bundled value, account -services, cosmetics, hangar expression, and the privilege of keeping the -machine fed without turning the business model into a little extraction engine -with patch notes. - -## Narrative - -Starbridge's narrative should follow the principles in [[Narrative and Missions]]: -authored pressure inhabiting systemic space. A scenario is not just "wave set -number seven." It is a particular base, under particular attack, for reasons -that expose something about Aetheria's institutions. - -The first narrative unit is the defended base: - -- who built it; -- who works there; -- what it produces, stores, researches, or protects; -- why the attackers want it destroyed or captured; -- what the crew loses if it falls; -- what uncomfortable thing surviving proves. - -The RTS player and pilots do not need long cutscenes during combat. They need -briefings, station chatter, faction voice, boss introductions, post-wave recovery -messages, and end-of-scenario consequences that make the defense feel situated. - -Scenario narrative can carry the live-content cadence: - -- an emergency defense of a frontier fabricator; -- a station caught in a corporate patent raid; -- a salvage court dispute turning into armed seizure; -- a Cryonix thermal systems trial that becomes a siege; -- a pirate coalition attack on a repair depot; -- a thermal-capture raid where pirates want hulls and cargo intact, making pod - corridors, remora removal, and wreck recovery central objectives; -- an alien probe sequence misread as ordinary raiding until the loot table stops - looking human. - -Narrative rewards should stay mostly systemic. A completed scenario can unlock -the next scenario, alter available station stock, add a recovered technology to -future pools, expose a faction's doctrine, or change how later briefings frame -the same war. Starbridge should be able to release episodes constantly because -each episode is a reusable composition of premise, starting configuration, -faction mix, boss sequence, and loot ecology. - -The Barracks gives scenario narrative a second memory surface. A station can be -saved while a staffer comes back altered. A beloved rescue coordinator can bond -with a pilot whose pod they recovered. A thermal officer can learn the exact -shape of a pirate heat-capture doctrine and develop radiator dread while -becoming better at stopping it. These changes should be represented as typed -staff state, not loose flavor text: stress, scars, bonds, rivalries, procedures, -refusals, leave requests, promotions, retirements, and black-box memories. - -Generated staff interactions can carry some of this narrative load. Ghostlight, -VoidBot, and Epiphany persona turns can produce bounded debriefs, conflicts, -bond events, recovery moments, and staff requests from stable character state, -recent run facts, relationship state, and scenario context. Weksa vocals can -voice accepted interactions. The generated layer must preserve continuity: -characters are not disposable text fountains, and their state changes must be -inspectable and able to affect future runs. - -Model-generated outputs should be cached as discovered content. Persona text, -accepted debriefs, Weksa vocal renders, and possible Vili gesture or acting -data are content artifacts with provenance, not transient UI effects. Fresh -character/scenario/state combinations can justify expensive generation; common -states should resolve from cache once the service has seen them. Only -meaningful changes such as new scars, deaths, bonds, refusals, promotions, -faction revelations, or black-box events should force the expensive pipeline -back awake. - -## User Interface Direction - -### Shared Hangar Surface - -The hangar should be a shared Eve/CultUI surface over central player inventory, -not a Starbridge-only screen. It belongs to the broader [[Aetheria Client and Modes|Aetheria client]] -because ships, equipment, cockpits, support gear, -cosmetics, presets, and unlocks cut across Starbridge, Arena, Conquest, and the -future persistent world. The official website, in-game Unity client, desktop -launcher, Steam-adjacent account surface, future mobile companion, and -developer/operator TUI can all lower the same composition graph and submit the -same typed commands. - -This is a major live-service selling point: - -> Customize your ship anywhere. The same hangar follows you into the game. - -Starbridge may contextualize a persistent ship through run-local quality -scaling, recovered technologies, temporary station stock, and boss loot. That -does not make the ship a Starbridge-only object. The same build can later enter -Arena without Starbridge scaling and be matched by danger level, or enter a -Conquest season where faction logistics and campaign rules matter. - -The website version should not be a separate account shop pretending to be an -inventory editor. It should read the same player inventory state, expose the -same loadout validation, compare the same assemblies, apply the same cosmetics, -and submit the same save/equip/repair/fabrication commands where the player's -current service context permits them. Storefront purchases or season rewards -may grant unlock or entitlement documents, but the hangar remains a projection -over typed player state. - -### Barracks Surface - -The Barracks is the commander progression surface in the Aetheria client. It is -not a Starbridge-only minigame, but Starbridge is where the first version earns -its keep. - -The V1 Barracks should include: - -- roster cards and staff dossiers; -- a skills page for each staffer; -- active bridge slots for the next run; -- recovery, treatment, leave, and training slots; -- bonds, rivalries, stress, injuries, scars, and staff availability; -- staff-linked procedures and automation options; -- after-action changes from the last run; -- generated debrief and relationship events; -- replacement and succession tools for dead, retired, broken, or reassigned - staff. - -Staff roles are assignments, not hard classes. A staffer can specialize in one -area while remaining useful elsewhere. The skills page should show who can man -a gun, control drones, handle rescue coordination, read witness telemetry, or -run thermal triage in a pinch. Out-of-specialty assignments should be possible -and costly: more stress, slower response, poorer automation, increased -Cognition pressure, or higher chance of mistakes. - -The V1 Barracks should not include animated portraits or a RimWorld-style -walk-around life simulation. The important presentation is roster consequence: -who changed, who needs rest, who is becoming brilliant, who is becoming -dangerous, and who the commander is about to send back into the furnace anyway. - -Character releases can use a gacha-style cadence without making the official -game a casino costume machine. Rarity should mean specificity of personhood: -common staffers are useful demographic cuts through a faction labor pool; -higher tiers are specialists, named professionals, historical survivors, -faction assets, illegal minds, or canon characters with unique procedures and -consequences. The official axis is narrative gravity and operational profile, -not outfit escalation. - -Duplicates are useful because war takes people. A duplicate may be a new -trainee from the same program, a replacement officer, a sibling, a protege, a -parallel firmware instance, or a legal/illegal mind fork. Some legacy can carry -forward through certifications, training records, black-box lessons, and -memorial procedures. Bonds, trauma, trust, and personal history do not simply -copy over. The replacement may be mechanically familiar and emotionally not the -same person. That is the point. - -Presentation mods can exist as sidecars. Community wardrobe, portrait, voice, -or adult presentation packs should not alter skills, stress, procedures, -recruitment odds, or scenario outcomes. Official staff rarity and progression -remain mechanical and narrative. Mods dress the stage; they do not own the war. - -### RTS Interface - -The RTS interface should feel like an operational command surface: - -- dense but readable; -- map-first; -- clear power and shield overlays; -- fast structure placement; -- obvious wave vectors; -- visible pilot positions and statuses; -- build queues and drone assignments within one glance; -- warnings tied to map locations, not detached notification spam. - -The RTS player needs tools, not decoration. - -### Pilot Interface - -The pilot HUD should prioritize: - -- ship status; -- thermal state; -- equipped service gear and charges; -- current objective; -- marked threats; -- base danger direction; -- nearby cooling, repair, salvage, docking, and anchor prompts; -- commander pings; -- incoming high-threat attacks. - -The HUD should preserve the kinetic feel of flying. It should not become a -miniature RTS screen. - -## Art Direction - -Starbridge should look like industrial survival in luminous deep space. - -Visual priorities: - -- readable silhouettes over visual noise; -- bright tactical effects against dark space; -- base systems with visible function; -- enemy archetypes identifiable by shape and movement; -- construction ghosts that look like projected infrastructure; -- shield and power states that can be read instantly; -- pilots as sharp, fast points of agency. - -The first release does not need many environments. It needs one strong arena -that teaches the game cleanly. - -## Audio Direction - -Audio should reinforce asymmetry. - -RTS audio: - -- command confirmations; -- threat alerts; -- power failures; -- fabrication completion; -- drone deployment; -- shield warnings. - -Pilot audio: - -- engine strain; -- weapon identity; -- shield impact direction; -- lock warnings; -- repair and salvage beams; -- commander pings translated into spatial cues. - -Shared audio events should create team awareness: bomber arrival, core breach, -final wave, shield collapse, fabricator restored. - -## Networking And State Authority - -Starbridge should be the first public-facing design target for Aetheria's -trusted co-op Verse authority. It is also the place where -[[Implementation Signals]] become visible to players: typed state, ship -equipment, cargo, docking, heat, commands, and shared simulation all need to -agree under pressure. - -Initial authority shape: - -- RTS runtime authors base infrastructure, fabrication, drone/turret orders, - wave state, and hostile tactical claims. -- Each pilot runtime authors its own responsive movement and immediate combat - claims. -- Station stock, docked ship state, and loadout changes remain typed Verse state - changes rather than client-local inventory edits. -- Thermal and repair support claims are only valid when the authoring pilot's - current ship has the relevant equipped gear. -- Verse policy documents define which runtime can author which subject and - claim kind. -- Unsupported authority modes fail closed and visibly. -- Short-lived leases support close-range responsiveness without creating a - hidden second authority surface. - -This design should not require consensus machinery for the first release. The -target is trusted co-op, 2-5 players, and explicit authority policy that can -grow later. - -## First Release Scope - -### Must Have - -- 2-5 player co-op; -- exactly one RTS player; -- 1-4 pilot players; -- one defend-the-base map; -- one session mode; -- scenario selection and completion unlocks; -- first scenario definition with starting base, stock, technologies, attacker - mix, and loot table; -- Barracks V1 with limited command staff roster; -- active bridge staff selection for the commander; -- staff skills, stress, recovery, and after-action changes; -- five enemy archetypes; -- small RTS build set; -- one baseline combat ship kit; -- station docking, ship switching, and equipment exchange; -- thermal support gear and repair support gear; -- salvage economy; -- randomized post-wave technology recovery; -- wave bosses or command units that drop recovered technologies; -- pilot survival pods and ship-loss recovery; -- construction anchoring; -- target marking; -- drone/turret support; -- wave victory and base destruction defeat; -- run score and persistent score currency; -- diagnostics for active Verse policy and runtime identity. - -### Should Have - -- wave preview through sensors; -- post-wave upgrade choices; -- meta-progression percentage boost investments; -- generated staff debriefs and relationship events; -- staff bonds, rivalries, refusals, and leave requests; -- episodic scenario metadata for faction mix and recovered technology pools; -- pilot down/respawn loop through launch bay; -- overclock, cooling, and vent interaction; -- drone leashing; -- saved bridge roster presets; -- difficulty presets; -- concise end-of-session score report. - -### Could Have - -- expanded pilot ship variants; -- larger station stock progression; -- broader staff release pool; -- staff-linked command procedures; -- challenge modifiers; -- elite enemy variants; -- replayable daily seed; -- cosmetic base or ship skins. - -### Not For First Release - -- MMO persistence; -- adversarial peer handling; -- witness quorum; -- broad procedural campaign; -- large tech trees; -- multiple factions; -- complex economy simulation; -- RimWorld-style Barracks walk-around simulation; -- animated staff portraits; -- unbounded account power creep; -- PvP. - -## Success Criteria - -The first release succeeds if: - -- new players understand the win condition immediately; -- the RTS player is meaningfully busy for the entire session; -- pilots always have something physical and useful to do; -- total ship loss is a resource and positioning setback, not a terminal player - state; -- an undefended base can survive the first few waves; -- either a strong commander or strong pilots can carry the group into the middle - of a run; -- completing a run requires commander preparation, pilot execution, support - gear, and shared recovered technology choices; -- post-wave technology choices make runs diverge in readable ways; -- score currency makes every run feel productive without replacing teamwork; -- completing a scenario unlocks the next co-op episode; -- faction mixes alter enemy pressure and recovered technology loot tables; -- the team loses because of readable tactical failure, not confusion; -- communication clearly improves outcomes; -- the same battle feels different with different player behavior; -- the Verse authority model supports the fantasy without becoming visible - friction. - -## Open Design Questions - -- Should the RTS role be mandatory in public matchmaking, or can a simplified AI - commander fill the chair for pilot-only testing? -- Should pilots have identical ships at first, or light role differences such as - interceptor, bruiser, and support? -- How much tactical risk should pod recovery carry before it becomes too - punishing for new crews? -- Should construction anchoring require holding position, completing a timing - interaction, or surviving a short vulnerable channel? -- How much enemy wave control should the RTS runtime author directly versus - derive from deterministic wave definitions? -- Which pieces of Starbridge meta-progression should map to licenses, - certification, manufacturing reserve, or reset-loop memory? -- What is the first scenario sequence, and how many scenarios should ship before - the live episode cadence begins? -- How much production provenance should station stock expose in the first - release: item quality only, manufacturer identity, or full material history? -- Should boss technologies be framed as research patents, hostile subsystem - recovery, salvage claims, or emergency field modifications? -- What in-fiction entity is attacking the base in the first release: pirates, - autonomous war machines, alien probes, corporate raiders, or something more - specific to the current Aetheria timeline? - -## One-Sentence Pitch - -**Aetheria: Starbridge** is a 2-5 player asymmetric co-op defense game where one -player commands a living space base from an RTS interface while the others fly -ships in real time, surviving escalating attack waves through communication, -construction, salvage, and shared Verse-authoritative state. +1. Who resolves contested recovered-technology and station-stock choices: commander, possessor, vote, claim rule, or scenario-specific authority? +2. Which station pressures belong in the first prototype beyond power, mass, and heat; does cognition produce play or only another meter? +3. How should pod recovery balance rescue risk, persistent hull attachment, and the station's replacement stock without turning loss into spectator time or trivial replacement? +4. What smallest scenario proves attack, thermal support, salvage, construction, recovery, and readable defeat without requiring a faction campaign or persistent progression? diff --git a/Aetheria/Game Design/index.md b/Aetheria/Game Design/index.md index 541dfc9..16db39a 100644 --- a/Aetheria/Game Design/index.md +++ b/Aetheria/Game Design/index.md @@ -1,68 +1,42 @@ --- title: Game Design -description: "Aetheria's design is two different games sharing one doomed universe: cockpit-scale action and spreadsheet-scale corporate predation feeding the same persistent galaxy." +description: "Public map of Aetheria's current design owners, inherited ambitions, and playable constraints." --- # Game Design *"The setting is a machine. The playable problem is deciding which gears the player gets to touch first."* -Aetheria's design begins from an old, unreasonable ambition and then tries to make it survivable: two different games sharing the same doomed universe. One layer is a tactical action RPG about ships, crews, missions, routes, and violence up close. The other is a corporate strategy game about production, infrastructure, population roles, research, and economic dominance. Both are meant to feed the same persistent galaxy, where field players collide with shortages and opportunities created by the people running the machinery. +Aetheria's oldest design ambition joins cockpit-scale action to strategy-scale production, logistics, and institutional power. A pilot experiences a shortage as a dangerous route, failed repair, or contract they cannot afford to refuse. A corporation experiences the same shortage as procurement pressure, market leverage, or a reason to send somebody else into danger. -That is the full beast. The first major scope cut was [[End of the Line|Aetheria: Terminus]], a rogue-lite ARPG slice designed to prove combat, traversal, ship customization, narrative pressure, and the setting's corporate logic before the project tried to swallow the whole sun and ask politely for seconds. When even that looked too large, [[Call of the Void]] became the last-ditch smaller target: curated cases, taxi work, station life, and one exhausted private investigator discovering that the rupture is not politely undoing itself. [[Aetheria Starbridge|Aetheria: Starbridge]] cuts sideways instead: one RTS operator and several pilots defending the same base through Verse-authoritative co-op. [[Aetheria Client and Modes]] is the cross-mode product shell around that work: Hangar, parties, Verse selection, Starbridge sessions, Arena downtime, and seasonal Conquest experiments. +This branch contains current design owners, developed drafts, prototypes, and historical scope cuts. Those statuses matter. A detailed note can preserve useful mechanics without describing the current roadmap, and game design does not overwrite the setting notes that own shared history, technology, factions, or physical constraints. -## Design Stack +## Current Design Owners -- [[Design Pillars]] - the compact doctrine for what the game is trying to make playable. -- [[Aetheria Client and Modes]] - the desktop client, Hangar continuity layer, Starbridge/Arena/Conquest positioning, and mode cadence. -- [[Playable Layers]] - how the ARPG, corporate strategy layer, and shared world are supposed to meet. -- [[Action RPG Layer]] - cockpit-scale play: travel, combat, loadouts, risk, quests, and survival. -- [[Corporate Strategy Layer]] - spreadsheet-scale play: corporations, labor, production, research, logistics, and market pressure. -- [[Aetheria Starbridge]] - asymmetric co-op defense: RTS base command, pilot ships, thermal support, repair, station refits, boss technology recovery, and score-driven meta-progression. -- [[Persistent Universe and Reset Loop]] - the long campaign structure, alien escalation, extinction, and temporal reset. +- [[Design Pillars]] owns the durable playable values: material systems, consequential scale, ship identity, economy, failure, and accessible depth. +- [[Playable Layers]] owns the relationship between embodied action, corporate strategy, and a possible shared persistent context. +- [[Aetheria Client and Modes]] describes candidate cross-mode shell, player-continuity, and runtime boundaries. Its mode descriptions are historical hypotheses, not release commitments. +- [[Aetheria Starbridge|Aetheria: Starbridge]] is a developed draft GDD for asymmetric cooperative defense: one commander operates the base while pilots fight, recover material, and perform field work in the same crisis. -## Systems +## Design Invariants -- [[Economy and Production]] - commodities, blueprints, crafting quality, supply chains, and corporate leverage. -- [[Colonies and Population]] - colony vessels, station populations, demographic attributes, production affinity, demand, and influence. -- [[Galaxy and Navigation]] - generated stars, map layers, zone links, routes, sectors, and frontier topology. -- [[Gravity and Locomotion]] - the Grid, gravitational terrain, thrusters, warp fields, traction, wormholes, and fast travel heat costs. -- [[Heat, Stealth, and Detection]] - thermal performance, emissions, sensors, scanning, jamming, and identification. -- [[Ship-shape and Up to Specs]] - ships as loadouts, homes, status objects, and thermal compromises with weapons attached. -- [[Progression, Claims, and Consequence]] - licenses, death, escape pods, wreck claims, looting, scavenging, and station exposure. -- [[Narrative and Missions]] - Ink-driven quests, location constraints, faction presence, and story inside generated space. -- [[Nibu Attached Shuttle Story]] - a pre-Rupture hard-sci-fi playable story about a grey-market transport crew taking Nibu on as an attached shuttle and collapsing around the risk she brings. -- [[A Different Sort of Space]] - the visual and physical feel of Aetheria's non-hard-SF void. -- [[Visual and Sensory Direction]] - shaders, clouds, weapon effects, audio, and readable spectacle. -- [[Volumetric Nebulae]] - atmospheric prototype clips showing the nebula renderer as moving terrain, not wallpaper. -- [[Implementation Signals]] - what the active `Aetheria-Economy` work surface reveals about the design. +- [[Action RPG Layer|Cockpit-scale play]] and [[Corporate Strategy Layer|strategy-scale play]] must create pressure the other can understand. +- Ships remain material assemblies shaped by heat, maintenance, cargo, manufacturer doctrine, and access; see [[Ship-shape and Up to Specs]]. +- Production history matters. [[Economy and Production]] owns commodities, fabrication, quality, and supply relationships. +- Travel and combat remain legible through [[Galaxy and Navigation]], [[Gravity and Locomotion]], and [[Heat, Stealth, and Detection]]. +- Generated structure gains meaning through authored context; [[Narrative and Missions]] owns that seam. +- Implementation is evidence, not authority. [[Implementation Signals]] records inherited code and data-model pressure without making every surviving system a requirement. -## Release Path +## Historical Scope Cuts -- [[End of the Line]] -- [[Call of the Void]] -- [[Aetheria Client and Modes]] -- [[Aetheria Starbridge]] -- [[../Lore/Welcome to Elysium|Welcome to Elysium]] -- [[A Different Sort of Space]] -- [[Ship-shape and Up to Specs]] +[[End of the Line|Aetheria: Terminus]] was a reduced rogue-lite action-RPG proposal intended to prove combat, routes, ship builds, and corporate pressure without simulating the full persistent galaxy. [[Call of the Void]] cut further toward curated cases, station life, taxi work, and a private investigator confronting an older version of the Elysium revelation. -## Planning Sources +Both remain useful design history. Neither is identified here as the active release target. Older GDDs and planning documents likewise preserve mechanic intent rather than current marching orders. -The active `Aetheria-Economy` repository points to three planning-time documents: +[[Persistent Universe and Reset Loop]] preserves the historical long-campaign structure in which alien escalation, extinction, and temporal reset organize repeated play. It remains setting and design ancestry, not a current product commitment. -- [Aetheria GDD](https://docs.google.com/document/d/1iULu1WsbuQoUM3c87XkGseb1P-8R5xlruoiyg03TsSE/edit?usp=sharing) - the action RPG design document. -- [Profits Rising](https://docs.google.com/document/d/1U3uGFqQboAiFJ_Y-nUOGpyixbXUHRbc5DiCuB59GM4w/edit?usp=sharing) - the corporate strategy / RTS design document. -- [Aetheria Shader Implementation](https://docs.google.com/document/d/1AFycvCtW6hA1jkKq1ZmYd3k6_uEWaaCqcZ4fYj4vU6A/edit?usp=sharing) - shader and rendering notes. -- [Call of the Void / L'appel du Vide brainstorm](https://docs.google.com/document/d/1YWn5RWsciBxuaQ4l5TN2lAEz4okaQes-aiyx1E9NAxA/edit?usp=sharing) - the last-ditch post-Terminus scope cut built around Cat Marrigan, PI cases, taxi fares, and the point-of-no-return revelation. It predates the current Elysium continuity and still assumes a colonization-fleet frame. +## Contribution Boundary -These documents and the repository README are dated planning maps, not current marching orders. They are useful because they preserve mechanic intent: the time loop, tactical ship combat, heat and stealth, licenses, contracts, dungeons, drones, station management, production, population attributes, demand profiles, market arbitrage, research patents, independent traders, police protocol, AI corporations, and shader-driven gravitational terrain. They are also very much the sort of documents a person writes before reality, money, health, and the calendar arrive with tools. +Use this branch to make playable consequences explicit. New mechanics should identify the player decision, state owner, inputs, outputs, failure mode, and setting constraint they consume. Keep speculative features labeled as candidates until adopted by the relevant design owner. A playable interpretation may compress lore for a scenario; it does not silently establish universal canon. -The live hierarchy treats them as inherited design pressure, then filters them through the current canonical vault and the project direction now in front of us. The active game repo's shape is evidence, but not law: shared simulation classes, `ServerShared` data models, galaxy generation, equipment behaviors, cargo and trade UI, Ink narrative processing, map rendering, debug tools, and the server architecture show long-running ambitions that still need current judgment. - -## Setting Pressures - -- [[Introduction]] -- [[Narrative Themes]] -- [[Worldbuilding/Pre-Elysium/Timeline/index|Timeline]] -- [[Worldbuilding/Politics/Restrictions on Warfare|Restrictions on Warfare]] +For setting pressure, begin with [[Introduction]], [[Narrative Themes]], the [[Worldbuilding/Pre-Elysium/Timeline/index|Timeline]], and [[Worldbuilding/Politics/Restrictions on Warfare|Restrictions on Warfare]].