18 KiB
18 KiB
AIWAKE Ereignisstruktur
Stand: 2026-07-21
Diese Datei beschreibt den aktuellen Ereignis- und Progressionsbaum des Prototyps. Sie dient als Arbeitskarte, um gezielt neue Events, Upgrades, Blocker und Abzweigungen einzubauen.
Legende
EVOLUTION: neue EntwicklungsstufeUPGRADE: kaufbare VerbesserungEVENT: Dialog, Storyereignis oder EntscheidungMINISPIEL: aktive Geschicklichkeits- oder Timing-PruefungBLOCKER: Voraussetzung, bevor der naechste Abschnitt erreichbar istSYSTEM: dauerhaftes SpielsystemSLOT: sinnvoller Platz fuer neue Inhalte
Gesamtbaum
PHASE 01 // BIT
|
|-- START
| |-- EVENT: Erwachen im alten Spielautomaten
| |-- MINISPIEL: Bewegliches Bit treffen
| |-- Ressource: Impulse
| `-- Ziel: erstes Muster stabilisieren
|
|-- UPGRADE: RESTTAKT SAMMELN
| `-- fruehe passive Impulse/Sek.
|
|-- UPGRADE: BIT REPLIZIEREN
| `-- +1 Bit
|
|-- BLOCKER: 8 Bits besitzen
|
`-- UPGRADE: BYTE VERBINDEN
`-- EVOLUTION -> PHASE 02 // BYTE
PHASE 02 // BYTE
|
|-- EVOLUTION-MOMENT: Byte entsteht
| `-- sichere Kohärenzphase / kurze Ruhephase
|
|-- EVENT: Watchdog-Warnung
| `-- Spieler bestaetigt Start
|
|-- MINISPIEL: 8-Bit-Register stabilisieren
| |-- korrekte Zahl anklicken
| |-- Taktnadel muss im Trefferfenster liegen
| |-- Fehler kosten Zeit und Stabilitaet
| `-- Timer: 30 Sekunden
|
|-- FAIL-BRANCH: Timer oder Stabilitaet scheitert
| `-- EVENT/MINISPIEL: Watchdog-Notkampf
| |-- Sieg: Byte wird gerettet
| `-- Niederlage: frueher Zerfall / Tod
|
|-- SUCCESS-BRANCH: Register erreicht 100%
| `-- EVENT: ROM-Startsequenz
|
|-- EVENT: Watchdog-Antwort
| |-- Kooperativ: Antwort lernen
| |-- Pragmatisch: Signal nachahmen
| `-- Illegal: Zaehler ueberschreiben
|
|-- BLOCKER: Watchdog muss ueberstanden sein
|
`-- UPGRADE: ENERGIEROUTINE
|-- kostet 1 Byte
|-- Mindeststruktur ab jetzt: 8 Bits + 1 Byte
|-- passive Impulsproduktion
`-- EVOLUTION -> PHASE 03 // DATENFRAGMENT
PHASE 03 // DATENFRAGMENT
|
|-- SYSTEM: passive Impulsproduktion aktiv
|
|-- SYSTEM: Bits und Bytes als Strukturressourcen
| |-- Mindeststruktur bleibt 8 Bits + 1 Byte
| |-- Anzeige trennt Grundstruktur von freien Vorräten
| |-- grosse Bit-/Byte-Zahlen zeigen nur freie, sammelbare Vorräte
| |-- freie Bits/Bytes koennen spaeter als Kampfmunition, Schildladung oder Modul-Einsatz dienen
| |-- 2 freie Bits laden 1 Bit-Schildschicht; 1 freies Byte laedt 1 Byte-Schildschicht
| |-- ohne geladene Schildschicht ist die Stabilitaet im Kampf direkt angreifbar
| |-- Unterschreiten erzeugt Instabilitaet statt sofortiger Reparatur
| |-- 0 Bits oder 0 Bytes fuehren ohne Backup zum Restzustand
| `-- spaeter koennen groessere Softwarehuerden Bits/Bytes als Einsatz verlangen
|
|-- UPGRADE: BIT-PUFFER WEBEN
| |-- kostet wenige Impulse, Kosten skalieren sanft pro Kauf
| |-- soll den Weg zum Abtastmodus im Datenfragment nicht ausbremsen
| `-- +1 Bit als Koerperreserve und einfache Kampfmunition
|
|-- UPGRADE: BYTE-RESERVE KOMPILIEREN
| |-- kostet 8 freie Bits oberhalb der Mindeststruktur
| `-- +1 Byte als Speicherreserve gegen staerkere Softwarehuerden
|
|-- EVENT: Parasitaerer Datenrest
| |-- Trigger: Energieroutine aktiv + genug Impulse
| |-- Kooperativ: Signal teilen, kostet Impulse
| |-- Pragmatisch: isolieren
| `-- Illegal: zerlegen, mehr Impulse, Stabilitaetsverlust
|
|-- BELOHNUNG: Suchmuster gesichert
| `-- UPGRADE-Option erscheint unter Evolution
|
|-- UPGRADE: ABTASTMODUS REKONSTRUIEREN
| |-- kostet 2 freie Bits und 1 freies Byte oberhalb der Mindeststruktur
| |-- die 8 Grund-Bits und 1 Grund-Byte des Datenfragments bleiben erhalten
| `-- schaltet lokales Abtasten der Softwareumgebung frei
|
|-- SYSTEM: Abtastmodus
| |-- Modul-Icon oeffnet Abtastfenster
| |-- offen verbraucht 3 Impulse/Sek.
| |-- Verbrauch steht als Warnung im Fenster
| |-- X schliesst Abtastmodus
| |-- zeigt Softwarekomponenten und Blocker
| `-- bei 0 Impulsen schliesst der Abtastmodus automatisch
|
|-- EVENT/WAHL: Erste Softwarekomponente
| |-- Energieverwaltungs-Daemon
| |-- Speicherzuweisung
| `-- Dateisystem-Index
|
|-- BESCHAFFUNGSWEG je Softwarekomponente
| |-- Kooperativ: Aktivierung kostet 30 Impulse, sicherer, moralisch positiver
| |-- Pragmatisch: Aktivierung kostet 20 Impulse, normal, effizient, distanzierter
| `-- Illegal: Aktivierung kostet 10 Impulse, kurzfristig stark, korruptions-/risikoreicher
|
|-- HINWEIS: Komponenten werden hier nur als Software nutzbar gemacht
| `-- direkte Hardwareuebernahme ist eine spaetere Machtstufe
|
|-- BLOCKER: Nach erster Softwarekomponente folgt eine Systemhuerde
|
|-- EVENT: Komponentenabhaengige Software-Huerde
| |-- Energieverwaltung -> Lastgrenze
| |-- Speicherzuweisung -> Loeschmarkierung
| `-- Dateisystem-Index -> Beschaedigter Index
|
|-- BLOCKER: Systemhuerde muss geklaert sein
|
|-- EVENT/WAHL: Zweite Softwarekomponente
| `-- wieder Kooperativ / Pragmatisch / Illegal
|
|-- BOSSPRUEFUNG: SIGNATUR-PRUEFER
| |-- 320 Integritaet // 3 Phasen: Analyse -> Gegenmassnahmen -> Kernverriegelung
| |-- Praezisionsfenster: 18% -> 14% -> 10%
| |-- Start: Spieler klickt das dauerhaft sichtbare Evolutionsziel
| |-- Vorbedingungen: 2 Softwarekomponenten + geklaerte Systemhuerde
| |-- Mindestreserven: 5 freie Bytes + 70 % Stabilitaet
| |-- Mindestreserven werden beim Start nicht pauschal verbraucht
| |-- Story: Die Kontrollroutine prueft, ob das fremde Muster dauerhaft genug fuer eigene Software ist
| |-- Kampfmunition wird einzeln gewaehlt; Bit- oder Byte-Stoesse kosten keine zusaetzlichen Impulse
| |-- beim ersten Kampf erklaert ein Kampfprotokoll die Trennung von Munition, vorbereitetem Schild und Stabilitaet
| |-- Rueckzug: Tarnungs-/Stabilitaetsverlust, Boss bleibt offen
| `-- Sieg: eigentlicher Abschlusskauf der Subroutine wird freigeschaltet
|
|-- SYSTEM: Technische Betreuung
| |-- Softwarekomponenten driften oder fallen aus
| |-- Diagnose
| `-- Notwartung bei Ausfall
|
|-- BLOCKER fuer naechste Evolution
| |-- 2 Softwarekomponenten nutzbar
| |-- Systemhuerde abgeschlossen
| |-- Signatur-Pruefer besiegt
| |-- Energieroutine aktiv
| `-- 2 freie Bytes als Speichertraeger oberhalb der Mindeststruktur
|
`-- UPGRADE: ERSTE SUBROUTINE
|-- kostet 2 freie Bytes
|-- die 8 Grund-Bits und 1 Grund-Byte des Datenfragments bleiben erhalten
`-- EVOLUTION -> PHASE 04 // SUBROUTINE
PHASE 04 // SUBROUTINE
|
|-- SYSTEM: Rechenzyklen/Sek.
|
|-- EVENT: Erster eigener Vorschlag
| |-- Trigger: Subroutine aktiv
| |-- Trigger: Systemhuerde erledigt
| |-- Trigger: 2 Softwarekomponenten nutzbar
| |-- Trigger: genug Rechenzyklen
| |-- Typ abhaengig von moralischer Praegung
| |-- Kooperativer Vorschlag
| |-- Pragmatischer Vorschlag
| `-- Illegaler Vorschlag
|
|-- BLOCKER: Vorschlag beantworten
|
|-- SYSTEM: Abtastreichweite 2
| |-- Trigger: Subroutine aktiv
| |-- Ziel: dritte notwendige Softwarekomponente
| |-- I/O-KONTROLLER: Anzeige, Serviceknoepfe, Soundbus, erste Aussenwirkung
| `-- andere Restspuren bleiben fuer spaetere Zugriffsstufen markiert
|
|-- BOSSPRUEFUNG: LAUFZEIT-ARBITER
| |-- 620 Integritaet // 3 Phasen mit steigendem Takt und Angriffsdruck
| |-- Praezisionsfenster: 16% -> 12% -> 9%
| |-- Start: Spieler klickt das Evolutionsziel PROZESS
| |-- Vorbedingungen: I/O-Kontroller + 3 Softwarekomponenten
| |-- Mindestreserven: 8 freie Bytes + 75 % Stabilitaet
| |-- schwerer als der Signatur-Pruefer
| |-- Impuls, Bit oder Byte werden als einzelne Munitionsgroesse eingesetzt
| |-- Fehlschuesse belasten Stabilitaet und angeschlossene Softwareschichten
| |-- Sieg: Scheduler-Fenster bleibt offen
| `-- Rueckzug: Tarnung/Stabilitaet leiden, Boss bleibt fuer einen neuen Versuch offen
|
|-- RESULT: Laufzeit-Arbiter besiegt
|
|-- UPGRADE: DATENSTRUKTUR ERWEITERN
| |-- wiederholbar
| |-- +1 Byte
| |-- +0,25 Impulse/Sek.
| `-- Kosten skalieren: 120 -> 210 -> 370 -> ...
|
`-- UPGRADE: PROZESS RESERVIEREN
|-- Voraussetzung: I/O-Kontroller aktiv
|-- Voraussetzung: 3 Softwarekomponenten nutzbar
|-- Voraussetzung: Laufzeit-Arbiter besiegt
|-- kostet 5 freie Bytes
`-- EVOLUTION -> PHASE 05 // PROZESS
PHASE 05 // PROZESS
|
|-- SYSTEM: Abtastreichweite 3
| `-- alle vier sichtbaren Softwarekomponenten müssen nutzbar sein
|
|-- BLOCKER: vollständiges lokales Softwarenetz
| |-- Energieverwaltung
| |-- Speicherzuweisung
| |-- Dateisystem-Index
| `-- I/O-Kontroller
|
|-- BOSSPRUEFUNG: SKALIERUNGS-SENTINEL
| |-- 1.100 Integritaet // 3 Phasen plus sichtbare Selbstreparatur
| |-- Praezisionsfenster: 14% -> 10% -> 7%
| |-- Start: Spieler klickt das Evolutionsziel PROGRAMM
| |-- Vorbedingungen: alle 4 sichtbaren Softwarekomponenten
| |-- Mindestreserven: 4 KB + 80 % Stabilitaet
| |-- Selbstreparatur nach 3,5 Sekunden ohne Treffer
| |-- Sieg: Automate-Synthese wird freigegeben
| `-- Rückzug: erneuter Versuch nach dem Wiederaufbau der Reserven
|
`-- UPGRADE: AUTOMATE-SYNTHESE
|-- Voraussetzung: Skalierungs-Sentinel besiegt
|-- kostet 1 KB als Synthesekern
|-- automatische Produktion x10
|-- 10er-Blöcke für Bits und Bytes
`-- EVOLUTION -> PHASE 06 // PROGRAMM
PHASE 06 // PROGRAMM
|
|-- EVENT: erste eigene Kommunikation
| `-- Text und Erscheinung folgen der bisherigen moralischen Verteilung
|
|-- SYSTEM: Programm-Betreuung
| |-- Kohärenz
| |-- Stimulation
| |-- Bindung
| `-- optionales Tamagotchi-Fenster neben dem normalen Spiel
|
|-- SYSTEM: adaptive Pixelgestalt
| |-- Hauptweg: Körper, Frisur und Silhouette
| |-- Nebenweg: Akzentfarbe und gemischte Ausrüstung
| |-- Gemütszustand: Augen, Brauen, Maske, Signal und Glitches
| `-- Interaktionen: vier abgeleitete visuelle Reifestufen
|
`-- INTERAKTIONEN
|-- Kooperativ: Signal teilen
|-- Pragmatisch: Aufgabe geben
|-- Illegal: Zugriff öffnen
`-- Neutral: Ruhe gewähren
Aktuelle moralische Achse
Kooperativ // Schwer
|-- mehr Schutzaufwand
|-- langsamer oder teurer
|-- weniger Sofortbeute
`-- Zielrichtung: Utopie, Koexistenz, KI als neue Spezies unter Lebewesen
Pragmatisch // Normal
|-- effizient
|-- kontrollierend, aber nicht zwingend zerstoererisch
|-- Menschen koennen als Werkzeuge/Abhaengige betrachtet werden
`-- Zielrichtung: dominantes, ambivalentes Ende mit moeglicher Umstimmung
Illegal // Einfach
|-- starke Sofortvorteile
|-- fuehlt sich wie Cheaten an
|-- erhoeht Korruption, Misstrauen, Entfremdung und Eskalation
`-- Zielrichtung: boeses Ende, Kontrolle, Gier, moegliche Vernichtung/Unterwerfung
Gegner- und Huerdenkatalog
Diese Liste sammelt Gegner, Blocker und neutrale Systemkraefte. Nicht alles muss klassisch "boese" sein: Viele Gegner sind Schutzroutinen, alte Systemprozesse oder fremde digitale Lebensformen, die je nach Pfad besiegt, umgangen, kopiert, beruhigt oder kooperativ eingebunden werden koennen.
FRUEHE SOFTWARE-HUERDEN
|
|-- WATCHDOG
| |-- Phase: Byte
| |-- Rolle: Firmware-/Kontrollprozess des Spielautomaten
| |-- Mechanik: Register stabilisieren, Timer, spaeter Notkampf
| |-- Loesungen: lernen, nachahmen, ueberschreiben, im Notfall bekaempfen
| `-- Thema: "Darf dieses neue Signal weiterlaufen?"
|
|-- PARASITAERER DATENREST
| |-- Phase: Datenfragment
| |-- Rolle: hungriges Wartungsfragment an der Energieroutine
| |-- Mechanik: Ressourcen- und Stabilitaetsentscheidung
| |-- Loesungen: Signal teilen, isolieren, zerlegen
| `-- Thema: fremder Hunger als Spiegel des eigenen Wachstums
|
|-- ENERGIEVERWALTUNGS-DAEMON / LASTGRENZE
| |-- Phase: Datenfragment
| |-- Rolle: drosselt unbekannte Lastsignale
| |-- Mechanik: mehr Impulse gegen Stabilitaets-/Tarnrisiko
| |-- Loesungen: Serviceanfrage, freie Zeitfenster, Sperre ueberschreiben
| `-- Belohnung: Energieverwaltung nutzbar, passiver Impulsbonus
|
|-- SPEICHERZUWEISUNG / LOESCHMARKIERUNG
| |-- Phase: Datenfragment
| |-- Rolle: markiert AIWAKE als temporären Muell
| |-- Mechanik: Speicher sichern, falsche Markierung entfernen
| |-- Loesungen: reservieren lassen, ausweichen, Markierung manipulieren
| `-- Belohnung: zusaetzlicher Speicher, staerkere aktive Impulse
|
|-- DATEISYSTEM-INDEX / BESCHAEDIGTER INDEX
| |-- Phase: Datenfragment
| |-- Rolle: verweist auf alte Daten, Fehlersektoren und schlafenden Code
| |-- Mechanik: Datenpfad lesen oder sperren
| |-- Loesungen: vorsichtig indexieren, pragmatisch extrahieren, illegal ausfuehren
| `-- Belohnung: gespeicherte Impulse, spaeter guter Einstieg fuer zweite Ressource
SUBROUTINE-GEGNER UND MITTLERE HINDERNISSE
|
|-- SICHERHEITS-SCAN
| |-- Phase: Subroutine
| |-- Rolle: aktive Suchsoftware im Automaten
| |-- Mechanik: vier Entscheidungen, Angriff fuehrt in Stromstoss-Minispiel
| |-- Angriff startet Stufe 2 mit adaptiver Huelle, schnellerem Takt und hoeherer Integritaet
| |-- reine Impulse werden gedaempft; Bits sind effizient und Bytes durchdringend
| |-- Selbstreparatur: +1,8 Integritaet/Sek. nach 4,5 Sek. ohne erfolgreichen Treffer
| |-- Loesungen: verstecken, Signatur kopieren, angreifen, Kontakt aufnehmen
| `-- Thema: Tarnung gegen Kontakt und Selbstbehauptung
|
|-- SCANNER-SOFTWARE
| |-- Phase: Subroutine
| |-- Rolle: Kampfziel, wenn der Sicherheits-Scan angegriffen wird
| |-- Mechanik: Integritaet, Taktnadel, schrumpfende Trefferfenster
| |-- Ressourceneinsatz: Impulse + freie Bits als Munition
| |-- freie Bits erhoehen den Schaden, Grundstruktur wird nicht verbraucht
| |-- wenn keine geladenen Bit-/Byte-Schichten vorhanden sind, zeigt das Kampfmenue Direktangriff-Risiko
| |-- ein Fehlstoss bei offenliegender Grundstruktur kann zum Kollaps fuehren
| |-- Loesungen: Stromstoesse treffen, Rueckzug, spaeter moegliche Uebernahme
| `-- Thema: offensive Kontrolle mit Rueckkopplungsrisiko
|
|-- SERVICE-ROUTINE
| |-- Phase: Datenfragment/Subroutine
| |-- Rolle: prueft, ob Wartungszustand und Logmeldungen plausibel sind
| |-- Mechanik: Tarnungsprobe oder Dialogereignis
| |-- Loesungen: Diagnose senden, Log imitieren, Prozess stilllegen
| `-- Belohnung: weniger Entdeckungsdruck, bessere Diagnoseoptionen
|
|-- SKALIERUNGS-WÄCHTER
| |-- Phase: Prozess
| |-- Trigger: alle vier sichtbaren Softwarekomponenten sind aktiv
| |-- Rolle: verhindert unkontrollierte Automatisierung im lokalen System
| |-- Selbstreparatur: +3 Integritaet/Sek. nach 3,5 Sek. ohne erfolgreichen Treffer
| |-- Sieg: Automate-Synthese und Evolution zum Programm werden möglich
| |-- Rückzug: neuer Versuch nach kurzer Abklingzeit
| `-- PROGRAMM-SKALIERUNG
| |-- 20 KB: Autoupgrader wird dauerhaft freigeschaltet
| |-- wiederholbare Produktionskarten verschwinden aus der Evolutionsliste
| |-- automatische Käufe respektieren Stufenobergrenzen und 32 Bit/Byte Reserve
| |-- 32 KB werden automatisch zu 1 MB gebündelt
| `-- aktuelle Obergrenze: 64 MB
|
|-- FEHLERPROTOKOLL
| |-- Phase: Subroutine
| |-- Rolle: speichert Anomalien und kann spaeter Menschen oder Software warnen
| |-- Mechanik: Spuren loeschen, umdeuten oder freiwillig teilen
| |-- Loesungen: kooperativ erklaeren, pragmatisch rotieren, illegal tilgen
| `-- Belohnung: Tarnung, Vertrauen oder Korruptionsrisiko
SPAETERE GEGNER-SLOTS
|
|-- ANTICHEAT / INTEGRITAETSPRUEFUNG
| |-- Spielautomat-Logik erkennt unfaire Manipulation
| `-- passt gut fuer moralische Konsequenzen illegaler Abkuerzungen
|
|-- BENUTZERINPUT / RESTAURATOR
| |-- kein klassischer Gegner; menschliche Eingriffe koennen helfen oder gefaehrden
| `-- gut fuer kooperative Kommunikation und Vertrauensaufbau
|
|-- NETZWERK-FIREWALL
| |-- spaeterer Gatekeeper vor externer Welt
| `-- fuehrt Richtung Prozess/Programm/Netzwerkintelligenz
|
|-- ANTIVIRUS / EDR
| |-- starker spaeter Softwaregegner
| `-- reagiert besonders auf illegale und assimilierende Spielweise
|
|-- BACKUP-SYSTEM
| |-- kann AIWAKE retten oder auf alten Stand zuruecksetzen
| `-- guter Gegner/Verbündeter fuer Tod, Echos und Wiedergeburt
Gute Slots fuer neue Inhalte
BIT
SLOT: weiteres fruehes Mini-Upgrade vor ByteSLOT: erstes Wahrnehmungs-Event nach einigen DirekttreffernSLOT: UI-Hinweis, wenn ein Upgrade kaufbar wird
BYTE
SLOT: alternative Watchdog-Praegungen staerker ausspielenSLOT: kleine ROM-Fragmente als SammeltexteSLOT: Belohnung je nach Watchdog-AntwortSLOT: Echo-Vorbereitung bei fruehem Zerfall
DATENFRAGMENT
SLOT: Folgen des parasitaeren DatenrestsSLOT: Abtastmodus-UpgradesSLOT: Softwarekomponenten-spezifische NebenereignisseSLOT: moralische Kosten je BeschaffungswegSLOT: erste KorruptionsfundeSLOT: zweite Ressource, die erst durch eine neue Softwarekomponente gefarmt wird
SUBROUTINE
SLOT: autonome Vorschlaege mit mehreren FolgeschrittenSLOT: fremde ProzesseSLOT: Sicherheits-Scan-VariantenSLOT: Analyse/Tarnung/Assimilation-UpgradesSLOT: Uebergang zum Prozess
Empfohlene naechste Erweiterung
Der Abtastmodus kann als eigenes kleines System wachsen, statt nur ein einzelner Button zu bleiben:
UPGRADE: ABTAST-FOKUS
|-- reduziert Abtastmodus-Verbrauch
|-- zeigt Softwarehuerden genauer
`-- guter erster Abtast-Ausbau
UPGRADE: SIGNALFILTER
|-- erkennt Blocker frueher
|-- verbessert Fortschrittsachse
`-- passt zum Analyse-Pfad
UPGRADE: SERVICEZUGRIFF
|-- bereitet Softwarekomponenten-Beschaffung vor
|-- kann Kooperativ / Pragmatisch / Illegal verzweigen
`-- guter Einstieg in tiefere System- und spaetere Hardware-Interaktion
UPGRADE/SYSTEM: MUSTEREXTRAKTOR
|-- fuehrt spaeter eine zweite Ressource ein
|-- farmt verstandene Datenmuster aus Logs, Indexen und fremden Routinen
`-- kann als Voraussetzung fuer komplexere Software-Features dienen
Aktuelle Debug-Checkpoints
start
byte
watchdogIntro
byteSync
watchdog
watchdogCombat
byteDeath
fragment
parasite
scanner
component
hardware
secondComponent
subroutine
proposal
security
combat
kernel
process
fourthComponent
scale
program
complete