ASE - Antares Simulation Engine · Ganze Welten bauen. Als eine Person.

// Skalierung by Design

Milliarden Entities. Millionen Spieler. Ein Planet.

ASE simuliert Individuen, keine Durchschnitte - jedes Blatt, jeder Wurm, jedes Bakterium ist eine vollwertige Entity. Skalierung ist kein Regler, den man schiebt; sie ist die Form der Architektur.

cloudforest - **eine Auswahl der Biom-Modelle der Engine**

coralreef - **jede Klimazone, simuliert**

rainforest - **eine Auswahl der Biom-Modelle der Engine**

mountains - **jede Klimazone, simuliert**

tundra - **eine Auswahl der Biom-Modelle der Engine**

mangrove - **jede Klimazone, simuliert**

ocean - **eine Auswahl der Biom-Modelle der Engine**

Milliarden

Entities anvisiert

Millionen

Gleichzeitige Spieler

0

L3-Sim-Module

0

L4-Plugins

0

Benannte Schedules

0

Ausführungs-Tiers

Millionen / Wiese

Eine einzelne Wiese ist bereits Millionen

10.000 Grashalme × 50 Blätter, 1.000 Insekten, 100 Regenwürmer, die den Boden umgraben, 10.000 Bakterien, die Materie zersetzen - für EINE Wiese. Multipliziert über einen Planeten erreicht die Zahl Milliarden unabhängig simulierter Entities.

20 Hz → 0.01 Hz

Geschichtete Uhren, von schnellem Leben bis zu langsamem Stein

Die Welt ist wie ein Geoinformationssystem modelliert, jede Sphäre auf eigener Uhr: Die Anthroposphäre tickt ~20 Hz, die Hydrosphäre ~1 Hz, die Atmosphäre ~0.1 Hz, die Lithosphäre ~0.01 Hz. Bakterien ticken schnell, Tektonik tickt langsam - jede Schicht besitzt ihre Rate, ihr LOD und ihre Persistenz.

EnTT → RAM → MongoDB

HOT-/WARM-/COLD-Streaming

Milliarden Entities passen nicht in den RAM, also streamt ASE sie: Der aktive Chunk ist HOT in EnTT (jeder Wurm gräbt, jedes Bakterium lebt), nahe Chunks WARM als aggregierte Dichten, ferne Chunks COLD in MongoDB - komprimiert und persistiert, bis ein Spieler sich nähert.

~6 GB / 1000×1000-Welt

Chunk-Mathe, die aufgeht

~6 KB pro 32×32-Heightmap-Chunk, 9 aktive Chunks um einen Spieler bei ~54 KB, eine Welt mit 1000×1000 Chunks bei rund 6 GB. Planetarer Maßstab, mit konkreten Zahlen dahinter.

20 / 1 / 0.1 pro Sek

Die Tickraten-Ökonomie

Bewegung, Kollision und Kampf laufen 20/Sek; Hunger, Durst und Temperatur 1/Sek; Pflanzenwachstum, Wetter und Verfall 0.1/Sek. Pflanzen denken nicht 20-mal pro Sekunde - langsame Prozesse nicht mit Framerate zu ticken ist genau das, was der CPU den Raum gibt, einen Planeten zu tragen.

Milliarden + Millionen

Das Ziel, klar benannt

Ganze Planeten mit Ökosystemen, jedes Blatt und Bakterium eine Entity, Millionen gleichzeitiger Spieler, echte Physik, Wetter und Fluide - kein Render einer Welt, sondern ihre Simulation.

O(n), nicht O(n²)

Skalierung ist per Design linear

Weil Systeme in geteilte Components schreiben, statt sich untereinander zu verdrahten, kosten neue Entities und neues Verhalten beide linear. Skalierung ist keine Wand, gegen die man später optimiert - sie ist die Form des Datenmodells ab der ersten Zeile.

WARM = Dichten

Aggregation statt Löschung

Ein Chunk, von dem du dich entfernst, wird nicht verworfen - er kollabiert zu aggregierten Dichten (wie viele Rehe, wie viel Biomasse) und entwickelt sich günstig weiter. Komm zurück, und er expandiert wieder zu Individuen. Nichts geht verloren, es wird nur zusammengefasst.

entity-per-item

Keine Arrays, keine Obergrenzen

Components halten keine Arrays und keine Zähler: Ein Molekül mit N Elementen ist N Entities, ein Wald ist seine Bäume. Strukturen sind unbegrenzt, weil eine Query sie durchläuft, kein fester Slot - das Datenmodell verweigert das harte Limit.

Neo4j + MongoDB

Zwei Stores, eine Welt

Beziehungen, Hierarchien und Inventar leben in einem Neo4j-Graphen; Chunks, State und Snapshots streamen nach MongoDB. Datenbanken sind reine Persistenz - jede aktive Entity lebt im RAM, die Simulation wartet beim Ticken nie auf eine Query.

ECS-Architektur: O(n), wo objektorientierte Engines O(n²) sind. Das ist möglich vs. unmöglich - nicht bloß “schneller”.

// Alles ist verbunden

Neue Ursache-Wirkung kostet ein Component-Feld, kein Geflecht aus Verdrahtung.

Das Gründungsaxiom von ASE ist eine Architektur, kein Slogan: Alles ist verbunden, alles ist Entity, alles ist simuliert. Pure ECS macht aus diesem Axiom etwas, das eine CPU tatsächlich fahren kann.

~10,000

OOP - 100 Systeme verdrahtet mit 100 · Zeilen Kopplung

kollabiert zu →

~100

ASE - 100 Systeme auf einem Component-Bus · Zeilen

Die Primitive

Entity · Component · System 3: Eine Entity ist nur eine ID, ein Component reine Daten ohne Methoden, ein System zustandslose Tick-Logik - das strikte Rückgrat, das die Engine jedes Blatt und Bakterium als vollwertiges Objekt behandeln lässt.
Components sind reine Daten POD: Reine Daten, keine Methoden, kein .cpp - zero-initialisiert, eine Verantwortung. Verhalten versteckt sich nie in Daten; es lebt in zustandslosen Systemen. Diese Disziplin hält eine Milliarde Entities billig.
Alles kann, nichts muss: Jede Entity KANN jedes Component tragen; keine MUSS. Ein Fels, der ein MetabolismComponent bekommt, beginnt zu metabolisieren - keine Klasse, keine Vererbung, keine Factory. Fähigkeit wird angehängt, nie vorab deklariert.
Tags statt Typ-Flags: Kein uint8_t-Typfeld, kein if-else-Dispatch. Ein PredatorTag-View fährt Räuber-Logik, ein PreyTag-View Beute-Logik - neues Verhalten ist ein neuer Tag plus ein neues System, kein Branch in einem alten.
Ein View ist eine Query, keine Schleife: Kein switch, kein manueller Dispatch. Ein System öffnet einen tag-gefilterten View und iteriert exakt die Entities, die passen - Verhalten gewählt durch die Components, die eine Entity trägt, aufgelöst von der Query selbst.

Kopplung

O(n²) → O(n) 10k→100: In OOP sind 100 Systeme, verdrahtet mit 100, ~10.000 Zeilen. In ASE sind 100 Systeme, die je in ein geteiltes Component schreiben, ~100. Füge einen Kausallink hinzu, indem du ein Feld schreibst; jeder Leser reagiert automatisch.
Components sind der einzige Kanal: Systeme rufen einander nie auf - verboten. ase-sky kann ase-metabolism über ase-predator beeinflussen, ohne dass eines der drei die anderen beim Namen kennt. Die geteilten Hub-Keys sind der gesamte Vertrag.
Der Hub ist ein Stern, kein Mesh: 83 L3-Module schreiben und lesen über einen Communication Hub - ein Stern mit null direkter Modul-zu-Modul-Kopplung. Ein neues Modul fügt dem Zentrum Speichen hinzu, nie Kanten zu den anderen.
Systeme besitzen keinen State: Ein System hält keine Member-Variablen und behält nichts zwischen Ticks - es liest Components, schreibt Components, fertig. Zustandslosigkeit macht Systeme trivial parallel und endlos komponierbar.
Parallel, weil zustandslos: Ohne geteilten mutablen State zwischen Systemen fährt der Scheduler unabhängige Systeme ohne Locks über die Kerne. Nebenläufigkeit ist nicht angeschraubt - sie fällt aus derselben Disziplin, die die Verdrahtung entfernt.

Das Datenmodell

Neues Verhalten = neue Daten 0 Recompiles: Das Schema lebt in Daten, nicht in Code. Ein neuer Typ oder neues Verhalten heißt: Entities spawnen, Components anhängen. Arrays in Components sind verboten, Strukturen bleiben unbegrenzt - null Rebuild.
Entity-per-Item, nie Arrays: Components halten keine Arrays und keine Zähler. Ein Molekül mit N Elementen ist N Entities, jede getaggt - Strukturen sind unbegrenzt, und eine Query durchläuft sie, keine Schleife. Das Modell verweigert feste Slots.
Data-driven, nicht hartkodiert: Formeln lesen Component-Felder; keine Magic Numbers, keine Sonderfälle. Eine neue Spezies, ein Klima oder eine Ökonomie ist neue Daten - nie ein Branch, vergraben in einem System.
Keine Vererbung, nur Komposition: Es gibt keine Klassenhierarchie. Eine Fledermaus ist keine Subklasse von Tier - sie ist eine Entity mit Wings-, Echolocation- und Metabolism-Components. Neue Arten sind neue Kombinationen, nie eine neue Basisklasse.
Deterministisch allein aus Inputs: Gib dieselben Inputs, und die Welt entfaltet sich identisch. Weil sich State nur über Components und geloggte Intents ändert, ist ein Lauf reproduzierbar und replaybar - das Fundament, auf dem die ganze Engine ruht.

Laufzeit & Skalierung

66 Schedules, 21 Tiers: Der Tick ist nicht eine Schleife. Ein eigener Tiered Scheduler ordnet jedes System über 66 benannte Schedules in 21 Tiers - von Once-per-Life-Init bis zu 60-Hz-Frames. Bewusst nicht Bevy.
Geschichtete Uhren: 20 Hz → 0.01 Hz: Schnelles Leben tickt ~20 Hz, die Hydrosphäre ~1 Hz, die Lithosphäre ~0.01 Hz. Jedes System läuft in der Kadenz, die sein Phänomen braucht - so teilen sich Pflanze und Berg günstig eine Welt.
Milliarden im RAM, auf Disk gestreamt HOT/WARM/COLD: Der Chunk, in dem du stehst, ist HOT in EnTT, nahe Chunks WARM als aggregierte Dichten, ferne Chunks COLD in MongoDB. Skalierung ist ein Streaming-Problem, das die Architektur bereits löst.
Dasselbe ECS auf beiden Seiten der Leitung: EnTT auf dem C++-Server, becsy im Browser, 1:1-Parität für SHARED-Components. Ein SHARED-System rechnet deterministisch nach, statt sein Ergebnis zu verschicken.
Es gibt keine Grafik ohne Bedeutung: Die Sonne ist keine Lichtquelle - sie ist ein Fusionsreaktor, dessen Output Photosynthese, Bodentemperatur, Verdunstung und die Stimmung jeder Kreatur antreibt. Jedes Visual ist die Oberfläche einer Simulation.
Eine Datei, ein System: Jedes System ist eine einzelne zustandslose Datei, registriert auf einen benannten Schedule. Die Datei zu lesen sagt dir exakt, wann es läuft und welche Components es berührt - keine versteckte Registrierung, kein God-Object, das den Rest orchestriert.
Reaktiv per Konstruktion: on_construct- und on_destroy-Hooks feuern in dem Moment, in dem ein Component hinzugefügt oder entfernt wird - Reaktionen hängen an Datenänderungen statt an Polling pro Tick. Ein Component anzuhängen ist selbst ein Event.

