Aetheria release: target and map for the release campaign

The target defines what the release is, the invariants, what is out of
scope, the four strands (feedback, audio, content pipeline, faction play),
the sequencing, and how this campaign avoids the Codex lanes in flight. The
map records the body facts behind the first feedback and audio cuts, the
model page, and the rationale for the recommended audio route.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Meta Vens 2026-10-03 13:19:02 +02:00
commit 9c7a2f8254
2 changed files with 410 additions and 0 deletions

View file

@ -0,0 +1,194 @@
# Aetheria Release Target
Date: 2026-10-03
Status: target. This document owns the ends. The typed `target` in the Eureka mind
(campaign `aetheria-release`) owns the labelled invariants and the not-in-scope list;
this file gives their reasons. Cut specs, questions and rulings are typed documents in
the mind and are not restated here. Body facts, the model page and the rationale for
the cut order are in `docs/aetheria-release-map.md`.
## Why
The game has enough systems to ship: fire control, stats and power, heat, item
provenance, locomotion, and the mining and scenario lanes in flight. What keeps it
unreleasable is presentation and breadth. It plays no sound at all. A hit on a hull
shows nothing where it lands, and the camera never reacts. Three hulls on two models
and one station are all a player can fly or dock at.
## Operator direction (2026-10-02 and 2026-10-03)
- "we already have plenty of game here, especially once we merge everything in flight
(and maybe another campaign or two geared at making the world feel more alive). The
only thing making it unreleasable to me is the lack of polish, content and feedback.
We need audio, we need ships, stations and gear for the player to covet and collect,
and we need our mechanics to be visible and visceral."
- "If we get the moddable ships pipeline usable and a Tripo3D subscription I can pump
one of these out every day, game ready." The pipeline is GPT Image 2.5, then
Tripo3D, then minor cleanup.
- "I don't think Asura is the way to go for content."
- The announcement bar (2026-10-02): a wider selection of ships and gear, a UX polish
pass, and audio feedback throughout.
## What "release" means
The release is the public announcement to players and Patreon, with a build they
can download. It is done when every line below holds on one build made from
`master`, and the operator has played that build and called it. The operator's call
is part of the definition: a ticked list without it is not a release.
1. **The lanes in flight have landed.** `codex/mining`, `codex/scenarios` and
`codex/moddable-ships` are merged into `master` or explicitly parked by the
operator. A release does not ship around half-merged work.
2. **Every player action that changes the world makes a sound.** That covers weapon
fire and charging, impacts on shield and hull, ship destruction, docking and
undocking, the wormhole, thrusters and the drive, inventory and trade actions, menu
clicks, the overheat alarm, and music in the menu, overworld and combat. The
player can set master, music, effects and interface volume, and the settings
persist.
3. **Every hit is seen where it lands and felt by the one who takes it.** An impact
on a shield shows on the shield at the side it came from. An impact on a hull
shows at the struck point. A hit on the player's own ship moves the camera in
proportion to the damage. The player can turn shake down to zero, and the hit is
still shown.
4. **Damage, heat and exposure are visible before they are fatal.** Lost armour,
a destroyed item and a critical hull each look different on the ship and in the
HUD. Overheat and hull-critical warnings use two channels, sound plus a visual,
and the more urgent one wins. The player can see how visible they are, how close
that is to being detected, and the largest source of it.
5. **There is enough to covet.** The content quota is set by the operator's ruling
on question `release-content-bar`. Every hull and station in the quota is
flyable or dockable and enters through the moddable-ships package path. Rarity
tiers show their colours, and every weapon type sounds and looks distinct.
6. **A new player can play for thirty minutes on the Windows build without hitting
a blocking defect.** The build is published through the build-delivery path.
## Ends
- **The simulation states what happened, and presentation shows it.** Fire control,
shields, damage, heat and detection publish typed facts. Visual and audio
presenters subscribe to them, derive a cue from each, and render it. They decide
no rule and recompute no geometry.
- **One cue, two channels.** Each fact becomes a cue in one engine-free function.
The visual and the audio presenter render that same cue, so the two channels
cannot disagree about what happened or how hard.
- **New content is data.** A new hull, station or piece of gear arrives as a catalog
record or a mod package. Nobody hand-wires a prefab array. The operator's daily
ship goes through the image model, Tripo, cleanup and the Blender add-on, and
comes out as a `ShipAuthoring` package with its GLB.
- **The player controls intensity without losing the signal.** Shake, flashes,
particle density and each audio channel have settings. Turning any of them down
never removes the tactical information it carried.
## Invariants that must survive
The typed target carries these as labelled statements. The reasons:
- **Legacy first** (operator, 2026-09-11). All work lands in the restored Unity tree.
There is no daemon, CultMesh or Eve re-architecture here. Shared infrastructure
is adopted, not invented.
- **The simulation owns the facts.** Fire control was rebuilt (Cuts 3 to 12.4(b)) so
that no Unity collider or effect decides a hit. Feedback must not reopen that
path. It reads `FireControl`'s facts and never re-derives them.
- **The simulation names no sound.** Today the simulation calls `FireAudioEvent`
with Wwise ids, against a sound bank that is never assigned. Audio becomes a
presenter of the same semantic events that visual effects use (`OnFire`,
`OnStartCharging`, impacts and deaths).
- **State is CultCache.** Player preferences such as shake and volumes go in the
player store (`PlayerSettings`), and authored data goes in the catalog. Engine
asset references are Addressables GUIDs (ruling of 2026-09-17). Presentation
tuning stays on its Unity component (fork M (a) of `docs/settings-globals-cut.md`).
- **Instruments bound what is shown** (`Visual and Sensory Direction`). A cue
never shows the player more than their sensors know.
- **The lanes are respected.** This campaign never commits to a `codex/*` branch or
to the operator's checkout. It branches from `origin/master` and rebases after
each lane merges.
- **Rules are tested headless.** Every rule decided in `ServerShared` has a
behavioural test in `tests/Aetheria.Shared.Tests`. A presentation-only behaviour
is an operator check, reachable through ordinary play or a scenario.
- **The operator judges whether the bar is met.**
## Not in scope
- Asura and procedural planet content. The operator ruled it out for content.
- New mechanics. Contact tiers beyond the current threshold, fused tracks, thermal
capture, probes and new weapon classes are not added here. This campaign makes
the existing mechanics visible.
- Faction mechanics beyond what `Faction Play.md` and its rulings name.
- "World feels alive" work such as ambient traffic and events. The operator named
it as a possible separate campaign.
- Build publishing machinery. `docs/build-delivery-target.md` owns it. This
campaign needs it done before release, but does not build it.
- Platforms other than Windows 64-bit, multiplayer, narrative and Ink work.
- Finishing other lanes' cuts: mining, scenarios, moddable-ships S2 and S5, thermal
balance, and the settings-globals tier-colour fix. This campaign depends on them
and does not do them.
## Strands
- **Feedback.** Impacts, damage states, warnings and detection, made visible and
felt. The first cut is mapped (`feedback-1`). It gives impacts a world point and a
layer, then shows them on the shield or hull and in the camera.
- **Audio.** The route is open as question `audio-route`. The first cut is mapped
for the recommended route (`audio-1`) and is blocked until the ruling. Its sketched
sequel covers interface, inventory, trade, docking and wormhole sounds, then
music, then continuous loops (thrusters, reactor, drive) and the overheat alarm,
then AquaSynth renders for whatever the 2021 library lacks.
- **Content pipeline.** This strand is a sketch until `codex/moddable-ships` merges.
1. The Blender add-on gains a collection-to-package action. It places anchors
with `aetheria.id` extras for weapon, radiator and thruster mounts, the collider,
map icon, shield and tractor, then exports the GLB with the `ship.cc`. This is
proof gate 2 of `docs/moddable-ship-authoring.md`.
2. Moddable-ships S3. The first playable mod ship is a Tripo mesh of a concept
whose image already worked (the Headliner or the Quiet Sense), taken through
the whole path.
3. Repeatability. A convex collider from the render mesh, and one material-slot
convention that leaves room for a later livery slot.
4. Throughput. One hull a day from the operator, plus stations, then gear.
- **Faction Play.** The design is `Game Design/Faction Play.md` in AetheriaLore,
at `5c45e27` plus `f3e0e6d`. It covers behaviour, relations, loadouts, resources,
visuals and hooks. On 2026-10-03 the operator accepted every proposal in it, and
the acceptance is recorded as three rulings:
- `faction-relations-field`: relations are their own authored field, not derived
from allegiance;
- `faction-lore-changes`: the five lore changes;
- `lucent-duel-bait`: Lucent's need for glory lets the player bait it into a
duel.
The strand's first cut, when mapped, is the note's smallest proof: Zhestokost,
Lucent and AU in one run, with implementation steps 1 to 3. Those steps are
`Personality`-driven engagement range and fire discipline, the four shared agent
states, and hail barks. The feedback and content strands leave room for faction
colour and livery, and decide nothing about them.
## Sequencing
Self proposed feedback, then audio, then content. Feedback goes first because it is
the cheapest per unit of perceived quality and it makes later content read. This
target keeps that order for agent-paced work, with one change: **content is the
calendar-critical path, so its unblocking runs in parallel rather than last.** The
quota is met one hull a day of operator time, and that clock cannot start until a
mesh flies. The steps that start it cost the agents little:
- the operator's owed S2 play checks on `codex/moddable-ships`;
- the merge;
- the add-on's package action.
Agent order: `feedback-1`. Then `audio-1`, once `audio-route` is ruled; it consumes
`feedback-1`'s impact cue. Then the content strand's add-on action as soon as
moddable-ships merges. After that, the remaining feedback and audio cuts alternate.
## Lanes and collisions
| Lane | Owner | This campaign |
|---|---|---|
| `codex/fire-control-12` (operator checkout, modified `.blend`) | Codex / operator | Never touched. Reads use `git show` or a scratch worktree. |
| `codex/mining` | Codex | Waits for its merge. `feedback-1` edits `FireControl.Apply`, `ApplyDirectHit` and `Detonate`, which mining does not change (it edits `FireControl.cs:72-100` and `:522-535`). Mining Cut 4 (shots at chunks) should publish impacts through the same contract (follow-up). |
| `codex/scenarios` | Codex, blocked on a fix batch | Waits. Operator checks in this campaign are reachable through ordinary play. Where one is not, it waits for scenarios Cut 4. |
| `codex/moddable-ships` | Codex, S2 owing operator checks | Waits for the merge. Ownership of anchor authoring and S3 after the merge is question `content-lane-owner`. |
| `eureka/aetheria-release-*` | This campaign | One branch per cut, from `origin/master`, each in its own worktree. |
The hot files are shared with the lanes: `Entity.cs`, `FireControl.cs`,
`ActionGameManager.cs`, `EntityInstance.cs` and `ZoneRenderer.cs`. Each cut keeps
its hunks out of the regions the open lanes change, which are listed per spec. New
behaviour goes in new files wherever an existing owner allows it.