spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

@buzz-steve

Ich denke ich verstehe nun, was noch unklar ist,... Es gab einfach im gesamtem Hype-Zeitraum, niemanden der programmieren wollte und/oder konnte. Die Professionals (2) im Team hatten zu wenig Zeit für das Projekt, waren mehr oder weniger nur als Berater im Team, die Hobbyisten (1) wiederum, hatte zu wenig Erfahrung. Er lernte gerade Java. Alle anderen im Team waren Non-Coder. Ich hatte zudem seiner Zeit Vollzeit damit zu tun, zu erklären was implementiert werden müsste, als Einstieg. Da es vor 500 Tagen eben noch keine spezifischen Dokumente für die technische Seite der Implementierung gab, ein schwieriges Unterfangen,.. natürlich auch dem Umstand geschuldet, keine leichte Kost umsetzen zu wollen. Zu dem Bestand Uneinigkeit, welchen Weg man sich als erstes Ziel setzen wolle. Eigene Interessen kamen dazu, welche sodann mit den Projektzielen kollidierten. Daher meine Aussage, es gab schlichtweg niemanden der den Kenntnisstand besaß, mit der Implementierung zu beginnen. Nach den Möglichkeiten der zur Verfügung stehenden Zeit, wurde jedoch versucht in Java einen kleinen Teil als Prototyp eines Moduls zu entwickeln, welches jedoch im Verlauf nicht weiter geführt wurde. Aus eben o.g. Gründen. Heute besteht eine komplett andere Handlungsgrundlage -da ich, wie ich schrieb-, die letzten 18 Monate damit verbracht habe, diesen Umstand aufzuarbeiten. Auch verfolge ich mittlerweile einen anderen Denkansatz im Bezug zur Umsetzungspolitik, so wie bereits einige Beiträge voraus geschildert wurde.

Ungeachtet dessen, würde ich sodann nun aber wieder zurück zum eigentlichem Thema des Thread kommen, Danke.

Update 14.05.19: Wer aktuelle Entwicklungen am Projekt weiter begleiten möchte, kann sich meinem Blog gerne anschließen. Das Projekt unterliegt dem stetigem Fortschritt, auch wenn hier im Moment nicht veröffentlicht wird.

Beste Grüße
Jan

#DEV Update 16.05.2019

Die letzte Antwort auf dieses Thema liegt mehr als 1 038 Tage zurück. Das Thema ist womöglich bereits veraltet. Mitnichten! So der erste Hinweis vom Forum vor dem Senden. Mit viel Erfurcht und Respekt erwecke ich diesen Thread, das Projekt jedoch sollte nie weg gewesen sein. Die Gründe der Schreibpause in diesem Forum lagen auf der Hand. So habe ich mein Lebenswerk die letzten 3 Jahre allein weiter geformt und stetig ein Stückchen näher an meine Visionen und Ziele gebracht. Diese Konsolidierung war nötig.

Seid der ersten Projektvorstellung vor fast 5 Jahren wurde stetig am Projekt gearbeitet. Wenn auch alleine, viele Sackgassen, so sollten noch mehr Hürden und Steine meinen Weg ebenen. So gab es bis heute kaum Stillstand. Alles was an Freizeit über die familiären und beruflichen Verpflichtungen an Freiraum zu Verfügung standen, wurden unausweichlich investiert.

Mittlerweile dürften über 8.000 Projektstunden zusammen gekommen sein. So haben natürlich auch die großen Game Engines, wie Unity 3D, Unreal & Co, ihre Entwicklung durchlaufen und Fortschritte zu meinem/unserem Vorteil verzeichnen können. Insbesondere nimmt Unity 3D für mich und mein Projekt den richtigen Weg. So habe ich meine Unreal Implementierung vor geraumer Zeit eingestellt und bin zu Unity 3D. Nein nicht zurück, es ist meine erste Erfahrung mit Unity und ich kann mit guten Gefühl sagen, im Moment in keine Sackgassen zu laufen.