// Wo wir stehen

Offen gebaut. Reift jeden Tag.

Jedes Component trägt einen Status in seiner VERSION-Registry - und der ist nicht behauptet, sondern automatisch aus der Commit-Zahl des Components abgeleitet. Genau hier steht ASE heute, kein Versprechen.

seed → poc → init → core → feat → refine wird automatisch aus der Commit-Zahl jedes Components berechnet; alpha · beta · stable werden von Hand gesetzt. Klick einen Status an um exakt zu sehen, welche Components dort sitzen - direkt aus den VERSION-Registries.

// Der Live-Graph

Zieh an einem Faden, die ganze Welt bewegt sich.

Jedes Modul lebt in einem Graphen. Klick unten eine Kachel an - der Live-Graph verdrahtet sich neu auf die echte Downstream-Kette des Moduls, direkt aus den Causality-Docs der Engine.

Live-Graph · ase-weather → 8 Module

Ein Modul pulsiert. Die ganze Welt antwortet.

Zieh am Wetter

ase-atmosphere · 5

Druck, Temperatur, Wind, Nebel und Regen fächern auf in Atemnot, Sicht, Geruchsausbreitung, Vogelverhalten und den Himmel. Dimm ein Feld, und fünf Module antworten.

Zieh an der Sonne

ase-ephemeris · 5

Die Position von Sonne und Mond treibt den Sternhimmel, circadiane Kreaturen, die Gezeiten über nautical, den Render und sogar die Himmelsereignisse der Religion.

Zieh am Land

ase-gis · 8

Geografie sät Terrain, Lokalklima, Selektion, Merkmalsausprägung, Habitate, erstes Leben, Pathing und wo die Fauna platziert wird - acht Downstream-Module aus einer Karte.

Zieh am Metabolismus

ase-metabolism · 6

Energiebudgets setzen Futtersuche, Überleben, Geruch, Bewegungsausdauer, Heilrate und jede hungergetriebene Entscheidung. Die Ökonomie des Körpers wird sechsfach gelesen.

Zieh am Himmel

ase-celestial · 4

Tag und Nacht verschieben KI-Verhalten, Aktivitätsfenster in der Nahrungskette, Sichtweite über Perception und den Himmels-Render. Die Uhr darüber bewegt den Boden darunter.

Zieh an der Witterung

ase-signature · 4

Eine Geruchsspur treibt Räuber, die ihr folgen, Beutefindung in der Nahrungskette, erweiterte Wahrnehmung über Perception und soziale Identität. Geruch ist kausal, nicht kosmetisch.

Zieh an einem Kampf

ase-combat · 4

Ein Schlag formt Intention über die BDI-Schicht um, verbrennt metabolische Energie, vergießt Blut, das Witterung trägt, und landet als Wunde. Gewalt propagiert durch vier Systeme.

Zieh an einem Leben

ase-lifecycle · 3

Geburt und Tod bewegen Nahrungsketten-Populationen, tragen eine Seele und formen über Verwundung die Resilienz um, während eine Entity altert. Ein einzelnes Leben schlägt drei Wellen.

Zieh an den Genen

ase-genetics · 3

Gene reichen zurück zum ersten Leben in der Abiogenese und nach vorn in die Sinne über Perception, in Geruch und Zeichnung über Signature. Vererbung ist in beide Richtungen verdrahtet.

Zieh am Ursprung

ase-abiogenesis · 4

Erste Chemie startet die Unordnung der Entropie, die Selektion der Evolution, die frühesten Genome und den Anfang von Leben-und-Sterben. Der Ursprung fädelt sich durch den ganzen Baum.

Zieh an der Jahreszeit

ase-calendar · 5

Der Kalenderwechsel setzt das Wetter neu, platziert den Sternhimmel, treibt die Sonnenbahn über die Ephemeride, tönt den Render und stellt die Uhr selbst weiter.

Zieh am Körper

ase-bbol · 7

Der Organismus greift in seine Gene, altert, kämpft und ermüdet, nimmt Schaden, lernt zu handeln, verfällt und treibt Verhalten - sieben Module downstream eines Körpers.

Zieh an der Intention

ase-bdi · 3

Eine Belief-Desire-Intention bindet metabolische Energie an ein Ziel, fokussiert die Sinne über Perception und formt die Geruchsspur, die ein Akteur hinterlässt. Der Geist bewegt den Körper.

Zieh an einem Skill

ase-skill · 5

Gelerntes Handeln verknüpft sich mit ererbter Begabung, einem Leben wachsender Meisterschaft, dem Körper, der es ausführt, der Übung, die den Verfall aufhält, und den Basisprozessen darunter.

// Emergenz, Schritt für Schritt

Es beginnt mit Wetter. Es endet mit einer überfluteten Siedlung.

Kein Skript hat das geschrieben. Die Kette unten ist, was der Output eines Moduls mit jedem Modul downstream macht - weil sie einen Graphen teilen.

Regen fällt.

from ase-weather → atmosphere & hydro

Pflanzen wachsen.

Bodenfeuchte steigt → ase-plant metabolism

Herbivoren blühen auf.

Futterangebot → ase-creature populations

Räuber folgen.

Beutedichte → ase-foodchain pressure

Flüsse erodieren.

Abflusslast → ase-erosion & Sedimenttransport

Siedlungen versinken.

Flussverlagerung → ase-terrain & die Welten, die du darauf gebaut hast

Alles aus EINEM module.

ändere einen einzigen Wert upstream - alles downstream re-simuliert.

~10 Zeilen, 1 System

Eine neue Kausalität ist normalerweise null neuer Code

Damit der Mond die Nacht aufhellt, schreibt ein SkyMoonSystem moon_contribution in SkyBrightnessComponent - ~10 Zeilen, ein System. StarSystem, PredatorSystem und PlayerVisibility lesen Helligkeit bereits, also ändern alle ihr Verhalten - unangetastet.

Sterne = Gefahr

Spieler lernen es beim Spielen, nicht per Tutorial

Viele sichtbare Sterne bedeuten einen dunklen, mondlosen Himmel, in dem Räuber auflauern; wenige Sterne bedeuten helles Mondlicht, das sie entlarvt. Löwen jagen am erfolgreichsten bei Neumond - ASE simuliert Realität, nicht Hollywood, und lehrt sie durchs Spielen.

kein Skript

Emergenz, keine Choreografie

Nichts in dieser Kette ist geskriptet. Jeder Schritt ist ein System, das ein Component liest, das ein anderes System geschrieben hat. Die Flut ist kein Event, das ein Designer platziert hat - sie ist, was Wasserkreislauf, Terrain und Regen zusammen ergeben.

// Die Vier-Tier-Topologie

Vier Prozesstypen, je eine Zuständigkeit.

ASE teilt seine Laufzeit in vier Planes - Engine, Replica, World und Reasoning - damit ein Simulations-Crash, ein Lifecycle-Kommando und ein LLM-Call einander nie blockieren können. Der Schnitt ist nicht kosmetisch; er ist, wie die Engine beobachtbar und skalierbar bleibt.

Engine

Control Plane · :808x

Orchestriert den Lifecycle, liest Projekt-Manifeste, exponiert eine typisierte HTTP-API allein für die ase CLI und CI. CLI-first getrieben, wie kubectl oder gh: Build-Promotion, Projektstart, Smoke-Test und Rollback sind alle skriptbar.

Replica

Data Plane · :900x

Besitzt den autoritativen State, persistiert nach MongoDB und ist das einzige öffentliche Gateway. Browser sprechen nur mit Replica-Ports. Authentifizierung, Sessions, Rate-Limiting und TLS leben alle hier - Engine und World tragen überhaupt kein öffentliches Auth-Modell.

World

Compute Plane · :9001+

Fährt die Simulations-Schedules und hält keinen State, keine Persistenz, keine Client-Verbindungen. Der Knoten, der State berechnet, ist nicht der Knoten, der ihn besitzt - eine World bootet, hängt sich an den State-Owner, holt auf, produziert und baut sich ab wie ein zustandsloser Web-Worker.

Reasoning

Cognition Plane · der 4. Typ

Die nicht-deterministische, sprachbasierte Arbeit, die deterministische Simulation strukturell nicht leisten kann: Skill-Outputs, NPC-Dialog, Narrativ-Generierung, Lore-Konsistenz-Checks, semantisches Routing und Verhaltens-Anti-Cheat. LLM-nativ, als eigenes Tier - kein Plugin.

Reasoning interprets

World simulates

Replica authorizes

Engine orchestrates

Engine :808x → Replica :900x (öffentlich) → World :9001+ + Reasoning Browser erreichen nur :900x

Planes & Grenzen

Vier Prozesstypen, je ein Job: Vier getrennte Binaries, kein Monolith: Engine orchestriert, Replica besitzt State und die öffentliche Oberfläche, World rechnet, Reasoning denkt. Ein Crash oder Skalierungsereignis in einem ist für die anderen unsichtbar - sie teilen nie einen Prozess.
Drei Planes, je eine Zuständigkeit control/data/compute: Engine orchestriert den Lifecycle; Replica besitzt den autoritativen State und gatewayt die Öffentlichkeit; World rechnet und besitzt nichts. Jede ist der kleinste Prozess, der allein neustarten kann, ohne die anderen mitzureißen.
Ports schneiden die Trust-Grenze 808x / 900x / 9001+: Die Port-Ranges sind das Sicherheitsmodell. Browser erreichen nur :900x; Control und Compute Plane sind per Konstruktion vom öffentlichen Internet unerreichbar, nicht per Policy.
Jedes Tier ist eine Observability-Grenze: Ein Broadcast-Latenz-Spike zeigt auf die Replica, ein Tick-Dauer-Spike auf die World, ein Lifecycle-Spike auf die Engine. Zwei Tiers in einem Prozess heißt: Ein Fehler in einem reißt State, Clients oder Skalierung mit.
Reasoning ist das vierte Tier: Neben Control, Data und Compute sitzt eine vierte Plane für Sprach-Arbeit - Skills, Dialog, Narrativ, semantisches Routing, Verhaltens-Anti-Cheat. Horizontal skalierbar und quotiert nach eigenen Regeln, nicht an die Loop geschraubt.

Transport & Wire

Fünf Transporte, jeder für eine Eigenschaft 10-Hz-Tick: HTTP/REST für CLI und CI; WS-Binary + BIN_MSG für Server-zu-Server (erstes Byte ist der Typ, flaches Layout per memcpy mit null Allokationen); WebRTC für Browser (reliable Snapshots, unreliable Input); SSE und WS-JSON bewusst Nicht-Default. Unter einem 10-Hz-Budget ist Binary-Zero-Parse Korrektheit.
Der Hub ist der geteilte Namensraum: Module schreiben und lesen benannte Hub-Keys, und der Almanach verschickt die Deltas; kein Modul kennt ein anderes beim Namen. 83 L3-Module koordinieren sich über einen Stern-Topologie-Hub - ein neues Modul verdrahtet die anderen nie um.
Wire-IDs leben in einer Registry pre-reserved: Jeder binäre Message-Typ hat eine ID, reserviert in einer Protokoll-Registry, vergeben vor der Implementierung. Tiers lassen sich in beliebiger Reihenfolge bauen und kollidieren nie auf dem Wire - der Vertrag steht vor dem Code.
Deltas statt Snapshots im Steady State: Nach einem Snapshot trägt der Wire nur noch Deltas im Tick-Takt. Ein SHARED-System rechnet clientseitig nach, statt Ergebnisse zu empfangen - ~100 B × 20 Hz kollabieren zu ~4 B × 1 Hz: Schick den Seed, nicht das Bild.

