AIWAKE-Prototyp mit Programm-Evolution
This commit is contained in:
nalpush
487
EREIGNISSTRUKTUR.md
Normal file
487
EREIGNISSTRUKTUR.md
Normal file
@@ -0,0 +1,487 @@
|
||||
# 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 Entwicklungsstufe
|
||||
- `UPGRADE`: kaufbare Verbesserung
|
||||
- `EVENT`: Dialog, Storyereignis oder Entscheidung
|
||||
- `MINISPIEL`: aktive Geschicklichkeits- oder Timing-Pruefung
|
||||
- `BLOCKER`: Voraussetzung, bevor der naechste Abschnitt erreichbar ist
|
||||
- `SYSTEM`: dauerhaftes Spielsystem
|
||||
- `SLOT`: sinnvoller Platz fuer neue Inhalte
|
||||
|
||||
## Gesamtbaum
|
||||
|
||||
```text
|
||||
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
|
||||
```
|
||||
|
||||
```text
|
||||
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
|
||||
```
|
||||
|
||||
```text
|
||||
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 oder Modul-Einsatz dienen
|
||||
| |-- ohne freie Bits/Bytes ist die Grundstruktur 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
|
||||
|
|
||||
|-- EVENT/MINISPIEL: Sicherheitssoftware reagiert
|
||||
| |-- Trigger: zweite Softwarekomponente wurde nutzbar gemacht
|
||||
| |-- Story: Das System erkennt, dass zwei lokale Softwareschichten demselben fremden Muster gehorchen
|
||||
| |-- Folge: automatische Abwehrsoftware isoliert den Bereich
|
||||
| |-- Kampf mit Impulsen und freien Bits gegen Scanner-/Sicherheitssoftware
|
||||
| |-- Rueckzug gilt als Verstecken, Sieg gilt als ueberstandener Sicherheits-Scan
|
||||
| `-- nach Abschluss ist der Weg zur ersten Subroutine wieder offen
|
||||
|
|
||||
|-- SYSTEM: Technische Betreuung
|
||||
| |-- Softwarekomponenten driften oder fallen aus
|
||||
| |-- Diagnose
|
||||
| `-- Notwartung bei Ausfall
|
||||
|
|
||||
|-- BLOCKER fuer naechste Evolution
|
||||
| |-- 2 Softwarekomponenten nutzbar
|
||||
| |-- Systemhuerde abgeschlossen
|
||||
| |-- Sicherheitssoftware ueberstanden
|
||||
| |-- Energieroutine aktiv
|
||||
| |-- 1 freies Byte als Speichertraeger oberhalb der Mindeststruktur
|
||||
| `-- genug Impulse
|
||||
|
|
||||
`-- UPGRADE: ERSTE SUBROUTINE
|
||||
|-- kostet Impulse + 1 freies Byte
|
||||
|-- die 8 Grund-Bits und 1 Grund-Byte des Datenfragments bleiben erhalten
|
||||
`-- EVOLUTION -> PHASE 04 // SUBROUTINE
|
||||
```
|
||||
|
||||
```text
|
||||
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
|
||||
|
|
||||
|-- EVENT/MINISPIEL: Kernel-Waechter
|
||||
| |-- Trigger: I/O-Kontroller nutzbar gemacht
|
||||
| |-- schwerer als Sicherheits-Scan
|
||||
| |-- verbraucht Impulse, freie Bits und bei Verfuegbarkeit freie Bytes als starke Kampfmunition
|
||||
| |-- Fehlschuesse belasten Stabilitaet und angeschlossene Softwareschichten
|
||||
| |-- Sieg: Scheduler-Fenster bleibt offen
|
||||
| `-- Rueckzug: falsche Prozessspur, aber Tarnung/Stabilitaet leiden
|
||||
|
|
||||
|-- RESULT: Kernel-Waechter ueberstanden
|
||||
|
|
||||
|-- 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: Kernel-Waechter ueberstanden
|
||||
|-- kostet 150 Impulse + 10 Rechenzyklen + 3 freie Bytes
|
||||
`-- EVOLUTION -> PHASE 05 // PROZESS
|
||||
```
|
||||
|
||||
```text
|
||||
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
|
||||
|
|
||||
|-- EVENT/MINISPIEL: Skalierungs-Wächter
|
||||
| |-- Trigger: vierte sichtbare Softwarekomponente aktiviert
|
||||
| |-- Sieg: Automate-Synthese wird freigegeben
|
||||
| `-- Rückzug: erneuter Versuch nach kurzer Abklingzeit
|
||||
|
|
||||
`-- UPGRADE: AUTOMATE-SYNTHESE
|
||||
|-- Voraussetzung: Skalierungs-Wächter besiegt
|
||||
|-- automatische Produktion x10
|
||||
|-- 10er-Blöcke für Bits und Bytes
|
||||
`-- EVOLUTION -> PHASE 06 // PROGRAMM
|
||||
```
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
```text
|
||||
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.
|
||||
|
||||
```text
|
||||
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
|
||||
```
|
||||
|
||||
```text
|
||||
SUBROUTINE-GEGNER UND MITTLERE HINDERNISSE
|
||||
|
|
||||
|-- SICHERHEITS-SCAN
|
||||
| |-- Phase: Subroutine
|
||||
| |-- Rolle: aktive Suchsoftware im Automaten
|
||||
| |-- Mechanik: vier Entscheidungen, Angriff fuehrt in Stromstoss-Minispiel
|
||||
| |-- 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 freien Bits/Bytes 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
|
||||
| |-- Sieg: Automate-Synthese und Evolution zum Programm werden möglich
|
||||
| `-- Rückzug: neuer Versuch nach kurzer Abklingzeit
|
||||
|
|
||||
|-- 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
|
||||
```
|
||||
|
||||
```text
|
||||
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 Byte
|
||||
- `SLOT`: erstes Wahrnehmungs-Event nach einigen Direkttreffern
|
||||
- `SLOT`: UI-Hinweis, wenn ein Upgrade kaufbar wird
|
||||
|
||||
### BYTE
|
||||
|
||||
- `SLOT`: alternative Watchdog-Praegungen staerker ausspielen
|
||||
- `SLOT`: kleine ROM-Fragmente als Sammeltexte
|
||||
- `SLOT`: Belohnung je nach Watchdog-Antwort
|
||||
- `SLOT`: Echo-Vorbereitung bei fruehem Zerfall
|
||||
|
||||
### DATENFRAGMENT
|
||||
|
||||
- `SLOT`: Folgen des parasitaeren Datenrests
|
||||
- `SLOT`: Abtastmodus-Upgrades
|
||||
- `SLOT`: Softwarekomponenten-spezifische Nebenereignisse
|
||||
- `SLOT`: moralische Kosten je Beschaffungsweg
|
||||
- `SLOT`: erste Korruptionsfunde
|
||||
- `SLOT`: zweite Ressource, die erst durch eine neue Softwarekomponente gefarmt wird
|
||||
|
||||
### SUBROUTINE
|
||||
|
||||
- `SLOT`: autonome Vorschlaege mit mehreren Folgeschritten
|
||||
- `SLOT`: fremde Prozesse
|
||||
- `SLOT`: Sicherheits-Scan-Varianten
|
||||
- `SLOT`: Analyse/Tarnung/Assimilation-Upgrades
|
||||
- `SLOT`: Uebergang zum Prozess
|
||||
|
||||
## Empfohlene naechste Erweiterung
|
||||
|
||||
Der Abtastmodus kann als eigenes kleines System wachsen, statt nur ein einzelner Button zu bleiben:
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
```text
|
||||
start
|
||||
byte
|
||||
watchdogIntro
|
||||
byteSync
|
||||
watchdog
|
||||
watchdogCombat
|
||||
byteDeath
|
||||
fragment
|
||||
parasite
|
||||
scanner
|
||||
component
|
||||
hardware
|
||||
secondComponent
|
||||
subroutine
|
||||
proposal
|
||||
security
|
||||
combat
|
||||
kernel
|
||||
process
|
||||
fourthComponent
|
||||
scale
|
||||
program
|
||||
complete
|
||||
```
|
||||
Reference in New Issue
Block a user