Der Unity Burst Compiler, das JOB und Entity Component System (ECS) zum Beispiel, Errungenschaften, welche in den letzten Jahren zu immer mehr Schnittmengen auf meiner Agenda führten. Zudem hat das Unternehmen Improbable mit seiner spatialOS Umgebung endlich wieder an Fahrt gewinnen können. Nicht zuletzt durch ihre GDK for Unity mit MIT Lizenz. Zudem sich nun auch die Wogen, um die TOS zwischen Unity und Improbable geglättet haben, ich auch die Bestätigung nach Anfrage an Unity erhalten habe, stand der nachhaltigen Umsetzung und Zugewinn dieser Partnerschaften, nichts mehr im Weg.

So wird es mir künftig möglich sein, Euch sehr nah an meiner, vielleicht auch wieder unserer Entwicklung halten zu können. Hierzu müsst Ihr nur den spatialOS Launcher installieren und den jeweiligen Stand der Entwicklung aus der Cloud heraus die Unity Instantiierung starten. Ich hoffe so in den nächsten Monaten, dass Prozedurale Terrain Modul aus meinen aktuellen Sprints vorstellen zu können. Ganz alleine bin ich dann seit kurzem nicht mehr, so wie im Bild zu erkennen. Das freut mich natürlich sehr.



Meine MMO Visionen, mit einem kleineren Team erfolgreich zu implementieren, könnten so durchaus künftig in Erfüllung gehen. Ich konnte damit zurück zu meiner eigentlichen Aufgabe kommen, ein Spiel zu entwickeln. Innovation braucht eben viel Zeit und Geduld.

Den Eröffnungspost dieser Projektvorstellung und Threads habe ich aktualisert. Die Antworten auf die wichtigsten Fragen, solltet Ihr dort auf Seite [1] finden.

Gerne kannst du meinen Blog zum Thema verfolgen. Auch könnten meine Beweggründe für den Wechsel zu Unity 3D, Entitas, SpatialOS, nSpec, etc. interessieren. Wer näheres zu meiner Person lesen möchte, findet mein LinkedIn Profil in der Signatur.

Beste Grüße aus Hamburg
Jan

Hallo @BlueCobold,

danke und ja natürlich. Leidenschaft und Spaß am Projekt gibt mir viel Motivation und hält dieses fanale Feuer seit Jahren. Der maßgebliche und indirekt bidirektionale Einfluss des Spielers auf die Topologie, durch die prozedurale Terrain Generierung, ist Teil des grundsätzlichen und strategischen Sandbox Gameplays. Von daher würden große Teile des Spielkonzeptes, mit statischem Level/Terrain Design einfach ausgehebelt werden. Der Spieler interagiert zu jederzeit auch mit dem Gelände, welches ihm umgibt. Im Kapitel KK/080, ab Seite 333 im AOW Manuskript versuche ich diese Aspekte zu erläutern.

Viele Grüße
Jan

#DEV Update 29.05.2019




Nach guten und rund einstündigen Video Gesprächen mit improbable.io zum Thema Rahmenbedingungen von spatialOS als Cloud Plattform für unser MMO Antares Open World (AOW), haben wir eine gute Basis für die künftige Zusammenarbeit gefunden. Die Weichen stehen jetzt auf grün. Hierbei ging es u.a., um die Skalierbarkeit, der Kalkulation von Risiken, einer individuellen Wahl von Templates, mögliche Verpflichtungen, Leistungsanforderungen, wie physikalische Sichtweiten, Anzahl von Entitäten, Instanzen und vieles mehr.

Nun ist es an der Zeit, die ersten Sprints der vergangenen Wochen zum prozeduralem Terrain Generation Modul zu präsentieren. Ich habe mich entschlossen hierfür Euch ein erstes Video zu zeigen. Die Umsetzung erfolgte komplett in einer Headless Entity Component Architecture (hECS) mit Entitas. Hierbei folgte ich einer vollständig entkoppelten Headless Server Architektur, welche du hier einsehen kannst, danke FNGames. So wird es mir/uns u.a. möglich sein, je nach Anforderungen und Kapazitäten, einer Vielzahl von agilen Änderungen im AOW DEV Kosmos kurzfristig Stand zu halten, aber auch grafische Endpoint Entscheidungen schneller treffen zu können. Die Modularität, Flexibilität und eine saubere Struktur/Architektur, steht bei einem Projekt dieser Größe im Fokus. Die Wahl der Unity 3D Engine stellte sich jedoch bis zum heutigem Zeitpunkt als Segen heraus. Im Moment arbeite ich mit 3 ECS Systemen zusammen. Der Unity ECS Workflow für die Grafik, Entitas ECS für unsere Business (Game) Logik und spatialOS (ECS) für unser MMO, das Persistente Universe (PU) Backend. Wie das genau funktioniert findest du in unserem Confluence Wiki.