Disziplin

Lane-Disziplin wird erzwungen, nicht empfohlen: Reasoning schreibt nur Intents, World konsumiert und schreibt State, Replica autorisiert, Engine orchestriert. Ein Skill, der einen nicht deklarierten Intent emittiert, wird auf Engine-Ebene abgewiesen - die harte Constraint, die eine Welt replaybar hält.
CLI-first, wie kubectl für eine Welt scriptable: Die HTTP-Oberfläche der Engine ist gebaut für die ase CLI und CI zuerst - Build-Promote, Projektstart, Smoke-Test und Rollback sind skriptbar. Die Web-Konsole ist eine Komfortschicht auf exakt derselben API.
State an der Replica, Compute ist fungibel: Weil State an der Replica lebt, kann jede World andocken, Deltas aufholen und übernehmen. Die Plane, die rechnet, ist nie die Plane, die besitzt - genau das macht den nahtlosen Handoff ohne Ladebildschirm möglich.

// Nahtlosigkeit, skaliert

Quantum-Travel-Handoff: Das Compute wechselt mitten in der Region, du siehst nie einen Ladebildschirm.

Weil der Browser an der Replica hängt und nicht an der World, kann ASE das Compute hinter einer Region verschieben, teilen und mergen - ein Topic-Subscription-Handoff - während der Spieler weiterläuft. Die Nahtlosigkeit ist kein Trick; sie fällt aus der Topologie.

World Aam Limit / migriert

1 boot 2 subscribe + Snapshot 3 Deltas aufholen 4 Compute übernehmen

World B<100ms · kein Reconnect

der Spieler läuft weiter → beobachtbarer State reißt nie ab

Unsichtbarer Handoff, per Konstruktion

kein Ladebildschirm

Nähert sich eine World ihrer Kapazität oder muss migrieren, bootet eine zweite Instanz, abonniert dieselben Replica-Topics, empfängt einen Snapshot, holt die Deltas auf und übernimmt das Compute. Clients reconnecten nicht, re-authen nicht, sehen keinen Ladebildschirm. Die Compute-Identität einer Region ändert sich, ohne dass ihr beobachtbarer State sich ändert.

Heiße Regionen splitten, kalte Regionen mergen - live

kein Neustart

Die Chunk-Region-Partition ist nicht fix. Ein lastadaptiver Scheduler teilt eine heiße Region in zwei Worlds oder kollabiert zwei kalte in eine - aus Live-Telemetrie, denn eine Region neu zuzuweisen ist eine Topic-Subscription-Änderung, keine State-Migration. Die Partitionsform folgt der Simulationsdichte, nicht der Spielerzahl.

Keine EVE-Zeitdilatation, kein Elite-Instancing

Zwei bekannte MMO-Design-Trade-offs sind explizite Nicht-Ziele für ASE. Es vermeidet die Zeitdilatation von EVE Online - horizontales Compute hält die Tickrate unter Last konstant - und das Player-Cap-Instancing von Elite Dangerous - eine Menschenmenge spawnt nie eine zweite, getrennte Kopie eines Ortes. Die Welt bleibt eine Welt.

Projektübergreifendes Reisen ist nur eine Kante

V-3 Verbund

Jedes Projekt lebt in einem Graphen, also ist eine Überquerung eine Beziehung zwischen zwei Knoten, kein Export und kein Sync-Job. Eine Handelskarawane von Projekt A nach B kopiert keine Daten und schickt keine Inter-Server-Message - und der Spieler sieht keinen Handoff, weil beide Projekte derselbe Graph sind.

100.000+ Projekte auf einem Substrat

100,000+

Hunderttausend Projekte teilen sich den vereinheitlichten Graphen und den gemeinsamen Hub-/Almanach-Namensraum; jedes deklariert per Manifest seine eigenen Replica-Gruppen. Kein Provisionieren von Datenbanken oder Compute pro Projekt - das 1001. Projekt kostet ungefähr dasselbe wie das 1000., weil sich das Substrat nicht ändert.

Drei unabhängige Skalierungsachsen

3 Achsen

Vertikal pro Prozess, horizontal pro Rolle (Replica pro Modulgruppe, World pro Chunk-Region), dazu die Multi-Projekt-Dimension. Kopplung ist topic-basiert: Eine neue World ist ein neuer Subscriber, ein Replica-Split eine Topic-Routing-Änderung, ein neues Projekt ein neues project_id-Label. Nichts davon berührt das Binary eines anderen Tiers.

State lebt an der Replica; die World ist fungibel

zustandslose World

Der Knoten, der State berechnet, ist nie der Knoten, der ihn besitzt. Eine World hält keinen State, keine Persistenz und keine Client-Verbindungen - ein zustandsloser Compute-Worker, der mitten in der Session ersetzt werden kann, ohne dass Spieler es merken.

Compute-Node-Tausch unter 100ms

<100ms

Das Compute hinter einer Region zu tauschen dauert unter 100ms, typisch unter 10ms. Spieler-Reconnects bei Migration: null. Ladebildschirme bei Migration: null. Das Handoff-Fenster ist kleiner als ein Frame.

Browser erreichen nur die Replica

Replica-Oberfläche

World (:9001+) und Engine (:808x) sind für Browser unerreichbar; ein Browser spricht nur mit Replica-Ports. Authentifizierung, Sessions, Rate-Limiting und TLS leben alle auf dieser einen öffentlichen Oberfläche - Compute und Control Plane tragen kein öffentliches Auth-Modell.

Snapshot, dann Deltas

Snapshot + Delta

Eine bootende Instanz abonniert die Replica-Topics der Region, empfängt einen vollen Snapshot, holt den Delta-Stream auf und übernimmt erst dann das Compute. Der Tausch ist unsichtbar, weil beobachtbarer State nie abreißt.

Fünf Transporte, jeder für einen Job

5 Transporte

HTTP/REST für CLI und CI, WS-Binary für Server-zu-Server, WebRTC DataChannel für Browser (reliable für Snapshots, unreliable für Input); SSE und WS-JSON bleiben bewusst Nicht-Default. Jeder Transport ist für eine Eigenschaft unter einem 10-Hz-Tick gewählt.

Binär, Zero-Parse auf dem Wire

0 Alloc

Server-zu-Server-Frames legen den Message-Typ ins erste Byte und memcpy-en ein flaches Layout direkt in Hub/Almanach - null Allokationen, kein JSON-Parsing auf dem Hot Path. Bei einem 10-Hz-Tick ist das Korrektheit, keine Mikro-Optimierung.

Ein Graph, project_id-gescoped

1 Neo4j

Jedes Projekt ist ein gelabelter Subgraph in einer Neo4j-Instanz - keine Datenbank pro Projekt, kein Silo. Projektübergreifende Beziehungen sind Cypher-Matches über Labels; eine Karawane, die Welten quert, ist eine Kante, keine Integration.

Jedes Tier ist eine Observability-Grenze

isolierte Planes

Ein Broadcast-Latenz-Spike zeigt auf die Replica, ein Tick-Dauer-Spike auf die World, ein Lifecycle-Latenz-Spike auf die Engine - weil die Planes nie einen Prozess teilen. Ein Fehler in einer kann State, Clients oder Skalierung nicht mitreißen.

Partition folgt Dichte, nicht Kopfzahl

adaptives Mesh

Der lastadaptive Scheduler formt die Chunk-Region-Partition aus Live-Telemetrie um: Eine dichte, belebte Region bekommt mehr Worlds, eine leere wird eingefaltet. Das Mesh folgt dorthin, wo die Simulation schwer ist, nicht dorthin, wo Spieler gezählt werden.

Wächst zur Laufzeit in ein Mesh

kein Neustart

Ein Projekt, das auf einer einzigen World startet, wird während seiner eigenen Laufzeit zum Multi-Instanz-Mesh. Eine Region neu zuzuweisen ist eine Topic-Subscription-Änderung - kein Neustart, keine State-Migration, kein Downtime-Fenster.

Der Spieler reconnectet nie

Session unangetastet

Durch einen Split, einen Merge oder eine volle Migration hindurch wird die Verbindung des Clients zur Replica nie getrennt. Kein Reconnect, kein Re-Auth, kein Ladebildschirm - das Compute hinter der Region hat gewechselt, die Session und ihr beobachtbarer State nicht.

Elastisch pro Region, aus Telemetrie

auto-scaled

Kapazität folgt Live-Telemetrie, ohne Operator in der Schleife: Eine belebte Region fährt mehr Worlds hoch, eine ruhige wird eingefaltet, kontinuierlich. Skalierung folgt dorthin, wo die Simulation tatsächlich schwer ist, von Moment zu Moment.

Compute folgt der Menge, Besitz nicht

State bleibt, wo er ist

Wo Spieler sich sammeln, hängen sich mehr Worlds an die Replica-Topics der Region und teilen die Last. Der Besitzer des States - die Replica - bewegt sich nie; nur das fungible Compute. Dichte formt das Mesh um, nicht die Source of Truth.

// Eine Quelle, beide Seiten der Leitung

Schreib die Simulation einmal in C++. Ein Transpiler züchtet ihren TypeScript-Zwilling.

ase-codegen parst das C++-Backend und generiert den becsy-Client - Components, Systeme und Konstanten - in 1:1-Parität. Dieselbe deterministische Logik läuft dann auf dem Server und in deinem Browser - genau das lässt den Wire einen Seed verschicken statt eines Bildes.

atmo_sim_prs_chg_sys.cpp C++ · EnTT

class AtmoSimPrsChgSystem
    : public ecs::System {
  void tick(Registry& r, float dt) {
    auto v = r.view<AtmoStPrsChgComponent,
                    AtmoStPrsBaseComponent>();
    for (auto [e, chg, base] : v.each()) {
      chg.timer_s += dt;
      if (chg.timer_s >= 60.0f)
        chg.delta = std::min(base.p, MAX_P);
    }
  }
};

AtmoSimPrsChgSystem.ts TS · becsy

@system(s => s.after(AtmoSimPrsAltSystem)
  .inAnyOrderWithWritersOf(AtmoStPrsChgComponent))
export class AtmoSimPrsChgSystem extends System {
  private readonly query = this.query(q => q.current
    .with(AtmoStPrsChgComponent).write
    .with(AtmoStPrsBaseComponent).read);
  execute(): void {
    const dt = this.delta;
    for (const e of this.query.current) {
      const chg = e.write(AtmoStPrsChgComponent);
      const base = e.read(AtmoStPrsBaseComponent);
      chg.timer_s += dt;
      if (chg.timer_s >= 60.0)
        chg.delta = Math.min(base.p, MAX_P);
    }
  }
}

registry.view<A,B>()→this.query(q => q.with(A).with(B))

view.each()→query.current

std::min / std::sin→Math.min / Math.sin

float x = 0.0f→let x: number = 0.0

float-Feld→@field.float32

constexpr PI→const PI · importiert (SSOT)

