Abenteuer abgeschlossen: Von der „Pre-Alpha“ zur „Alpha“

October 3, 2018

Von Caspian

 

Hallo Elyrianer!

 

Wenn die Blätter von ihrem sommerlichen Grün in die herbstlichen Rot- und Gelbtöne wechseln, gehen auch die unerschrockenen Abenteurer hier bei Soulbound Studios zum nächsten Abenteuer über. Das bedeutet, dass es Zeit für unseren abschließenden Abenteuer Blog-Post ist. Bevor wir anfangen, macht euch noch einmal über unsere Ziele zu Beginn von Abenteuer 0.4.0 vertraut. Das könnt ihr im Einführungsbeitrag nachlesen oder bei der entsprechenden Aktualisierung. Sobald ihr das getan habt oder ihr zu neugierig seid, holt euch einen warmen Cidre oder heißen Tee und lest weiter!

 

Die Erstellung neuer Systeme

 

Es gibt zwar keinen Mangel an Screenshots oder Konzeptzeichnungen, wie ihr unten sehen könnt, aber als ich anfing diesen Post zu schreiben, bemerkte ich, dass viele Bilder, Illustrationen der Systeme und vom Gameplay in Version 0.4.0 fehlten. Wir haben zwar viele Bilder der Landschaft gezeigt, von Gegenständen, die man für das Handwerk oder die Landwirtschaft braucht und anderen Systemen, aber es gibt weder Bilder noch Videos von neuem Gameplay in diesem Release.

 

Um die Wahrheit zu sagen, liegt die Abwesenheit hiervon nicht an mangelndem Fortschritt, sondern daran, dass wir unsere Herangehensweise bei der Entwicklung des Spiels beibehalten haben. Ich habe allerdings das Gefühl, dass wir euch trotzdem über den Fortschritt in 0.4.0 aufklären sollten. Der beste Weg, um zu erklären, wo wir uns gerade befinden, ist eine Analogie.

 

Ein Spiel wie „Chronicles of Elyria“ zu erschaffen, ist vergleichbar mit dem Designen und Bauen eines neuen Autos. Als wir im Jahr 2015 anfingen über „Chronicles of Elyria“ zu sprechen, war es wie das Teilen eines Datenblattes für CoE. Wir sprachen über die wichtigsten Systeme, wie leistungsfähig der Motor sein würde und welche Laufleistung die Leute von diesem Spiel erwarten konnten, etc.

 

Genau wie bei einem Auto, wollten die Leute schnell sehen, wie das Spiel aussehen soll. Wir verbrachten dementsprechend viel Zeit damit, den Körper des Spiels zu erstellen. In der MMO-Terminologie ist das dann der Client. Es ist der Teil, den die Leute sehen können und den sie benutzen, um das Spiel mit einem anderen zu vergleichen. Damals haben wir an vielen Prototypen des Clients gearbeitet. Das beinhaltete dann die Prototypen und Demos unserer Alterungs- und Dynamiksysteme, das Interaktionssystem mit der Welt, das Wetter, der Kampf, das Handwerk, Parkour und ein paar weitere. Alle wurden erstellt um Ideen zu testen und wie Spieler darauf reagieren würden, wenn wir ihnen das „Äußere“ unseres Spiels vorstellen. Das waren also alles nur maßstabsgetreue Modelle – um bei der Auto-Metapher zu bleiben. Sie sollten also zeigen, wie das Spiel aussehen würde, aber sie wurden auf temporären Fahrgestellen gebaut, die man ersetzen muss, sobald wir echte Fortschritte gemacht haben.

 

Natürlich wussten wir, dass wir das Spiel auf der Straße testen müssen, also begannen wir mit der Entwicklung unseres Antriebs. Im MMO-Sprachgebrauch wäre das unsere Back-End-Serverarchitektur. In der Tat wurde der Großteil des Jahres 2017 damit verbracht, unseren Antrieb zu entwickeln. Diese Arbeit ging noch Anfang 2018 weiter, als wir mit den Hauptkomponenten des Antriebs anfangen konnten. Aber auch dann hatten wir kein funktionierendes Spiel. Es ist halt noch mehr in einem Auto als ein Antrieb, das Lenkrad und die Karosserie.

 