Ich habe bis heute, eine komplette und automatisierte DEV OP Pipeline von der Jira Story bis hin zum Backend Deployment für ein mittleres Entwickler Team aufstellen können. Im nachfolgendem Bild siehst du meine/unsere Arbeitsweisen. Es zeigt den Jira Workflow, welchen ich auch hauptberuflich in leicht abgewandelter Form verwende. Umgesetzt, aber nicht veröffentlicht ist auch eine Confluence Status Seite mit allen Storys (Dashboard), um so den Fortschritt für die Community transparenter zu halten. Was steht im nächstem Sprint an? Wie viele Storys müssen noch bis zur nächsten Veröffentlichung in die Cloud abgearbeitet werden? Das macht natürlich erst ab einer bestimmten Teamstärke Sinn. Auch wird dann ein Service Desk (Jira) in den Startlöchern stehen, damit ich/wir uns um Deine Rückmeldungen kümmern kann/können.



Zudem habe ich mein erstes AWGS/PTG Modul, respektive Antares World Genration System, Procedural Terrain System heute unter Berücksichtigung der 80/20 Pareto Regelung vorerst abschließen können. Es ist noch viel Feinschliff notwendig. Bisher kann ich Multiple Perlin Noise Algorithmen mit Brownian Motion, Midpoint Displacement Tessellation und einen Smoothing Blur Algorithmus zur Laufzeit (Runtime) durch den Spieler zur Anwendung bringen. Sobald der Spieler, wie im Video zu sehen ist, in die Cloud tritt, entsteht eine auf pseudo Zufall basierende Welt, welche anhand von Parametersätzen, zu jederzeit deterministisch dank ECS rekonstruierbar ist und an anderer Stelle auf dem Geoid persistent gespeichert werden kann. (Siehe AOW Manuskript). Dies passiert zum Beispiel dann, wenn der Spieler das Terrain als wertvoll einstuft und mit diesem in einem bestimmten Bereich z.B. durch Terra Forming, Bergbau, etc., interagiert.

Einen aktiven Cloud Zugang für die Teilhabe an der Entwicklung, plane ich in den nächsten Monaten. Das Deployment im Video läuft heute erstmal bis 20:54 Uhr UTC aus Kostengründen. Auf Wunsch kann ich aber das Deployment jederzeit wieder starten. Anbei auch ein paar Telemetriedaten vom laufendem Deployment in den Screenshots.







So wie in meinem Video zu sehen, kann jeder der die Cloud URL besitzt, sich den spatialOS Launcher installieren, und mein erstes Deployment testen. Ich denke die Version 0.0.1 wurde geboren. Später plane ich natürlich einen AOW Launcher, der sich gegen einen Authentifizierungsserver melden kann, um die spatialOS Umgebung elegant zu verstecken. Viel möglich ist natürlich im Bereich Gameplay noch nicht, aber man kann gut erkennen, wie sich die Welt bei einem Neustart prozedural verändert und welche Richtung das Ganze nun annimmt. Mit WASD kann man etwas herum laufen. Springen geht auch schon, obwohl noch keine Animation hierfür hinterlegt wurde. Mit dem Mausrad kann man stufenlos heraus/herein zoomen. Die Ego Perspektive ist geplant mit der Taste V. Mit der Tabulator Taste kann man die Maus Ansicht entkoppeln und im Fenstermodus das "Spiel" wieder schließen. Im Vollbild, einfach ALT+TAB und aus der Startleiste entfernen.

