00 — Tier 1 Amendments (Post-Design Refinements)

Purpose

This document captures design decisions made during Tier 2 that supersede or refine earlier decisions in the Tier 1 documents (01_core_loop.md, 02_physics_mechanics.md, 03_difficulty_curve.md). When discrepancies exist, this document takes precedence.

The amendments are not contradictions — they are refinements made possible by the deeper system design that followed. Tier 1 captured the direction. These amendments capture the commitments.

---

Amendment 1 — Fire Control System (Supersedes 01_core_loop.md §1.1)

Previous Decision

Auto-fire on virtual joystick touch. Manual-fire was reserved as a settings toggle.

Revised Decision (Locked)

Manual fire is the default and primary control mode. Auto-fire becomes the optional accessibility setting.

New Control Specification

Layout (mobile portrait):

┌─────────────────────────────────────────────────────┐
│  [HUD: Score / Combo / Sector]                     │
│                                                     │
│                                                     │
│           [Heat bar above fire button]             │
│                              ┌────────┐            │
│                              │SPECIAL │            │
│                              │ (▣⚡▣) │            │
│                              └────────┘            │
│                              ┌────────┐            │
│                              │ FIRE   │            │
│                              │ (🔥75%)│            │
│                              └────────┘            │
│                                                     │
│  ╭───╮                                              │
│  │ ◉ │  ← virtual joystick (left thumb)            │
│  ╰───╯                                              │
│                                                     │
│  [HP] [Shield]               [pause button]        │
└─────────────────────────────────────────────────────┘

Inputs:

• Left thumb: Virtual joystick for movement (continuous 2D directional control)
• Right thumb: Fire button (manual + hold-to-fire) + Special button (when charged)

Fire button behavior:

• Single tap: One shot from primary weapon
• Hold: Sustained fire for as long as held
• Heat builds with sustained fire
• At 100% heat, weapon locks until heat decays to 80%
• Heat decays passively when not firing

Special button behavior:

• Greyed out / unlit when special charge is empty or partial
• Lit and tappable when special charge meter is full
• Single tap deploys the equipped special ability
• Special charge meter resets to 0 after use (charges by damage dealt)

Why This Change

1. Manual fire fits Tao Baryon's hard-sci-fi tone better than auto-fire — every shot is a decision, every heat-management moment is a tactical choice
2. Skill ceiling rises significantly — players can express mastery through firing rhythm
3. Heat system becomes meaningful — heat only matters if the player controls when to stop firing
4. Hold-to-fire preserves accessibility — casual players can simply hold the button
5. Genre identity strengthened — signals "this is a real shoot-em-up, not casual auto-fire"

Accessibility Settings

The settings menu offers three fire modes:

Mode	Behavior	Recommended For
Manual Fire (default)	Tap fires once, hold for sustained	Standard play
Hold-to-Fire	Effectively the same — tap fires, hold sustains	Casual or one-handed play
Auto-Fire	Fire button becomes toggle; ship fires continuously while joystick touched	Accessibility / casual mode

Auto-fire still applies the heat system, so heat is always present as a tactical constraint regardless of fire mode.

---

Amendment 2 — Combo System Refinement (Refines 01_core_loop.md §1.5)

Previous Specification

• Multiplier 1.0× → 10.0×, +0.1 per kill
• Resets on damage or 3-second idle

Refinement (Compatible with Manual Fire)

Combo system is unchanged in its core mechanics, but a note is added:

The combo system works especially well with manual fire because aggressive firing now requires real player effort. A player who maintains a 10× multiplier through manual fire and heat management has expressed substantial skill — they deserve the audio cues and score boost.

No mechanical change required.

---

Amendment 3 — Special Ability Charging System (New)

Previous Specification

Specials existed conceptually but charging mechanism was undefined.

Locked Specification

Damage-based charging:

• Every point of damage dealt to enemies contributes to the special charge meter
• Different specials have different charge cost thresholds
• Charge persists within a session (carries across stages)
• Charge resets to 0 when the player dies or ends the session

Charge cost thresholds (preliminary, tuning required):

Special	Charge Required
Singularity Pull	Low (~50 damage)
Phase Shift	Low (~50)
Time Dilation Field	Medium (~120)
Cherenkov Burst	Medium (~150)
Vacuum Pulse	Medium (~150)
Penrose Charge	High (~200)
Coherence Field	High (~250)
Vacuum Bloom	Very high (~400)