Und genau darum ging es bei Release 0.4.0. Es ging darum, all die anderen Teile herzustellen, aus denen ein Auto besteht. In der Version 0.4.0 ging es darum, die Basis zu schaffen, damit die verschiedenen Systeme ineinandergreifen und daraus ein funktionierendes Spiel entsteht. Aufgrund unserer einzigartigen Herangehensweise bei der Entwicklung, wurden all diese Systeme isoliert vom Hauptspiel als Teil eines kleineren Herstellungsprozesses gebaut. Das klingt zunächst albern. Aber bedenkt, dass Automobilhersteller ihre Teile nicht in die Autos einbauen. Sie fertigen und prüfen ihre Teile getrennt von den Fahrzeugen und montieren sie erst anschließend. Das Gleiche trifft auf uns zu. Das ist übrigens der Grund, warum wir trotz der ganzen Designs und Entwicklungen, die wir in 0.4.0 fertigstellen konnten, euch wenig zeigen können. Wir haben weiterhin viele Einzelteile, die noch zu einem großen Ganzen zusammengesetzt werden müssen.

 

Ich möchte zwar nicht den Post über die Version 0.5.0 vorwegnehmen (der später in der Woche folgt), aber genau darum geht es dann bei 0.5.0. Die Teile müssen zusammengebaut werden und wir müssen schauen, wie es dann alles aussieht. Kurz gesagt, die Fertigstellung von 0.5.0 bringt uns dahin, wo wir endlich sein wollen; in der Lage, das Spiel als ein funktionierendes Produkt zu zeigen und nicht nur als eine Reihe unabhängiger, voneinander getrennter Teile.

 

Trotz allem hat uns 0.4.0 ermöglicht, mehrere neue Systeme zu implementieren und bestehende zu testen. Lasst uns also einen genaueren Blick darauf werfen, welche Systeme wir in 0.4.0 angefasst haben.

 

Die Herstellung neuer Teile

 

Während wir ursprünglich geplant hatten, die Pre-Alpha als eine Version mit lediglich der Möglichkeit herumzulaufen und zu reden (und dann schrittweise neue Funktionen einzufügen), entschieden wir uns nach Abschluss von 0.3.0, dass die Welt zu spärlich und die Mechanik zu dünn war, um irgendeinen echten Wert der Test zu liefern. Welche Art von Feedback sollten die Tester uns schon geben, wenn es nichts zu testen gab? In 0.4.0 wollten wir so viele Systeme der Alpha 1 einbauen wie möglich. Diese sind dann nicht endgültig, da sie auch nicht immer einen großen Wert für die Pre-Alpha hätten, wenn wir nicht in der Lage sein würden daran zu arbeiten.

 

Neu hinzugefügt

 

Viele neue Systeme wurden in 0.4.0 bearbeitet, aber hier eine Übersicht über die wichtigsten Systeme.

 

Künstliche Intelligenz

 

Während wir das Design unseres NPC und der Kreaturen-KI mehr oder weniger abgeschlossen hatten, hatten wir nur einzelne Rollen eingebaut. In Version 0.4.0 haben wir mit der Implementierung eines allgemeineren, zielbasierten und bedarfsorientierten KI-Systems begonnen, das komplett mit einem Node-Graph System ausgestattet ist. Damit können wir das Verhalten der NPC anpassen und den ganzen Code zu bearbeiten. Wenn wir alles richtig machen, wird dieses Node-Graph System das gleiche sein, dass die Spieler benutzen werden um ihre eigenen OPC Skripte zu erstellen. Auch wenn wir hier noch viel dran arbeiten müssen, bevor die Spieler es in die Hände kriegen können, könnt ihr in der folgenden Übersicht ein Interaktionsszenario von einem NPC sehen.

 

 

Handwerksstationen

 

Während wir bereits vor 0.4.0 eine Schmiededemo und ein funktionierendes System hatten, wurde in dieser Version ein neues Framework für die schnelle Entwicklung neuer Handwerksstationen implementiert. Das Endergebnis ist eine engere Integration mit unserem Welt-Interaktionssystem und ein tieferes Verständnis davon, wie die Stationen funktionieren werden. Sowohl vom Design- als auch vom Entwicklungs-Standpunkt. Die Integration mit dem Welt-Interaktionssystem und dem Survival-System ermöglichte uns auch, einige nicht-Handwerksstationen zu erschaffen, wie zum Beispiel Brunnen und Wasserfontänen, Feuerstellen, Zelte und Schlafsäcke.

 

