ASE - Antares Simulation Engine · Baue LLM-getriebene MMORPGs. Als eine Person.

// Größenordnung

Ein Planet ist kein Level.

Klassische Engines laden ein Level, spielen es ab und werfen es weg. ASE verwaltet einen persistenten Planeten: Das Weltmodell ist auf Milliarden Entities ausgelegt und wird chunk-weise gestreamt.

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 im Weltmodell

0

Reconnects beim World-Handoff

0

L3-Sim-Module

0

L4-Plugins

0

Benannte Schedules

0

Ausführungs-Tiers

jede Pflanze eine Entity

Eine Wiese lebt von allein

Auf einer Wiese in ASE ist jede Pflanze eine Entity: Sie keimt, blüht, trägt Früchte und stirbt. Wälder wachsen über Jahre und vergehen wieder. Nichts davon wartet auf Publikum - und die Rechenlast folgt der Simulationsdichte, nicht der Spielerzahl: Ein dicht simuliertes Tal ohne einen einzigen Spieler kann teurer sein als eine Ebene voller Spieler.

GIS layers

Eine Welt, modelliert wie ein Kartendienst

Das Terrain ist ein Raster aus Heightmap-Chunks mit geografischen Datenschichten - Höhe, Feuchtigkeit, Temperatur, Biom, Geologie. Wetter, Vegetation und Kreaturen lesen diese Schichten und reagieren; Terrain-Veränderungen schreiben sie zurück. Der Planet ist ein gemeinsamer, geschichteter Datenbestand.

EnTT → MongoDB

Geladen wird, was gebraucht wird

Chunks entstehen und verschwinden dynamisch, während sich Spieler durch die Welt bewegen - mit LOD-Streaming nach Distanz. Entladene Chunks liegen persistiert in MongoDB und warten. Und jede Terrain-Änderung läuft über den Hub an Wetter, Vegetation und Kreaturen - die Welt reagiert als Ganzes.

32×32-Chunks

Der Chunk ist die Einheit von allem

Die Welt ist in Heightmap-Chunks unterteilt: geladen rund um Spieler, verändert durch Erosion, Wetter und Spieler, persistiert in MongoDB, wenn nichts sie braucht. Chunk-Regionen sind zugleich die Einheit der horizontalen Skalierung - ein World-Server besitzt eine Menge von Chunk-Koordinaten, mehr nicht.

66 Schedules / 21 Tiers

Die Tickraten-Ökonomie

Jedes System deklariert seinen Takt: Frame-Systeme ticken mit 60 Hz, Kinetic mit 30 Hz, Cyclic mit 1 Hz - 66 benannte Schedules über 21 Tiers. Pflanzen denken nicht im Frame-Takt, und genau das Nicht-Beschleunigen langsamer Prozesse macht die CPU frei, einen Planeten zu tragen.

ein Planet, simuliert

Das Ziel, klar benannt

Ganze Planeten mit Ökosystemen, jede Pflanze eine Entity, echte Physik, Wetter und Fluide, Spielerzahlen horizontal skaliert über Chunk-Regionen - kein Rendering 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.

player_muts: 0

Die Welt macht keine Pause

Die Welt simuliert sich auch ohne Spieler - im Terrain-Log ist player_muts: 0 der Normalfall. Die Erosion gräbt weiter, das Wetter zieht weiter, die Pflanzen wachsen weiter - ob jemand eingeloggt ist oder nicht.

entity-per-item

Keine Arrays, keine Obergrenzen

Components halten keine Arrays und keine Zähler: Ein Molekül mit N Elementen wird zu N Entities, ein Wald zu seinen einzelnen Bäumen. Strukturen sind unbegrenzt, weil eine Query sie durchläuft statt eines festen Slots - das Datenmodell kennt kein hartes 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 Kausalität kostet ein Component-Feld. Keinen Umbau.

Das Gründungsaxiom ist Architektur, kein Slogan: Alles ist verbunden, alles ist Entity, alles ist simuliert. Damit eine CPU das ausführen kann, gilt eine harte Disziplin - Systeme rufen einander nie auf. Sie kommunizieren ausschließlich über Components.

10 billion

OOP - mögliche Verbindungspfade bei 100k Entities

kollabiert zu →

100k

ASE - Component-Lookups pro System und Tick, dieselbe Welt

Die Primitive

Entity · Component · System 3: Eine Entity ist nur eine ID. Ein Component sind reine Daten ohne Methoden. Ein System ist zustandslose Tick-Logik. Dieses strenge Rückgrat erlaubt der Engine, jedes Blatt und jedes Bakterium als vollwertiges Objekt zu behandeln.
Components sind reine Daten POD: Reine Daten, keine Methoden, keine eigene .cpp-Datei - alles null-initialisiert, eine einzige Verantwortung. Verhalten steckt nie in den Daten; es lebt in zustandslosen Systemen. Diese Disziplin macht eine Milliarde Entities bezahlbar.
Alles kann, nichts muss: Jede Entity KANN jedes Component tragen, keine MUSS es. Bekommt ein Fels ein MetabolismComponent, beginnt er zu verstoffwechseln - ohne Klasse, ohne Vererbung, ohne Factory. Fähigkeiten werden angehängt, nicht vorab deklariert.
Tags statt Typ-Flags: Kein uint8_t-Typfeld, kein if-else-Dispatch. Ein View über PredatorTag fährt die Räuber-Logik, ein View über PreyTag die Beute-Logik. Neues Verhalten heißt: ein neuer Tag und ein neues System - kein weiterer Zweig in einem alten.
Ein View ist eine Query, keine Schleife: Kein switch, kein manueller Dispatch. Ein System öffnet einen tag-gefilterten View und bekommt exakt die Entities, die passen. Welche Logik greift, entscheiden die Components, die eine Entity trägt - aufgelöst von der Query selbst.

Kopplung