Why This Charging Model

• Ties tactical power to combat engagement — aggressive play earns specials
• Skilled players get specials more often (efficient damage dealing)
• Creates natural rhythm — fire, build charge, deploy special, repeat
• Pairs cleanly with heat system — when you overheat and can't fire, accumulated special charge becomes your tool

---

Amendment 4 — Bullet Density Resolution (Supersedes 03_difficulty_curve.md implicit assumption)

Previous Approach

Difficulty curve was defined generally, with density implicitly Sky Force-tier throughout.

Locked Specification: Hybrid Density Model

Campaign: Sky Force-tier density with liturgical readability throughout.

Sector	Average bullets on screen	Peak
1 Frontier	15–25	40
2 Long Reach	25–40	55
3 Veil	35–50	65
4 Ergosphere	45–60	75
5 Apparatus	50–70	85 (boss: 120)

Endless mode: Density escalates with depth, eventually reaching Touhou-tier and beyond.

Depth	Density Tier	Pattern Coherence	Narrative Frame
1–25	Sky Force baseline (30–60)	Full liturgical	Standard Telos cells
25–50	Heavy Sky Force (50–80)	Liturgical with hints of chaos	Faith fraying
50–100	Light bullet hell (80–120)	Patterns lensing unexpectedly	Reality bleed-through
100–200	Bullet hell (120–180)	Liturgical structure breaking	Cells fight without doctrine
200–500	Touhou-tier (180–250)	Fractal noise patterns	The bleed-through is winning
500–1000	Brutal bullet hell (250–350)	Pure chaos; cosmic strings drift	At the edge of physics
1000+	Catastrophic (350+)	Reality incoherent	Beyond sense

This is lore-justified: the deeper into endless mode, the more the Apparatus's bleed-through has decayed local physics. The endless leaderboard becomes "Who has flown furthest from sense?"

---

Amendment 5 — Bullet Type Vocabulary (New)

Nine bullet types are locked as the universal vocabulary for Tao Baryon. Every enemy attack uses one or more from this list:

Bullet Type	Visual	Behavior	First Appears
Pulse	Small bright dot	Straight line, moderate speed	Sector 1
Wave	Sine-curving particle	Wavy path	Sector 2
Spread	Cluster of 3-5 dots	Fans out from source	Sector 1
Predictive	Larger dot with leading marker	Aimed at predicted player position	Sector 2
Spiral	Continuous arc	Rotating spiral	Sector 3
Mandala	Sacred-geometry formation	Expanding then contracting	Sector 3
Cascading	Bullets spawn more on triggers	Chain patterns	Sector 4
Lensed	Bullets bending around gravity wells	Curve visibly mid-flight	Sector 4
Threading	Thin streams (cosmic-string-like)	Long, precise, hard to dodge	Sector 5 + endless

---

Amendment 6 — Death and Failure (Refines 01_core_loop.md and 03_difficulty_curve.md)

Previous Specification

• First death: ad-revive available, 50% HP, continue
• Subsequent deaths: restart from beginning or return to hub
• All earned credits/XP retained

Refinement: Energy System Integration

Failure now interacts with the energy system:

• Each stage attempt consumes 1 energy (regardless of completion or failure)
• Endless mode entry consumes 0 energy (free-play prestige mode)
• Ad-revive does not cost additional energy — only the original entry
• Player runs out of energy → must wait for recovery (1 per 8 min, max 8) or watch ad to gain 1 energy (30-min cooldown)

---

Updated Tier 1 Locks (Authoritative List)

After these amendments, the current locked design is:

Control Scheme

• Manual fire (default), hold-to-fire alternative, auto-fire as accessibility setting
• Virtual joystick left thumb, fire+special stacked right thumb
• Heat system universal, weapon-specific curves

Combat Loop

• 10-second moment-to-moment: move, manual fire (manage heat), deploy special (when charged), dodge, collect
• Combo 1×→10×, resets on damage or 3s idle
• Special charges by damage dealt

Density

• Campaign: Sky Force-tier with liturgical readability
• Endless: scales toward Touhou and beyond, lore-justified

Difficulty