Familiengeschichte

 

Obwohl wir bereits in den ersten Releases von CoE an der Charaktererstellung gearbeitet hatten, hatten wir das Familiensystem übersprungen und uns darauf konzentriert, Wards (Waisen) zu erstellen. In Release 0.4.0 begannen wir mit der Arbeit an der Charaktererstellung unter Verwendung des Familienerzählungssystems. Dies stellt eine Reihe von Hintergrundanfragen und historischen Erzählungen dar, die der Spieler während der Charaktererstellung beantworten muss, um sowohl die Welt nach passenden Familien zu filtern als auch ihre Startwerte für Fähigkeiten und Attribute festzulegen. Es gibt noch viel Arbeit an diesen System, aber es bietet schon eine Grundlage für die Charaktererstellung mit Familien.

 

Das persönliche Schicksalssystem

 

Wir arbeiteten außerdem in 0.4.0 an dem persönlichen Schicksalssystem. Es wurde bereits gründlich entworfen, aber in der neusten Version haben wir unsere erste Version dieser Mechanik implementiert. Sie erlaubt es uns, das Jahr, den Monat und den Tag der Geburt eines Charakters zu wählen und die Reihe von Konflikten und einzigartigen Handlungsbögen hieraus zu generieren, die während der Lebenszeit in Elyria auf einen zukommen. Das persönliche Schicksalssystem knüpft stark an unsere dynamische Story-Enginge an und wird auch in 0.5.0 weiterbearbeitet, wenn wir an der dynamischen Geschichtserzählung arbeiten.

 

Seelen

 

Ähnlich wie beim persönlichen Schicksalssystem hatten wir bereits ein Design für die Seelen, aber es wurde bisher noch nicht mit irgendetwas anderem verbunden. Das heißt, während man zwar eine Seele bei der Charaktererstellung auswählen konnte, brachte sie nicht ihre individuellen Fähigkeiten mit etc. Das tut sie nun ebenfalls.

 

Identitäten

 

Nach der Charaktererstellung widmeten wir uns den Identitäten. Diese hängen stark mit etlichen Systemen zusammen, so dass sie implementiert werden mussten, bevor viele andere Systeme gestartet werden konnten, da sie einer der Eckpfeiler des Spiels sind. Mit Abschluss von 0.4.0 greifen nun viele andere Systeme auf den Charakter zurück bzw. seine Identität und nicht eine feste Charakter-ID. Dadurch ist es möglich, zwischen deiner Hauptidentität oder einer alternativen Identität zu wechseln, was die Art und Weise, wie du mit NPCs und Verträgen interagierst, verändert.

 

Verträge

 

Apropos Verträge, eines der ersten Systeme, das Charakteridentitäten verwendet, ist das Vertragssystem. In Release 0.4.0 bauten wir das erste System der Verträge ein, die initiiert, verfolgt und erfüllt werden können. Wir haben auch einige der Startbedingungen und Bedingungen für den Abschluss eines Vertrages umgesetzt. Abgesehen von der Implementierung führte die Iterationsarbeit, die wir auf dem Skill-System durchführten, in Kombination mit der Arbeit an Wissen und Gerüchten zu einigen ziemlich erstaunlichen Änderungen am Vertragssystem. Ich würde gerne mehr erzählen, aber die jüngsten Änderungen im Vertragssystem rechtfertigen wirklich ein eigenes Design-Journal darüber.

 

Umgebung

 

Zu guter Letzt hatten wir zwar bereits Wettereffekte auf der Clientseite, aber wir hatten kein serverseitiges Wettersystem. In Release 0.4.0 haben wir eine Basisversion von dynamischer Temperaturänderung, Feuchtigkeit und Wetterbedingungen implementiert. Dies ermöglicht den Gebieten, ihr Wetter dynamisch zu ändern, angetrieben von einem übergeordneten Wettersystem. Dies knüpft natürlich an das Survival-System an, das in Release 0.4.0 bereits etwas begonnen hat.

 

Überarbeitete Systeme

 

Neben den neuen Systemen haben wir auch einige alte Bekannte überarbeitet. Spätestens in 0.5.0 werden diese dann auch teilweise neue Funktionen erhalten.

 

Überlebensmechanik (Survival)

 

