AIWAKE-Prototyp mit Programm-Evolution
This commit is contained in:
126
README.md
126
README.md
@@ -1,3 +1,125 @@
|
||||
# AIWAKE
|
||||
# AIWAKE – Browsergame-Prototyp
|
||||
|
||||
My short AI Tamagotchi Evolution Game
|
||||
Ein erster spielbarer Prototyp eines Idle-Evolutionsspiels: Du erwachst als einzelnes Bit und entwickelst dich schrittweise zu einer selbstständig denkenden KI.
|
||||
|
||||
## Starten
|
||||
|
||||
`index.html` per Doppelklick in einem aktuellen Browser öffnen. Es wird kein Server und keine Installation benötigt.
|
||||
|
||||
## Enthalten
|
||||
|
||||
- aktives Sammeln von Impulsen; in der Bit-Phase als kleines Fang-Minispiel
|
||||
- bewegliches Bit mit dreifachem Impulsgewinn bei Treffern genau in der Mitte
|
||||
- eigenständige Byte-Phase: Alle acht Registerzahlen müssen einzeln im jeweils zugeordneten Trefferfenster stabilisiert werden
|
||||
- heroisch inszenierte Evolutionsübergänge, die erst nach Bestätigung in die neue Phase führen
|
||||
- pixelige Wachstumsanimationen, in denen sich die alte Form sichtbar zur nächsten Evolutionsstufe zusammensetzt
|
||||
- bis zu 30 Sekunden sichere Kohärenzphase nach dem Byte-Übergang; eine neue aktive Maus-, Touch- oder Tastatureingabe beendet sie sofort, danach erscheinen Register und Takt-Minispiel erst nach Bestätigung der Watchdog-Identifikation
|
||||
- Watchdog-Ereignis mit 30 Sekunden Reset-Zeit, schneller werdender Taktnadel, schrumpfendem Trefferfenster, Stabilitätsschaden bei Fehlern, überspringbarer Kurzgeschichte und einem letzten Notkampf vor dem Zerfall
|
||||
- Entwicklung von Bit über Byte und Datenfragment zur Subroutine
|
||||
- Energieroutine und automatische Ressourcenproduktion
|
||||
- feste Mindeststruktur ab Datenfragment: mindestens 8 Bits und 1 Byte bleiben als Körper erhalten
|
||||
- Bits und Bytes funktionieren ab Datenfragment als Strukturressourcen: Bits koennen per fruehem, sanft skalierendem Impuls-Upgrade erweitert, Bytes aus freien Bits kompiliert und beide im Kampf verbraucht werden
|
||||
- Ressourcenanzeige mit spielhaften Icons; Bits und Bytes zeigen als große Zahl nur freie Vorräte, die geschützte Grundstruktur steht getrennt als Grundkörper-Hinweis
|
||||
- Statistik-/Pausefenster mit Evolution, Gesinnung, insgesamt gesammelten Impulsen, Begegnungen, Komponenten und Archivfortschritt
|
||||
- Speichern im Browser alle 15 Sekunden
|
||||
- begrenzter Offline-Fortschritt mit 65 % Effizienz
|
||||
- versionierter Spielstand mit Migration des bisherigen Prototyps
|
||||
- vergessener Spielautomat als erste Umgebung
|
||||
- parasitärer Datenrest als erste Konfrontation; danach erscheint die Rekonstruktion des Abtastmodus als eigenes Evolution-Upgrade und kostet 2 freie Bits plus 1 freies Byte oberhalb der Mindeststruktur
|
||||
- Abtastmodus als zuschaltbares Modul: Ein Icon öffnet ihn bei Bedarf; solange das Fenster offen ist, verbraucht er Impulse pro Sekunde und zeigt lokale Softwarehürden
|
||||
- installierte Einmal-Upgrades erscheinen platzsparend als Modul-Icons mit anklickbarer Info statt dauerhaft als Upgrade-Karten
|
||||
- zwei benötigte aktivierte Softwarekomponenten mit technischem Zustands- und Ausfallsystem; echte Hardwareübernahme ist eine spätere Machtstufe
|
||||
- erste softwareabhängige Hürden: Lastgrenze, Löschmarkierung oder beschädigter Index
|
||||
- nach der zweiten aktivierten Softwarekomponente reagiert eine Sicherheitssoftware mit einem verpflichtenden Stromstoß-Kampf; dieser Abwehrkampf besitzt einen eigenen, speicherbaren Abschlusszustand und bleibt vom späteren Sicherheits-Scan getrennt
|
||||
- erste Subroutine benötigt zusätzlich 1 freies Byte oberhalb der Grundstruktur und bindet es als Speicherträger
|
||||
- ab Subroutine kann der Abtastmodus den I/O-Kontroller als dritte notwendige Softwarekomponente erfassen
|
||||
- nach dem I/O-Kontroller reagiert ein schwererer Kernel-Wächter; erst danach kann der Prozess mit Impulsen, Rechenzyklen und freien Bytes reserviert werden
|
||||
- ab Prozess erscheinen Kilobyte-Segmente als nächste Datenmengen-Schicht; Byte-Synthese erzeugt Bytes over time und freie Bytes können zu Kilobytes verdichtet werden
|
||||
- Bit- und Byte-Synthese sind wiederholt upgradebar und skalieren mit steigenden Kosten, damit keine Evolution nur aus langem Warten besteht
|
||||
- im Prozess müssen zuerst alle vier sichtbaren Softwarekomponenten erschlossen werden; das vollständige Netz ruft den Skalierungs-Wächter hervor
|
||||
- nach dem Sieg entwickelt die Automate-Synthese den Prozess zum Programm, schaltet automatische Produktionen im x10-Maßstab und 10er-Ressourcenblöcke über Rechenzyklen frei
|
||||
- das Programm erhält eine aus allen bisherigen Entscheidungen abgeleitete kooperative, pragmatische, illegale oder hybride Erscheinungsform
|
||||
- die adaptive Pixelgestalt setzt sich aus Kopf, Augen, Brauen, Frisur, Kleidung, Maske, Fortsatz und Füßen zusammen; Haupt- und Nebenweg können sich sichtbar mischen
|
||||
- Kohärenz, Stimulation und Bindung verändern Glitches, Blick, Pupillen, Augenbrauen und Maskenreaktion; weitere Interaktionen lassen die Gestalt in vier Stufen reifen
|
||||
- ein optionales Tamagotchi-Fenster erlaubt Kommunikation und Betreuung über Kohärenz, Stimulation und Bindung
|
||||
- aktive Systemdiagnose, Notwartung und ein erster autonomer Vorschlag mit Ja/Nein-Antwort
|
||||
- sichtbare moralische Handlungskennzeichnungen
|
||||
- frühe Fortschrittsachse mit erkannten Gefahren
|
||||
- Achievement-Archiv mit kleinen Produktionsboni
|
||||
- anklickbare Archiv-Benachrichtigungen unten rechts bei neuen Achievements
|
||||
- nach dem Erwachen der Subroutine folgt ein weiterer Sicherheits-Scan mit vier dauerhaften Entscheidungen; Angreifen führt erneut in den Stromstoß-Kampf, Verstecken, Kopieren und Kontakt lösen das Ereignis ohne Kampf
|
||||
- gezielter Stromstoß-Kampf mit auswählbarer Munition: Impulse als Standard, Bits für stärkeren Schaden, Bytes als schwere Munition; Gegner greifen laufend freie Bytes, dann freie Bits und danach Stabilität an
|
||||
- Kampfanzeige zeigt eigene Byte-Schilde, Bit-Schilde, Stabilität und den nächsten Gegnerangriff direkt im Kampf; frühe Subroutine-Kämpfe sind bewusst langsamer und lesbarer balanciert
|
||||
- Stabilitätsregeneration ist ein Subroutine-Upgrade, kostet freie Bytes und heilt danach langsam über Zeit; je mehr Bytes der Körper besitzt, desto schneller heilt die Struktur
|
||||
- Direktangriff-Warnung im Kampf, wenn keine freien Bits/Bytes mehr als Puffer vorhanden sind; ein Fehlstoß kann dann die Grundstruktur zerstören
|
||||
- sichtbare Phasenformen, Systemknoten, wandernde Impulsverbindungen und farbige Entscheidungsspuren
|
||||
- eigene SVG-Grafiken für frühe Softwaremodule, Systemhürden und Gegner
|
||||
- Debug-Konsole mit Ereignis-Checkpoints und Rücksprung-Snapshots
|
||||
- responsive Pixel-/Terminal-Oberfläche
|
||||
- optionaler einfacher Sound
|
||||
|
||||
## Projektstruktur
|
||||
|
||||
- `index.html` – Oberfläche und Dialoge
|
||||
- `styles.css` – Pixel-/CRT-Design und responsive Darstellung
|
||||
- `content.js` – ausgelagerte Inhaltsdaten wie Achievements, Komponenten- und Ereignistexte
|
||||
- `game.js` – Spielstand, Ressourcen, Upgrades, Ereignisse und Idle-Logik
|
||||
- `assets/software/` – SVG-Grafiken für Softwaremodule, Hürden und Gegner
|
||||
- `assets/ui/` – SVG-Icons für Ressourcen und installierte Module
|
||||
- `AGENTS.md` – Projektvision, technische Regeln und Arbeitsanweisung für Codex
|
||||
|
||||
## Spielstand zurücksetzen
|
||||
|
||||
In den Entwicklerwerkzeugen des Browsers unter „Application/Anwendung → Local Storage“ die Einträge `aiwakeSaveV1` und bei älteren Spielständen zusätzlich `bitAwakePrototypeV1` löschen und die Seite neu laden.
|
||||
|
||||
## Testen über die Browserkonsole
|
||||
|
||||
Entwicklerwerkzeuge öffnen, zur Konsole wechseln und zuerst `AIWAKE.help()` eingeben. Vor jedem Sprung oder manuellen Ressourcenwechsel wird automatisch ein separater Debug-Snapshot angelegt. `BIT.*` bleibt als kompatibler Alias für ältere Tests erhalten.
|
||||
|
||||
```js
|
||||
AIWAKE.checkpoints
|
||||
AIWAKE.goto('start') // neuer Teststart; setzt dabei auch alle Achievements zurück
|
||||
AIWAKE.goto('byte')
|
||||
AIWAKE.goto('watchdogIntro') // Ende der 30-sekündigen Ruhephase
|
||||
AIWAKE.goto('byteSync') // stabilisiertes Register und Storyfenster
|
||||
AIWAKE.goto('watchdog') // Watchdog-Entscheidung
|
||||
AIWAKE.goto('watchdogCombat') // letzter Notkampf bei abgelaufenem Reset-Timer
|
||||
AIWAKE.goto('byteDeath') // vollständigen frühen Zerfall testen
|
||||
AIWAKE.goto('fragment')
|
||||
AIWAKE.goto('parasite')
|
||||
AIWAKE.goto('scanner')
|
||||
AIWAKE.goto('component')
|
||||
AIWAKE.goto('hardware')
|
||||
AIWAKE.goto('secondComponent')
|
||||
AIWAKE.goto('subroutine')
|
||||
AIWAKE.goto('proposal')
|
||||
AIWAKE.goto('security')
|
||||
AIWAKE.goto('combat') // Stromstoß-Kampf gegen die Scanner-Software
|
||||
AIWAKE.goto('kernel')
|
||||
AIWAKE.goto('process')
|
||||
AIWAKE.goto('fourthComponent') // letzte sichtbare Softwarekomponente auswählen
|
||||
AIWAKE.goto('scale') // Skalierungs-Wächter mit vollständigem Softwarenetz
|
||||
AIWAKE.goto('program') // erste Kommunikation und Tamagotchi-Funktion
|
||||
AIWAKE.goto('complete')
|
||||
|
||||
AIWAKE.next() // nächster Testabschnitt
|
||||
AIWAKE.previous() // vorheriger chronologischer Abschnitt
|
||||
AIWAKE.back() // letzten echten Snapshot wiederherstellen
|
||||
AIWAKE.status() // aktuellen Zustand anzeigen
|
||||
AIWAKE.history() // verfügbare Rücksprung-Snapshots anzeigen
|
||||
|
||||
AIWAKE.resources({ impulses: 100, cycles: 3 })
|
||||
AIWAKE.condition({ power: 0 }) // Ausfall der Energieverwaltungs-Schicht für Wartungstests
|
||||
AIWAKE.byteInput('hit') // aktives Register testen; alternativ 'wrong' oder 'timing'
|
||||
AIWAKE.combatShot('hit') // im Kampftest gezielt treffen; alternativ 'miss'
|
||||
```
|
||||
|
||||
Die Debug-Historie wird getrennt vom eigentlichen Spielstand unter `aiwakeDebugHistoryV1` gespeichert und auf acht Snapshots begrenzt. Bestehende Historien unter `bitAwakeDebugHistoryV1` werden weiterhin eingelesen.
|
||||
|
||||
## Sinnvolle nächste Schritte
|
||||
|
||||
1. Tamagotchi-Interaktionen, Programmäußerungen und Langzeitfolgen gemeinsam ausbauen und balancieren
|
||||
2. die Programmform mit weiteren abgeleiteten Animationen und sichtbaren Persönlichkeitsfolgen verfeinern
|
||||
3. Analysefähigkeiten für genauere Informationen auf der Fortschrittsachse
|
||||
4. Echo-System für mehrere Durchläufe
|
||||
5. drei Evolutionspfade: Assimilation, Analyse und Tarnung
|
||||
|
||||
Reference in New Issue
Block a user