// warum wir das tun - nicht, um Tipparbeit zu sparen

Zwei handgeschriebene Engines driften auseinander, sobald jemand einen Bug nur auf einer Seite fixt. Also schreibt ASE nie zwei: Die Logik wird einmal in C++ verfasst, und der TypeScript-Zwilling wird daraus transpiliert . Eine Logik auf beiden Seiten lässt den Browser die Welt aus einem Seed nachrechnen , statt das Bild zu streamen, durch einen Latenz-Spike vorhersagen, ohne zu stottern, und am Server eingerastet bleiben. Es driftet trotzdem - Floating-Point und Prediction tun das immer -, aber der autoritative Server zieht ihn zurück mit winzigen Deltas, so wie NTP eine Quarzuhr gegen eine Atomreferenz diszipliniert. Dieselbe Logik hält den Drift klein und die Korrektur winzig.

SHARED beide Seiten · 1:1

Components und deterministische Systeme, die auf Server und Client mit identischen Feldern existieren. State, der rendern muss - Position, Druck, Gesundheit. Die transpilierten Systeme leben hier.

SERVER-ONLY nie gesendet

Buffer, Forderes, Broadcast, Persistenz und Hub-Zugriff. Sie bleiben in C++ und queren nie den Wire - der Client trägt nichts vom Gewicht des Servers.

CLIENT-ONLY auto-generated

NetworkInput-, RenderSync- und EntityExport-Systeme, die der Codegen für dich schreibt - die Plumbing, die Netzwerkdaten ins ECS einspielt und nach React synct.

Warum ein Transpiler, keine zweite Codebase

Identische Logik auf identischen Daten: Beide Seiten fahren denselben transpilierten Algorithmus über dieselben SHARED-Components - der Browser prädiziert deterministisch und bleibt durch einen Latenz-Spike hindurch flüssig, statt zu stottern.
Schick den Seed, nicht das Bild: Weil der Client nachrechnet, statt Ergebnisse zu empfangen, verschickt der Wire die Inputs - ~100 B × 20 Hz Broadcast kollabieren zu ~4 B × 1 Hz. Der Client ist die Quarzuhr, der Server die Atomuhr: Die Deltas stupsen ihn nur zurück in den Takt, sie streamen nie die ganze Welt neu.
Eine Source of Truth, kein Drift: Das C++ wird verfasst; das TypeScript wird generiert und als do-not-edit markiert. Ein handgepflegter Client-Zwilling kann still aus dem Sync driften - ein generierter kann das nicht.
Typsicher über die Grenze: Jeder C++-Typ mappt auf einen becsy-Decorator - float to @field.float32, uint32_t to @field.uint32. Ändere ein Feld in C++, und der Client-Typ formt sich beim Regenerieren neu.
Konstanten haben ein Zuhause: Eine Konstante lebt einmal - in hub/data oder der types.hpp eines Moduls. Derselbe Name in zwei Modulen ist ein Build-Fehler, keine stille Divergenz zwischen Server und Client.
SHARED kann nicht schummeln: Ein transpiliertes System darf weder den Hub noch eine Datenbank noch irgendeine Server-only-Ressource anfassen. Diese Restriktion garantiert, dass es im Browser genauso läuft wie auf dem Server.

ase-codegen --module ase-atmosphere

analyze
clean
structure
types
interfaces
components
transpile
Client-Systeme
integrate
index

// Bring your own AI

Entwickle auf deinem eigenen Claude-Abo. Leg einen Schalter um zum Shippen.

ASEs Reasoning-Edge-Daemon fährt die CLI, die du ohnehin bezahlst - die schwere Iterationslast beim Bau eines LLM-getriebenen MMORPGs bleibt während der Entwicklung ein fixes Monatsabo, keine getaktete API-Rechnung.

developmentedge_only dein CLI-Abo · $0 Operator-Kosten

einen Schalter umlegen

ein Manifest-Feld

productioncloud_only gedeckelte, auditierbare API-Backends

edge-daemon

$ase edge run

Der Edge-Daemon läuft auf deiner Maschine und spawnt die installierte CLI - claude, codex, gemini-cli, cursor-agent - als Kindprozess, stdin/stdout durchgereicht. Er proxyt keine OAuth-Tokens und manipuliert keine Header: technisch ununterscheidbar davon, dass du die CLI in einer Shell startest.

Deine CLI, als Subprozess

lifecycle.phase

$ase ship --phase production

development defaultet auf edge_only (dein Abo, null Operator-Kosten); production defaultet auf cloud_only (gedeckelte API-Backends). Die Phase umzulegen shippt dieselben Skills ohne Skill-Code-Änderung - ein inkompatibler Wechsel wird mit einer Skill-Update-Liste geblockt, kein stiller Bruch.

Ein Schalter zum Shippen

install.sh

$curl edge.ase.dev/install | sh

Ein natives Binary unter 50 MB für fünf Plattformen, jedes mit SBOM und einer ES256-YubiKey-PIV-Signatur zur Offline-Verifikation. Es öffnet nur eine ausgehende WSS-Verbindung - kein Inbound-Port, läuft also hinter NAT und Firewalls - und hält keinen At-Rest-State.

Ein-Zeilen-Install

tos.check

$ase reasoning --tos-check

Das OAuth-Token eines Abos in einem Drittprodukt wiederzuverwenden ist verboten; die offizielle CLI als Subprozess aufzurufen ist sanktioniert. Weil diese Klarstellung informell ist, wird ein Provider, der das Modell wieder schließt, absorbiert durch einen einzigen Manifest-Schalter von Edge zu Cloud-API - null Skill-Code-Änderungen.

ToS-sauber & resilient

backends

$ase edge backends

Vier CLI-Backends plus ein custom_backend Slot. Ein Skill deklariert einen work_type, nie einen Modellnamen - Provider wechseln ist eine Engine-Config-Änderung ohne Skill-Code-Edit, und Dev vs. Prod nutzen verschiedene Backends für denselben Skill.

Bring jede CLI mit

manifest.yaml

$ase edge init

Der Daemon liest ~/.ase-edge/manifest.yaml - welche CLI, welches Projekt, welches Connection-Token. Kein Projektcode lebt auf der Edge; sie marshallt nur das stdout der CLI in typisierte Intents, die die World konsumieren kann.

Config, nicht Code

connection

$ase edge status

Outbound nur WSS zur Replica, mit Heartbeat und Auto-Reconnect. Kein Inbound-Port heißt: läuft hinter NAT, Firewalls und Café-WLAN; ein gerissener Link hängt sich wieder an, ohne die Session zu verlieren.

Nur ausgehend, NAT-sicher

vault.lease

$ase vault lease

In Produktion leben Kunden-LLM-Keys in einem dedizierten 3-Knoten-Vault; Reasoning liest Vault nie direkt. Jede Inferenz holt ein frisches 60-Sekunden-Lease-Token über die Replica, max. 5 Renewals - ein kompromittierter Prozess kann nur ein Token stehlen, das in Sekunden abläuft.

60s-Leases, nie gehostet

resolve

$ase reasoning --explain-resolve

Ein deterministischer 7-Schritte-Backend-Resolver mappt den work_type eines Skills auf ein konkretes Backend und loggt resolved_backend_id, backend_pool_version, was_fallback und was_degraded pro Call - jede Inferenz ist im Nachhinein auditierbar.

Deterministisch + geloggt

multi-edge

$ase edge lock

Mehrere Edge-Daemons können sich an ein Projekt hängen; ein Lock-Modus entscheidet, welcher Daemon einen gegebenen Skill bedient. Ein Solo-Dev auf zwei Maschinen - oder ein kleines Team - teilt sich das Reasoning eines Projekts ohne Kollisionen.

Multi-Edge, gelockt

local.first

$ase reasoning --local

A local_resolution Manifest-Block lässt Resolution-Schritt 0 auf der Edge antworten - mit null Egress , bevor irgendein Cloud-Backend berührt wird. Der günstigste, privateste Pfad wird per Konstruktion zuerst probiert - nicht als Nachgedanke.

No-Egress-Pfad zuerst

audit

$ase reasoning Audit-Query --skill <id>

Jede Inferenz protokolliert resolved_backend_id, was_fallback und was_degraded; die Audit-Query liefert den Trace für jeden Skill über jeden Zeitraum. “Warum landete das auf Backend X?” hat eine Antwort, im Nachhinein.

Jeder Call ist nachvollziehbar

dev.cost

$ase edge cost

Während der Entwicklung sind die Iterationskosten ein flaches CLI-Abo - extern liegt ein Claude-Max-Plan bei rund $200/Mon. gegenüber geschätzten $1.000–3.000/Mon. in äquivalenten getakteten API-Tokens. Die teure Phase läuft nie über Taktung.

Fix, nicht vierstellig

auto.tune

$ase reasoning tune

Eine Tuning-Policy wechselt Backend oder Model-Class eines Skills, wenn Live-Kosten-und-Qualitäts-Telemetrie eine Schwelle kreuzt - data-driven, ohne hartkodierte Modellnamen. Du setzt ein Ziel; das System findet das günstigste Backend, das es noch erfüllt.

Kostenkontrolle im Closed Loop

~$200 vs. ~$1.000–3.000 / Mon.

Fixe Dev-Kosten, keine vierstellige API-Rechnung

Weil Skills während der Entwicklung gegen dein eigenes CLI-Abo laufen, sind die Iterationskosten ein fixes Monatsabo statt getakteter Tokens. Extern liegt ein Claude-Max-Plan bei rund $200/Monat flat, gegenüber geschätzten $1.000–3.000/Monat in äquivalenten API-Token-Kosten. Produktion flippt dann auf gedeckelte, transparente Cloud-Abrechnung.

2 Schichten, nie gekreuzt

Zwei Kostenschichten, die sich nie berühren

Schicht 1 (Server, MongoDB-/Neo4j-Hosting, engine-interne Skills) deckt das flache ASE-Abo. Schicht 2 - die LLM-Inferenz, die dein Spiel erzeugt - geht direkt auf deine eigene Provider-Rechnung und läuft nie über den Operator. Der Operator subventioniert nie deine LLM-Kosten und hostet nie deine Abo-Tokens.

// Skills als ECS-Entities

Ein Skill ist eine Entity, kein Service - komponier sie wie LEGO.

In ASE ist ein Skill keine Markdown-Datei und kein registrierter Microservice. Er ist eine ECS-Entity, zur Laufzeit aus einem deklarativen Manifest geboren und von einer Query aufgegriffen - dasselbe Alles-kann-nichts-muss-Prinzip, auf Reasoning ausgedehnt.

SkillManifest · ein Skill ist Daten, kein Service

id: lore-consistency-checker
subscriptions: [ DialogueIntent, LoreState ]
reads:  [ CharacterMemory, WorldFacts ]
writes: [ AnomalyIntent ]        # nichts außerhalb davon ist erlaubt
work_type: reasoning_heavy      # ein Bedarf, kein Modellname
cost_layer: game
communication_pattern: standard
memory: [ episodic, semantic, procedural ]
quota: { usd, rate, concurrency, … }  # 10 Achsen, geprüft vor dem Spend

Häng ein Component an → der Skill ist live.
Zwei Skills auf überlappenden Components → emergentes Reasoning, keine Orchestrierung.

11 Manifest-Feldgruppen · 9 work_types · 0 Registry-Services

Component anhängen, der Skill ist live

0 Registry-Services