Eigentlich hatten wir bereits die grundlegenden Überlebensmechaniken an Ort und Stelle. Die Charaktere hatten Erschöpfung und Energie, Hunger und Durst. Hungriger und durstig zu werden oder müde, würde nur dazu führen, dass sie quasi auf 0 fallen. Das war es schon. In Version 0.4.0 haben wir die Möglichkeit der Bewusstlosigkeit und die erste Version des Spirit Walking hinzugefügt. Wir haben auch einige neue Überlebensmechanismen wie Wunden und Statuseffekte oder die Homöostase (Gleichgewicht der physiologischen Körperfunktionen; Stabilität des Verhältnisses von Blutdruck, Körpertemperatur, pH-Wert des Blutes u. a.). Wie bereits erwähnt, ist es nun möglich, die Körpertemperatur durch dynamische Temperatur und Feuerstellen zu regulieren.

 

Fähigkeiten (Skills)

 

Die Skills bekamen die größte Überarbeitung in CoE. Als wir CoE seinerzeit vorstellten, hatten wir das Ziel, dass alle Aktionen die ein Spieler durchführt, auf der Basis von Charakter- und Spielerfähigkeiten basierten. Wie ihr euch vorstellen könnt, erforderte das die Entwicklung einiger künstlicher Beschränkungen und UIs um sicherzustellen, dass es sowohl Fähigkeiten von Spielern als auch Charakteren gab. Wenn man näher darüber nachdenkt, wird einem bewusst, dass es viele verschiedene Aktionen gibt, die eher Charakterfertigkeiten oder Spielerfertigkeiten erfordern – manche erfordern weder noch. In diesen Fällen, wenn keine Fähigkeiten des Charakters oder Spielers erforderlich sind, ist immer noch ein gewisses Maß an Charakter- oder Spielerwissen erforderlich. Die jüngsten Änderungen sind eines neuen Designjournals würdig. Letztlich hat 0.4.0 das bisher bekannte Skill-System ziemlich stark überarbeitet und verbessert. Demnächst folgt eine genauere Erklärung über die Skills, das Wissen und diesbezügliche Mechaniken.

 

Kampf

 

Ein anderes System das stark überarbeitet wurde, war das Kampfsystem. Diejenigen, die uns schon seit 2016 verfolgen wissen, dass wir schon damals ein erstes Kampfsystem hatten. Dieses Kampfsystem verwendete eine Kombination von Techniken – Ausweichen, Parieren und Abwehren – um ein Kampfsystem zu erschaffen, das leicht zu erlernen war, aber schwer zu meistern. Der Erfolg basiert auf dem Timing und deiner Fähigkeit, die Aktionen deiner Gegner vorauszuahnen und effektiv zu kontern. Ähnlich wie in traditionellen Kampfspielen. Um das System zu zeigen, nahmen wir eine erste Version zu unserer ersten PAX East Show auf. Im Jahr 2017, als wir von technischen Demos und Proofs zu einem Online-Spiel übergingen, sahen wir davon ab dieses System in die Parkour-Demo einzubauen. Damit sollte das Gefühl des Abenteuers stärker hervorgehoben werden. Wir haben daher ein simpleres Kampfsystem eingebaut um sicherzustellen, dass dieses Erlebnis nicht komplett fehlte.

 

Jetzt arbeiten wir daran, eine Variante des ursprünglichen Kampfsystems wieder in das Spiel zu integrieren. Ich sage Variante, denn obwohl wir das allgemeine Gefühl und den Ablauf des Kampfes mochten, fehlte es an Abwechslung. Da nur die rechte und linke Maustaste genutzt werden musste, gab es jeweils nur zwei Möglichkeiten. Dies fühlte sich eingeschränkt an und so begannen wir in 0.4.0 mit der Implementierung eines neuen Kampfsystems. Dieses nutzt dynamische Haltungen, die dann mehr Abwechslung ermöglichen sollen. In 0.5.0 wird diese Arbeit fortgesetzt.

 

Wissen

 

Die Version 0.4.0 hat die erste Version des Wissens- und Gerüchtesystems eingebaut bekommen. Hier geht es nicht um etwas sehr detailliertes. Es geht lediglich um welche Art von Information erlernt werden kann, wie sie gelernt werden kann und wie man sie an andere Personen weitergeben kann. Wir haben sogar ein Papiermodell entwickelt, damit wir anderen Mitgliedern des Studios das Konzept vorstellen konnten. In dieser Version werden nun die Ereignisse erfasst und aufgezeichnet, die dein Charakter erlebt und im Wissenspeicher abgelegt. In 0.5.0 wir die Arbeit hieran stark im Fokus sein.

 