Im nächstem Schritt ist ein prozedurales nachladen der Terrain Kacheln für ein unendliches Terrain geplant, welches der Spieler dann entdecken kann. Im Backlog befindet sich auch schon eine Story, um Gelände zu ebenen. Bis dahin wird aber noch einiges an Zeit vergehen. Input, Kamera und Player Controller müssen für das spatialOS Backend programmiert werden. Schließlich, sollen sich die ersten Spieler auch miteinander bald sehen können.

Wer sich für einen Start mit AOW interessiert, findet auf dieser Confluence Seite einen guten technologischen Einblick.

In diesem Sinne freue ich mich ganz persönlich über diesen Meilenstein, die auf Grundlagen der Nachhaltigkeit in den letzten 5 Jahren entstanden sind.

Hier geht´s direkt zum Video: http://archiv.antares.community/p/aow-aw…patialos-02.mp4

Gerne auch auf YouTube:




»Der Weg ist das/mein Ziel. Konfuzius.«

Viele Grüße
Azzuriel // Jan

Posts, wie der nachfolgende zeigt einmal mehr deutlich, welches Wissen und Aufklärungspotential zu Arrangements, Durchhaltevermögen, Umfang und vor allem aber Arbeit von tausenden Stunden, über die Komplexität eines fanalen MMO´s exponenziell zu einem Muliplayer/Singleplayer Projekt vorherrscht und/oder von Nöten wäre. Dies obwohl das Forum hierbei voll von Abratungen ist oder es sehr gute Erläuterungen zur dessen Arbeitsintensität/Lernkurven gibt. Ich nenne dies ab heute das MMO Paradoxon, über viel zu viel Arbeit und Aufwände zu lamentieren, aber diese zudem gleichzeitig, wenn sie vollbracht wurden nicht zu sehen und/oder in dessen Rahmen nicht anerkennen zu können.

#DEV Update 03.06.2019

Mein Prozedurales Terrain Generation System macht Fortschritte. So kann ich nun die verschiedenen mathematischen Verfahren, jeweils als eigenes System in der ECS Architektur implementiert, diese nun beliebig über ein Regelwerk mischen. Die so implementierten Systeme, wie ein auf n-Ebenen basierter Perlin Noise Algorithmus, die Voronoi Tessellation oder der Midpoint Displacement Algorithmus, erzeugen so hoffe ich bald dank der späteren Erweiterung der Implementierung mittels neuronaler Netze, eine realistisch wirkende Topologie für den Spieler. Zum Aufzeigen der als nächstes anstehenden Game Mechaniken, reicht aber auch schon das implementierte Terrain System.



Vor kurzem habe ich angefangen am Terrain Tile Manager AWGS-29 zu arbeiten, da die so generierte Welt später natürlich weitläufig begehbar und interaktiv werden soll. Insbesondere sollen hier dem Spieler TSP Herausforderungen, siehe das Reisen & Rasten System KK/048 im AOW Manuskript ab Seite 163, näher gebracht werden.

So konnte ich in meinem Urlaub die ersten beiden Subsysteme, das Terrain Buffer System und das Terrain Create/Drop Cycle System implementieren. Im Anhang habe ich die zugehörige Jira Story beigefügt.

So werden initial Terrains nun prozedural nach einem Regelwerk in Moor Nachbarschaft, um den Spieler in Abhängigkeit einer Kachelweite erzeugt. Entsprechende Terrain Teilstücke werden in einem zu spezifizierenden Terrain Buffer gehalten und nach der Laufrichtung des Spielers automatisch erzeugt und geladen.

Natürlich gibt es im Unity Asset Store käuflich zu erwerbende Produkte, die in diese Richtung gehen. Ich habe auch hier viel Evaluierung betrieben. Häufiges Problem ist der Editor Namensraum, der in einer Headless ECS Server Implementierung, wie wir/ich sie anstreben, dieses sehr schwierig machen. Insbesondere, da mein Hauptaugenmerk auf eine Veränderung zur Laufzeit (Runtime) abzielt und die Performance eine gewichtige Rolle in der spatialOS Umgebung spielen wird.

Wie im Anhang zu sehen, sind noch einige weitere Subsysteme zu implementieren. Ich werde versuchen 2-4 Stunden pro Tag nach Feierabend freizuhalten und diese zu investieren. Mein Ziel, jeden Tag einen kleinen Schritt in die richtige Richtung zu unternehmen.