Ein Projekt hängt SkillManifest-Components an die richtigen Entities; das Reasoning-Tier greift sie auf über registry.view<SkillManifest, SkillSubscriptions>. Kein Skill-Registry-Service, kein Loading-Pattern, kein Setup-Endpoint pro Projekt - die Kompositionslogik lebt in der Query, nicht in einer Orchestrierungsschicht.

Eine Skill-Entity, jedes passende Projekt

1 Entity · N Projekte

Ein einzelner, zentral verfasster Skill - etwa ein Lore-Konsistenz-Checker - lebt einmal als Entity und traversiert den geteilten V-3-Verbund-Graphen über Projektgrenzen, ohne Install pro Projekt. Zwei Projekte mit überlappenden Subscriptions bekommen überlappendes emergentes Reasoning, ohne voneinander zu wissen.

Ein Skill kann physisch nicht außerhalb seiner Lane schreiben

11 Manifest-Feldgruppen

Das Manifest ist die einzige Autorität über das Verhalten eines Skills. Emittiert ein Skill - durch Bug, Prompt Injection oder LLM-Drift - einen Intent-Typ, den er nicht deklariert hat, wird der Write abgewiesen und als Lane-Violation geloggt. Die reads-Liste ist genauso strikt - ein nicht deklariertes Component kommt nicht einmal in den Prompt, eine Default-Privacy-Zeile unter DSGVO/LGPD.

Deklarier, was du brauchst, nicht welches Modell

9 work_types · 7-Schritte-Resolution

Ein Skill deklariert einen work_type wie reasoning_heavy, keinen Modellnamen. Provider wechseln ist eine Engine-Config-Änderung ohne Skill-Code-Edit, deterministisch in sieben Schritten aufgelöst und voll geloggt - resolved_backend_id, was_fallback, was_degraded und ein voller Trace pro Inferenz.

Reasoning schreibt State nie direkt

source:skill vs. source:player

Skill-Outputs werden als *Intent-Components mit source:skill geloggt; Spieler-Inputs als *Intent mit source:player; die World konsumiert beide identisch. Diese eine Lane-Regel hält eine ASE-Welt allein aus Inputs reproduzierbar - ein Replay kann geloggte Intents wiederverwenden oder frisches Reasoning neu würfeln.

Memory, modelliert nach menschlicher Kognition

9 Collections

Skill-Memory sind neun MongoDB-Collections entlang der Tulving/Squire-Klassifikation - episodisch, semantisch, prozedural, relational - mit Vektorindizes auf den drei semantischen. Die Replica besitzt alle neun; Reasoning fasst MongoDB nie an. Spieler-Memory sitzt in einer DSGVO-/LGPD-Löschkaskade, getrieben von einem einzigen ase player forget.

Alles-kann-nichts-muss, fürs Reasoning

Komposition per Anhängen

Das Prinzip, das Welt-Entities regiert, regiert auch Skills: Ein Skill KANN alles abonnieren, was er deklariert, und MUSS nichts implizit tun. Verhalten wird per Component-Anhängen komponiert, nie von einem Koordinator verdrahtet - Reasoning ist einfach mehr ECS.

Zwei Skills, emergentes Reasoning

emergent

Zwei Skills auf überlappenden Components erzeugen kombiniertes Verhalten, das keiner allein deklariert. Das ist das LEGO-Versprechen: kein Orchestrierungscode, keine Integration - die Komposition ist emergent, exakt wie die Simulation darunter.

Quota gatet jeden Call, vor dem Spend

10 Achsen · pre-spend

Zehn orthogonale Quota-Achsen werden geprüft, bevor eine Inferenz läuft. Am harten Limit wird der Call nie abgesetzt - stattdessen wird ein QuotaExceededIntent geschrieben - ein prompt-injizierter oder durchdrehender Skill kann keine Kosten anhäufen, weil der Spend nie beginnt.

communication_pattern wählt die Lane

4 Lanes

Der communication_pattern eines Skills - standard, anti_cheat_lane, reasoning_pipeline oder engine_internal_bus - routet ihn auf die richtige Lane mit eigenen Caps und eigener Eskalationstiefe. Einmal im Manifest deklariert, von der Engine erzwungen.

Anti-Cheat ist nur ein weiterer Skill

Anti-Cheat-Lane

Verhaltens-Anomalie-Erkennung shippt als Skills auf einer dedizierten Anti-Cheat-Lane mit tieferen Eskalations-Caps und einer invertierten Spieler-Quota - je anomaler das Verhalten, desto mehr Analyse bekommt es. Gleiches Entity-Modell, umgedrehte Ökonomie.

Credentials, die der Skill nie sieht

60s-Lease

Kunden-LLM-Keys erreichen nie einen Skill. Reasoning holt für jede Inferenz ein frisches 60-Sekunden-Lease-Token über die Replica (max. 5 Renewals); ein Skill bekommt eine Capability, kein Secret - und ein kompromittierter Prozess kann nur stehlen, was in Sekunden wertlos wird.

Zur Laufzeit geboren, weg beim Abhängen

Lifecycle = Entity

Der Lifecycle eines Skills ist der Lifecycle einer Entity: Er wird lebendig, sobald sein Manifest-Component angehängt ist, und stoppt, sobald es entfernt wird. Kein Deploy-Schritt, keine Registrierung, kein Teardown-Skript - Spawnen und Despawnen ist die ganze Install-Story.

Reasoning ist ein Tier, kein Chatbot

4. Prozess-Plane

Das Reasoning-Tier ist eine eigene, horizontal skalierbare Prozess-Plane neben Engine, Replica und World - kein API-Call, der an eine Render-Loop geschraubt ist. Sprachbasierte Arbeit lebt dort, wo sie nach eigenen Regeln skaliert, quotiert und auditiert werden kann.

Zwei Kostenschichten, pro Skill

cost_layer

Ein cost_layer-Feld entscheidet, wer zahlt: Engine-interne Skills fahren auf dem flachen ASE-Abo; Skills, die dein eigenes Modell aufrufen, gehen direkt auf deine Provider-Rechnung. Der Operator subventioniert nie deine Inferenz und streckt nie deine Tokens vor.

Die World kann Skill nicht von Spieler unterscheiden

beides sind *Intent

Skill-Outputs und Spieler-Inputs kommen beide als *Intent-Components an; die World wendet sie nach denselben Regeln an und verzweigt nie auf ihre Herkunft. Genau diese Symmetrie lässt ein nicht-deterministisches Tier auf einer deterministischen Simulation sitzen.

Vektorsuche auf drei von neun

semantisches Memory

Von den neun Memory-Collections tragen die drei semantischen Vektorindizes für Ähnlichkeits-Recall; episodisches und prozedurales Memory bleiben Exact-Match. Reasoning hält nur ECS-Referenz-Pointer hinein - die Replica besitzt den Store.

Ein Kommando löscht einen Spieler

ase player forget

Betroffenen-Löschung ist ein einziges Operator-Kommando: ase player forget kaskadiert eine DSGVO-/LGPD-Löschung über alle neun Memory-Collections auf einmal. Privacy ist eine eingebaute Operation, kein manuelles Durchkämmen der Stores.

Jede Inferenz hinterlässt einen Trace

voll auditierbar

resolved_backend_id, backend_pool_version, was_fallback, was_degraded und ein voller Resolution-Trace werden pro Call geloggt. Welches Modell geantwortet hat, ob es zurückfiel und ob es degradierte, lässt sich für jede Inferenz im Nachhinein rekonstruieren.

Untätige Skills kosten nichts

subscriben, nicht pollen

Skills reagieren auf Component-Änderungen über Subscriptions, nicht über eine Polling-Schleife. Ein Skill ohne Anlass setzt keine Inferenz ab und gibt nichts aus - Aufmerksamkeit und Kosten folgen dorthin, wo die Simulation sich tatsächlich ändert.

Frag, warum ein Skill ein Backend wählte

Audit-Query

ase reasoning Audit-Query --skill <id> liefert die Resolution-Traces für jeden Skill über jeden Zeitraum. “Warum landete dieser Skill auf Backend X?” hat eine konkrete Antwort im Nachhinein, kein Schulterzucken.

Drei Flow-Patterns, mehr nicht

3 Patterns

Jede Reasoning-Tier-Interaktion reduziert sich auf drei benannte Flow-Patterns. Reasoning-Domain-Module und LLM-Plugins implementieren sie; Phasenpläne referenzieren das Pattern beim Namen, statt es neu zu choreografieren. Die Kognitionsschicht hat eine Grammatik.

Skills, die sich selbst tunen

Closed Loop

Eine Tuning-Policy kann Model-Class oder Backend eines Skills wechseln oder eine andere Manifest-Version pinnen, wenn Live-Kosten-und-Qualitäts-Telemetrie eine Schwelle kreuzt - data-driven, ohne hartkodierte Modellnamen und ohne Sonderfälle pro Skill. Das System tunt sich selbst.

Erst lokal antworten

local_resolution

A local_resolution Manifest-Block lässt Resolution-Schritt 0 fragen: “Kann das auf der Edge beantwortet werden, ohne Egress?”, bevor irgendein Cloud-Call erwogen wird. Günstige, private, lokale Kognition wird zuerst probiert - der ökonomische Schlussstein von Reasoning im Planetenmaßstab.

Der Engine-interne Bus ist versiegelt

lane-enforced

Ein Skill mit cost_layer engine trägt einen Lane-Marker, der seinen Output nur zu anderen Engine-Cost-Skills routet, nie zu Kunden-Skills - erzwungen auf Wire-Ebene im Decode der Replica. Interne Kognition kann nicht auf eine Kunden-Lane lecken.

// Planbare Kosten

Am harten Limit startet die Inferenz gar nicht erst - Kosten können nicht driften.

Das Reasoning-Tier gatet jeden LLM-Call hinter zehn orthogonalen Quota-Achsen. Ein prompt-injizierter oder durchdrehender Skill kann keine Rechnung auftürmen, weil der Spend nie beginnt. Indie-freundliche Caps sind eine Eigenschaft der Architektur, kein Versprechen.

Achse 01USD-Kosten

Achse 02Rate-Limit-Slots

Achse 03Memory-Speicher

Achse 04Concurrency

Achse 05Player-Spam

Achse 06Eskalationstiefe

Achse 07Projektübergreifende Reads

Achse 08Edge-Subscription

Achse 09Blast-Radius / Skill

Achse 10Blast-Radius / Projekt

ein Inferenz-Fordere → alle 10 Achsen geprüft vor jedem Spend → pass · der Call läuft fail · nie abgesetzt → QuotaExceededIntent

Hartes Limit = Inferenz nicht gestartetder Spend beginnt nie

Am harten Limit wird der Call nicht gedrosselt, er wird nie abgesetzt - stattdessen wird ein QuotaExceededIntent geschrieben. Ein prompt-injizierter oder durchdrehender Skill kann keine Kosten anhäufen, weil die Inferenz gar nicht erst beginnt.

Volle Token- und USD-Transparenz, pro InferenzDashboard pro Skill

Jeder Call protokolliert resolved_backend_id, backend_pool_version, was_fallback, was_degraded und einen vollen Resolution-Trace. Das Kunden-Dashboard aggregiert Kosten pro Skill, aufgeschlüsselt nach Backend, Fallback-Rate und Degradations-Rate - du liest die Rechnung Zeile für Zeile.

Zwei Kostenschichten, nie gekreuzt2 Schichten