Auf die Plätze, Fertig, Wählen

 

Zusätzlich zur Arbeit am Spiel selbst, verbrachten Orlando und ich in 0.4.0 Zeit mit dem Map-Voting. Das Map-Voting ist etwas, auf das wir alle gespannt warten. Sobald es beginnt, können die Spieler an einem historischen Ereignis teilnehmen, indem sie die Weltkarten für die verschiedenen Server auswählen. Das ist etwas, dass (soweit ich weiß) kein MMO-Spieler jemals zuvor tun konnte. Sobald das Map-Voting beendet ist, werden die Spieler endlich in der Lage sein, das jeweilige Land und die Biome ihres Servers zu sehen. Darüber hinaus sind wir mit der Kartenabstimmung nur einen Katzensprung von der Domain & Settlement Selection entfernt, die zu den am meisten erwarteten Pre-Launch-Events zählt.

 

Mit der Domain & Settlement Selection können all jene Königreiche, Herzogtümer, Grafschaften und Siedlungen, die auf den beginnenden Kontinenten existieren, endlich von ihrem Herrscher beansprucht werden! Spieler können endlich mit Sicherheit kommunizieren, welche Biome, Stämme  und Umgebungen sie anderen Spielern bieten können. Außerdem können sie den Start angemessen planen und mit der Rekrutierung beginnen.

 

Auf der Seite mit den Maps, könnt ihr dann auch direkt abstimmen. Während die Arbeit an der Weltgeneration weitergeht, haben wir in 0.4.0 das Map-Voting-Portal fast fertiggestellt. Im Folgenden findet ihr einige Screenshots des Map-Voting-Portals, wie es heute schon aussieht.

 

 

 

 

 

Ich weiß, was ihr euch jetzt fragt: „Wann ist denn nun Map Voting?“ Wir haben zwar schon ein Datum im Kopf, aber ich werde es erst im Post zum Release 0.5.0 veröffentlichen, da es dort stattfinden wird.

 

Die Evolution der Pre-Alpha

 

Bisher habe ich hauptsächlich darüber gesprochen, was die Ingenieur- und Designgilden getan haben, aber die Kunstgilde war nicht untätig. Bevor ich jedoch darüber rede, was das Content-Team getan hat, ist es wahrscheinlich eine gute Idee, ein bisschen mehr Informationen über unseren Entwicklungsansatz zu geben.

 

Unsere Herangehensweise an die Entwicklung ist etwas, das ich in der Vergangenheit als unsere Seilbrücken-Philosophie bezeichnet habe. Es geht also darum, dünne vertikale Schichten unserer Systeme und Lösungen - isoliert - zu bauen und sie dann schnell und häufig zu durchlaufen. Unsere Implementierungen konzentrieren sich stark auf die Entwicklung von den SOLID-Designprinzipien, zusätzlich zu einigen unserer eigenen Prinzipien. Insbesondere versuchen wir, CoE so zu entwickeln, dass "Trennung von Bedenken", "Wiederholen, wo es am günstigsten ist", "Code nach Notwendigkeit" und "Letztes Optimieren" möglich sind. Von diesen Prinzipien sind die ersten beiden besonders relevant für das, woran die Kunstgilde gearbeitet hat.

 

Trennung von Bedenken

 

Die Trennung von Bedenken von einem SOLID-Designstandpunkt aus betrachtet bedeutet, sicherzustellen, dass der Code und die Systeme, die wir entwickeln, nur auf eine einzige Verantwortung ausgerichtet sind. Es gibt viele Vorteile für diesen Ansatz, die im Internet gefunden werden können, aber wir sind noch einen Schritt weiter gegangen. Die Trennung von Bedenken bedeutet für uns, das Spiel unabhängig voneinander entwickeln zu können, so dass niemand im Team jemals durch die Arbeit eines anderen blockiert wird. Das bedeutet, dass nicht nur der Client vom Server getrennt wird, sondern auch unabhängig voneinander gearbeitet werden kann, aber auch das Engineering vom Inhalt getrennt werden kann. Dies ist der Hauptgrund, warum wir CoE mit zwei separaten Clients entwickelt haben. Ein High-Fidelity-, High-Polygon-Client, den ihr als CoE-Client kennen gelernt habt und ein Low-Fidelity-, Low-Polygon-Client, den ihr als Pre-Alpha Client oder "VoxElyria" kennengelernt habt.

 

Iterieren, wo es am günstigsten ist

 

Neben der Trennung von Bedenken versuchen wir auch zu iterieren, wo es am billigsten ist. Dieses Konzept wird im Projektmanagement häufig verwendet, da es sinnvoll ist, Iterationen dort zu betreiben, wo sie am wenigsten kosten. Wir sind mit der Entwicklung von Dual-Clients einen Schritt weiter gegangen. Während Konzeptzeichnungen es einem ermöglicht, Ideen schnell zu iterieren und zu verwerfen, bevor Sie zu 3D-Modellen werden und 3D-Modelle iteriert und verworfen werden können, bevor Sie zu Animationen werden. Mit unserer Entwicklung von Dual-Clients können wir funktionale Anforderungen und Designs testen und validieren während wir möglichst wenig Zeit für Kunst und Inhalt verbringen. Natürlich haben sich die Designs und Funktionen, die wir validieren können, im Laufe der Zeit geändert, da wir versucht haben, die Pre-Alpha für Spieler zugänglicher zu machen. Außerdem war es notwendig, dass wir mehr Funktionalität testen können.

 

ElyriaMUD

 

Als wir 2015/2016 zum ersten Mal über unsere Designmethodik und Rapid Prototyping sprachen, sprachen wir über ElyriaMUD. Es sollte ein reines Text-RPG sein, mit dem wir grundlegende Spielmechaniken implementieren können, ohne uns um Assets kümmern zu müssen. Eine solche Implementierung erfordert die geringste Kopplung zwischen Konstruktion und Inhalt, die mach sich vorstellen könnte. Es erlaubt uns tatsächlich, neue Mechaniken ziemlich schnell zu testen und zu erforschen, und die einfache Art der Implementierung bedeutet, dass sogar unsere Entwickler in der von uns ausgewählten Sprache von TypeScript neue Spielmechaniken schreiben und testen können. Ich sage "erlaubt es uns", denn obwohl niemand es wusste, haben wir tatsächlich ElyriaMUD implementiert. ElyriaMUD wurde bereits seit Version 0.4.0 verwendet, um neue Funktionen zu erkunden, ohne das Content-Team einbeziehen zu müssen. Die Arbeit in ElyriaMUD kann implementiert und getestet werden und dann auf einen der anderen Clients migriert werden. Während wir ElyriaMUD nie zuvor gezeigt haben, dachte ich, dass es jetzt ein guter Zeitpunkt ist, Bilder davon zu teilen. Hier sind ein paar.

 

1992 möchte seinen Loginbildschirm zurück

 

 Die Charaktererstellung zeigt das persönliche Schicksalssystem

 

Diesen Screenshot habe ich echt gut gemacht

 

Schaut euch die Überlebensanzeigen an und wie sie steigen, weil wir die Zeit vorlaufen lassen haben

 

Hier sind sowohl die Charakterattribute als auch die Ausrüstungsplätze sichtbar

 

ElyriaMUD eignet sich hervorragend für die schnelle Iteration von Design und Engineering. Es ist allerdings für die meisten Spieler unspielbar, da es Textbefehle zum Ausführen von Aktionen erfordert, keine Karte hat oder eine andere Möglichkeit bietet, um sicher zu sein wo Sie sich befinden abgesehen von der Möglichkeit sich Notizen zu machen oder die Räumlichkeiten auswendig zu lernen). Während es also quasi ein großer Sandkasten ist, würde es zusätzliche Zeit / Energie erfordern, um wirklich alle "Räume" zu entwickeln die erforderlich sind, um es wie ein spielbares Spiel erscheinen zu lassen. Aus diesem Grund ist es unwahrscheinlich, dass ElyriaMUD jemals als Teil einer Pre-Alpha veröffentlicht wird. Das andere Problem mit ElyriaMUD ist in der Tradition von MUDs begründet. Es verwendet ein Raumkonzept anstelle von XYZ-Koordinaten, so dass es unmöglich ist, Mechaniken zu testen, die eine absolute Positionierung erfordern. Daher wird eine Funktionalität, die eine XYZ-Koordinatenposition erfordert, normalerweise ganz anders implementiert, wenn sie von ElyriaMUD auf einen anderen Client verschoben werden soll. In jedem Fall haben uns das Format und die fehlenden Positionskoordinaten dazu gebracht, uns öffentlich von ElyriaMUD zu distanzieren und einen 2D-Top-Down-Client zu entwickeln.

 

Elyria 2D (mehr oder weniger)

 

Obwohl nur von kurzer Dauer und lediglich kurz erwähnt, haben wir Anfang 2017 einen Client erstellt, der auf WebGL basiert und Voxel verwendet, um ein Top-Down-Gameplay-Erlebnis zu ermöglichen. Dies war der Vorläufer von VoxElyria. Es wurde erstellt, als wir planten so wenig grafische Details wie möglich in die Pre-Alpha zu übertragen. Es sollten die immer gleichen „Sprites“ verwendet werden. Die „Sprites" wurden ursprünglich von den Ingenieuren mit Voxel-Modellen erstellt. Kurz nachdem wir mit der Arbeit an dem Elyria2D-Client begonnen hatten, beschlossen wir ihn etwas weiterzuentwickeln, damit unsere Alpha-Unterstützer teilhaben konnten. Dies erforderte einen Wechsel von einer 2D-Perspektive von oben nach unten zu einer 3D-Ansicht. Wir haben auch die Qualität unserer Voxel-Modelle usw. verbessert. In jedem Fall ist hier ein animiertes GIF von Elyria2D.

 

 

VoxElyria

 

Auch wenn ihr VoxElyria schon einmal gesehen habt - hier sind einige Screenshots, die wir in der Vergangenheit geteilt haben. Zur Erinnerung: VoxElyria sollte es uns ermöglichen, Funktionalitäten so schnell wie möglich zu testen und zu entwickeln, ohne sich auf das Content-Team verlassen zu müssen, um die Assets zu entwickeln. Die Design- und Entwicklungsteams könnten schnell eigene Voxel-Modelle mit niedriger Qualität erstellen und diese dann in unserem WebGL-basierten Client testen.

 

 

 

 

 

Als wir an Release 0.3.0 arbeiteten, wurden uns allerdings einige Dinge klar.

 

  1. Während das Voxel-Format es uns erlaubte schnell Spielmechaniken zu erstellen, ohne sich um die Assets zu kümmern, waren die Mechaniken nicht 1:1. Aufgrund der Kameraposition wurden beispielsweise verschiedene Implementierungen zwischen CoE und VoxElyria notwendig. Zum Beispiel mussten Kampf, Crafting und Welt-Interaktion, wohl drei der wichtigsten Systeme im Spiel, zwischen VoxElyria und CoE leicht unterschiedlich sein.

  2. Während die Assets selbst schnell erstellt werden konnten, war es uns nicht möglich einige der fortschrittlicheren Mechaniken effektiv zu visualisieren. Zum Beispiel konnten wir die Voxel-Modelle nicht einfach animieren, weshalb Dinge, die Animationen erforderten, schwer zu validieren waren. Da es sich um Voxel-Modelle handelte, konnte etwas wie das Ausrüstungs- und das Schichten-System im VoxElyria-Client nicht effektiv repliziert werden.

  3. Während wir für VoxElyria nicht WebGL (oder andere webbasierte Game-Engines) verwenden mussten, hat es sich auf natürliche Weise aus Elyria2D dahingehend entwickelt. Es bedeutete, dass während die clientseitige Implementierung der Mechanik zwischen CoE und ElyriaMUD identisch sein konnte, alle Funktionen die wir testen wollten (die eine engere Client-Integration erforderten), entweder zwischen den Clients portiert oder doppelt implementiert werden mussten.

Wir hatten ein langes Gespräch mit der Führung, den Designern und dem Inhaltsteam und haben entschieden, dass es einen besseren Weg geben musste. Zunächst haben wir erkannt, wie wichtig es ist, einen Low-Poly- und Low-Fidelity-Client zu verwenden, aber wir mussten sicherstellen, dass einige Einschränkungen eingebaut wurden. Sie sind wie folgt:

 

  • Der Client musste die gleiche Technologie wie CoE verwenden

  • Der Client musste dieselbe Animations-Pipeline verwenden

  • Der Client musste in der Lage sein, das gleiche UI / UX-Gameplay wie CoE zu nutzen

  • Der Client musste die gleiche schnelle Entwicklung der Assets ermöglichen wie bisher

 