O(n²) → O(n) Pfade→Lookups: Bei 100k Entities hat OOP zehn Milliarden mögliche Verbindungspfade. In ECS ist dieselbe Welt 100k Component-Lookups pro System und Tick. Eine neue Kausalverbindung heißt: ein Feld schreiben - jeder Leser reagiert von selbst.
Components sind der einzige Kanal: Systeme rufen einander nie auf - das ist verboten. ase-sky kann ase-metabolism über ase-predator beeinflussen, ohne dass eines der drei die anderen beim Namen kennt. Die gemeinsamen Hub-Keys sind der gesamte Vertrag.
Der Hub ist ein Stern, kein Mesh: 83 L3-Module schreiben und lesen über einen zentralen Hub - ein Stern ohne direkte Modul-zu-Modul-Kopplung. Ein neues Modul fügt dem Zentrum eine Speiche hinzu, nie Kanten zu den anderen.
Systeme besitzen keinen State: Ein System hält keine Member-Variablen und merkt sich nichts zwischen zwei Ticks: Es liest Components, es schreibt Components, mehr nicht. Diese Zustandslosigkeit macht Systeme trivial parallelisierbar und beliebig kombinierbar.
Parallel, weil zustandslos: Ohne geteilten veränderlichen Zustand zwischen Systemen verteilt der Scheduler unabhängige Systeme ohne Locks über alle Kerne. Nebenläufigkeit ist nicht angeschraubt - sie ergibt sich aus derselben Disziplin, die die Verdrahtung überflüssig macht.

Das Datenmodell

Neues Verhalten = neue Daten 0 Recompiles: Das Schema lebt in den Daten, nicht im Code. Ein neuer Typ oder ein neues Verhalten heißt: Entities spawnen und Components anhängen. Arrays in Components sind verboten, Strukturen bleiben unbegrenzt - und nichts davon braucht einen Rebuild.
Entity-per-Item, nie Arrays: Components halten keine Arrays und keine Zähler. Ein Molekül mit N Elementen wird zu N Entities, jede einzeln getaggt - Strukturen bleiben unbegrenzt, und eine Query durchläuft sie, keine Schleife. Das Modell kennt keine festen Slots.
Data-driven, nicht hartkodiert: Formeln lesen Component-Felder; keine Magic Numbers, keine Sonderfälle. Eine neue Spezies, ein neues Klima oder eine neue Wirtschaft heißt: neue Daten anlegen - nie einen neuen Zweig tief in einem System vergraben.
Keine Vererbung, nur Komposition: Es gibt keine Klassenhierarchie. Eine Fledermaus erbt nicht von einer Klasse Tier - sie ist eine Entity mit Wings-, Echolocation- und Metabolism-Components. Eine neue Art ist eine neue Kombination, nie eine neue Basisklasse.
Deterministisch allein aus Inputs: Gib der Welt dieselben Inputs, und sie entfaltet sich identisch. Weil sich der Zustand nur über Components und geloggte Intents ändert, ist jeder Lauf reproduzierbar und wiederholbar - 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. Ein bewusst eigener Entwurf.
Zwei Uhren: Echtzeit und Spielzeit: Jeder Schedule deklariert, ob er der Echtzeit oder dem antarischen Spielkalender folgt. 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 RAM→MongoDB: Jede aktive Entity lebt im RAM in EnTT; MongoDB persistiert Chunks, State und Snapshots, wenn sie nicht gebraucht werden. Skalierung ist ein Streaming-Problem - und die Architektur ist darum herum gebaut.
Dasselbe ECS auf beiden Seiten der Leitung: EnTT auf dem C++-Server, becsy im Browser - SHARED-Components in strikter 1:1-Parität. Ein SHARED-System rechnet das Ergebnis deterministisch nach, statt es geschickt zu bekommen.
Es gibt keine Grafik ohne Bedeutung: Die Sonne ist keine Lichtquelle, sie ist ein Fusionsreaktor: Ihr Output treibt Photosynthese, Bodentemperatur, Verdunstung und die Stimmung jeder Kreatur an. Jedes Bild ist die Oberfläche einer Simulation.
Eine Datei, ein System: Jedes System ist eine einzelne zustandslose Datei, registriert auf einen benannten Schedule. Wer die Datei liest, weiß exakt, wann sie läuft und welche Components sie berührt - keine versteckte Registrierung, kein God-Object, das im Hintergrund dirigiert.
Reaktiv per Konstruktion: on_construct- und on_destroy-Hooks feuern in dem Moment, in dem ein Component hinzukommt oder verschwindet. Reaktionen hängen an Datenänderungen, nicht an Polling - ein Component anzuhängen ist selbst schon ein Ereignis.

// Wo wir stehen

Offen gebaut. Jeden Tag reifer.

Jede Komponente trägt ihren Status in einer VERSION-Registry - nicht behauptet, sondern automatisch aus der Commit-Historie abgeleitet. Was du hier siehst, ist der echte Stand - kein Versprechen. Architektur und Vision stehen; die Implementierung läuft - öffentlich nachvollziehbar, Commit für Commit.

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, und die ganze Welt bewegt sich.

Jedes Modul lebt in einem Graphen. Wähle unten ein Modul - der Graph verdrahtet sich live zu dessen echter Downstream-Kette, gezogen aus den Kausalitäts-Dokumenten der Engine. Fällt atmosphere.temperature unter genetics.cold_tolerance, friert ein Tier - zwei Module, null direkte Kopplung, eine Vergleichsregel im Hub.

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, Sichtweite, Geruchsausbreitung, Vogelverhalten und den Himmel. Ändere 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 ase-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 steuern 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 bis zum ersten Leben der Abiogenese und nach vorn in die Sinne über Perception, in Witterung und Zeichnung über Signature. Vererbung ist in beide Richtungen verdrahtet.

Zieh am Ursprung

ase-abiogenesis · 4

Die erste Chemie stößt die Unordnung der Entropie an, 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, färbt 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 zeigt, was der Output eines Moduls mit jedem Modul weiter unten macht - weil alle denselben 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 laufen voll.

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

Alles aus EINEM module.

ändere einen einzigen Wert upstream - alles downstream simuliert sich neu.

~10 Zeilen, 1 System

Eine neue Kausalität bedeutet normalerweise: kein neuer Code

Damit der Mond die Nacht aufhellt, schreibt ein SkyMoonSystem moon_contribution in die SkyBrightnessComponent - ~10 Zeilen, ein System. StarSystem, PredatorSystem und PlayerVisibility lesen die Helligkeit bereits - ihr Verhalten ändert sich, ohne dass sie angefasst werden.