Gerne möchte ich Euch auch mitteilen, das ich Friedrich (Schüler), Peter (beruflich/Lead Developer) und Sven (Asset Designer) für das Projekt begeistern konnte. So wird sich Friedrich und Peter mit dem Input/Camera Systemen AWGS-34/48 beschäftigen und Sven wird unsere ersten Surface Assets/Ressourcen ADPR-3 und Bausteine/Fertigteile ASSR-5 für ein Holzhaus dessen Beruf des Holzfällers übernehmen. Der anhangende Screenshot zeigt einen Ausschnitt aus einer seiner Jira Storys.

Welche künftigen Synergie Effekte hieraus entstehen werden, wird die Zeit zeigen. In jedem Fall sind wir weit von einem Stillstand entfernt, es fördert die Motivation und hilft bei der weiteren Bildung von Substanz in diesem ehrgeizigem Projekt.

In diesem Sinne wünsche ich uns allen eine schöne Woche.
Azzuriel // Jan

#DEV Update 12.06.2019

Mein Terrain Tile Manager AWGS-29 nimmt endlich Formen an. Für alle die sich hierunter noch nicht so viel vorstellen können, habe ich ein YouTube Video erstellt. Das Video zeigt diesmal bewusst die Unity Engine, um Dir das Zusammenspiel aus Sicht des Spielers und der Szene zeitgleich aufzeigen zu können. So ist die direkte Moore Nachbarschaft in Laufrichtung des Charakters, durch Aktivierung der jeweiligen Kacheln dargestellt, zu erkennen.



Ein Parameter kann die Tiefe der Nachbarschaft steuern. So zum Beispiel, nicht nur eine Kachel, sondern auch 2 oder 3 entsprechend vorauszuberechnen/darzustellen. Die Umsetzung erfolgt durch 2 getrennte EC Systeme. Ein Buffer System und ein Erstell, Löschen, Vorhalte Kachel System. Alle Systeme arbeiten hierbei dedizierend und sind autark, sie manipulieren die Komponenten (Daten) der jeweiligen in Gruppen (Contexte) organisierten Entitäten. So kann ich ein System deaktivieren, welches dann im Resultat eben keine Tiles generiert, oder die Perlin Aufmodellierung im Terrain einfach weglässt. Im Video ist nur das Midpoint Tessellation System, das Procedural Ground & Texture Placement System und das Endless Terrain Tile Manager (Feature) System, aktiv im Einsatz. Das Input und Orbit Kamera System stammt von Peter und Friedrich. Weitere Features in dessen Systeme folgen, Danke Euch Zwei. Um das Zusammenspiel noch besser darstellen zu können, habe ich die Laufgeschwindigkeit stark erhöht. Es sieht recht lustig aus, aber es erfüllt den Zweck. Die Jira Story AWGS-29 sehe ich so erstmal als genügend abgeschlossen. Ich greife diese später in einem erneutem Sprint und weiteren Features bestimmt noch einmal auf.

Auch habe ich mich jetzt schon mit UI und der Auslagerung asynchroner Prozesse beschäftigen müssen, da die initiale Terrain Generierung nun doch ein paar Sekunden in Anspruch nahm. So schrieb ich ein ECS Asynchronous Scene Loader (ASL) System, um die Benutzererfahrung in dessen Terrain Generierung zu verbessern. Meine ersten UI Erfahrungen habe ich als Anhang diesem Beitrag ebenfalls beigefügt. Die Buttons werden später noch dem Corporate (Game) Design, so ähnlich wie das im Main Menu zu sehende AOW Logo rund dargestellt, angepasst.

Anzumerken in diesem Zusammenhang sei jedoch, das mir eine Chromium Embedded Framework (CEF) Lösung vorschwebt, so wie es zum Beispiel auch die Firma Coherent Labs mit ihrem Unreal Plugin umsetzt. So kann ich wiederum entkoppelt und mittels HTML5, CSS3 und JavaScript eine komplexe UI Pipeline implementieren, die sonst nur in Adobe After Effects, etc. ihr volles potential aufzeigen würde. Dies hilft mir insbesondere auch bei möglichen UI Auftragsarbeiten, die dann eine hohe Schnittmenge mit der Web Design Branche bilden.


