LifeGameLab ist ein deterministisches Browser-RTS, das mit genau einer Zelle startet. Kein Tutorial, keine Gebaeudemenues, keine versteckten Hilfssysteme: Der erste Spielzug ist direkte Kontrolle einer einzelnen Zelle im Grid.
Das Spiel baut auf einer harten Kernspannung auf:
- Nutze ich neue Zellen weiter als Worker?
- Oder binde ich sie dauerhaft in Muster und Infrastruktur?
Aus dieser Entscheidung entstehen Oekonomie, Expansion, Zonen, Automatisierung und spaeter Kampf.
Die Welt ist seedbasiert und reproduzierbar:
- gleicher Seed -> gleiche Welt
- gleiche Inputs -> gleiche Sim-Ergebnisse
Die Karte ist fair, aber nicht trivial gespiegelt. Beide Seiten bekommen vergleichbare Startchancen, nicht zwingend identische Geometrie.
Die Ressourcenverteilung erzeugt den Spannungsbogen organisch:
- Stabilisierung
- Expansion
- Konflikt
Jeder Spieler startet mit einer einzigen Zelle. Diese Zelle ist der erste Worker und wird direkt bewegt.
Erster Loop:
- zur nahen Quelle bewegen
- abbauen
- zweite Zelle erzeugen
- Einkommen parallelisieren
Mit zwei Zellen beginnt das eigentliche Wirtschaftsspiel:
- paralleler Abbau
- schnellerer Ressourcenzuwachs
- Vorbereitung der ersten Zone
Frueher Kernloop:
- Ressourcen abbauen
- neue Zellen erzeugen
- Einkommen stabilisieren
- erste Zone vorbereiten
Zonen sind feste quadratische Felder im Grid:
- 2x2
- 4x4
- 6x6
- 8x8
Groessere Zonen sind teurer, eroeffnen aber mehr Topologie und mehr Kombinationsraum.
Zonentyp wird beim Platzieren festgelegt:
- Abbauzone
- Weiterverarbeitungszone
- Herstellungszone
Ab dem ersten Ueberschuss gilt permanent:
- Worker behalten (kurzfristiger Ertrag)
- Worker binden (langfristige Investition)
Zu fruehes Binden schwaecht die Wirtschaft. Zu spaetes Binden verhindert Infrastruktur.
Ab mindestens vier Zellen in einer Zone koennen Verbindungen gelegt werden. Das System erkennt daraus Muster und erzeugt bei Bestaetigung Objekte/Funktionen.
Prinzip:
- keine Gebaeudeliste klicken
- Funktionen durch Muster entdecken
Drei Stufen:
- Abbau
- Weiterverarbeitung
- Herstellung
Ziel des Early Games: Grundversorgung auf Selbsttragfaehigkeit bringen.
- Early Game: Ueberleben, erste Stabilisierung, erste Zone
- Mid Game: Teilautomatisierung, freie Zellen fuer Spezialisierung
- Endgame: Produktions- und Militaer-Synergien dominieren
Konflikt entsteht durch geteilte, wertvolle Ressourcenraeume. Kein Script-Event muss Kampf kuenstlich starten.
Loss Condition:
- letzte Zelle tot -> Match verloren
- kein Respawn
Militaer entsteht aus Herstellungsentscheidungen und Kombinationen, nicht nur aus Masse. Wichtig ist nicht nur "mehr Armee", sondern "andere Armee".
Zellzustaende muessen direkt sichtbar sein (z. B. Marker, Form, Effekte), damit Micro-Entscheidungen ohne Tooltip-Zwang moeglich sind.
Start mit einer Zelle -> Wirtschaft stabilisieren -> Zellen in Muster investieren -> Objekte und Produktionsketten aufbauen -> Grundversorgung automatisieren -> Kaempfer spezialisieren -> durch bessere emergente Kombinationen dominieren.
- Vanilla JavaScript
- deterministischer Kern
- 24 Ticks pro Sekunde
- UI dispatcht nur, mutiert State nicht direkt
- Replay-/Hash-faehige Zustandsentwicklung
Was bereits belastbar ist:
- deterministische Kernel-/Dispatch-Pipeline
- Tick-Loop ohne dt/catchup-Cap (tick-genauer Catch-up)
- Founder-Budget auf 1 ausgelegt
- UI auf neutralen Adapter reduziert
- Determinismus-/Replay-Testlinie ist aktiv
Was noch fehlt bzw. offen ist:
- renderAlpha-Interpolation sichtbar im Runtime-Flow
- erste klar sichtbare interpolierte Zellbewegung im Browser
- durchgaengiger Worker-Order-Flow (select -> move -> execute) als finaler Gameplay-Standard
Der naechste Schritt ist nicht Feature-Breite, sondern harte Sichtbarkeit des Kerns:
- renderAlpha sauber im Live-Rendering verankern
- 24 Ticks/Sekunde als stabile Basis halten
- erste interpolierte Zellbewegung sichtbar und testbar machen
Repository: