AETHERIA/AOW Lore & Design Deutsch

Globalstrategie & Kernsysteme — Antares World Engine

Dieses Kapitel beschreibt die strategische Bedeutsamkeit der zu implementierenden Globalstrategie, die Hybridisierung klassischer 4X-Strategieelemente mit Echtzeit-MMO-Mechaniken auf chronobiologischer Basis, sowie die drei fundamentalen Subsystemgruppen der Engine: AEC Core System (22), RES Ressources Layer (9) und LLC Low Level Renderer (16).

Bedeutsamkeit der Globalstrategie

In diesem Zusammenhang lenke ich auf die strategische Bedeutsamkeit der zu implementierenden Globalstrategie. Insbesondere wird dieser Aspekt durch die Hybridisierung der klassischen, auf Runden basierten 4X-Strategie in einer Integrierung und deren konzeptionellen Umsetzung in Echtzeit fokussiert. Alleine schon aufgrund der dem Genre bekannten, äußerst komplexen Zusammenhänge — und der Herausforderung, diese zudem in einem MMO zu implementieren — obliegt einer echten konzeptionellen Herausforderung.

Dabei hybridisieren und verkapseln wir die klassischen MMO-Elemente mit den strategischen 4X-Komponenten und allen künftigen Kernkompetenzen. Die so etablierte Globalstrategie wird über den in der Community geprägten Aphorismus Explore, Expand, Exploit, Exterminate am besten beschrieben. Die Besonderheit des Konzeptes liegt in der in Echtzeit vollzogenen, aber unsichtbaren, auf chronobiologischen Zyklen (Runden) basierten Strategie.

Der Spieler kann seine offerierten Möglichkeiten und Optionen, in den Spielverlauf einzugreifen, jeweils für einen frei definierten Zeitraum bis zur Deadline nutzen. Die Kernkompetenz Chronobiologische Zyklen & Rhythmen wird die detaillierten Mechanismen dieser unsichtbaren Runden beschreiben.

Zeitliche Struktur und das Dreißiger-System

Alles im Universum ist sterblich und vergänglich — dabei spielt die Sequenzierung der Zeit eine entscheidende Rolle. Der antarianische Tag ist auf einer Tageszählung im Dreißiger-System aufgebaut. Die Tageszählung wird über jeweils im Mittel 3 x 10 Stunden (Antarianische Zeit) in die drei Tagesperioden ASO (Jagdphase), RAL (Triebphase) und PEX (Schlafphase) unterteilt.

Wichtig ist zunächst die Circadiane Frequenz, welche den antarianischen Tag mit beispielhaft 30 Stunden im Wach/Schlaf-Rhythmus beschreibt. Die Basis für die zeitlichen Normierungen (Offsets) aller Teilnehmer bildet der astronomische Arcturus Kalender, welcher es in seiner Befähigung ermöglicht, die spielergesteuerten fließenden Ein- und Ausstiegstrategien über den Frühlingspunkt zu koordinieren.

Die nationale Lokalität, die Verortung des Heimatplaneten sowie die des Sonnensystems finden aufgrund der zu berücksichtigenden globalen Zeitverschiebungen ihre Anwendung. Aus Himmelsbeobachtungen, Gottgeburten, Tag-und-Nacht-Rhythmen, Alterungsprozessen und Witterungseinflüssen — um nur einige sichtbare stilistische Mittel zu benennen — lassen sich Zeitfenster durch den Spieler auf Basis seines Standortes im Spielareal ermitteln.

Das Konzept spricht von Prophezeiungen (vgl. Nostradamus), wenn ein Zyklus sein Ende findet — da die Welt sodann in diesem jeweiligen Spielsektor und Sonnensystem neu normiert und bewertet wird. So erinnert sich der Leser an das einleitende Kapitel, wo die Rede von der Geburt des Gottes Ras im »RAL 22.10.0.3.15.7« nach »SURA 17.2.30« war, und nach Überlieferung der Stern Antares blutrot wurde. Es handelt sich um ein weiteres sichtbares Zeichen, das für einen Spielsektor eine neue Zeitrechnung beginnt und für alle Sektoren im Einflussbereich die in Echtzeit bis dato vollzogenen Spielschritte ihre Anpassung finden.