Meine weiteren Schritte:

Ich muss jetzt einmal Schauen, ob ich anfange und das Terrain für das Graben/Stollen Vortrieb System über den Transvoxel Algorithmus zu erweitern, oder ob ich erste Gameplay Inhalte, wie das Planieren/Flatten von Terrain implementiere. In jedem Fall, soll das Terrain dynamisch, an den für Spieler wichtigen POI´s, zur Laufzeit Heightmap/Voxel Hybrid befähigt sein. Ich schrieb in meinem AOW Manuskript einiges zu diesem Thema. Auch wenn der Transvoxel Algorithmus im Prinzip klar ist, wird es mich einiges an Herausforderungen und Zeit Kosten, hier dies in einer Headless ECS Server Architektur, insbesondere in Zusammenhang mit der spatialOS Umgebung und dessen Persistierung zu implementieren, kosten.

P.S. @BlueCobold Dann bin ich ja froh, k.a. warum das Wort erst in Rot moniert wurde, vielleicht war´s ja denglisch.

Habt eine schöne Woche
Jan // Azzuriel

#DEV Update 19.06.2019

Ein weiterer 7 Tage Sprint wurde gestern abgeschlossen. So konnten ich/wir einige weitere und wichtige Punkte abschließen.

• Major PTG Terrain Modul Update
  
• Bugfixes
  
• Namespace Changes
  
• Update ECS Warn, Error Messages System
  
• Cleanup Mono Behaviours
  
• Change Procedural Hierarchy/Parent Game Objects
  
• Initialized/Mixed Terrain Mechanism
  
• Implementierung Player Spawn System
  
• Update Terrain Buffer System
  
• Player Character Update Vyuras Version 2.4.1 (Unity Optimierung)
  
• Platzhalter Animationen für rudimentäre Bewegungsabläufe
  
• Updates Terrain Extentions (Enitäten Erzeugung)
  

Character Design:

Insbesondere der komplette Neuaufbau des ersten Charakters "Vyuras/Antarianer" und die Überarbeitung der gesamten dazugehörigen Asset Pipeline hat mich viel Zeit gekostet. Gerne möchte ich Euch auch hier meine neuste Version und Änderungen am Modell natürlich nicht vorenthalten.





Das Besondere sind vor allem die prozeduralen Vorbereitungen des Charakters für den späteren AOW Charakter Editor. Hier das Modell in viele kleine Prefabs zu zerlegen und auf die Konformität, sowie den Best Practices der Unity Engine zu achten. Auch die Möglichkeit über Parameter die morphologischen Aspekte im Quellcode, durch das Entstehen dessen Anspruchs aus Alterungs- und/oder Metabolischen Prozessen gemäß AOW Manussript, implementieren zu können.





Projekt Management:

Ebenfalls haben wir uns darauf geeinigt, unsere Scrum Sprints nun auf einen 14 Tage Rhythmus zu erweiteren, um harmonischer und mit mehr Spaß an der Freude im Team zusammen arbeiten zu können. Im nachfolgenden findest du auch einen kleinen Überblick (Ausschnitt) meines/unseres AOW ADG Dashboards, einen Teil der laufenden AOW Produkte -in Jira sind das die Projekte-, sowie das aus dem ersten Produkt des Antares World Generation Moduls (AWGS), das/mein entsprechende/s Backlog.








Zudem habe ich mich nun doch dazu entschlossen, so wie im Backlog zu sehen mit der prozeduralen Landschaftsgestaltung, respektive dem Baum Platzierungsmodul weiter zu machen. Dies hängt vor allem damit zusammen, das ich versuche möglichst viel Schnittmenge mit meinen Mitstreitern im Projekt zu finden. So kann unser Technical Asset Designer, dann deutlich näher mit mir zusammen arbeiten und entsprechende Entwürfe zeitnah und direkt im Zusammenspiel mit den von mir geschaffenen Systemen testen.

In diesem Sinne, auf geht´s
Jan // Azzuriel