Sterne = Gefahr

Spieler lernen es beim Spielen, nicht im Tutorial

Viele sichtbare Sterne bedeuten einen dunklen, mondlosen Himmel, in dem Räuber lauern; wenige Sterne bedeuten helles Mondlicht, das sie verrät. Löwen jagen am erfolgreichsten bei Neumond - ASE simuliert die Realität, nicht Hollywood, und bringt sie dir beim Spielen bei.

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

Reasoning interpretiert. World simuliert. Replica autorisiert. Engine orchestriert.

Inspiriert von Star Citizens Replication Layer - eigenständig neu gedacht für Ein-Personen-Teams: Der Spielzustand lebt an der Replica, World-Instanzen sind austauschbares Compute, und der Browser spricht ausschließlich mit der Replica. Nie mit der Engine, nie mit einer World.

Engine

Control Plane · :808x

Orchestriert den Lifecycle, liest Projekt-Manifeste und stellt eine typisierte HTTP-API bereit - allein für die ase CLI und CI. CLI-first, wie kubectl oder gh: Build-Promotion, Projektstart, Smoke-Test und Rollback sind 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 den Zustand berechnet, ist nicht der Knoten, der ihn besitzt: Eine World bootet, dockt am State-Besitzer an, holt auf, rechnet - und verschwindet wieder wie ein zustandsloser Web-Worker.

Reasoning

Cognition Plane · der 4. Typ

Die nicht-deterministische Spracharbeit, die eine deterministische Simulation strukturell nicht leisten kann: Skill-Outputs, NPC-Dialoge, Narrativ-Generierung, Lore-Konsistenz-Checks, semantisches Routing und Verhaltens-Anti-Cheat. LLM-nativ, als eigene Ebene - 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 eine Aufgabe: Vier getrennte Binaries, kein Monolith: Engine orchestriert, Replica besitzt den State und die öffentliche Oberfläche, World rechnet, Reasoning denkt. Ein Crash oder ein Skalierungsereignis in einem ist für die anderen unsichtbar - sie teilen sich nie einen Prozess.
Drei Ebenen, je eine Zuständigkeit control/data/compute: Engine orchestriert den Lebenszyklus; Replica besitzt den autoritativen Zustand und ist das öffentliche Gateway; World rechnet und besitzt nichts. Jede Ebene ist der kleinste Prozess, der allein neu starten kann, ohne die anderen mitzureißen.
Ports schneiden die Vertrauensgrenze 808x / 900x / 9001+: Die Port-Bereiche sind das Sicherheitsmodell. Browser erreichen nur :900x; Control und Compute Plane sind vom öffentlichen Internet aus per Konstruktion unerreichbar - nicht per Richtlinie.
Jede Ebene 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. Lägen zwei Ebenen in einem Prozess, risse ein Fehler in der einen den State, die Clients oder die Skalierung der anderen mit.
Reasoning ist die vierte Ebene: Neben Control, Data und Compute sitzt eine vierte Ebene für Spracharbeit - Skills, Dialoge, Narrative, semantisches Routing, Verhaltens-Anti-Cheat. Horizontal skalierbar, quotiert nach eigenen Regeln - nicht an die Game-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 (das erste Byte ist der Typ, flaches Layout per memcpy mit null Allokationen); WebRTC für Browser (reliable für Snapshots, unreliable für Input); SSE und WS-JSON bewusst kein Default. Bei einem 10-Hz-Takt ist binäres Zero-Parse keine Optimierung, sondern Korrektheit.
Der Hub ist der gemeinsame Namensraum: Module schreiben und lesen benannte Hub-Keys, und der Almanach verteilt die Deltas; kein Modul kennt ein anderes beim Namen. 83 L3-Module koordinieren sich über einen Hub in Stern-Topologie - 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 und vergeben, bevor implementiert wird. Die Ebenen lassen sich in beliebiger Reihenfolge bauen und kollidieren nie auf dem Wire - der Vertrag steht vor dem Code.
Deltas statt Snapshots im Normalbetrieb: 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 schrumpfen auf ~4 B × 1 Hz: Schick den Seed, nicht das Bild.

Disziplin

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

// Nahtlos, im Maßstab

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 ergibt sich aus der Topologie.

World Aam Limit / migriert

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

World Bübernimmt · 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 sie umziehen, bootet eine zweite Instanz, abonniert dieselben Replica-Topics, empfängt einen Snapshot, holt die Deltas auf und übernimmt das Compute. Clients verbinden sich nicht neu, authentifizieren sich nicht neu, sehen keinen Ladebildschirm. Die Compute-Identität einer Region wechselt, ohne dass ihr beobachtbarer Zustand sich ändert.

Heiße Regionen teilen sich, kalte verschmelzen - im laufenden Betrieb

kein Neustart

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

Kein Ausbremsen, keine geteilten Welten

Zwei klassische MMO-Kompromisse sind für ASE erklärte Nicht-Ziele: Die Simulation wird unter Last nie ausgebremst - horizontales Compute hält die Tick-Rate konstant - und ein voller Ort erzeugt nie eine zweite, getrennte Kopie seiner selbst. Die Welt bleibt eine Welt.

Projektübergreifendes Reisen ist nur eine Kante

V-3 Verbund

Jedes Projekt lebt im selben Graphen - ein Übertritt ist eine Beziehung zwischen zwei Knoten, kein Export, kein Sync-Job. Eine Handelskarawane von Projekt A nach B kopiert keine Daten und schickt keine Server-Nachricht. Und der Spieler sieht keinen Übergang, 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 im Manifest seine eigenen Replica-Gruppen. Keine Datenbank, kein Compute pro Projekt zu provisionieren - das 1001. Projekt kostet ungefähr so viel wie das 1000., weil sich am Substrat nichts ä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. Die Kopplung ist topic-basiert: Eine neue World ist ein neuer Subscriber, ein Replica-Split eine Änderung im Topic-Routing, ein neues Projekt ein neues project_id-Label. Nichts davon berührt das Binary einer anderen Ebene.

Der Zustand lebt an der Replica; die World ist austauschbar

zustandslose World

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