Letztlich entschieden wir uns dafür, die Idee von Low-Po-Assets beizubehalten, dies aber zurück in UE4. Anstatt Voxel-Modelle zu entwickeln, haben wir uns für Low-Poly-Meshes entschieden, die noch schneller entwickelt werden können als die bisher verwendeten Voxel-Modelle. Natürlich kostet es etwas, dass das Content-Team Assets für uns entwickelt, aber in der Realität ist es schneller und ressourceneffizienter, dass das Content-Team die Assets entwickelt und nicht die Designer und Ingenieure. Insbesondere wenn es heißt, dass wir nicht die UI / UX zwischen dem Pre-Alpha-Client und dem CoE Client duplizieren mussten. Es ist außerdem wichtig, flexibel und bereit zu sein. Die Arbeit so neu zu verteilen, wie es unsere internen Ressourcen erfordern. Zum Glück, wie ihr unten sehen werdet, arbeiten unsere „Künstler“ wirklich gerne mit dem neuen Client und sie haben schon unglaubliche Inhalte erschaffen.

 

Das Content-Team hat daher mit Release 0.4.0 an Assets für unseren neuen Pre-Alpha-Client gearbeitet. Da Voxel nicht mehr verwendet werden, konnten wir es auch nicht länger VoxElyria nennen. Wir nennen es nun einfach Pre-Elyria oder "Prelyria".

 

Prelyria

 

Bei dem Versuch zu entscheiden welchen Kunststil und welche Art von Assets in Prelyria verwendet werden sollten, erinnerten wir uns daran, wie einfach und beliebt unser cel-shaded Artwork als Teil unserer Animatics war. Es ist wichtig, dass wir weiterhin den visuellen Stil unserer Pre-Alpha vom endgültigen Launch trennen, also entschieden wir uns, eine Cel-Shading-Methode zu verwenden. Wir begannen mit einigen Konzeptzeichnungen, die ihr hier sehen könnt:

 

 

 

 

 

 

 

 

 

Danach fingen wir an die Assets an sich zu erstellen.

 

 

 

 

 

 

 

 

 

(Ignoriert bitte einfach den gelben Streifen im Himmel. Er dient als Markierung, damit wir Entfernungen messen können.)

 

Fazit

 

Puuh! Release 0.4.0 war bis jetzt unsere größte Entwicklungsetappe. Aber es hat sich gelohnt. Dabei herausgekommen ist eine Reihe von Implementierungen für einiges, wenn nicht sogar für das meiste unseres Kernsystems der Alpha Version, die bereit ist in die Prelyria Version eingefügt zu werden und im Release 0.5.0 zusammengefügt wird. Zur gleichen Zeit haben wir Release 0.4.0 mit einem neuen Client and Art-style beendet, dass uns erlaubt das Spiel genauso schnell wie vorher (ehrlich gesagt noch schneller) zu entwickeln. Es ermöglicht uns ebenso Pre-Alpha Szenerien zu entwickeln, die noch näher am finalen Spiel sind und konstruktiveres Feedback zu bekommen.

Und schlussendlich hat uns Release 0.4.0 einen Schritt näher zur Landauswahl gebracht und zur Verwirklichung von Elyria wie es für die Spieler existieren soll.

Zu Beginn von Release 0.4.0 sagte ich, dass die nächsten zwei Veröffentlichungen (4 und 5) die wichtigsten seien und ich erkläre euch warum. Am Ende von Release 5 werden wir endlich da sein, wo wir hin wollten. An einem Punkt an dem wir euch endlich das Spiel, an dem wir so lange gearbeitet haben, zeigen können. Bleibt dran und seid gespannt auf den Release 0.5.0 Intro Post Ende der Woche, in dem wir darüber reden was wir alles in 0.5.0 machen werden. Außerdem geben wir das Startdatum für die Landauswahl bekannt!

Caspian

Share on Facebook
Share on Twitter
Please reload

Empfohlene Einträge

Zeit für Geschenke

December 21, 2017

1/1
Please reload

Aktuelle Einträge