Vergleichbar ist dies mit dem Ende einer klassischen Spielrunde eines 4X-rundenbasierten Strategiespiels. Der Unterschied liegt in der durch den Spieler steuerbaren Laufzeiten einer unsichtbaren theoretischen Runde. Über die Altersphasen, den Aufbau von Supra- und Infrastruktur kann der Spieler indirekten Einfluss auf das Verhalten dieser suggerierten Rundenlängen nehmen. Wenn der Tag im Abendrot zu Ende geht, sollten alle Entscheidungen des Tages getroffen und die Auswirkungen am neuen Morgen vielleicht spürbar sein. So entsteht eine echtzeit-gespielte 3D-MMO-Welt im RPG-Feeling auf rundenbasiertem Hintergrund für die strategisch wichtigen 4X-Komponenten.

Die Hybridisierung von rundenbasierter 4X-Strategie und Echtzeit-MMO ist das Alleinstellungsmerkmal der Globalstrategie: Der Spieler trifft strategische Entscheidungen innerhalb unsichtbarer, chronobiologisch gesteuerter Zyklen, waehrend die Welt sich in Echtzeit weiterentwickelt. So entsteht ein strategisches Zeitfenster, das weder kuenstlich begrenzt noch unendlich offen ist -- sondern vom Spieler selbst beeinflusst werden kann.

Einflussgrößen und Erforschung

Mit der Erforschung neuen antarianischen Wissens können Einflussgrößen komplexer Zusammenhänge in Spielerhand gegeben werden. {{Antares Open World}} setzt dort an, wo es nicht einfach genügt, das neu erforschte Update zu installieren, sondern für jedes dieser Module eine ausgeklügelte Strategie für die Produktion und Installation notwendig wird, um die Bonifikationen des Updates nutzen zu können. So sieht der Workflow für Anbauten an Gebäuden (vgl. Bauplätze, Blueprints & Housing), welche die strukturelle Integrität einer Spielzone besichern sollen, komplexe technologische Arbeitsschritte vor.

Ein konkretes Beispiel — Die Dorfgemeinde und der Glaube

Der Einfluss des Glaubens einer kleinen Dorfgemeinde soll zum Schutz dieser ausgebaut werden. Die Strategie der Spieler liegt in der Postulierung ihres Glaubens: Durch das Innehalten eines dedizierten, dem Einsatzzweck befähigten Gurus bekommt das Dorf eine mächtige Verteidigung. Sollten feindlich gesinnte Parteien versuchen, in den umliegenden Spielarealen sesshaft zu werden, würden diese im Einflussbereich des eigenen Glaubens diesen annehmen.

Um nun diesen Einflussbereich zu vergrößern oder zu kanalisieren, benötigt das Dorf eine Kirche, Kapelle, Kathedrale, einen Schrein oder Opferplatz — um die Infrastruktur dahingehend auszubauen. Mit der Erkenntnis und Erforschung dieser Art des Widerstandes gegen Blasphemiker muss dieses Gebäude in einem Gemeinschaftsprojekt über viele Tage erbaut werden. Da wo anderweitig in Spielen ein einfaches Icon in einem Fenster dazu geklickt und Zeit mit Warten verstrichen wird, will {{Antares Open World}} optisch ansprechende und sichtbare Objektmodifikationen in den Spielzonen etablieren.

Die so aufgewerteten Ressourcen sollen dem Spieler eine tiefe Immersion seiner erschaffenen Werte offenbaren. Da die Spielzonen nur begrenzt Adaptionen an die Suprastruktur zulassen, bedarf es einer stetigen Expansion. Der Platz einer Spielzone ist begrenzt — strategische Ressourcen abzubauen benötigt wiederum technologischer Bebauung. Viele Voraussetzungen müssen geschaffen werden, um den Fortschritt der Globalstrategie folgen zu können. Die anderen Spieler arbeiten bereits euphorisch an der Sicherung ihrer Grenzposten.

Die Macht ist bösartig und unersättlich — erst stumpft sie uns ab gegen das Leid anderer Menschen und dann macht sie uns süchtig danach, denn nur das Leiden anderer verleiht uns die Gewissheit, dass unsere Macht über sie ungebrochen ist. Im Gegensatz dazu will wahre Autorität nur das Beste für die Mitmenschen; ihr Wirken ist geprägt von Mitgefühl und Gerechtigkeit.

AWE/AEC — Core System

Das AEC Core System bildet das Fundament der gesamten Antares World Engine. Mit 22 Subsystemen deckt es alle grundlegenden Infrastruktur-Dienste ab — von der World Engine selbst über Modulregistrierung, Profiling, Mathematik-Bibliotheken bis hin zu Serialisierung und Reflection.

Subsysteme 01–22

AEC//CORE — Agents Environment Engine Core. Zentraler Kern der World Engine, der alle Subsysteme orchestriert und den Lebenszyklus der Simulation steuert.