Null Reconnects, konstruktiv garantiert

0

Die Client-Verbindung führt zur Replica und wird beim Tausch der World hinter einer Region nie getrennt. Spieler-Reconnects bei Migration: null. Ladebildschirme bei Migration: null. Der beobachtbare Zustand lebt an der Replica und bleibt schlicht dort.

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-Ebene tragen kein öffentliches Auth-Modell.

Erst Snapshot, dann Deltas

Snapshot + Delta

Eine bootende Instanz abonniert die Replica-Topics der Region, empfängt einen vollen Snapshot, holt den Delta-Strom auf - und übernimmt erst dann das Compute. Der Tausch ist unsichtbar, weil der beobachtbare Zustand 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 kein Default. Jeder Transport ist für genau eine Eigenschaft gewählt - unter einem 10-Hz-Takt.

Binär und Zero-Parse auf dem Wire

0 Alloc

Server-zu-Server-Frames tragen den Message-Typ im ersten Byte und kopieren ein flaches Layout per memcpy direkt in Hub und Almanach - null Allokationen, kein JSON-Parsing auf dem heißen Pfad. Bei einem 10-Hz-Takt ist das Korrektheit, keine Mikro-Optimierung.

Ein Graph, gescoped per project_id

1 Neo4j

Jedes Projekt ist ein gelabelter Subgraph in einer einzigen 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.

Jede Ebene ist eine Observability-Grenze

isolierte Planes

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

Partition folgt der Dichte, nicht der 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 zusammengelegt. Das Mesh folgt dorthin, wo die Simulation schwer ist - nicht dorthin, wo Spieler gezählt werden.

Wächst zur Laufzeit zum Mesh

kein Neustart

Ein Projekt, das auf einer einzigen World startet, wird in seiner eigenen Laufzeit zum Multi-Instanz-Mesh. Eine Region neu zuzuweisen ist eine Änderung der Topic-Subscription - kein Neustart, keine Zustands-Migration, kein Wartungsfenster.

Der Spieler verbindet sich nie neu

Session unangetastet

Durch einen Split, einen Merge oder eine volle Migration hindurch bleibt die Verbindung des Clients zur Replica bestehen. Kein Reconnect, kein neues Login, kein Ladebildschirm - das Compute hinter der Region hat gewechselt, die Session und ihr beobachtbarer Zustand nicht.

Elastisch pro Region, aus der Telemetrie

auto-scaled

Kapazität folgt der Live-Telemetrie, ohne Operator in der Schleife: Eine belebte Region fährt mehr Worlds hoch, eine ruhige wird zusammengelegt - kontinuierlich. Die Skalierung folgt dorthin, wo die Simulation gerade wirklich schwer ist.

Das Compute folgt der Menge, der Besitz nicht

State bleibt, wo er ist

Wo Spieler sich sammeln, hängen sich zusätzliche Worlds an die Replica-Topics der Region und teilen sich die Last. Der Besitzer des Zustands - die Replica - bewegt sich nie; nur das austauschbare Compute. Die Dichte formt das Mesh um, nicht die Quelle der Wahrheit.

// Eine Quelle, beide Seiten der Leitung

Der Server rechnet in C++. Der Browser rechnet in TypeScript. Beide meinen dieselbe Welt.

Jede SHARED-Component existiert zweimal: als C++-Struct in EnTT auf dem Server und als becsy-Component im Browser - strukturell identisch, weil ase-codegen beide aus einer Quelle transpiliert. Von Hand gespiegelt wird nie.

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 von Hand geschriebene Engines driften auseinander, sobald jemand einen Bug nur auf einer Seite behebt. Deshalb schreibt ASE nie zwei: Die Logik wird einmal in C++ geschrieben, 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, einen Latenz-Spike per Prädiktion überbrücken, ohne zu stottern, und am Server eingerastet bleiben. Er 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 an einer Atomreferenz nachführt. Dieselbe Logik hält die Drift klein und die Korrektur winzig.

SHARED beide Seiten · 1:1

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

SERVER-ONLY nie gesendet

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

CLIENT-ONLY auto-generated

NetworkInput-, RenderSync- und EntityExport-Systeme schreibt der Codegen für dich - die Leitungen, die Netzwerkdaten ins ECS einspielen und nach React synchronisieren.

Warum ein Transpiler und keine zweite Codebasis

Identische Logik auf identischen Daten: Beide Seiten fahren denselben transpilierten Algorithmus über dieselben SHARED-Components - der Browser prädiziert deterministisch und bleibt auch 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 schrumpfen auf ~4 B × 1 Hz. Der Client ist die Quarzuhr, der Server die Atomuhr: Die Deltas führen ihn zurück in den Takt, sie streamen nie die ganze Welt neu.
Eine Quelle der Wahrheit, keine Drift: Das C++ wird von Hand geschrieben; das TypeScript wird generiert und trägt die Markierung do-not-edit. Ein handgepflegter Client-Zwilling kann still auseinanderdriften - ein generierter kann es nicht.
Typsicher über die Sprachgrenze: Jeder C++-Typ hat einen festen becsy-Decorator - float to @field.float32, uint32_t to @field.uint32. Ändere ein Feld in C++, und der Client-Typ formt sich beim nächsten Generieren neu.
Konstanten haben genau ein Zuhause: Eine Konstante lebt genau einmal - in hub/data oder in der types.hpp eines Moduls. Derselbe Name in zwei Modulen ist ein Build-Fehler, keine stille Abweichung zwischen Server und Client.
SHARED kann nicht schummeln: Ein transpiliertes System darf weder den Hub noch eine Datenbank noch irgendeine Server-Ressource anfassen. Diese Beschränkung garantiert, dass es im Browser exakt so 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 mit deiner eigenen Claude-Subscription. Launch über die API. Ein Config-Switch.

ASEs Reasoning-Edge-Daemon fährt die CLI, für die du ohnehin bezahlst - die schwere Iterationslast beim Bau eines LLM-getriebenen MMORPGs bleibt während der Entwicklung ein festes Monatsabo statt einer getakteten 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 startet die installierte CLI - claude, codex, gemini-cli, cursor-agent - als Kindprozess, stdin und stdout direkt durchgereicht. Er leitet keine OAuth-Tokens weiter und verändert keine Header - technisch nicht zu unterscheiden vom Start der CLI in deiner eigenen Shell.

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). Wer die Phase umstellt, shippt dieselben Skills, ohne eine Zeile Skill-Code zu ändern - ein inkompatibler Wechsel wird blockiert und liefert eine Liste der anzupassenden Skills, statt still zu brechen.

