12
Apr

AOW ECS Architektur Implementierung Unity3D/Entitas

Antares Open World [AOW] – DEV Update 12.04.19

Meine ersten ECS Umsetzungen

Heute möch­te ich Euch die Ziele und Vorteile mei­ner AOW ECS Architektur vor­stel­len, an wel­cher ich die letz­ten Tage mit Unity3D und dem ECS Framework Entitas ge­ar­bei­tet ha­be. Vielen Dank auch an die Schreiber der vie­len Tutorials rund um Entitas. Zu Entitas selbst ha­be ich be­reits in mei­nem frü­he­ren Blog Post be­rich­tet.

Um was geht es al­so ge­nau. Lass uns ei­nen Blick auf die Anforderungen neh­men.

Definition von Daten/Logik und Ansichtsebenen
strik­te Trennung die­ser Ebenen
Generalisierung über Schnittstellen
Inversion der Kontrolle
Abstraktionen al­ler Ansichten

Antares Open World (AOW) ist ge­nau ge­nom­men, oh­ne all sei­ne Grafiken ei­ne wer­den­de kopf­lo­se MMORPG Simulation, wel­che stän­dig Zustände des Systems ge­gen­ein­an­der auf­rech­net und ver­rech­nen wird. Man könn­te auch sa­gen, dies sind al­les ge­sam­mel­te Daten des Spiels. Anhand der Spiellogik, dem Regelwerk (Business Logik), wer­den die­se Daten (Zustände) nun ste­tig an­ge­passt. Dieses AOW Herzstück (Core) kann so­dann oh­ne die­se wei­te­ren Schichten exis­tie­ren.

Erst der Spieler, der von au­ßen in die Simulation ein­greift, ver­än­dert die­se ak­tu­el­len Zustände. Hierzu wird nun ei­ne Ansichtsebene be­nö­tigt, wel­che für die­se Kommunikation mit dem Spieler zu­stän­dig ist. Zudem weis die Simulation nicht, das sie von die­ser Ebene aus trans­pa­rent ge­macht und/oder ge­steu­ert wird.

Welche Vorzüge ergeben sich nun aus dieser Art der Herangehensweise?

Am wich­tigs­ten, wir ha­ben un­se­re Spiel Code Implementierung voll­stän­dig von der Game Engine, hier Unity3D und an­de­ren Bibliotheken ent­kop­pelt. Wir ha­ben ei­ne voll­stän­dig vom Motor un­ab­hän­gi­ge AOW Simulation. Es gibt nur ei­nen Ort, wo al­le Unity Implementierungen in Form von Schnittstellen lan­den. So kann ich mor­gen, z.B. auf die Unreal Engine, Lumberyard oder Cry Engine, etc,.. wech­seln. Eines mei­ner Hauptanliegen der let­zen Jahre war es, ge­nau die­se Flexibilität er­rei­chen zu kön­nen.

Daten: Speicherung al­ler Zustände des Spiels
Logik: Das Regelwerk des Spiels
Ansicht: Anzeige des Status im Spiel/Simulation
Dienste: al­le Drittanbieter Libraries, auch die Engine selbst
Eingabe: Zugriff auf Netzwerk, Controller und Tastatur

Viel mehr noch, wir ha­ben ei­ne spe­zi­fi­sche Position in Kopf der Anwendung, wo ich ent­schei­den kann, wel­che Implementierungen ich künf­tig nut­zen möch­te. So kann ich Testumgebungen und Situationen si­mu­lie­ren, oder Drittanbieter Software ein­fach tau­chen, eta­blie­ren und Erfahrungen sam­meln. Die Spiellogik fas­se ich hier­bei nicht an. Dank der Trennung der Ansichtsebene mit­tels Event Listeners, kann ich den Ansichtscode pro­blem­los auf Client Rechnern im­ple­men­tie­ren. Der Server Code bleibt hier­bei Headless in ei­ner hoch ska­lier­ba­ren Umgebung, wie z.B. Azure oder AWS. Ich über­le­ge hier noch.

Der Code ist da­bei sau­ber und ein­fach struk­tu­riert les­bar. Komplexe Implementierungen wer­den ver­steckt. Einfache Aufrufe und be­schrei­ben­de Methoden er­mög­li­chen dank der AOW Plattform Architektur schnel­ler und wart­ba­rer ans Ziel zu kom­men. Die Schnittstellen sind spe­zi­fisch auf die je­wei­li­gen zu de­di­zie­ren­den Einsatzzwecke fo­kus­siert. Der Roslyn Code Generator er­zeugt dank Entitas al­le not­wen­di­gen Code Konstrukte des Frameworks.

Dies ist von enor­mer Wichtigkeit, da tau­sen­de Systeme und Komponenten war­ten, das Licht der AOW Simulation zu er­bli­cken. Durch ei­ne hier­ar­chi­sche Ordnungsstruktur, die sich durch al­le agi­len Plattformen, Foren und Tools zie­hen, kann ich so auch sehr gro­ße kom­ple­xe Zusammenhänge, die durch die­ser Art der Software Entwicklung en­ste­hen gut auf­lö­sen.

Anbei: Screenshot des Unity Titelbildes (Hochauflösend)

Ich hal­te Euch auf dem Laufenden.
Jan

Überblick in PDF Form: AOW Konzept
Community Forum: AOW ADG Forum
Facebook: AOW FB Seite
Mitarbeit: ADG Slack Portal