AOW ECS Architektur Implementierung Unity3D/Entitas
Antares Open World [AOW] – DEV Update 12.04.19
Meine ersten ECS Umsetzungen
Heute möchte ich Euch die Ziele und Vorteile meiner AOW ECS Architektur vorstellen, an welcher ich die letzten Tage mit Unity3D und dem ECS Framework Entitas gearbeitet habe. Vielen Dank auch an die Schreiber der vielen Tutorials rund um Entitas. Zu Entitas selbst habe ich bereits in meinem früheren Blog Post berichtet.
Um was geht es also genau. Lass uns einen Blick auf die Anforderungen nehmen.
Definition von Daten/Logik und Ansichtsebenenstrikte Trennung dieser EbenenGeneralisierung über SchnittstellenInversion der KontrolleAbstraktionen aller Ansichten
Antares Open World (AOW) ist genau genommen, ohne all seine Grafiken eine werdende kopflose MMORPG Simulation, welche ständig Zustände des Systems gegeneinander aufrechnet und verrechnen wird. Man könnte auch sagen, dies sind alles gesammelte Daten des Spiels. Anhand der Spiellogik, dem Regelwerk (Business Logik), werden diese Daten (Zustände) nun stetig angepasst. Dieses AOW Herzstück (Core) kann sodann ohne diese weiteren Schichten existieren.
Erst der Spieler, der von außen in die Simulation eingreift, verändert diese aktuellen Zustände. Hierzu wird nun eine Ansichtsebene benötigt, welche für diese Kommunikation mit dem Spieler zuständig ist. Zudem weis die Simulation nicht, das sie von dieser Ebene aus transparent gemacht und/oder gesteuert wird.
Welche Vorzüge ergeben sich nun aus dieser Art der Herangehensweise?
Am wichtigsten, wir haben unsere Spiel Code Implementierung vollständig von der Game Engine, hier Unity3D und anderen Bibliotheken entkoppelt. Wir haben eine vollständig vom Motor unabhängige AOW Simulation. Es gibt nur einen Ort, wo alle Unity Implementierungen in Form von Schnittstellen landen. So kann ich morgen, z.B. auf die Unreal Engine, Lumberyard oder Cry Engine, etc,.. wechseln. Eines meiner Hauptanliegen der letzen Jahre war es, genau diese Flexibilität erreichen zu können.
Daten: Speicherung aller Zustände des Spiels
Logik: Das Regelwerk des Spiels
Ansicht: Anzeige des Status im Spiel/Simulation
Dienste: alle Drittanbieter Libraries, auch die Engine selbst
Eingabe: Zugriff auf Netzwerk, Controller und Tastatur
Viel mehr noch, wir haben eine spezifische Position in Kopf der Anwendung, wo ich entscheiden kann, welche Implementierungen ich künftig nutzen möchte. So kann ich Testumgebungen und Situationen simulieren, oder Drittanbieter Software einfach tauchen, etablieren und Erfahrungen sammeln. Die Spiellogik fasse ich hierbei nicht an. Dank der Trennung der Ansichtsebene mittels Event Listeners, kann ich den Ansichtscode problemlos auf Client Rechnern implementieren. Der Server Code bleibt hierbei Headless in einer hoch skalierbaren Umgebung, wie z.B. Azure oder AWS. Ich überlege hier noch.
Der Code ist dabei sauber und einfach strukturiert lesbar. Komplexe Implementierungen werden versteckt. Einfache Aufrufe und beschreibende Methoden ermöglichen dank der AOW Plattform Architektur schneller und wartbarer ans Ziel zu kommen. Die Schnittstellen sind spezifisch auf die jeweiligen zu dedizierenden Einsatzzwecke fokussiert. Der Roslyn Code Generator erzeugt dank Entitas alle notwendigen Code Konstrukte des Frameworks.
Dies ist von enormer Wichtigkeit, da tausende Systeme und Komponenten warten, das Licht der AOW Simulation zu erblicken. Durch eine hierarchische Ordnungsstruktur, die sich durch alle agilen Plattformen, Foren und Tools ziehen, kann ich so auch sehr große komplexe Zusammenhänge, die durch dieser Art der Software Entwicklung enstehen gut auflösen.
Anbei: Screenshot des Unity Titelbildes (Hochauflösend)
0 comments