Ein Schalter bis zum Launch

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-Signatur vom YubiKey-PIV zur Offline-Prüfung. Es öffnet genau eine ausgehende WSS-Verbindung - kein eingehender Port, läuft also hinter NAT und Firewalls - und hält keinen Zustand auf der Platte.

Installation in einer Zeile

tos.check

$ase reasoning --tos-check

Das OAuth-Token eines Abos in einem Drittprodukt wiederzuverwenden ist verboten; die offizielle CLI als Subprozess aufzurufen ist ausdrücklich erlaubt. Und sollte ein Provider das Modell je wieder schließen, genügt ein einziger 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. Den Provider zu wechseln ist eine Config-Änderung der Engine ohne Skill-Code-Edit - und Entwicklung und Produktion nutzen verschiedene Backends für denselben Skill.

Bring jede beliebige 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 übersetzt nur das stdout der CLI in typisierte Intents, die die World konsumieren kann.

Config statt Code

connection

$ase edge status

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

Nur ausgehend, NAT-fest

vault.lease

$ase vault lease

In Produktion liegen die LLM-Keys der Kunden in einem dedizierten 3-Knoten-Vault; Reasoning liest den Vault nie direkt. Jede Inferenz holt ein frisches 60-Sekunden-Lease-Token über die Replica, maximal 5 Verlängerungen - ein kompromittierter Prozess kann nur ein Token stehlen, das in Sekunden wertlos ist.

60-s-Leases, nie gehostet

resolve

$ase reasoning --explain-resolve

Ein deterministischer 7-Schritte-Backend-Resolver übersetzt den work_type eines Skills in ein konkretes Backend und protokolliert resolved_backend_id, backend_pool_version, was_fallback und was_degraded pro Call - jede Inferenz lässt sich im Nachhinein prüfen.

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 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 Ein Manifest-Block lässt Resolution-Schritt 0 direkt auf der Edge antworten - mit null Egress , bevor irgendein Cloud-Backend berührt wird. Der günstigste und privateste Pfad kommt per Konstruktion zuerst - nicht als nachträglicher Einfall.

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 Verlauf für jeden Skill über jeden Zeitraum. Auf die Frage, warum ein Call auf Backend X landete, gibt es eine Antwort - im Nachhinein.

Jeder Call ist nachvollziehbar

dev.cost

$ase edge cost

Während der Entwicklung ist der Iterationspreis eine feste CLI-Subscription - dein eigener Plan zum öffentlichen Listenpreis (ein Claude-Max-Plan kostet $200/Mon.), statt gezählter Token. Die teure Phase wird nie pro Token abgerechnet.

Fix, nicht vierstellig

auto.tune

$ase reasoning tune

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

Kostenkontrolle im Closed Loop

Festpreis statt Token-Zähler

Feste Entwicklungskosten statt offener API-Rechnung

Weil Skills während der Entwicklung gegen deine eigene CLI-Subscription laufen, ist der Iterationspreis der feste Monatspreis deines Plans - ein Claude-Max-Plan steht mit 200 $/Monat in der Liste - statt gezählter Token. Die Produktion wechselt dann auf gedeckelte, transparente Cloud-Abrechnung, bei der nur echte Spieler-Inferenz bezahlt wird.

2 Schichten, nie gekreuzt

Zwei Kostenschichten, die sich nie berühren

Schicht 1 (Server, MongoDB-/Neo4j-Hosting, engine-interne Skills) ist durch das pauschale ASE-Abo gedeckt. 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 - Komposition wie aus Bausteinen.

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

SkillManifest · ein Skill sind 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 passenden Entities; das Reasoning-Tier findet sie über registry.view<SkillManifest, SkillSubscriptions>. Kein Skill-Registry-Service, kein Lade-Muster, 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 einziger, zentral geschriebener Skill - etwa ein Lore-Konsistenz-Prüfer - lebt einmal als Entity und durchläuft den gemeinsamen V-3-Verbund-Graphen über Projektgrenzen hinweg, ohne Installation pro Projekt. Zwei Projekte mit überlappenden Subscriptions bekommen überlappendes emergentes Reasoning, ohne voneinander zu wissen.

Ein Skill kann nicht außerhalb seiner Lane schreiben - physisch nicht

11 Manifest-Feldgruppen

Das Manifest ist die einzige Autorität über das Verhalten eines Skills. Setzt ein Skill - durch einen Bug, eine Prompt-Injection oder LLM-Drift - einen Intent-Typ ab, den er nicht deklariert hat, wird der Write abgewiesen und als Lane-Verstoß geloggt. Die reads-Liste ist genauso strikt: Ein nicht deklariertes Component gelangt nicht einmal in den Prompt - unter DSGVO und LGPD ist das die Datenschutz-Grundeinstellung.

Deklariere, was du brauchst - nicht, welches Modell

9 work_types · 7-Schritte-Resolution

Ein Skill deklariert einen work_type wie reasoning_heavy - keinen Modellnamen. Der Provider-Wechsel ist eine Config-Änderung der Engine ohne Skill-Code-Edit, in sieben Schritten deterministisch aufgelöst und voll protokolliert: resolved_backend_id, was_fallback, was_degraded und der komplette Verlauf jeder Inferenz.

Reasoning schreibt State nie direkt

source:skill vs. source:player

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

Memory, modelliert nach menschlicher Kognition

9 Collections

Skill-Memory besteht aus 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 hängt an einer DSGVO-/LGPD-Löschkaskade, ausgelöst von einem einzigen ase player forget.

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

Komposition per Anhängen

Das Prinzip, das für Welt-Entities gilt, gilt auch für Skills: Ein Skill KANN alles abonnieren, was er deklariert, und MUSS nichts. Verhalten entsteht durch angehängte Components, nie durch einen Koordinator - 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 Kompositions-Versprechen: kein Orchestrierungscode, keine Integration - die Komposition ist emergent, exakt wie die Simulation darunter.