Operator-Infrastrukturkosten und deine LLM-Inferenzkosten sind strukturell getrennt. Der Operator subventioniert nie Kunden-LLM-Spend und hostet nie Kunden-Abo-Tokens - die beiden Rechnungen können einander nicht kontaminieren.

Zehn orthogonale Quota-Achsen10 Achsen

USD-Kosten, Rate-Limit-Slots, Memory-Speicher, Concurrency, Player-Spam, Eskalationstiefe, projektübergreifende Reads, Edge-Subscription und zwei Blast-Radius-Achsen - alle zehn müssen erfüllt sein, bevor eine einzige Inferenz läuft.

Gedeckelt pro Skill, Spieler, Projekt, Backendvierfach gedeckelt

Jede Achse wird pro Skill, pro Spieler, pro Projekt und pro Backend erzwungen - keine einzelne Dimension kann durchgehen. Planbare Caps sind eine Eigenschaft der Architektur, kein Versprechen auf einer Pricing-Seite.

Forecast auf ±5%±5%

Mit einem korrekt deklarierten Skill-Manifest landen Kosten-Forecasts bei etwa fünf Prozent Abweichung - weil die Caps deklarativ sind, ist die Rechnung planbar, bevor du shippst, nicht im Schock hinterher abgeglichen.

Entwickle auf Abo, shippe auf Capsedge → cloud

Entwicklung läuft edge_only auf deinem eigenen flachen CLI-Abo; Produktion flippt auf gedeckelte, auditierbare Cloud-Abrechnung. Die teure Iterationsphase berührt nie getaktete Tokens - Kostendisziplin wird erzwungen, bevor Geld fließt.

Frag die Rechnung pro Skill abAudit-Query

ase reasoning Audit-Query --skill <id> liefert die Resolution-Traces hinter dem Spend eines Skills über jeden Zeitraum. Die Rechnung ist keine Blackbox - du kannst fragen, welches Backend geantwortet hat, wie oft es zurückfiel und was es gekostet hat.

cost_layer entscheidet, wer zahltengine / game

Der cost_layer eines Skills ist entweder engine (fährt auf dem flachen ASE-Abo) oder game (geht auf deinen eigenen Provider). Die Abrechnungsachse steht im Manifest - wer eine Inferenz bezahlt, ist nie eine Überraschung auf einer Rechnung.

Günstigster Pfad zuerst: lokale Resolutionnull Egress

Resolution-Schritt 0 fragt, ob ein Call lokal auf der Edge ganz ohne Egress beantwortet werden kann, bevor irgendein bezahltes Cloud-Backend erwogen wird. Der Null-Kosten-Pfad wird per Konstruktion zuerst probiert - der ökonomische Schlussstein skalierender Kognition.

Quota persistiert ohne Bridgefire-and-forget

Das Reasoning-Tier schickt Quota-Inkremente fire-and-forget an die Replica, die sie in einen dedizierten Quota-State persistiert - kein extra Bridge-Service, kein synchroner Write im Hot Path. Buchhaltung bremst nie eine Inferenz.

Das System tunt auf ein Ziel zuMin-Qualität @ Max-Kosten

Eine Auto-Tune-Policy drückt ein Ziel aus - minimale akzeptable Qualität bei maximalen Kosten - und wechselt Backend oder Model-Class eines Skills, wenn Live-Telemetrie die Schwelle kreuzt. Kosten/Qualität ist ein Regler, den du setzt, keine Rechnung, die du später auditierst.

Flache Grenzkosten pro Projekt1001 ≈ 1000

Projekte teilen sich ein Substrat - ein Graph, ein Hub-/Almanach-Namensraum - also kostet das 1001. Projekt ungefähr so viel wie das 1000. Es gibt keine Datenbank und kein Compute pro Projekt zu provisionieren, und keine Kosten-Klippe pro Projekt.

Bring your own AI, während der Entwicklungedge_only

Iteriere gegen dein eigenes CLI-Abo, während du baust; Produktion flippt mit einem Manifest-Schalter auf gedeckelte Cloud-Abrechnung. Die Phase, in der du am meisten Inferenz verbrennst - die Entwicklung - berührt getaktete Tokens überhaupt nie.

Kosten sind ein Manifest-Feld, kein Rätseldeclared

Quota, cost_layer und Model-Class werden pro Skill im Manifest deklariert. Spend wird vorab designt - du kannst das Kostenprofil eines Skills lesen, bevor er je läuft, statt es auf der Rechnung nächsten Monat zu entdecken.

Eskalation und Blast-Radius sind gedeckeltbegrenzte Reichweite

Zwei der zehn Quota-Achsen begrenzen, wie weit ein einzelner Skill eskalieren darf und wie breit seine Wirkung reichen kann. Ein durchdrehender oder prompt-injizierter Skill kann sich nicht in einen unbegrenzten Spend verketten - die Reichweite ist gedeckelt, nicht nur die Kosten pro Call.

Indie-freundliches Pricing mit planbaren Caps. Bring your own AI während der Entwicklung.

✓ Planbare Caps - kein getaktetes Durchdrehen, keine Überraschungsrechnungen

✓ Entwickle auf deinem eigenen AI-Abo, shippe auf gedeckelter Cloud-Abrechnung

✓ Kostendisziplin erzwungen, bevor Geld fließt, nicht hinterher abgeglichen

// Anti-Cheat als vollwertiges Reasoning

Reasoning erkennt, World verhängt Quarantäne, Engine sanktioniert - ein Mensch signiert den Bann.

Anti-Cheat ist ein eingebauter Reasoning-Use-Case mit einer dreistufigen Autoritätshierarchie, die in Irreversibilität eskaliert - und davor haltmacht, je ein LLM allein einen Spieler bannen zu lassen.

// warum ab Stunde eins, nicht nach Launch

Jedes MMO kämpft gegen dieselbe Fäulnis: Bot-Farming, Exploits, Griefing, gedupte Items, galoppierende Inflation. EVE Online, World of Warcraft, Star Citizen: Jede langlebige Welt hat sie öffentlich bekämpft, und die Lektion wiederholt sich. Enforcement, nach Launch angeschraubt, kommt zu spät; die Ökonomie ist schon vergiftet, der Wipe folgt, die Spieler gehen. ASE ist gegen diese Geschichte gebaut ab Stunde eins, mit drei Jahrzehnten MMO-Erfahrung in die Architektur eingefaltet: Erkennung, Quarantäne und menschlich signierte Sanktionen sind Engine-Primitive, kein Post-Launch-Patch.

reversibleAnomalyIntentReasoning erkennt

→

reversibleQuarantineStateWorld verhängt Quarantäne

→

irreversiblePlayerSanctionStateEngine sanktioniert · ein Mensch signiert

Drei Autoritäts-Tiers, eskalierende Irreversibilität

3 Tiers

Reasoning schreibt einen reversiblen AnomalyIntent (Score + Kategorie + Evidenz-Pointer). World akkumuliert sie deterministisch in einen reversiblen QuarantineState. Nur die Engine schreibt den irreversiblen PlayerSanctionState - der eine human_reviewer_id und einen Audit-Trail verlangt. Die recommended_action eines Skills kann monitor, quarantine oder review sein, aber nie ban.

Eine Detektor-Suite, die du pro Projekt aktivierst

4 Detektoren

Das Design umfasst Engine-Cost-Detektoren, die jedes Projekt aktivieren kann: BehaviorWatcher (Verhaltensanomalien), CoordinationDetector (Multi-Account-Muster), EconomyAuditor (ökonomische Exploits) und MovementValidator (Speed-Hack/Teleport, reasoning-augmentiert über dem deterministischen Fast-Check der World).

Verdächtige Spieler werden mehr beobachtet, nicht weniger

invertierte Quota

Anti-Cheat-Skills tragen eine invertierte Spieler-Quota - je anomaler das Verhalten, desto mehr Analyse bekommt es - und laufen auf einer dedizierten Kommunikations-Lane mit tieferen Eskalations-Caps. Die Ökonomie ist absichtlich umgedreht.

Determinismus überlebt ein nicht-deterministisches Tier

replayable

Weil Reasoning immer nur Intents schreibt, nie simulativen State, bleibt eine ASE-Welt allein aus Inputs reproduzierbar. Ein Replay kann geloggte Skill-Intents für eine perfekte Reproduktion wiederverwenden oder frische Reasoning-Calls für nicht-deterministische Re-Generierung absetzen - deine Wahl, nur möglich wegen der Lane-Regel.

Deine API-Keys: gespeichert, nie gesehen

60s-Leases · max. 5 Renewals

Kunden-LLM-Credentials leben in einem dedizierten 3-Knoten-Vault-Cluster (Raft, Auto-Unseal), auf Storage-Ebene von Engine-Credentials getrennt. Die Operator-Identität hat keine Read-Policy auf Kundenpfade, und Reasoning hat keinen direkten Vault-Zugriff - jede Inferenz holt ein frisches 60-Sekunden-Lease-Token, max. 5 Renewals, vermittelt über die Replica. Ein kompromittierter Reasoning-Prozess kann nur kurzlebige Tokens stehlen, die schnell wertlos werden.

Ein Mensch signiert jeden Bann

human-in-loop

Die irreversible Sanktion kann nur die Engine schreiben, und sie verlangt eine human_reviewer_id plus einen Audit-Trail. Ein LLM kann monitor, quarantine oder review empfehlen - es kann nie allein einen Spieler bannen. Automation eskaliert; ein Mensch entscheidet.

Deterministischer Fast-Check, semantischer Slow-Check

<1s / <30s

MovementValidator fährt einen deterministischen Speed-/Teleport-Check auf der World in unter einer Sekunde; reasoning-augmentierte Mustererkennung liefert dann semantischen Kontext in unter dreißig. Zwei Geschwindigkeiten, ein Urteil - billige Gewissheit zuerst, teure Nuance danach.

Quarantäne ist reversibel, Sanktion nicht

reversibel → final

QuarantineState akkumuliert deterministisch aus AnomalyIntents und kann aufgehoben werden; nur die finale Sanktion ist permanent. Eskalation läuft immer von reversibel nach irreversibel, nie andersherum - ein False Positive kostet eine aufgehobene Quarantäne, keinen unrechtmäßigen Bann.

Kollusion über Accounts hinweg

multi-account

CoordinationDetector sucht nach Mustern, die ein einzelner deterministischer Check nicht sehen kann - synchronisiertes Timing, Ökonomie-Flüsse und Bewegungskorrelation über Accounts - als LLM-Mustererkennungs-Skill. Kontext ist genau das, was deterministischem Anti-Cheat fehlt.

Ökonomie-Auditing, eingebaut

economy

EconomyAuditor achtet auf Dupe-Loops, Marktmanipulation und unmögliche Vermögenskurven - als Engine-Cost-Skill, den jedes Projekt einschaltet, kein Service, den du integrierst. Die Ökonomie ist simuliert, also sind ihre Exploits lesbar.

Evidenz-Pointer, kein Rohdaten-Dump

auditable

Ein AnomalyIntent trägt einen Score, eine Kategorie und einen Evidenz-Pointer - Reasoning referenziert ECS-State, es kopiert ihn nicht. Der Audit-Trail bleibt schlank, die World bleibt autoritativ, und jede Entscheidung ist aus denselben Inputs reproduzierbar.

Kein Kernel-Treiber, kein Client-Scanning

nur serverseitig

Erkennung ist verhaltensbasiert und lebt auf dem Server - ASE shippt keinen Anti-Cheat-Kernel-Treiber und scannt den Speicher keines Spielers. Cheaten wird erkannt an dem, was ein Spieler does in der Simulation, nicht durch Überwachung seiner Maschine.