AEC//MREG — Module Registration Startup/Shutdown Subsystem. Verwaltung des Modul-Lebenszyklus: Registrierung, Initialisierung und geordnetes Herunterfahren.

AEC//LCLZTN — Localization Service Framework Subsystem. Mehrsprachigkeit und Lokalisierung aller Spielinhalte für den internationalen Server.

AEC//MOVIE — Movie Player Framework Subsystem. Wiedergabe von Zwischensequenzen und cinematischen Inhalten innerhalb der Engine.

AEC//CONFIG — Engine Configuration Framework Subsystem. Verwaltung aller Engine-Konfigurationsparameter und deren persistente Speicherung.

AEC//OHANDLE — Objects Handles Framework Subsystem. Verwaltung von Objekt-Handles für den sicheren Zugriff auf Engine-Ressourcen.

AEC//PRFL/STATE — Profiling/Status Gathering Framework Subsystem. Erfassung und Auswertung von Leistungsdaten und Systemzuständen.

AEC//DEBUG — Debug Printing Framework Subsystem. Debug-Ausgabe und Diagnose-Werkzeuge für die Entwicklungsphase.

AEC//RNG — Random Number Generator Framework Subsystem. Deterministische und nicht-deterministische Zufallszahlengenerierung für prozedurale Inhalte.

AEC//LOGS — Logging Framework Subsystem. Strukturierte Protokollierung aller Engine-Ereignisse über das Drei-Achsen-Filtersystem.

AEC//MATH — Math Library Framework Subsystem. Mathematische Grundfunktionen: Vektoren, Matrizen, Quaternionen, Interpolation.

AEC//MEMORY — Memory Allocation Framework Subsystem. Speicherverwaltung mit Pool-Allokatoren und Arena-basierter Allokation.

AEC//AIOS — Asynchronous File I/O Framework Subsystem. Asynchrone Datei-Ein-/Ausgabe für unterbrechungsfreies Laden von Assets.

AEC//SRLZTN — Serialization Framework Subsystem. Serialisierung und Deserialisierung von Spielzuständen und Netzwerkdaten.

AEC//ASSRTNS — Assertions Framework Subsystem. Laufzeit-Assertions und Vertragsüberprüfungen für die Engine-Integrität.

AEC//PARSERS — Parsers Framework Subsystem. Generische Parser für Konfigurationsdateien, Skripte und Datenformate.

AEC//UTEST — Unit Testing Framework Subsystem. Integriertes Testframework für automatisierte Qualitätssicherung der Engine-Komponenten.

AEC//CRV/SRFC — Curves/Surface Framework Subsystem. Mathematische Kurven- und Oberflächenberechnung für Terrain und Animation.

AEC//STRINGS — Strings/Hash Strings IDS Framework Subsystem. String-Verwaltung mit Hash-basierten Identifikatoren für performanten Zugriff.

AEC//RTTI — RTTI/Reflection Framework Subsystem. Laufzeit-Typinformation und Reflection für dynamische Modulsysteme.

AEC//UID — Unique Identify Framework Subsystem. Generierung und Verwaltung global eindeutiger Identifikatoren für alle Engine-Objekte.

AEC//VSAMDS — Vertical SA Modul Decomposition Subsystem. Vertikale Software-Architektur-Dekomposition für modulare Systemtrennung.

Das AEC Core System bildet Layer 0 der Engine-Architektur. Alle höheren Subsystemgruppen (RES, LLC, SGO, VFX, etc.) sind von AEC abhängig. Eine Änderung an einem AEC-Subsystem hat potentiell Auswirkungen auf alle 175+ darüber liegenden Subsysteme. Änderungen am Core System erfordern daher maximale Sorgfalt und vollständige Regressionstests.

AWE/RES — Ressources Layer

Der RES Ressources Layer verwaltet alle Spiel-Assets und Ressourcen — von 3D-Modellen und Texturen über Skelett-Daten und Materialien bis hin zu Fonts und Kollisionsdaten. Dieser Layer stellt sicher, dass alle Assets effizient geladen, gecached und verwaltet werden.

Subsysteme 26–34

RES//RSSRCS — Game Assets System Ressources Core. Zentrales Asset-Management-System für alle Spielressourcen und deren Lebenszyklus.

RES//GWMAPS — Gameworld Map Framework Subsystem. Verwaltung und Streaming von Weltkarten-Daten für die prozedurale Generierung.

RES//SKELETONS — Skeleton Ressources Framework Subsystem. Skelett-Daten für Character-Animation und Ragdoll-Physik.