Quota prüft jeden Call, vor der Ausgabe

10 Achsen · pre-spend

Zehn orthogonale Quota-Achsen werden geprüft, bevor eine Inferenz läuft. Am harten Limit wird der Call gar nicht erst abgesetzt - stattdessen entsteht ein QuotaExceededIntent. Ein prompt-injizierter oder durchdrehender Skill kann keine Kosten anhäufen, weil die Ausgabe 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 - legt seine Lane fest, 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 kommt als Skill-Paket auf einer eigenen Anti-Cheat-Lane - mit tieferen Eskalations-Caps und einer umgekehrten Spieler-Quota: Je auffälliger das Verhalten, desto mehr Analyse bekommt es. Gleiches Entity-Modell, umgedrehte Ökonomie.

Credentials, die der Skill nie sieht

60s-Lease

LLM-Keys der Kunden erreichen nie einen Skill. Reasoning holt für jede Inferenz ein frisches 60-Sekunden-Lease-Token über die Replica (maximal 5 Verlängerungen); ein Skill bekommt eine Fähigkeit, kein Geheimnis - und ein kompromittierter Prozess kann nur stehlen, was in Sekunden wertlos wird.

Zur Laufzeit geboren, weg beim Abhängen

Lifecycle = Entity

Der Lebenszyklus eines Skills ist der Lebenszyklus 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, mehr Installation gibt es nicht.

Reasoning ist ein Tier, kein Chatbot

4. Prozess-Plane

Das Reasoning-Tier ist eine eigene, horizontal skalierbare Prozess-Ebene neben Engine, Replica und World - kein API-Call, der an eine Render-Loop geschraubt ist. Spracharbeit lebt dort, wo sie nach eigenen Regeln skalieren, quotiert und geprüft werden kann.

Zwei Kostenschichten, pro Skill

cost_layer

Ein cost_layer-Feld entscheidet, wer zahlt: Engine-interne Skills laufen auf dem festen 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 ist *Intent

Skill-Outputs und Spieler-Inputs kommen beide als *Intent-Components an; die World wendet sie nach denselben Regeln an und verzweigt nie nach ihrer Herkunft. Genau diese Symmetrie erlaubt es, eine nicht-deterministische Ebene auf eine deterministische Simulation zu setzen.

Vektorsuche auf drei von neun

semantisches Memory

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

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. Datenschutz ist eine eingebaute Operation, kein manuelles Durchsuchen der Stores.

Jede Inferenz hinterlässt einen Trace

voll auditierbar

resolved_backend_id, backend_pool_version, was_fallback, was_degraded und der komplette Auflösungs-Verlauf werden pro Call protokolliert. 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 über Subscriptions auf Component-Änderungen, nicht über eine Polling-Schleife. Ein Skill ohne Anlass setzt keine Inferenz ab und gibt kein Geld aus - Aufmerksamkeit und Kosten wandern dorthin, wo die Simulation sich wirklich ändert.

Frag, warum ein Skill ein Backend wählte

Audit-Query

ase reasoning Audit-Query --skill <id> liefert die Auflösungs-Verläufe für jeden Skill über jeden Zeitraum. Warum landete dieser Skill auf Backend X? Darauf gibt es eine konkrete Antwort - kein Achselzucken.

Drei Flow-Patterns, mehr nicht

3 Patterns

Jede Interaktion mit dem Reasoning-Tier reduziert sich auf drei benannte Flow-Patterns. Reasoning-Module und LLM-Plugins implementieren sie; Phasenpläne verweisen auf 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 festpinnen, wenn die Live-Telemetrie aus Kosten und Qualität eine Schwelle kreuzt - datengetrieben, ohne fest verdrahtete Modellnamen, ohne Sonderfälle pro Skill. Das System stimmt sich selbst ab.

Erst lokal antworten

local_resolution

A local_resolution Ein Manifest-Block lässt Resolution-Schritt 0 fragen: Kann das auf der Edge beantwortet werden, ganz ohne Egress? - bevor irgendein Cloud-Call erwogen wird. Günstige, private, lokale Kognition kommt zuerst - das ökonomische Fundament für 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 leitet, nie zu Kunden-Skills - erzwungen auf Wire-Ebene beim Decode der Replica. Interne Kognition kann nicht in eine Kunden-Lane durchsickern.

// Planbare Kosten

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

Das Reasoning-Tier prüft jeden LLM-Call gegen zehn orthogonale Quota-Achsen. Ein prompt-injizierter oder durchdrehender Skill kann keine Rechnung auftürmen, weil die Ausgabe 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 deinen LLM-Verbrauch und hostet nie deine Abo-Tokens - die beiden Rechnungen können sich nicht vermischen.

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 ausbrechen. Planbare Caps sind eine Eigenschaft der Architektur, kein Versprechen auf einer Pricing-Seite.

Der Cap stoppt die Ausgabe, nicht erst die Rechnungby design

Ist ein Limit erreicht, wird die Inferenz gar nicht erst gestartet - Kostendrift ist strukturell ausgeschlossen. Weil die Caps deklarativ sind, ist die Rechnung begrenzt, bevor du launchst - nicht hinterher im Schock abgeglichen.

Entwickle auf Abo, shippe auf Capsedge → cloud

Entwicklung läuft edge_only auf deinem eigenen CLI-Flatrate-Abo; Produktion wechselt 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 auf einen Fallback ausgewichen wurde und was es gekostet hat.

cost_layer entscheidet, wer zahltengine / game