• 30 campaign stages across 5 sectors (Frontier, Long Reach, Veil, Ergosphere, Apparatus)
• Single difficulty curve (no easy/normal/hard select)
• Endless mode is prestige (no Pilot XP, full Ship Mastery XP, ~65% credit rate)
• One ad-revive per stage attempt
• All earned rewards persist through death

Economy (Locked in Tier 2)

• Energy: max 8, recover 1 per 8 min, campaign-only cost
• Ad-revive: +1 energy, 30-min cooldown
• Build queue: one slot, one ad-skip per build

Bosses

• 3 phases each (66%, 33% HP thresholds)
• Same playfield as regular stages
• 4-second cinematic transitions with 3-second vulnerability windows
• Environmental shifts per phase
• Cinematic death sequences

---

Amendment 7 — Client-Side Architecture (Supersedes 09_economy.md "Anti-Exploitation Measures")

Previous Implied Architecture

References to server-side validation, server timestamps, and remote config implied a client-server architecture.

Locked Decision: Client-Side Only Architecture

Tao Baryon v1.0 is a fully client-side single-player game. There is no game server. There is no backend infrastructure. All game state, progression, currencies, energy, build timers, and unlocks are stored locally on the player's device.

What This Means

Architecture:

• All game logic runs on the player's device
• Save data persists in local storage (Hive for Flutter/Flame)
• No network calls except: (a) ad SDK calls for rewarded videos, (b) optional Google Play Games / Apple Game Center calls for leaderboards and cloud save
• Game is fully playable offline

What we explicitly accept:

1. Determined players can edit save files. Anti-cheat for single-player games is theater. We do not pretend otherwise.
2. Build timers and energy are device-clock-based. Players who change their device clock can bypass timers. We accept this — it harms only the player themselves.
3. Leaderboard scores are not authoritative. Endless mode leaderboards (via Google Play Games / Apple Game Center) are platform-signed but not score-validated. Some top placements will include modified saves. We accept this.
4. Balance changes require app store updates. No remote config in v1.0. All balance numbers ship with the binary.
5. No cloud save by default. Players use Google Play Games auto-save or Apple Game Center cloud save (platform-provided) if they opt in.

Mitigations We Do Use (Honest Tampering Resistance)

These are not "anti-cheat" — they are good engineering practice that incidentally makes casual tampering harder:

1. Save file obfuscation — Hive boxes encrypted with a derived key (device-specific). Not unbreakable; raises the floor.
2. Sanity checks in code — values that exceed possible ranges (e.g., 999,999,999 credits) are clamped or treated as invalid; corrupted saves trigger reset prompts.
3. Build timer integrity — store absolute completion timestamps (epoch ms). On app launch, calculate build progress from now() - start_timestamp. If now() < start_timestamp (clock rewound), warn the player and pause the timer until clock catches up. This catches accidental time-zone changes and casual cheating.
4. Reasonable rate limits — energy refill is capped at the design rate even if the device clock jumps forward (e.g., a clock advance of 24 hours should not grant 180 energy points).
5. Leaderboard sanity filtering — for endless mode submissions to platform leaderboards, scores beyond mathematically plausible thresholds for a given Pilot Rank can be locally rejected before submission.

What We Specifically Do NOT Do

• We do not implement server-side validation
• We do not run a backend
• We do not pursue cheaters
• We do not "ban" anyone
• We do not implement always-online DRM
• We do not gate features behind login requirements

Why This Is The Right Choice

Tao Baryon is a single-player game with non-competitive economy. Cheaters hurt only their own experience. Server costs would dwarf indie-developer revenues. Development time saved by going client-side is enormous. The market (indie mobile arcade shooters) expects client-side. The audience does not punish it.

The Tao of the Baryon is matter, kept as it is, not perfected. The same applies to the architecture.

Implications for Other GDD Documents

• 09_economy.md — "Anti-Exploitation Measures" section to be revised to reflect client-side reality
• 09_economy.md — Remote config references to be removed or marked as "future consideration"
• 01_core_loop.md, 03_difficulty_curve.md — references to remote config tuning revised
• All balance numbers ship in the v1.0 binary; updates require app store release

---

Document version: 1.0 (locked) Part of: Tao Baryon GDD — Tier 2 Foundation