RES//TEXTURES — Texture Ressources Framework Subsystem. Texturverwaltung mit Streaming, Mip-Mapping und Kompression.

RES//PPARAMS — Physics Parameter Framework Subsystem. Physikalische Materialeigenschaften für Kollision, Reibung und Elastizität.

RES//MATERIALS — Material Ressources Framework Subsystem. PBR-Materialien mit Shader-Parametern für realistische Oberflächendarstellung.

RES//MODELS — 3D Model Ressources Framework Subsystem. Verwaltung von 3D-Modellen mit LOD-Stufen und Instancing-Unterstützung.

RES//FONTS — Fonts Framework Subsystem. Schriftarten-Verwaltung für UI-Rendering und In-Game-Texte.

RES//COLLISION — Collisions Framework Subsystem. Kollisionsdaten und -geometrien als Asset-Ressource für das Physiksystem.

AWE/LLC — Low Level Renderer

Der LLC Low Level Renderer ist die grafische Basis der Engine. Mit 16 Subsystemen deckt er alles ab — vom Device Interface über Beleuchtung (statisch und dynamisch), Shader-Management, Kamerasysteme bis hin zu Text- und Font-Rendering. Der Name wechselt im Original zwischen LLR und LLC; die Subsystem-Codes verwenden durchgehend LLC.

Subsysteme 51–66

LLC//RENDER — Device Interface Low Level Render Control. Abstraktionsschicht für die GPU-Ansteuerung und Render-Pipeline-Konfiguration.

LLC//SBMSSNS — Primitive Submission Framework Subsystem. Einreichung von Render-Primitiven (Draw Calls) an die GPU-Pipeline.

LLC//DEBUG — Debug Drawing Framework Subsystem. Visuelle Debug-Ausgabe: Wireframes, Bounding Boxes, Physik-Shapes.

LLC//TEXTURES — Texture Management Framework Subsystem. GPU-seitige Texturverwaltung, Bindung und Sampler-Konfiguration.

LLC//SURFACES — Surface Management Framework Subsystem. Verwaltung von Render-Surfaces und Framebuffer-Objekten.

LLC//SLGHTNG — Static Lightning Framework Subsystem. Vorberechnete statische Beleuchtung: Lightmaps, Light Probes, Ambient Occlusion.

LLC//DLGHTNG — Dynamic Lightning Framework Subsystem. Dynamische Echtzeitbeleuchtung: Punktlichter, Spotlights, Schattenwurf.

LLC//MATERIALS — Material Renderer Framework Subsystem. PBR-Material-Rendering mit Shader-Pipeline und Material-Instancing.

LLC//SHADERS — Shaders/Network Framework Subsystem. Shader-Kompilierung, Hot-Reload und netzwerkbasierte Shader-Distribution.

LLC//CAMERAS — Cameras Framework Subsystem. Kamerasystem: Projektion, View-Matrix, Frustum und Kamera-Interpolation.

LLC//VIEWPORTS — Viewports Framework Subsystem. Viewport-Verwaltung für Split-Screen, PiP und Multi-Monitor-Unterstützung.

LLC//VSCREENS — Virtual Screens Framework Subsystem. Virtuelle Bildschirme für In-Game-Displays und UI-Overlays.

LLC//TEXTS — Text Renderer Framework Subsystem. GPU-beschleunigtes Text-Rendering mit SDF-Fonts und Unicode-Unterstützung.

LLC//FONTS — Fonts Renderer Framework Subsystem. Font-Rasterisierung und Glyph-Atlas-Management für die Render-Pipeline.

LLC//INTERFACE — Graphics Device Interface Framework Subsystem. Abstraktion der Graphics-API (Vulkan, WebGPU) für plattformunabhängiges Rendering.

LLC//SKLTN/MSH — Skeleton Mesh Rendering Framework Subsystem. GPU-basiertes Skelett-Mesh-Rendering mit Vertex-Skinning und Bone-Animation.

Die Trennung zwischen RES (Asset-Daten) und LLC (Rendering) folgt dem bewährten Muster der Daten-Logik-Separation: RES verwaltet die Ressourcen als Daten, LLC konsumiert sie für die visuelle Darstellung. Dies ermöglicht unabhängiges Streaming, Caching und Hot-Reloading von Assets ohne den Renderer zu blockieren.

Siehe auch

Module: Ase Docs 00.16.32 [feat] Author: Jan Ohlmann (antarien.com@gmail.com) Co-Author: Claude Code (Anthropic) Created: 2026-02-19 Updated: 2026-02-19 Status: Kuratierte Version — Globalstrategie & Kernsysteme (PortalViewer DSL)