Server-autoritativ per Konstruktion

World besitzt den State

Die World hält den autoritativen State; Client-Input kommt auf dem unreliable Channel an und wird serverseitig validiert. Ein gehackter Client kann anfragen, aber nicht behaupten - er darf nie State schreiben, den die Simulation nicht berechnet hat.

Verhaltensanomalie, keine Regelliste

neuartige Exploits

BehaviorWatcher flaggt statistische Anomalien per LLM-Mustererkennung und fängt damit neuartige Exploits, die eine feste Regelliste nie gesehen hat. Der Detektor denkt über Verhalten nach, statt eine Signatur zu matchen, die Angreifer längst kennen.

Eskalationstiefe ist eine gedeckelte Achse

quota-bounded

Wie weit ein Anti-Cheat-Skill eskalieren darf, ist eine der zehn Quota-Achsen - mit bewusst höherem Cap auf der Anti-Cheat-Lane. Selbst die Wächter laufen im selben begrenzten, auditierbaren Kostenmodell wie alles andere.

Kontrolle skaliert horizontal

mehr Compute, kein Flaschenhals

Anti-Cheat läuft als Reasoning-Skills auf dem eigenen, horizontal skalierbaren Tier - einen verdächtigen Spieler schärfer zu beobachten ist mehr Compute, nie ein Stillstand in der Game-Loop. Enforcement kann wachsen, ohne dass die Simulation dafür zahlt.

Ein unveränderlicher Audit-Trail

append-only

Jede Sanktion protokolliert die human_reviewer_id, den Evidenz-Pointer und einen Zeitstempel in einem Append-only-Trail. Ein Einspruch spielt exakt den Datensatz ab, der zur Entscheidung führte - keine nachträglich geschriebene Zusammenfassung.

Der Intent ist Score, Kategorie, Evidenz

meldet, entscheidet nicht

Ein AnomalyIntent trägt nur einen numerischen Score, eine Kategorie und einen Pointer auf den ECS-State, der ihn auslöste. Er meldet; die World entscheidet, was akkumuliert wird, und die Engine entscheidet, ob je ein Mensch ihn sieht.

Beobachten läuft auf getakteter Quota

begrenzte Kontrolle

Anti-Cheat-Inferenz ist quotiert wie jeder andere Skill - Score, Rate und Eskalationstiefe sind alle gedeckelt. Kontrolle hat begrenzte, auditierbare Kosten - die Enforcement-Seite kann so wenig durchdrehen wie die Spielseite.

Erkennung verbessert sich ohne Patch

Manifest, kein Release

Weil BehaviorWatcher über Verhalten nachdenkt, statt eine feste Regelliste zu matchen, ist ihm ein neues Exploit-Muster beizubringen eine Manifest- und Prompt-Änderung - kein Engine-Release. Die Wächter lernen schneller als ein Patch-Zyklus.

Ein False Positive ist billig

reversibel by Design

Weil alles unterhalb der finalen Sanktion reversibel ist, kostet ein falsches Flag eine aufgehobene Quarantäne, keinen unrechtmäßigen Bann. Die Eskalation ist so gebaut, dass der teure Fehler - eine schlechte permanente Sanktion - der ist, den ein Mensch signieren muss.

// Welten, die du bauen kannst

Aetheria: 9.000 prozedurale Planeten, die in eine gemeinsame Welt kollabieren.

Das sind keine Features von ASE - das sind Welten, die MIT ihr gebaut werden. Aetheria ist der Beweis im Entstehen, so wie Fortnite Unreal beweist. Mythisch an der Oberfläche, mechanisch darunter.

9,000→1

Reinkarnation kollabiert das Multiversum - eine Seele bindet sich an Fleisch, jeder nicht gegangene Pfad hört auf zu existieren, und eine irreversible, gemeinsame Welt bleibt.

9.000 Planeten · 6 Phasen

9.000 Planeten, nicht 9.000 Shards

Aetheria generiert 9.000 prozedurale Planeten, die Geburtsorte sind, keine Parallel-Server. Jeder prägt einen Charakter über sechs Phasen - Genetik, Physis, Berufung, Theologie, Psyche, Transzendenz - so wird prozedurale Vielfalt zur kulturellen, genetischen und spirituellen Diversität einer gemeinsamen Welt.

9.000 → 1

Reinkarnation kollabiert das Multiversum

Eine Seele bewegt sich als Superposition durch ungewählte Zukünfte; jede Entscheidung spawnt einen Zweig, jedes verworfene Genom kollabiert endgültig. In dem Moment, in dem sie sich an Fleisch bindet, hören alle 9.000 Planeten und jeder nicht gegangene Pfad auf zu existieren - eine irreversible, gemeinsame Realität, persistiert nach MongoDB und Neo4j.

5% / 10% / 15% / >15%

Eine Welt mit Immunsystem

Antarien ist kein Körper, sondern ein Organismus - Mater Dormiens, die schlafende Mutter. Ein datengetriebener Wund-Index, gekoppelt an den Bergbau, eskaliert: Unter 5% schläft sie; bei 5–10% verheilen Furchen und Werkzeug korrodiert; 10–15% bringt Beben, Gravitationsanomalien und Giftgas; über 15% pulsieren und glühen die Nervenbahnen unter dem Meeresboden, während sie erwacht.

1 Universum

Ein Organismus, zwei Spiele, keine Shards

Die Konvergenz übergibt einen Charakter aus dem Prequel Aetheria in die persistente Welt Antares Open World per serverseitigem Handoff - ein globales Universum, jeder Spieler, keine Instanzen. Der volle Datensatz (Seed, Biom, Genetik, Theologie, Psyche) wird permanent und irreversibel.

5 Charaktere

Fünf Seelen, ein Spieler

Jeder Spieler betreibt fünf Resonanzkammern - fünf Charaktere, fünf Claims, fünf Startzonen, alle gleichzeitig lebendig. Einen steuerst du; die anderen vier laufen KI-getrieben, mit einem Seelensprung zum Wechseln. Eine Glühwürmchen-Schwarmintelligenz-Brücke pendelt zwischen deinen eigenen Charakteren entlang des Cruor-Netzwerks.

das Pyramiden-Paradox

Prequel-Wissen wird zum Kompass

Bei der Reinkarnation geht das bewusste Gedächtnis verloren, aber der Körper behält alles - Genetik, Berufung als Muskelgedächtnis, Seelenfarben-Prädispositionen. Der Spieler weiß, was der Charakter nicht wissen kann: Die “heiligen Steine” sind geronnenes Blut, die “Erdbeben” sind eine Kreatur, die sich umdreht, die Schreine sind die dünnsten Stellen in atmender Haut.

offen gebaut

Die Referenzwelt, in Zahlen

153 Components · 86 Systeme (null Violations), 13 Web-Submodule - das Schaufenster, das sagt: Damit lässt sich ein echtes Spiel bauen - und es reift täglich.

6 Phasen

Eine Person, kein Spawn

Genetik, Physis, Berufung, Theologie, Psyche, Transzendenz - jede Phase prägt den Charakter und macht aus einem prozeduralen Planeten eine Person mit Körper, Kultur, Glauben und Schicksal. Diversität wird eingeprägt, nicht aufgeklebt.

Schiff = Komet

Das Generationenschiff ist ein Komet

Das Gefährt, das Seelen zwischen Welten trägt, liest sich von außen als Komet - dasselbe Objekt ist zugleich der Mythos am Nachthimmel und der Mechanismus der Konvergenz. Nichts in der Welt ist nur Dekoration.

72 / 1,789 / 1,794

Lore konstruiert, nicht improvisiert

Die Welt ist als Neo4j-Design-Graph modelliert - 72 Module, 1.789 Use Cases, 1.794 Aktoren - bevor eine Zeile davon gespielt wird. Die Story hat eine Architektur, genau wie die Engine.

46.730 Sterne

Ein echter Nachthimmel

Die Sternkarte besteht aus 46,730 echten Körpern aus der HYG-Datenbank - der Himmel über Aetheria ist der reale Katalog, navigierbar und konsistent, keine gemalte Kulisse hinter der Action.

soul-jump

Fünf Leben, kein Logout

Du steuerst einen von fünf Charakteren; die anderen vier leben KI-getrieben weiter. Ein Seelensprung bewegt deine Aufmerksamkeit zwischen ihnen entlang des Cruor-Netzwerks - fünf Claims, fünf Startzonen, eine kontinuierliche Präsenz in der Welt.

das Cruor-Netzwerk

Eine Glühwürmchen-Brücke zwischen Seelen

Eine Glühwürmchen-Schwarmintelligenz-Brücke pendelt zwischen deinen eigenen Charakteren entlang des Cruor-Netzwerks. Zwischen deinen fünf Leben zu wechseln ist kein Menü-Toggle - es ist eine Reise durch ein lebendiges System, das sie verbindet.

Prequel → persistent

Aetheria schmiedet, Antares bewahrt

Aetheria ist das Prequel, in dem eine Seele über die sechs Phasen geschmiedet wird; Antares Open World ist die persistente Welt, in der sie dann lebt. Zwei Spiele, ein kontinuierliches Universum - die Konvergenz ist die Naht dazwischen.

MongoDB + Neo4j

Gebundene Realität, niedergeschrieben

In dem Moment, in dem eine Seele sich an Fleisch bindet, persistiert der volle Datensatz - Seed, Biom, Genetik, Theologie, Psyche - nach MongoDB und Neo4j als permanenter, irreversibler Fakt. Die Lore wird nicht erzählt; sie wird gespeichert.

// Die Modul-Wand

Dreiundachtzig L3-Simulationsmodule, verdrahtet über einen Hub.

Die Engine ist kein Monolith - sie ist ein Stern unabhängiger L3-Module, die Outputs schreiben und einander über einen Communication Hub lesen, mit null direkter Kopplung. Jedes L3-Modul im Baum unten - jedes mit eigenem Marker, mit seiner echten Reife.

// Architektur in Schichten

Sechs Schichten. Abhängigkeiten zeigen immer nur nach unten.

ASE ist in strikten Schichten gebaut, L0 bis L5 - und die Linie zwischen Engine und Spiel läuft mitten durch sie. Engine-Entwickler besitzen L0–L3; du baust dein Spiel in L4 und L5 und siehst nichts außer dem ase-sdk-Header.

L0Foundation

L1Core

L2Kernel

L3Module

L4Plugins

L5Server & Clients

▸ Jede Schicht hängt nur nach unten ab. Keine Ausnahmen.

L0

Foundation

ase-math · ase-types · ase-utils · ase-containers · ase-json

Vektor, Matrix, Noise und Interpolation ohne Abhängigkeiten. Bewusst pur - kein ECS - damit nichts nach unten lecken kann. Jedes Simulationssystem darüber rechnet auf diesem Fundament.

L1

Core

ase-ecs · ase-log · ase-neo4j · ase-mongodb

Das EnTT-wrappende ECS, Logging und die Neo4j- und MongoDB-Clients. Neo4j hält Beziehungen und Hierarchien; MongoDB hält Chunks, State und Snapshots.

L2

Kernel

ase-kernel

Der Herzschlag: Game Loop, dlopen-Modul-Loader und der eigene Tiered Scheduler - 66 Schedules über 21 Tiers, bewusst nicht Bevy, von Once-per-Life-Init bis zu 60-Hz-Frames.