Der cost_layer eines Skills ist entweder engine (fährt auf dem ASE-Flatrate-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 in Frage kommt. Der Null-Kosten-Pfad wird per Konstruktion zuerst probiert - das ökonomische Fundament, auf dem Reasoning im großen Maßstab bezahlbar bleibt.

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 regelt sich auf ein Ziel einMin-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 verletzt. 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. Das 1001. Projekt kostet deshalb ungefähr so viel wie das 1000.: Es gibt keine Datenbank und kein Compute pro Projekt zu provisionieren - und keinen Kostensprung pro Projekt.

Bring your own AI, während der Entwicklungedge_only

Iteriere gegen dein eigenes CLI-Abo, während du baust; Produktion wechselt 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 nächsten Monat auf der Rechnung 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 reicht. Ein durchdrehender oder prompt-injizierter Skill kann sich nicht in unbegrenzte Ausgaben hochschaukeln - gedeckelt ist die Reichweite, nicht nur der Preis pro Call.

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

✓ Planbare Caps - keine galoppierenden getakteten Kosten, 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 Bürger erster Klasse

Reasoning erkennt Muster, 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 stufenweise in Richtung Unumkehrbarkeit eskaliert - und vorher haltmacht: Kein LLM darf je allein einen Spieler bannen.

// warum ab Stunde eins, nicht nach Launch

Jedes MMO stirbt an denselben Wunden: Farming-Bots, Speed-Hacks, koordiniertes Griefing, galoppierende Inflation - und am Ende stehen Wipes und Abwanderung. Drei Jahrzehnte MMO-Geschichte lehren dieselbe Lektion, und nachgerüstete Kontrolle kommt zu spät: Die Wirtschaft ist dann längst vergiftet. ASE zieht diese Lektion in die Architektur ab Stunde eins: Erkennung, Quarantäne und von Menschen gegengezeichnete 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 diese Intents 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 höheren Eskalations-Caps. Die Ökonomie ist absichtlich umgedreht.

Determinismus überlebt ein nicht-deterministisches Tier

replayable

Weil Reasoning immer nur Intents schreibt und nie simulierten Zustand, bleibt eine ASE-Welt allein aus ihren Inputs reproduzierbar. Ein Replay kann geloggte Skill-Intents für eine perfekte Reproduktion wiederverwenden - oder frische Reasoning-Calls für eine neue, nicht-deterministische Generierung absetzen. Diese Wahl hast du nur 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

schnell → tief

MovementValidator fährt einen deterministischen Speed-/Teleport-Check direkt auf der World; reasoning-gestützte Mustererkennung liefert danach den semantischen Kontext. 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 in der Simulation tut - 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 per Konstruktion

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 falsche permanente Sanktion - der ist, den ein Mensch signieren muss.

// Welten, die du bauen kannst

Aetheria: 9.000 prozedurale Planeten, die zu einer gemeinsamen Welt kollabieren.

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

9,000→1

Reinkarnation lässt das Multiversum kollabieren - eine Seele bindet sich an Fleisch, jeder nicht gegangene Pfad hört auf zu existieren, und was bleibt, ist eine unumkehrbare, gemeinsame Welt.

9.000 Planeten · 6 Phasen

9.000 Planeten, nicht 9.000 Shards

Aetheria generiert 9.000 prozedurale Planeten - Geburtsorte, 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 Vielfalt einer gemeinsamen Welt.

9.000 → 1

Reinkarnation lässt das Multiversum kollabieren

Eine Seele wandert als Superposition durch ungewählte Zukünfte; jede Entscheidung öffnet 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 - übrig bleibt eine unumkehrbare, gemeinsame Realität, persistiert nach MongoDB und Neo4j.

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

Eine Welt mit Immunsystem

Antarien ist keine Landmasse, 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 % heilen Furchen nicht mehr, 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 per serverseitigem Handoff aus dem Prequel Aetheria in die persistente Welt Antares Open World - ein globales Universum, alle Spieler, keine Instanzen. Der volle Datensatz - Seed, Biom, Genetik, Theologie, Psyche - wird permanent und unumkehrbar.

5 Charaktere

Fünf Seelen, ein Spieler

Jeder Spieler betreibt fünf Resonanzkammern - fünf Charaktere, fünf Claims, fünf Startzonen, alle gleichzeitig am Leben. Einen steuerst du; die anderen vier führt die KI weiter, und ein Seelensprung wechselt zwischen ihnen. Eine Glühwürmchen-Schwarmintelligenz pendelt als Brücke zwischen deinen Charakteren, entlang des Cruor-Netzwerks.

das Pyramiden-Paradox

Prequel-Wissen wird zum Kompass

Bei der Reinkarnation geht das bewusste Gedächtnis verloren - der Körper behält alles: die Genetik, die Berufung als Muskelgedächtnis, die Prädisposition der Seelenfarben. 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 einer atmenden Haut.

offen gebaut

Die Referenzwelt, in Zahlen

153 Components · 86 Systeme (null Verstöße), 13 Web-Submodule - das Schaufenster, das zeigt: 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. Vielfalt wird eingeprägt, nicht aufgeklebt.

Schiff = Komet

Das Generationenschiff ist ein Komet

Das Gefährt, das Seelen zwischen Welten trägt, erscheint von außen als Komet - dasselbe Objekt ist zugleich der Mythos am Nachthimmel und der Mechanismus der Konvergenz. Nichts in dieser Welt ist bloß 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 Geschichte 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, konsistent, keine gemalte Kulisse hinter dem Geschehen.

soul-jump

Fünf Leben, kein Logout

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

das Cruor-Netzwerk

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

Eine Glühwürmchen-Schwarmintelligenz pendelt als Brücke zwischen deinen eigenen Charakteren, entlang des Cruor-Netzwerks. Zwischen deinen fünf Leben zu wechseln ist kein Menüpunkt - 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 danach lebt. Zwei Spiele, ein durchgehendes Universum - die Konvergenz ist die Naht dazwischen.

MongoDB + Neo4j

Gebundene Realität, niedergeschrieben

In dem Moment, in dem eine Seele sich an Fleisch bindet, wird der volle Datensatz - Seed, Biom, Genetik, Theologie, Psyche - nach MongoDB und Neo4j geschrieben: als permanenter, unumkehrbarer 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 über einen zentralen Hub schreiben und lesen, mit null direkter Kopplung. Jedes L3-Modul steht unten im Baum - einzeln aufgeführt, 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 Grenze zwischen Engine und Spiel verläuft mitten hindurch. Engine-Entwickler besitzen L0 bis L3; dein Spiel baust du in L4 und L5 und siehst dabei nichts außer dem einen ase-sdk-Header.

L0Foundation

L1Core

L2Kernel

L3Module

L4Plugins

L5Server & Clients

▸ Jede Schicht hängt nur von den Schichten darunter 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 von oben hineinsickern kann. Jedes Simulationssystem darüber rechnet auf diesem Fundament.

L1

Core

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

Das ECS als EnTT-Hülle, das Logging und die Clients für Neo4j und MongoDB. Neo4j hält Beziehungen und Hierarchien; MongoDB hält Chunks, Zustand und Snapshots.

L2

Kernel

ase-kernel

Der Herzschlag: Game Loop, dlopen-Modul-Loader und der eigene Tiered Scheduler - 66 Schedules über 21 Tiers, ein bewusst eigener Entwurf, 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 Kopplung von Modul zu Modul. Hier bekommen Milliarden Entities ihr Verhalten.

L4

Plugins · 27 Stück

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

Hot-ladbare Shared Libraries, die der Kernel entdeckt, auf API-Version prüft und per dlopen lädt. Fehlt ein Plugin, degradiert der Server sauber - er läuft auch ohne das Wetter-Plugin. So stellt sich ein Spiel exakt die Systeme zusammen, die es braucht.

L5

Server & Clients

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

Die Vier-Ebenen-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 in 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 und -Clients - hinter dem einen ase-sdk-Header. Diese Kapselung ist der Grund, warum eine Person mit der Engine ein MMORPG baut - statt an der Engine selbst zu bauen.

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

EnTT auf dem C++-Server, becsy im Browser - view<A,B>() wird zu query, on_construct zu added - SHARED-Components halten strikte 1:1-Parität. Ein SHARED-System rechnet deterministisch nach und schrumpft ~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 bis L0, strikt: Eine höhere Schicht darf nach unten greifen, nie nach oben, nie zur Seite. L0 Foundation (Mathe, Typen, Utils) hat null ECS-Abhängigkeit - in das Fundament, auf dem die ganze Simulation rechnet, kann nichts von oben einsickern.

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. Ein bewusst eigener Entwurf; alles darüber bekommt seinen Takt von ihm.

L1 Core: ECS plus die DB-ClientsNeo4j + MongoDB

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

L4-Plugins laden hot und degradierenhot-loadable

Plugins sind per dlopen geladene Shared Libraries mit API-Versions-Check; fehlt eines, degradiert der Server sauber - er läuft auch ohne das Wetter-Plugin. Ein Spiel stellt sich exakt die Systeme zusammen, die es braucht - nicht mehr.

L3 ist die Engine selbst83 Module

Dreiundachtzig Simulationsmodule, verdrahtet über die Stern-Topologie von ase-hub, ohne direkte Kopplung von Modul zu Modul - 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 hineinsickern kann.

Die Integrationsschicht ist main.cppeine Ausnahme

Systeme rufen einander nie auf - die einzige erlaubte 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 - React-Three-Fiber über einem becsy-ECS. Beide sind L5, gebaut auf allem darunter: die einzigen Schichten, die die meisten Spiele-Entwickler 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, klar zu sagen, wer heute darauf bauen sollte und wer nicht. Komplementär per Design, nicht im Wettbewerb.

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 - die volle Simulationskaskade bekommst du überall dort geschenkt, wo du etwas angehängt hast.

Für Planetensimulation jenseits von Spielen

7+ Domänen

Weil ASE echte Kausalsysteme simuliert, statt Kulissen zu rendern, taugt dasselbe Substrat für 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

Eine dedizierte Reasoning-Ebene, Skills als ECS-Entities, eine Bring-your-own-AI-Ökonomie und Anti-Cheat als vollwertiger Use-Case - Reasoning ist hier eine Prozess-Ebene 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 schärfsten 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.

Offen darüber, wo es steht

Closed Beta kommt

ASE wird offen gebaut und reift täglich. Architektur und Vision stehen, die Implementierung läuft, eine Closed Beta kommt. Niemand behauptet hier “fertig” - die 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 vollwertigen Skills denkst, überträgt ASE diese Philosophie auf Welten: Skills sind ECS-Entities, Reasoning ist eine föderierte Ebene mit Edge-Daemon. Kreuzbestäubung zwischen KI- und Game-Dev-Welt, kein Genre-Schwenk.

Für Klima- & Erdsystemforschung

climate

CO²- und Temperaturzyklen, Hydrologie, Erosion über geologische Zeit - dieselbe GIS-geschichtete Simulation, die eine Spielwelt trägt, trägt einen Planeten, den du untersuchen kannst. Der Output sind Daten, nicht nur Kulisse.

Für Ökologie & Evolution

ecology

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

Nicht für einen Hobby-Platformer

Power, kein Händchenhalten

Wenn du ein Bau-dein-erstes-Spiel-in-30-Minuten-Tutorial suchst, passen Unity oder Godot besser. ASE tauscht Händchenhalten gegen Möglichkeiten - es ist für die, die von freundlichen Tools sonst ausgebremst werden, 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 die Engine für jeden.

Für Stadtplanung & Logistik

cities

Verkehr, Lieferketten, Bevölkerungsströme und Infrastrukturlast lassen sich natürlich als Agenten auf einer GIS-geschichteten Welt modellieren. Dasselbe Substrat, das eine Stadt im Spiel trägt, trägt 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 ergeben sich aus derselben Tiered-Scheduler-Architektur, die schnelles Leben und langsamen Stein in getrennten Takten tickt. Zeitskala ist ein Schedule-Tier, kein Sondermodus.

Für generative Kunst & Installationen

eine lebendige Leinwand

Eine Welt, die auf echter Ursache und Wirkung läuft, ist ein generatives Instrument: Setz einen Seed, lass die Simulation atmen - 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

Große Agenten-Populationen 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 verzahnte Systeme liebst - die Tradition von EVE, Dwarf Fortress und 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 Abliefern einer Szene bis Sonntagnacht. Für einen Jam-Prototyp in 48 Stunden passt eine leichtere Engine besser - ASE ist für den langen Bau, den eine tiefe, lebendige Welt wirklich braucht.

Was du baust · Starter-Kits legen ein Genre-Gerüst - dann baust du

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

rpg-quest - **legen ein Genre-Gerüst, dann baust du**

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

evolution-sim - **legen ein Genre-Gerüst, dann baust du**

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