Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Implementierung der Benutzerverwaltung, Lobby und Matchmaking mit Amazon Web Services (AWS), respektive der Dienste Amazon GameLift, CloudWatch, Cognito, DynamoDB, IAM, Lambda (Ruby) und S3.
Implementierung Benutzerverwaltung, Lobby und Servermap
Heute möchte ich Euch die nächsten Fortschritte meines Projektes vorstellen. Der aufmerksame Leser, wird sicher noch meine Ankündigung zum Thema improbable.io vor Augen haben. Leider konnte ich diesen Weg nicht weiter gehen. Die Gründe sind Vielschichtig. Unser Projekt ist so speziell, das ich die Kontrolle über die Mechanismen der Implementierung benötige, um in Funktionalitäten eingreifen, oder diese erweitern können muss, welches bei einer Out of the Box Lösung, extreme Probleme entstehen lässt. Wem dies im Detail interessiert, schreibe mich per PM an.
Mit jeder geschlossenen Tür öffnen sich aber auch neue Türen, so gehe ich nun schon seit geraumer Zeit einen neuen Weg über die Amazon Web Services (AWS). Inspiriert wurde ich von diesem Artikel: https://forums.awsgametech.com/t/can-i-u…e-based-mmo/877 Der Weg ist steinig, aber ich konnte viele Fortschritte verzeichnen, welche ich Euch natürlich nicht vorenthalten möchte.
In diesem Video seht Ihr meine Umsetzung der vollständigen Benutzerverwaltung (Erstellung eines neuen Spielers, inklusive MFA, Password Reset, Benutzer Komfort Funktionen), Freunde Verwaltung, Party/Lobby System mit Einladung auf einem dedizierenden Gamelift Server (c5.large). Zudem habe mich vorerst dazu entschlossen, auf einen Launcher zu verzichten und die Benutzerverwaltung direkt in das Hauptmenü des Spiels zu implementieren.
Die serverseitigen Abfragen erfolgen über den Lambda Service von AWS. Die Funktionen sind in Ruby geschrieben und greifen auf die notwendigen AWS Dienste, wie dynamoDB, IAM, CloudWatch zu.
Alle prozeduralen Foliage Spawner habe ich im Video deaktiviert, um hier besser die zu replizierenden Mechanismen in Bezug auf die Performance beobachten zu können. Um Euch aber einen Einblick in die Möglichkeiten des Prozeduralem Foliage Spawners zu geben, am Ende noch ein Screenshot eines möglichen Szenarios in einem herbstlichen Wald.
Ebenfalls könnt ihr am Ende des Videos, meine ersten Versuche eines Aktivitäten Menüs erkennen (Danke @TheMaddestHatter), für welche ich gerade Icons mit Adobe Illustrator zeichne.
Hier im zweitem Bild könnt ihr die hochgeladenen Builds, die erzeugten Flotten und die referenzierenden Aliasse zu den Fleets sehen. Die Aliase ermöglichen es mir, ohne Änderungen des Client Quellcodes eine Fleet auszutauschen, zum Beispiel um Änderungen an den Server Maps vorzunehmen.
Um Kosten zu sparen, laufen alle Fleets auf einem Amazon Linux OS. Als Typ habe ich den Spot Modus gewählt, welcher im Rechenzentrum Frankfurt (eu-central-01) seine Arbeit verrichtet. Es können im Moment 20 Game Sessions gleichzeitig gestartet werden. Die Match Making Config entscheidet, in welcher Session dieser landet. Für Details gerne per PM anschreiben. Ich experimentiere gerade mit der Persistenz, welche für die künftige Open Hybride World via Server Travelling/Zoning, so zu implementieren ist, dass ich die Funktionen aus SpartialOS in einem ähnlichem Ansatz nutzen kann. Das ganze ist aber echt harter Stoff, und über Hilfe im AWS Backend freue ich mich natürlich um so mehr.
Auch haben wir/ich es geschafft, die Transitionen auf Basis einer virtuell berechneten Höhenkarte in Voxel Plugin für die Biome zu implementieren. Harte Übergange sind also nun auch Geschichte. Dank Oceanology haben wir/ich nun auch einen guten Weg gefunden die Wasseroberfläche für unsere Zwecke replikationsfähig zu machen. Leider ist das originäre Unreal Wasser/Fluid System (UE 4.26) zu stark an das Unreal Landscape gebunden, was es im aktuellem Stand unmöglich macht, es auf unser Procedural Runtime Mesh oder auf Voxel anzuwenden. Denn egal wie sehr du nach Plugins für Lösungen auf dem Marktplatz suchst wirst du merken, dass alles nur in einem kleinem Ökosystem im Single Player läuft, nicht für Multiplayer geschaffen ist,.. schon gar nicht für ein MMO, oder sich eben einfach vieles gegenseitig in Wechselwirkungen behindert/ausschließt.
Ja und um meine kreative Ader bei der Programmierung nicht ganz versiegen zu lassen, habe ich mich noch mit dem Zeichnen von Icons beschäftigt. Eine Wissenschaft für sich. Am Ende des Videos sind bereits zwei Icons zu erkennen, die im späterem Verlauf für die Aktivitäten des Försters im Beispiel an Fokus gewinnen werden.
Hier im Beispiel: Ein Loch für einen Baum Setzling im Beruf des Försters graben:
Noch etwas in eigener Sache. Wenn du Lust hast am Projekt mitzuwirken melde Dich! Zudem bin ich mittlerweile an dem Punkt auch kleinere Auftragsarbeiten vergeben zu wollen. Wer also Lust hat kann sich gerne melden. Es wird sicher nicht viel sein können, aber es sollte zumindest einer Aufwandsentschädigung als dank für die Mitarbeit am AOW Projekt behilflich sein.
Vor kurzem ist die Unreal Engine 5 Preview 1 und 2 erschienen. Dies habe ich zum Anlass genommen, nun auch mein AOW AWAKE Projekt auf die erste Phase der Migration zu heben. Für dieses Upgrade musste ich einen neuen Unreal AOW Fork auf Github anlegen, da einige unserer Plugins nur auf Source Code Engine Ebene funktionieren.
Zudem habe ich die Awake Projekt Architektur von Grund auf neu organisieren müssen, um unsere Workflows gegenüber Drittanbieter Tools, wie Houdini, iClone, WWISE und die Amazon Game Tools nicht zu gefährden.
Ebenfalls musste unser AOW Prozedural Runtime Terrain Modul nun auf das Unreal Procedural Mesh (PMC) umgeschrieben werden, da einige Funktionalitäten des Runtime Meshes (RMC) der Community Edition für mich unzufriedene Ergebnisse in der Unreal 5 lieferten.
Anmerkung: Der erste Screenshots ist direkt aus dem Unreal Editor, und der weite Screenshot direkt aus dem Spiel aufgenommen worden.
So habe ich von Hand und Schritt für Schritt die einzelnen Unreal Assets in das neue Unreal 5 Projekt überführt. Einige Plugins zu Modulen vorerst für die weitere Entwicklung umgeschrieben, und wieder direkt in den AOW Projekt Source Code verlagert.
Im Moment bin ich zum Beispiel, auch dabei einen generischen prozeduralen Foliage Spawner mit diversen Funktionalitäten zu schreiben, der es mir ermöglichen wird, statische Assets, als auch dynamische Akteure an Böschungen und definierten Höhen in Bezug zu einer variablen Transformation und Rotation zu spawnen.
Im Screenshot seht ihr einen Blick auf die einzelnen Terrain Kacheln/Areale, welche prozedural im Umkreis eines Unreal Akteurs, ein dynamisch erzeugtes Gelände anhand von Seeds, immer wieder auf die gleiche Weise erzeugen kann. Ich berichtete in einen der früheren DEV Tagebucheinträgen davon.
Meine Ideen das Ganze ausschließlich auf Basis von Voxels zu implementieren, musste ich leider wieder verwerfen, da es ein Performance Albtraum in der AWS Cloud war.
Nun wird es wohl doch -vielleicht nur vorerst-, auf ein hybrides Höhenkarten System hinauslaufen, welches an POI´s dann mittels dem Transvoxel Algorithmus, hier die Voxel Ebene bei Interaktion durch den Spieler unter der eigentlichen Terrain Höhenkarte, dieses spawnen wird.
So sind Suprastrukturen, die über die Game Mechanik ein Gebäude, zum Beispiel einen Eingang zu einem Bergwerk (horizontal, als auch vertikal) vom Spieler gebaut, denkbar, welche dann durch eine Lade Animation beim Eintritt in das Gebäude, oder dem hinunter Fahren in den Schachtes, den Spieler in die Voxelwelt instanziiert, mögliche Ideen.
Das gute daran wäre, das ich je nach Spielerauslastung, diese dann auf den Voxel basierten Ebenen (Levels), auch instanziieren kann, ohne die eigentliche weitläufige Open World dabei in ihrer Performance zu gefährden.
Die größte Herausforderung ist es dann natürlich, dem Spieler dennoch einen "seamless" Übergang und mögliche Immersion versuchen zu geben.
In den letzten beiden Screenshots könnt ihr, ein Zusammenspiel mit dem Ozeanologie Plugin und dem prozeduralem Terrain Generator sehen.
--
Noch etwas in eigener Sache. Wenn du Lust hast am Projekt mitzuwirken melde Dich! Zudem bin ich mittlerweile an dem Punkt auch kleinere Auftragsarbeiten vergeben zu wollen. Wer also Lust hat kann sich gerne melden. Es wird sicher nicht viel sein können, aber es sollte zumindest einer Aufwandsentschädigung als dank für die Mitarbeit am AOW Projekt behilflich sein.
Es ist der perfekte Zeitpunkt sich mit vielen Hürden meines AOW Projektes in langen dunklen Nächten zu beschäftigen. Denn eines kann ich Euch schreiben, mein Wissen,... wie etwas nicht funktioniert, oder wie ich etwas künftig angehen werde, habe ich in den letzten 8 Jahren perfektionieren können. Aber kommen wir zu meinen aktuellen Gedankengängen und meiner aktuellen Problemstellung.
Wer seit vielen Jahren meine DEV Logs ließt, der weis das ich schon einige Engines, wie die Unity oder Unreal evaluiert habe und auf Grund fehlenden Wissens und Erfahrungen, auf mögliche falschen Verlockungen geschaut habe. In den Jahren haben sich jedoch die Anforderungen speziell an das Terrain System sehr fest kristallisieren können. So ist eines der Kernkompetenzen, wie ihr ja wisst, dass ein Spieler seine Welt über das Terrain (Terraforming) verändern kann. Genau hier bat zum Beispiel die Unity Engine das Terrain als Gameobjekt an. Dennoch habe ich vor einigen Jahren zur Unreal gewechselt,... aus triftigen Grund, was der interessierte Leser ausführlich in den Archiven dieses Threads nachlesen kann.
Die neue große Hoffnung in den Händen ist die Unreal Engine 5. Zwar gab und gibt es keine "Out of the Box" Lösung, die es zulässt ein Terrain zur Laufzeit manipulieren zu können. Ich spreche vom Unreal Landscape. (Mit einigen Hacks ist es möglich, ich weiß...) Jedoch hatte ich in den vergangenen 2 Jahren einen durchaus performanten und nutzdienlichen PoC mit der Runtime Mesh Component (RMC), sowie auch mit dem Prozedural Mesh (PMC) von der Unreal Engine selbst, eine ganz passable Lösung implementieren können. Die Ergebnisse findet ihr ja in den älteren Thread Einträgen von mir.
Leider hat diese parallele Entwicklung Konsequenzen. Sämtliche tollen Neuerungen und Ideen der Unreal 5 basieren auf das hauseigene Landscape Terrain, was soviel bedeutet, das meine eigenen Entwicklungen zum Unreal 5 Fortschritt im Prinzip inkompatibel wurden. Sei es die neue Streaming Technologie (World Partition) oder das neue Wasser System, welches auf das Landscape Modul abgestimmt ist. So gesehen hänge ich dem Fortschritt der Unreal immer durch die eigene Entwicklung meiner "Galapagos Insel" hinterher. Und dies ist ein sehr harter Beigeschmack den ich so für mein Projekt nicht mehr tragen will. Zudem sprechen wir hier noch nicht von einem Cloud to Terrain Streaming basierenden Ansatz auf ECS Basis.
Die lange Rede hinter dem Sinn,...
Es hat mich dazu bewegt meine Gedanken noch einmal in Form von Akzeptanzkriterien neu zu formulieren und auf dem Markt nach Engine Alternativen zu schauen, um vielleicht eine bessere Ausgangsbasis für mein AOW Projekt bekommen zu können. Auch der Gedanke meine Entwicklung in die Richtung der eigenen Engine weiter zu treiben, kamen mir dabei in den Sinn.
So habe ich mir die vielversprechende Unigine Engine, insbesondere die COM/ENG/SIM Version genauer angeschaut, welches ein Terrain System mit einer doppelten Genauigkeit bietet, und zudem tatsächlich auch zur Laufzeit das Gelände verändern kann. Leider sind die Kosten der für mich sinnvollen SIM Version einfach zu hoch, als das ich hier mit 3-5 Entwicklern realistisch gesehen, mein Projekt implementieren könnte.
Lumberyard geht Open Source
Ich hatte schon früher die Lumberyard im Auge, insbesondere weil Star Citizen und New World imposante Vorzeigeprojekte sind. Zudem die Engine einen nahtlosen Übergang zur AWS bietet. Jedoch bin ich damalig auf Grund der Lizenz Politik (Steam, etc) und anderen Restriktionen, wieder davon abgewichen. Nun ergab sich jedoch vor kurzen ein äußerst interessanter Umstand. Amazon Games überführt ihre Lumberyard Engine unter Aufsicht der Linux Foundation in ein Open Source Projekt unter der Apache 2 MIT Lizenz.
Und jetzt wird es plötzlich extrem spannend für mich.
Diese Entwicklung hat mich nun eindeutig hellhörig gemacht, und ich habe angefangen die o3de Engine auf meine Anforderungen zu evaluieren. Zu meinem erstaunen musste ich feststellen, das erstmal das alte Cry/Lumberyard Terrain System bei der Open Source Portierung rausgeflogen ist. Nun gut,... hierin steckt natürlich auch die einmalige Chance, das die neue Entwicklung des Terrain Systems durch die Community für die o3de Engine nun "zufällig" auch meinen Kriterien entsprechen könnte. Ich begab mich also auf die Suche dessen, und fand folgendes RFC Paper. Ich konnte meinen Augen beim Lesen kaum glauben,... und tatsächlich gab es viele andere Entwickler die ähnliche bis fast identische Vorstellungen von einem modernen und zeitgemäßen Terrain System hatten und bereits in die Umsetzung gegangen sind.
So hatte ich den Entschluss gefasst, mich tiefgehend mit der neuen o3de Engine, insbesondere dem Terrain System zu befassen. Mittlerweile ist der erste Prototyp in die Engine in Form eines GEMs eingeflossen,... und was soll ich sagen. Ich bin wirklich begeistert. Eine ganze Community entwickelt etwas, was ich schon immer versucht habe selbst, mehr oder weniger alleine zu entwickeln. So konnte ich mich seit geraumer Zeit, wieder auf die Game Mechanik konzentrieren, die dieses o3de Terrain GEM nun als Abhängigkeit benutzt, um meine Terraforming Simulation, wie Erosion, Vulkanausbrüche, Plattenverschiebungen... oder der die vom Spieler veränderbare Welt, meine Simulation ala Worldmachine in Runtime in die Engine zu implementieren.
Noch viel besser,... die notwendige Cloud Schnittstelle zu den AWS Services kommen hier sogar "Out of the Box", welches der Community und mir ein Cloud Streaming Datenfeed an das o3de Terrain System auf Basis eines Entity Component System (ECS) ermöglicht.
Wer sich genauer in die o3de Terrain Technologie einlesen möchte, dem empfehle ich das RFC Terrain Paper, welches auf der Basis dieser Evaluierung und Diskussion entstand. Es beantwortet bereits viele Fragen, vor allem jedoch meine Fragen zufriedenstellend zum Thema der Terrain Anforderungen an mein AOW Projekt.
So kann ich nativen Engine Code benutzen, ohne wieder mit meiner Entwicklung ausgegrenzt zu werden. Es bleibt natürlich abzuwarten, was die Community nun aus dieser großartigen Chance machen wird,... mich eingeschlossen, da ich mich aktiv an der Terrain Entwicklung der o3de Engine beteiligen werden.
Ich sehe aber endlich wieder Möglichkeiten und Freiheitsgrade, die mir so vorher nicht mehr gegeben waren. Unreal Engine 5 ist großartig, keine Frage,.. für ihren spezifischen Einsatzweck jedoch vorausgesetzt. Dies liegt natürlich vor allem daran, das die Engine ihr Steckenpferd "Fortnite" bedienen muss. Und in diesem Spiel gibt es nun mal kein Terraforming. Solange du im Fahrwasser dessen Entwicklung bleibst, wirst du großartige Ergebnisse mit der Engine erzielen.
Wir werden sehen was die Zukunft bringt. Im Moment denke ich einen begehbaren Weg mit der o3de Engine gefunden zu haben. Was im Moment bleibt sind ein paar Wehrmutstropfen, wie die noch Floating Genauigkeit der Engine und/oder der PhysX Engine,.. auf dessen bezogen. Aber alles ist im Grunde so modular aufgebaut, das sich auch eine andere Physik Engine ohne großen Aufwand tauschen ließe.
In diesem Sinne, erwartet mich nun viel Arbeit hier systematisch mein Projekt vermutlich, statt zu portieren eher in o3de Engine neu zu implementieren.
--
Noch etwas in eigener Sache. Wenn du Lust hast am Projekt mitzuwirken melde Dich! Zudem bin ich mittlerweile an dem Punkt auch kleinere Auftragsarbeiten vergeben zu wollen. Wer also Lust hat kann sich gerne melden. Es wird sicher nicht viel sein können, aber es sollte zumindest einer Aufwandsentschädigung als dank für die Mitarbeit am AOW Projekt behilflich sein.
Veränderung ist Fortschritt,
Euer Jan aka Azzuriel
P.S. @**Achilles** ich hoffe ich konnte ein wenig Licht in meine Gedankenprozesse bringen. Vor allem, warum es die letzte Zeit wenig zu berichten gab.
Tod geglaubte, leben länger... seit dem ich meine Entwicklungsschritte auf die What´s Up Gruppe verlegt habe, ist es hier still um das Projekt geworden. Gerne möchte ich Euch aber von Zeit zu Zeit oder nach Aufforderung auch auf dieser Plattform meine neusten Updates liefern.
Am Anfang des Jahres habe ich neue Entscheidungen getroffen und meine grundlegende Strategie der Machbarkeit erneut reflektiert. Es geht ja nun in das 11 Jahr AOW und im Prinzip, bin ich so Reich wie noch nie an Erfahrungen rund um meine Versuche irgendwelche Implementierungen als im Prinzip Einzelperson aus dem Boden zu stampfen. Ich denke ich muss meiner Realität in die Augen sehen, und habe in viel Zeit des Nachdenkens nun für mich folgende Dinge beschlossen: (Bis ich eines besseren belehrt werde...)
- aufgeben ist keine Option, ABER:
- kein AOW mehr, das O fliegt raus,... ergo AW = Antares World
- kein MMO mehr, ergo ein Single Player Game, noch nicht mal Multiplayer (vorerst)
- kein 3D mehr,... ja nur noch klassisches oldschool 2D like Rim World, Dwarf Fortress oder Iso Darstellung Richtung Ultima Online (3D kann später adaptiert werden)
- Keine AAA+ Engines mehr mit Overloaded oder historisch gewachsenem Quellcode, ergo, kein Unity, Unreal,..
- kompletter Neuanfang
+ zurück zu meiner ursprünglich angedachten ECS Architektur
+ Keep it Smart & Simple
+ Wechsel auf die Programmiersprache RUST mit der BEVY Engine (von Hause aus ECS & Data Driven Language)
+ nun viel Zeit für die wesentlichen simulativen Mechaniken des Games
Ebenfalls hat sich meine Politik zur Community geändert, denn der Grundgedanke war schon ja immer ein Spiel von Gamern für Gamer zu entwickeln:
So auch in der Hoffnung gleichgesinnte zu finden und diese im Stream gemeinsam in Synergieeffekte zu wandeln.
Es schmerzt, aber ich hoffe diese Kompromisse, werden es mir möglich machen, irgendwann nun doch noch zu einer spielbaren Version zu kommen. Es geht um die Spielidee der komplexen Simulation meiner designten Systeme. Ich werde jetzt und ausschließlich dort mein Augenmerk legen. Ich habe 10 Jahre ausgefeiltes Game Design,.. also viel Stoff bei dem das Gamer Herz höher schlagen könnte.
Vielleicht ändert sich durch meinen Strategiewechsel die Situation der Implementierung, so das ich auf diesem Wege neue Möglichkeiten ergeben,... bis dahin heißt es Minimalismus.
Veränderung ist Fortschritt,
Euer Jan aka Azzuriel
P.S: Fragen zum Fortschritt und der gleichen beantworte ich gerne im Stream ;)
Keine AAA+ Engines mehr mit Overloaded oder historisch gewachsenem Quellcode, ergo, kein Unity, Unreal,..
- kompletter Neuanfang
Meiner Erfahrung nach bedeutet das keinen schnelleren Fortschritt. Lediglich mehr Erfahrung muss gesammelt werden, weil die Technologie getauscht wird. Das Projekt zu verkleinern ist sinnvoll, aber die Engine zu tauschen, ist fraglich.
Ich persönlich sehe jedoch leider im Moment keine Möglichkeit mit z.B. der Unreal weiter zu machen. Begründet wird dies u.a., durch den doch sehr speziellen Anspruch von mir auf gewisse Kern Kompetenzen im Spiel nicht verzichten zu wollen. Hier Terraforming prozedural zur Laufzeit mal in den Raum geworfen. Und ja, ich habe ein performantes Unreal Terrain Plugin geschrieben, welches eigentlich den PoC mittels RMC den Beweis bietet, mit Unreal weiter machen zu können.
Jedoch mit dem Erkauf von anderen Kompromissen, die ich auch nach 10 Jahren nicht bereit bin einzugehen, Stichwort parallele Entwicklung, die mein Terrain Plugin mit den neuen Features der Unreal 5 inkompatibel macht. Mal sehen vielleicht passiert es noch in meinem Leben und Unreal überarbeitet ihr Landscape Modul, ich denke ich wäre Ernsthaft in Versuchung :)
Dabei gäbe es die Lösung direkt im Quellcode des Editors selbst, jedoch nicht ohne eine Lizenz Verletzung des Design Codes in Kauf zu nehmen. Wie auch immer, ich finde es mittlerweile sogar erfrischend und als Fortschritt auf 2D gewechselt zu haben. Es wird dadurch nicht einfacher, aber viele Dinge passen zu einem hardcore sandbox simulativen Spiel gefühlt fast besser zusammen,.. ich schaue Richtung V-Rising, Rim World gepaart mit Project Zomboid und den schönen und alten old-school Elementen von Ultima Online.
Projektvorstellungen und Stellenangebote »
NEGAIA
(15.09.2013, 13:10)
19.04.2024, 04:44
Zum Seitenanfang