L3

Module · 83 Stück

ase-hub · ase-weather · ase-replication · ase-foodchain · ase-perception …

Die Engine selbst - die Simulationsmodule, verdrahtet über die Stern-Topologie von ase-hub, ohne direkte Modul-zu-Modul-Kopplung. Hier bekommen Milliarden Entities ihr Verhalten.

L4

Plugins · 27 Stück

ase-pl-erosion · ase-pl-sky · ase-pl-water · ase-pl-flora …

Hot-loadbare Shared Libraries, die der Kernel entdeckt, API-versionsprüft und per dlopen lädt. Fehlende Plugins degradieren sauber - der Server läuft auch ohne das Wetter-Plugin - so komponieren Spiele exakt die Systeme, die sie brauchen.

L5

Server & Clients

ase-server-world · ase-server-replica · ase-client-web

Die Vier-Tier-Server und der Browser-Client. Der World-Server ist der Compute-Prozess, in dem Physik, Ökologie und Wetter tatsächlich ticken; der Web-Client fährt becsy mit strikter 1:1-Parität zum C++-Backend.

Die Engine-/Spiel-Grenze2 Schichten, 1 Header

Engine-Entwickler besitzen Foundation bis Module; Spiele-Entwickler bauen nur L4-Plugins und L5-Server/-Clients, hinter dem einen ase-sdk-Header. Diese Kapselung ist, wie eine Person mit der Engine ein MMORPG baut statt einer Engine.

Dasselbe ECS, beide Seiten der Leitung1:1-Parität

EnTT auf dem C++-Server, becsy im Browser - view<A,B>() mappt auf query, on_construct auf added - SHARED-Components halten strikte 1:1-Parität. Ein SHARED-System rechnet deterministisch nach und kollabiert ~100 B × 20 Hz Broadcast auf ~4 B × 1 Hz: Schick den Seed, nicht das Ergebnis.

Abhängigkeiten zeigen nur nach untenL0 ← L5, eine Richtung

L5 nach L0, strikt: Eine höhere Schicht darf nach unten greifen, nie nach oben oder zur Seite. L0 Foundation (Mathe, Typen, Utils) hat null ECS-Abhängigkeit - nichts kann aufwärts in das Fundament lecken, auf dem die ganze Simulation rechnet.

L2 Kernel: der Herzschlag66 Schedules · 21 Tiers

Der Kernel fährt die Game Loop, den dlopen-Modul-Loader und einen eigenen Tiered Scheduler - 66 benannte Schedules über 21 Tiers, von Once-per-Life-Init bis zu 60-Hz-Frames. Bewusst nicht Bevy; alles darüber tickt seinetwegen.

L1 Core: ECS plus die DB-ClientsNeo4j + MongoDB

Das EnTT-wrappende ECS, Logging und die Clients für Neo4j (Beziehungen, Hierarchien) und MongoDB (Chunks, State, Snapshots) - die heiße Echtzeitschicht plus die Persistenz der Data Plane, eine Ebene unter den Modulen gehalten.

L4-Plugins laden hot und degradierenhot-loadable

Plugins sind per dlopen geladene Shared Libraries mit API-Versions-Checks; ein fehlendes Plugin degradiert sauber - der Server läuft auch ohne das Wetter-Plugin - so komponiert ein Spiel exakt die Systeme, die es braucht, nicht mehr.

L3 ist die Engine selbst83 Module

Dreiundachtzig Simulationsmodule, verdrahtet über die Stern-Topologie von ase-hub, ohne direkte Modul-zu-Modul-Kopplung - die Schicht, in der Milliarden Entities ihr Verhalten bekommen und neue Kausalität ein Component-Feld kostet.

L0 Foundation hat kein ECSpures Fundament

Mathe, Typen und Utils sitzen ganz unten und hängen von nichts darüber ab - nicht einmal vom ECS. Das Fundament, auf dem die ganze Simulation rechnet, bleibt frei von Engine-Kopplung, damit nichts hineinlecken kann.

Die Integrationsschicht ist main.cppeine Ausnahme

Systeme rufen einander nie auf - die einzige sanktionierte Ausnahme sind die HTTP-Handler im main des Servers, die Integrationsschicht. Überall sonst spricht Logik nur über Components - das hält das Ganze komponierbar.

L5: die Server und Clients, die du shippstR3F + becsy

Ganz oben fährt ase-server-game die Welt, und ase-client-web rendert sie im Browser mit React-Three-Fiber über einem becsy-ECS. Beide sind L5, gebaut auf allem darunter - die einzigen Schichten, die die meisten Spiele-Devs je anfassen.

// Für wen das ist

Die Engine für AI-native MMORPGs. Für alles andere gibt es weiterhin Unreal.

ASE ist scharf fokussiert, und es lohnt sich, ehrlich zu sagen, wer heute darauf bauen sollte - und wer nicht. Komplementär by Design, nicht kompetitiv.

Für den Solo-Erbauer einer lebendigen Welt

2 Schichten, 1 Header

Wenn du ein LLM-getriebenes MMORPG als eine Person bauen willst - es an einer Werkbank designen und als Schöpfer außerhalb davon stehen - ist ASE für genau das gebaut. Spiele-Devs fassen zwei Schichten und einen Header an; häng die Components an, die du willst, und die volle Simulationskaskade kommt gratis, wo immer du etwas angehängt hast.

Für Planetensimulation jenseits von Spielen

7+ Domänen

Weil ASE echte Kausalsysteme simuliert, statt Kulisse zu rendern, zielt dasselbe Substrat auf Klimaforschung (CO²- und Temperaturzyklen), Ökologie (invasive Arten, Aussterben), Stadtplanung, Geologie über Jahrmillionen, Evolution und Populationsdynamik, Bildung und generative Kunst.

Für Teams, die LLM-nativ wollen, nicht angeschraubt

Ein dediziertes Reasoning-Tier, Skills als ECS-Entities, BYO-AI-Ökonomie und Anti-Cheat als vollwertiger Use-Case - Reasoning ist eine Prozess-Plane in der Architektur, kein Chatbot, der seitlich an eine Render-Loop getackert ist.

Nicht für deinen nächsten Photoreal-FPS

ASE optimiert auf simulierte Bedeutung und planetaren Maßstab, nicht auf den hochauflösendsten Render eines kleinen handgebauten Levels. Das ist eine bewusste Grenze: Für AI-native MMORPGs bau mit ASE; für alles andere gibt es weiterhin Unreal.

Ehrlich darüber, wo es steht

Closed Beta kommt

ASE wird offen gebaut und reift täglich. Architektur und Vision sind durchdacht, die Implementierung läuft, eine Closed Beta kommt. Keine Behauptung von “fertig” - die Live-Build-Status-Leiter oben zeigt die echte Reife jedes Moduls, von seed bis refine.

Für die AI-Builder-Szene

AI-native

Wenn du in agentischer KI, Tool-Use und Skills-als-vollwertig denkst, wendet ASE diese Philosophie auf Welten an: Skills sind ECS-Entities, Reasoning ist ein föderiertes Tier mit Edge-Daemon. Kreuzbestäubung zwischen KI und Game-Dev, kein Genre-Schwenk.

Für Klima- & Erdsystemforschung

climate

CO²- und Temperaturzyklen, Hydrologie, Erosion über Deep Time - dieselbe GIS-geschichtete Simulation, die eine Spielwelt fährt, fährt einen Planeten, den du untersuchen kannst. Der Output ist Daten, nicht nur Kulisse.

Für Ökologie & Evolution

ecology

Invasive Arten, Aussterbekaskaden, natürliche Selektion und Populationsdynamik emergieren aus Entity-pro-Organismus-Simulation - ein Labor, in dem die Mechanismen lesbar sind, weil jeder Organismus eine vollwertige Entity ist, keine Spawn-Tabelle.

Nicht für einen Hobby-Platformer

Power, kein Händchenhalten

Wenn du ein Bau-dein-erstes-Spiel-in-30-Minuten-Tutorial willst, passen Unity oder Godot besser. ASE tauscht Händchenhalten gegen Power - es ist für die Leute, die die freundlichen Tools sonst ausbremsen, nicht für den freundlichen Pfad selbst.

Nicht für ein Single-Player-Story-Spiel

complementary

Für ein handgeschriebenes Single-Player-Narrativ ist Unreal das bessere Zuhause. ASE ist für lebendige, LLM-getriebene, persistente Welten - ein anderes Problem, anders gelöst, und bewusst nicht jedermanns Engine.

Für Stadtplanung & Logistik

cities

Verkehr, Lieferketten, Bevölkerungsströme und Infrastrukturlast modellieren sich natürlich als Agenten auf einer GIS-geschichteten Welt. Dasselbe Substrat, das eine Stadt im Spiel fährt, fährt eine Stadt, die du untersuchen willst - jedes Fahrzeug und jeder Bewohner eine vollwertige Entity.

Für Geologie über Deep Time

Deep Time

Erosion, Sedimentation und tektonische Veränderung über Millionen simulierter Jahre fallen aus derselben Geschichtete-Uhren-Architektur, die eine Pflanze mit 0.1 Hz und Stein mit 0.01 Hz tickt. Zeitskala ist ein Schedule-Tier, kein Sondermodus.

Für generative Kunst & Installationen

eine lebendige Leinwand

Eine Welt, die auf echter Ursache-Wirkung läuft, ist ein generatives Instrument: Seed sie, lass die Simulation atmen, und der Output ist emergent statt verfasst. Die Simulation ist der Inhalt - eine Leinwand, die sich selbst weitermalt.

Für KI- & Multi-Agenten-Forscher

Emergenz im Maßstab

Millionen gleichzeitiger Agenten mit echter Wahrnehmung, Memory und Reasoning machen ASE zum Testbett für emergente Multi-Agenten-Dynamik - keine Spielzeug-Grid-World. Verhalten komponiert sich aus Components - neue Experimente sind neue Daten, keine neuen Engines.

Für den Systems-first-Metagamer

Tiefe vor Politur

Wenn du tief ineinandergreifende Systeme liebst - die Linie EVE, Dwarf Fortress, Rimworld - ist ASE für genau diesen Instinkt gebaut: Alles ist simuliert, alles ist verbunden, und die Tiefe ist der Punkt, kein Schwierigkeitsgrad.

Für Bildung, als Instrument

den Mechanismus lehren

Eine Simulation, in der jeder Effekt eine lesbare Ursache hat, ist ein Lehrwerkzeug: Sieh zu, wie ein Wund-Index einen Planeten weckt, eine Nahrungskette kollabiert, eine Klimazone wandert - der Mechanismus ist sichtbar, weil er echt ist, nicht für die Lektion geskriptet.

Nicht für einen Weekend-Game-Jam

belohnt Tiefe

ASE belohnt das Bauen einer Welt, nicht das Shippen einer Szene bis Sonntagnacht. Wenn du einen Jam-Prototyp in 48 Stunden willst, passt eine leichtere Engine besser - ASE ist für den langen Bau, den eine tiefe, lebendige Welt tatsächlich braucht.

Was du baust · Starter Kits scaffolden ein Genre - dann baust du

space-sim - **ein Starter Kit, das die Engine mitliefert**

rpg-quest - **scaffolden ein Genre, dann baust du**

survival-3d - **ein Starter Kit, das die Engine mitliefert**

evolution-sim - **scaffolden ein Genre, dann baust du**

multiplayer-arena - **ein Starter Kit, das die Engine mitliefert**