CSE
Die ersten 30 Tage der Beta 1

Danksagungen

Meine Absicht war es, euch so viel des unbearbeiteten „offiziellen“ Dokuments zur Verfügung zu stellen, wie möglich. Dasselbe habe ich auch dem Team gesagt, nachdem wir mit der Arbeit am Dokument fertig waren. Das „wir“ meine ich dabei wörtlich, denn CSE ist ein hochgradig gemeinschaftlich agierendes Studio. Wir besprechen uns, tauschen Ideen aus, sind verschiedener Meinung, debattieren und bleiben dabei – meistens – höchst professionell und höflich. Schließlich ist niemand perfekt, nicht wahr?

Ein Danke an CSE!

Ich will mich nur bei all den Leuten von CSE bedanken, die dieses Dokument lesen sowie bei denjenigen, die bereits jede Menge Zeit mit meinen Texten verbracht hatten, bevor das Dokument an das gesamte Team rausging und die dabei Vorschläge einbrachten, Kommentare abgaben, Fragen stellten, Lücken füllten, usw. Ferner möchte ich auch diejenigen loben, die sich nach der Herausgabe des Dokuments eingängig mit dem Kommentarbereich auseinandersetzten: Ihr habt ganze Arbeit geleistet und genau wie bei unserem Spiel ist dieses Dokument nur zu dem geworden, was es ist, weil wir alle gemeinsam daran getüftelt haben.

Das vorherige Dokument sowie sämtliche unserer Kommentare dort verbleiben an Ort und Stelle, damit wir uns stets darauf zurückbeziehen können.

Ab sofort ist allerdings dieses Dokument hier unser offizieller Fahrplan für die Beta 1. In den kommenden Wochen werde ich noch die folgenden beiden Varianten erstellen:

  1. Eine redigierte Fassung für unsere Backer. Nach ihrer Fertigstellung wird sie Stück für Stück auf unserer Website enthüllt.
  2. Eine Fassung in „Erzählform“ aus der Perspektive unserer Backer.

Erneut vielen Dank euch allen, das war tolle Arbeit!

Ein Danke an unsere Backer!

Der Weg zur Beta 1 war steiniger, als wir letztes Jahr angenommen hatten. Dafür entschuldigen wir uns in aller Aufrichtigkeit und Demut bei euch. Schon beim alten Mythic war meine Philosophie stets, dass der Geschäftsführer einer Firma in solch einer Situation Farbe bekennen muss. Das tue ich hiermit erneut und sage: „Mea Culpa“. Damit ist es allerdings nicht getan, zumindest nicht meiner bzw. unserer Meinung nach. Worte sind schließlich nur Worte. Sie mögen von Herzen kommen, der Wahrheit entsprechen und sinnstiftend wirken, doch in diesem Fall reichen sie nicht aus. Wir müssen noch mehr tun und das werden wir auch.

Als Einstieg danke ich euch im Namen aller hier bei CSE wahrhaftig für eure Geduld und eure Unterstützung. Es bedeutet uns die Welt, dass ihr uns weiterhin die Treue haltet, uns kleine Geschenke schickt und uns nicht das Leben schwer macht. Ihr könnt euch gar nicht vorstellen, wie viel es dem Team und mir bedeutet, wenn wir sehen, wie sich manche von euch ins Zeug legen, um uns mit Worten oder gelegentlich auch Taten zu unterstützen. Manchmal macht das für das Studio wirklich den entscheidenden Unterschied.

Was mich angeht, so habe ich bereits mehr Geld in das Studio investiert, als ich ursprünglich vorhatte, indem ich das Büro in Seattle eröffnete und das dortige Team erweiterte. Gleichzeitig haben wir es allerdings vermieden, euch darum zu bitten, uns bei den zusätzlichen Kosten, welche beachtlich ausfielen, behilflich zu sein. Glücklicherweise waren die dadurch erzielten Resultate ebenso beachtlich! Wenn ihr das hier lest, werden wir den ersten SNB-Testläufen (Samstagnacht-Belagerungen) schon schmerzhaft nahe sein und die ARCs/Bots wieder auf 2100 aufgestockt haben. Zudem werden die Fähigkeiten-, Animations- und VFX-Systeme erwartungsgemäß funktionieren und der Fokus der Programmierer mehr denn je auf dem Gameplay anstelle der Technik liegen.

Es war ein langer Weg, weitaus länger als erwartet, doch wir sind unseren Backern treu geblieben und nun beinahe in der nächsten Testphase angelangt. Wie üblich bedanken wir uns für eure Unterstützung, euer Verständnis und vor allem für eure Geduld.

-Mark

Leitprinzipien

Wie lauten die übergreifenden Leitprinzipien für die Beta 1?

  • Wir müssen mit einem Spiel aufwarten, welches zwar definitiv nicht die Kriterien heutiger „fast fertig“-Betatests erfüllt, aber dennoch substanziell genug ist, dass sich die Backer auf den Prozess der Betatests freuen. Dabei stellt die Beta 1 lediglich den Beginn dieses Prozesses dar und keinesfalls die Endphase der Tests für ein Spiel, das bereits sämtliche Features enthält oder nur noch für andere Länder lokalisiert werden muss.
  • Wir müssen uns vor Augen halten, dass die meisten Backer aufgrund der Neu-Befähigung über ein Jahr länger auf diese Beta gewartet haben. Wir müssen ihre Geduld, ihr Verständnis und ihre Unterstützung angemessen belohnen. Es gibt nichts wichtigeres.
  • Die Beta 1 sollte sich für den Spieler bei jeder Gelegenheit mehr um den Spaß am Spiel drehen, als es noch bei der Alpha der Fall war. Es mag weiterhin eine Beta 1-Testphase sein, doch indem wir ihnen unterhaltsamere Dinge wie etwa die Samstagnacht-Belagerungen oder vergleichbare Testszenarien zur Verfügung stellen, können wir entscheidend dazu beitragen, dass die Beta 1 gleichermaßen das Interesse von Backern als auch Nichtbackern weckt und für den Rest des Jahres aufrechterhält.
  • Beta 1-Tests sollten so stabil wie möglich laufen. Unglücke passieren, doch wir sollten keine Tests mit instabilen Versionen abhalten, nur um an einem Ablaufplan festzuhalten. Es sei denn natürlich, der Zweck des Tests wäre das Aufspüren und Beheben jener Instabilität unter mithilfe der Alpha-, Beta- und IT-Backer.
  • Wir müssen uns bewusst machen, dass die Server auch während der Beta 1 nicht rund um die Uhr laufen werden und uns deshalb beschleunigte Versionen des Fortschritts-, Handwerks-, Bau- und ähnlichen Systemen zur Verfügung stehen müssen. Das wird in meinen Handwerksdokumenten, weiteren Dokumenten sowie in diesem Dokument besprochen. Der Grad der Beschleunigung sollte während eines Tests wenn möglich jederzeit anpassbar sein.
  • Wir brauchen eine zentrale Tabelle anstelle eines XML-Dokuments, die alle diese Variablen enthält. Dadurch fiele es sicherlich nicht nur den Designern leichter, an diesen Werten zu arbeiten, sondern auch den Programmierern, die sich nicht mehr um das Anfertigen einzelner Tabellen, Funktionen, usw. sorgen müssten.

    • Anmerkungen von MJ: Dieser Abschnitt des Dokuments spiegelt die „Kernprinzipien“ unserer Beta 1-Tests und unserer Firma wider. Diesen Begriff verwende ich seit Langem und hier stellen sie das Äquivalent zu den Grundlegenden Prinzipien von Camelot Unchained dar. Sie sollen als Richtlinie für alles Folgende dienen.

    Der Zweck dieses Dokuments

    Dieses Dokument soll einen breiten Querschnitt jenes Spiels präsentieren, das unsere Backer beim Start der Beta 1 erwarten können. Es dient außerdem dazu, dem Team einige der konkreten Ziele zu beschreiben, die wir während der künftigen Entwicklung von der Beta bis zum Erscheinungstag verfolgen werden. Dabei handelt es sich allerdings weder um einen allumfassenden Überblick aller Features unseres Spiels, noch um eine lückenlose Beschreibung sämtlicher Einzelheiten irgendeines Features, Systems oder einer Mechanik. Vielmehr ist es ein Ausblick auf alles, von dem wir glauben, dass es beim Start der Beta 1 spielbar sein sollte. Ferner ist dieses Dokument nicht in Stein gemeißelt, sollten wir also ein Element aufgrund seiner Komplexität oder aus anderen Gründen opfern müssen, damit es etwas anderes in die Beta 1 schafft, bin ich zu Gesprächen diesbezüglich bereit.

    Sobald dieses Dokument unseren Ansprüchen genügt, werden wir unseren Backern eine redigierte Fassung zugänglich machen, damit sie wissen, was sie zum Start der Beta 1 erwartet. Die unten beschriebenen Dreingaben werden dort allerdings sowohl aus Wettbewerbsgründen als auch aus dem Selbsterhaltungsdrang meiner geistigen Gesundheit nicht aufgeführt werden, da ich mich selbst bei der redigierten Fassung schon um genügend Fragen, Kommentare, usw. unserer Backer zu kümmern habe. Zudem stehen sie als bloße Dreingaben auch niedriger in der entwicklerischen Nahrungskette als andere Posten, die in jedem Fall rein müssen.

    Anmerkungen von MJ: Was unsere Backer also als Quintessenz dieses Abschnitts mitnehmen sollten, ist, dass dieses Dokument nie dazu gedacht war, alle geplanten Inhalte der Beta 1 zu umfassen, geschweige denn die der Verkaufsfassung. Hier soll lediglich ein sehr genauer Einblick auf die zur Beta 1 zu erwartenden Inhalte gewährt werden. Es enthält keine Erläuterungen zu den einzelnen Elementen und auch keine Einzelheiten oder Ähnliches, da das Dokument sonst auf über 100 Seiten angeschwollen wäre. Betrachtet es stattdessen als die Mindestvision der Beta 1. 😊

    Aufschlüsselung des Dokuments

    SCHWARZ = Für die Beta 1 benötigt

    ROT/DREINGABE = Alles rote wäre zum Start der Beta 1 lediglich eine Dreingabe, muss allerdings im weiteren Verlauf der Beta 1 integriert werden.

    LILA = Fragen an das Programmiererteam. Alle alten Fragen, die bereits beantwortet wurden, werden entfernt. Nur unbeantwortete und NEUE FRAGEN verbleiben im Dokument.

    BLAU = Spezifische Designfragen

    Die aus diesem Dokument entfernten Inhalte fallen in die folgenden Kategorien:

    1. Zitate bzw. Ideen einzelner Entwickler. Diese Informationen wandern in unser Teamdokument, haben aber in einem schon bald öffentlichen Dokument nichts verloren. Zudem gefallen diese Ideen vielleicht nicht jedem und ich möchte vermeiden, dass irgendein Mitglied von CSE persönlich beleidigt oder angegriffen wird. Wenn ihr den Drang dazu verspürt, CSE oder unsere Ideen zu kritisieren, dann wendet euch an mich (MJ), denn ich habe das Hauptdokument verfasst und alles abgesegnet, das hier drinsteht.
    2. Material, welches wir derzeit noch nicht enthüllen möchten. Wie viele von uns bereits bemerkt haben, sind Ideen aus CU in anderen Spielen aufgetaucht, genau wie sich auch Ideen aus fremden Spielen in CU wiederfinden. Das ist zwar ein normaler Vorgang, doch möchte ich niemandem einen vermeidbaren Vorsprung auf uns schenken.😊
    3. Material, welches als DREINGABE für die Beta 1 erachtet wird.

    Der Patcher
    Patcher

  • Ein verbessertes UI für Server und Charaktere. Sämtliche UI-Bugs sollten behoben sein, sodass Spieler wissen, welche Charaktere sich auf welchem Server befinden, welchen Charakter sie derzeit ausgewählt haben, usw.
  • Der „erste Schritte“-Link (Getting Started) sollte auf ein „Willkommen zur Beta 1“-Dokument verweisen. Derzeit landet man auf der Hauptseite des Spiels und da jeder, der an dieser Stelle im Patcher angelangt ist, bereits Abonnent ist, kann er auch genauso gut woanders hinführen.
  • Eine Anzeige der Spielerzahl im Chatbereich des Patchers. Es wird äußerst nützlich und notwendig sein, irgendwo eine aktuelle Zählung zu haben, die sowohl für uns als auch für Backer leicht zugänglich ist. Wir sollten sowohl außerhalb als auch innerhalb des Spiels ablesen können, wie viele Leute sich gerade in welchem unserer Systeme (Chat, Patcher, Fledgling, usw.) aufhalten.
  • Wir werden außerdem die Anzahl von Leuten, die sich auf den einzelnen Servern befinden, direkt beim jeweiligen Servereintrag im Patcher anzeigen.
  • Wir werden den Patcher nicht mehr automatisch alle Kanäle (=Server) updaten lassen, sondern das System dezent abändern. Stattdessen lassen wir ihn den derzeit ausgewählten Server aktualisieren, sofern er nicht bereits etwas anderes herunterlädt. Die „Spielen“-Schaltfläche (Play) wird in diesem Fall den weiteren Download entweder hinter dem bestehenden anreihen oder das entsprechende Update unverzüglich einleiten.
  • Links zu FAQs, Hilfen, ein Link oder Bereich zu bekannten Problemen und anderes Material zum Spiel. Zudem ein neuer Beta-Willkommensbildschirm, unsere eigene Erläuterung zum Erstellen eines DXDiags sowie einige neue Patcherbildschirme für die Beta 1.
  • Eine „Helft mir!“-Schaltfläche (Help Me!), die anstelle des breiter gefächerten FAQ-Bereichs ein Dokument öffnet, das die häufigsten Probleme auflistet, die Spielern begegnet sind. FAQs tendieren zu einer gewissen Überlänge und ich möchte, dass unsere Übersetzer diese Infos schnell und unkompliziert in ihre jeweilige Sprache übertragen können.
  • Ein Banner (oder eine Seite), die alle wichtigen Meldungen des Tages (falls vorhanden) auflistet. Beispiele wären: „Alle Server sind momentan down.“ oder „Heute findet ein Test of WyrmlingPrep statt.“ Dadurch können wir Spielern wichtige Informationen zukommen lassen, ohne dass sie dafür im Spiel, den Foren oder Ähnlichem nachsehen müssen. Diese Seite können wir zudem auf unserer Website, Facebook, usw. verlinken. Derzeit können Mitteilungen vom Spiel über herunterfahrende Server nicht vom Patcher aus gelesen werden. Unterm Strich müssen wir auf diversen Ebenen besser mit unseren Backern kommunizieren und hier bietet sich eine gute Möglichkeit dafür.
  • Bei Leuten mit veralteten Patchern müssen wir dem Patchclient eine Nachricht schicken, die ihn vom Server trennt und dem Anwender eine Meldung ausgibt, dass sich der Client nun für ein Update beendet oder vorübergehend deaktiviert usw. Der Anwender kann diese Meldung dann bestätigen und so das Update einleiten.

    • Anmerkungen von MJ: Wie ihr an diesem Abschnitt erkennt, haben wir uns für die Beta 1 sogar mit einer Überholung des Patchers befasst. Für die Zeit nach der Beta 1 haben wir noch haufenweise weitere Ideen und dementsprechend musste ich diesen Bereich dezent redigieren. Selbstverständlich gehen wir nicht davon aus, dass diese Verbesserungen den Start der Beta 1 verzögern. Wäre das wider Erwarten doch der Fall, wären wir dazu bereit, einige der genannten Neuerungen zu opfern, um die Eröffnung der Beta 1 zu beschleunigen.

    Charaktererstellung
    Character Creation

  • Spieler müssen dazu in der Lage sein, sich Charaktere in jeder zulässigen Reich-, Rassen- und Klassenkombination zu erstellen.
  • Die Reihenfolge der gelisteten Attributspunkte sollte alphabetisch sein. Zudem wollen wir sie entsprechend ihrer Wichtigkeit für die gewählte Klasse farblich hervorheben. Seht euch diesbezüglich das Prinzip der „Konzeptgruppen“ (concept groups) aus dem Pen-&-Paper-Rollenspiel „Die Hohen“ (Exalted) oder einiger älterer Vertreter dieses Genres als Referenz an.
  • Alle Attribute können angepasst werden, auch wenn manche derzeit noch keine Auswirkungen haben.
  • Wir brauchen ein Eingabefeld für Zahlen, damit Spieler die gewünschte Zahl einfach eingeben oder die Hoch-&-Runterpfeile verwenden können.
  • Die Hervorhebungen auf diesem Bildschirm müssen repariert werden, sodass alle Textelemente einheitlich aussehen. Einige Einträge verschiedener Attributsbeschreibungen sind gedimmt/ungedimmt und sehen deswegen unordentlich aus.
  • Eine Hilfefunktion für jeden Abschnitt des Auswahlprozesses. Jede einzelne Seite sollte über eine Hilfsdatei bzw. -information verfügen, die nur einen Tastendruck entfernt ist und einem bei derjenigen Stelle des Charaktereditors behilflich ist, an der man sich gerade befindet. Wenn möglich sollte dies innerhalb des Charaktererstellungsprozesses angezeigt werden und einen nicht auf die Website umleiten.
  • Spieler können bei der Charaktererstellung aus einer kleinen Auswahl von Flüchen & Segen wählen. Diese werden sich in eine Rasse-, Klasse- und Allgemein-Kategorie aufgliedern. Derzeit wollen wir mindestens 10 Flüche & Segen pro erstelltem Charakter bieten (sofern man alle drei Kategorien miteinbezieht). Wenn wir mehr schaffen, umso besser!
  • Auf dem F&S-Bildschirm muss „Minimale Punkte“ zu „Benötigte Mindestpunktzahl“ geändert werden.
  • Auf dem F&S-Bildschirm muss „Maximale Punkte“ zu „Erlaubte Höchstpunktzahl“ geändert werden.
  • Namen sollten auf dem selben Server nur einmal vorkommen dürfen.
  • Jede Rasse im Spiel sollte ihren eigenen animierten Hintergrund erhalten, genau wie wir es bereits bei den Klassen handhaben.
  • Die Spieler werden mit Ausrüstung starten, die zu ihrem Reich und ihrer Klasse passt. Zudem erhält jeder Spieler eine Vox Magus, da es die Handwerksklasse zum Start der Beta 1 noch nicht geben wird. Wie weiter unten erwähnt, wollen wir nicht, dass die Leute sich beliebig viele Vox erschaffen können, es sei denn, wir geben ihnen explizit die Möglichkeit neue zu erstellen und sie in der Welt zu platzieren.
  • Neben der „Weiter“-Schaltfläche (Next) sollte es eine „Abbrechen“-Funktion (Cancel) geben, damit man nicht zur Startseite (Home) zurück muss.
  • Die unterste Leiste des Patchers sollte während der Charaktererstellung ausgeblendet oder -gegraut werden, da sie für manche Spieler, insbesondere neue, verwirrend wirken kann.

    • Anmerkungen von MJ: Für den Start der Beta 1 wollen wir zwar nicht all zu viel Aufwand bei der Verbesserung der Charaktererstellung betreiben, aber eine Steigerung im Vergleich zum derzeitigen Bedienkomfort soll es schon geben. Im Laufe des weiteren Betaprozesses könnt ihr allerdings mit tiefgreifenden Veränderungen rechnen. Momentan ist es den Aufwand schlicht nicht wert, da sich an den zugrundeliegenden Systemen bzw. Werten noch viel ändern kann. Je mehr endgültig feststeht und für den Erscheinungstag bestätigt ist, desto mehr Arbeit werden wir in die Charaktererstellung stecken.

    REDIGIERT

    Anmerkungen von MJ: Tut uns leid, aber dieser Abschnitt ist ausschließlich für CSE gedacht und nicht für Backer.

    Die Sicheren Inseln

  • Bei den Sicheren Inseln handelt es sich um „private“ Inseln, die dem jeweiligen Reich gehören. Sie können ausschließlich von Reichsangehörigen betreten werden, welche mittels Portalen dorthin gelangen. Diese Portale dienen als Platzhalter für das geplante Transportsystem, mit dem man sich zwischen den Inseln bewegen und welches aus Booten und anderen Fortbewegungsmitteln bestehen wird, die einen dann nicht mehr augenblicklich zum Zielort teleportieren. Die Portale werden keine Spieler gegnerischer Reiche auf den falschen Sicheren Inseln absetzen. Auch die Sicheren Inseln sind wie die Portale lediglich Platzhalter für das, was einmal die Hauptinseln der jeweiligen Reiche sein werden.
  • Wir hoffen, dass wir einige der Sicheren Inseln solange tagesübergreifend persistent halten können, bis wir ein Zurücksetzen für unvermeidlich halten. Spieler sollten sich also nicht auf eine dauerhaft persistente Welt einstellen, die während der gesamten Betazeit Bestand hat, doch eine tagesübergreifende Persistenz sollte im Allgemeinen unsere standardmäßige Vorgehensweise während der Beta 1 sein. Wie wir bereits während der Kickstarter-Kampagne erwähnten, werden wir im Laufe der Beta häufig Elemente zurücksetzen, insbesondere solange noch nicht alle Klassen im Spiel sind.
  • Wir werden die Gesamtzahl der während der restlichen Beta benötigten Sicheren Inseln erst dann festlegen, wenn wir mittels der endgültigen Beta-1-Technologie die Grundstücksanzahl, Grundstücksgröße, Gebäudeanzahl, usw. pro Insel an die jeweilige Inselgröße gekoppelt haben. Nachdem wir vorhaben, die Gebäudestatik für die Beta 1 zu aktivieren, werden wir, solange wir noch Optimierungen vorzunehmen haben, die Grundstücksanzahl pro Insel begrenzen, um die Performance im grünen Bereich zu halten. Mit fortschreitender Optimierung werden wir auch die Sicheren Inseln erweitern, um unsere Systeme steigenden Belastungen auszusetzen.
  • Jede Sichere Insel verfügt über einen Landungsbereich, welcher im nächsten Kapitel näher beschrieben wird. Die Landungsbereiche werden sich je nach Art der Sicheren Insel (Bau-Insel, Starter-Insel, usw.) unterscheiden. Hiervon werden die Landungsbereiche der Starter-Inseln die kompliziertesten sein.

  • Die Sicheren Inseln mit Landungsbereichen werden in der Regel am häufigsten geöffnet sein, um unserer Baumeister-Brigade die Mithilfe am Aufbau und dem Verändern der Inseln zu ermöglichen. Wir sollten für die Sicheren Inseln einen gesonderten Server einrichten (nicht Hatchery/Fledgling), damit sich unsere Baumeister-Brigade bei ihrer Arbeit nicht darum sorgen muss, was wir auf unseren primären Entwicklungs- und Testservern anstellen. Eine engagierte Gruppe von Baumeistern zu haben, die diesen Aspekt des Systems unter die Lupe nimmt, ist ebenso wichtig wie Kämpfer, die das Kampfsystem auf den Umkämpften Inseln testen. Ich weiß, dass sich unsere Kämpfer gewaltig darüber freuen werden, was wir im Kapitel über die Umkämpften Inseln für sie auf Lager haben!
  • Einen neuen Server (weder Hatchery noch Fledgling) hinzufügen, auf dem ein stabiles Abbild entweder des Hatchery- oder Fledgling-Servers läuft, damit die Baumeister gemeinschaftlich vorgehen können, ohne durch die Serverneustarts zwecks etwaiger Änderungen am Code ausgebremst zu werden. Die Zugangsberechtigung für diesen Server könnten wir auf diese Damen und Herren beschränken, sodass er nur von CSE und den Baumeistern installiert und betreten werden kann. Da hier keine große Spieleranzahl vonnöten ist, wären die Serverkosten folglich gering, insbesondere unter Verwendung unserer „eingebetteten“ Systeme.
  • Jede Sichere Insel sollte beim Betreten durch den Spieler mit einem individuellen Musikstück aufwarten.

  • Um den Landungsbereich herum sollte es ein durch Backer unbebaubares Areal geben, das groß genug ist, damit unsere Baumeister-Brigade haufenweise Gebäude, angrenzende Städtchen, usw. errichten kann.
  • Die für Spielergebäude vorgesehenen Sicheren Inseln sollten groß genug sein, um jede Menge Gebäude und Spieler beheimaten zu können. Allerdings sollten wir sie wegen den damit verbundenen Serverhardwarekosten (durch AWS) vermutlich nicht rund um die Uhr laufen lassen. Sobald wir zu einer endgültigen Schätzung der Kosten sowie der je Insel vorgesehenen Anzahl an Grundstücken, Gebäuden usw. gelangt sind, kann die Designabteilung festlegen, wie viele Inseln wir für die Beta 1 benötigen.

    • Anmerkungen von MJ: Die Sicheren Inseln sind ein wichtiger Bestandteil der Beta 1. Im Gegensatz zu den Charakteren wollen wir ihnen Persistenz verleihen, damit unsere Baumeister-Brigade die Inseln nicht ständig neu bebauen muss. Zudem sollen sie unseren Backern abseits der Kämpfe einen Ort zum Tüfteln und Verfeinern bieten. Während der verschiedenen Betaphasen und später auf den LIVE-Servern wird so ein Gefühl der „Heimkehr“ ins eigene Land bzw. Zuhause entstehen. Da die Sicheren Inseln vor den Augen unserer Backer Gestalt annehmen werden, wird sich dadurch auch die Welt zunehmend wie eine richtige Welt anfühlen und nicht mehr nur wie eine Bühne für eine echt coole Tech-Demo. Das hat natürlich auch den weiteren Vorteil, dass es den Backern neue Zuversicht vermitteln wird, was den derzeitigen Zustand der Entwicklung angeht, über den sie sich nach vier Jahren völlig berechtigt Gedanken machen dürfen.

    Zudem werden es die Sicheren Inseln allen unseren Backern ermöglichen, sich mit unserem Bausystem auseinanderzusetzen und es zu kommentieren, damit wir es während der Beta 1 verfeinern und verbessern können. An jenem Punkt in der Entwicklung des Spiels ist es wichtig am Bausystem zu feilen, um so etwaige größere Probleme aufzustöbern, die zusätzlicher Zeit und Aufmerksamkeit bedürfen.

    Landungsbereiche

  • Bei ihrer ersten Ankunft werden sich Spieler in einem Landungsbereich der größten Starter-Insel ihres Reiches wiederfinden.
  • Der Standort eines Spielers wird persistent sein, ungeachtet auf welcher Insel er sich beim Verlassen des Spiels befand, es sei denn natürlich jene Insel wurde in der Zwischenzeit geschlossen oder ist aus anderen Gründen offline. In solch einem Fall wird der Spieler beim nächsten Einloggen zu einem reichseigenen Landungsbereich zurückgesetzt. Das bedeutet also, dass sich Spieler nicht innerhalb feindlicher Burgen/Gebiete ausloggen und nach einem Neustart des Servers bzw. Matches an selber Stelle wieder einloggen können.
  • Jeder Landungsbereich sollte über einen Hafen, eine Reihe von Portalen sowie einige grundlegende Gebäude und Mauern verfügen. Sofern alles nach Plan verläuft, sollten diese Gebäude von der Baumeister-Brigade errichtet werden. Dabei sollte die Starter-Insel vollständiger ausgebaut sein als der Rest. Eventuelle weitere Inseln sollten schlicht Abbilder der bereits existierenden sein.
  • Betreffs der Gebäude bzw. Portale:
  • Kneipe
    • dB sollte die Kneipenstimmung mit ortsgebundener, atmosphärischer Musik untermalen. Bis es soweit ist, werden wir unsere derzeitige Methode anwenden, bei der wir Umgebungsmusik manuell platzieren und radial begrenzen. Zudem werden wir uns künftig nach weiteren Methoden umsehen, mit denen wir Orten eine bestimmte Musik zuweisen können.
    • Setze einen NSC als Kneipenbesitzer ein. Wir werden mit den Backern Kontakt aufnehmen, die sich bei Kickstarter ihre eigene CU-Kneipe gesichert haben und sie fragen, ob sie einem dieser Kneipenwirte ihren Namen leihen wollen.
      • Bei einem Klick auf den Wirt sollte er einem ein paar grundlegende Eckpunkte zu Kneipen erklären. Ein einfaches Beispiel wäre: „Kneipen dienen als Versammlungsort, an dem sich Leute unterhalten, Spiele spielen und sich allgemein vernetzen können. Sie werden entweder von den Spielern, denen sie gehören, oder eurem Reich verwaltet.“
        • Wir brauchen einen technischen Weg, der es Autoren bzw. Designern erlaubt, derartige Texte ohne Hilfe eines Programmierers einzusetzen.
        • Die verwendete Methode sollte so eingerichtet sein, dass die Texte nicht nur jederzeit von Autoren bzw. Designern angepasst, sondern auch von unseren freiwilligen Helfern übersetzt werden können.
  • Bank
    • Umgebungsmusik für Banken
    • Provisorischer NSC-Bankier
    • Bei einem Klick auf den Bankier sollte dieser einem die grundlegende Funktionsweise unseres spielinternen Bankwesens erläutern.
    • Die Bank an sich wird in der Beta 1 keine Funktion haben.
  • Portal
    • Umgebungsmusik für Portale
    • VFX für Portale
    • Portale sollten diese VFX nur anzeigen, sofern sie aktiv sind: Das sorgt nicht nur für weniger Verwirrung bei den Spielern, sondern scheint auch logischer, wodurch die Welt wiederum immersiver wirkt.
    • Provisorischer NSC-Portalhüter
    • Fahre mit der Maus über das Portal oder dessen Hüter, um Informationen darüber zu erhalten und schreite hindurch (sofern es nur einen festen Zielort gibt) oder wähle dein Ziel per Klick aus, falls es zu mehreren Zielorten führen kann.
    • Eine Admin-Oberfläche für Portale, die im Spiel bedient werden kann
  • Hafen
    • Standort für Portale und eines Tages selbstverständlich Boote. Für die Portale erschaffen wir wenn möglich reichsspezifische Varianten. Die künstlerische Abteilung wird sich diesem Thema annehmen und sie zudem skalierbar machen, damit man die verschiedenen Portal-Arten besser unterscheiden kann. Beispielsweise könnte das kleinste Portal bei den Booten stehen, während die größten Portale so mächtig sind, dass sie einen an mehrere verschiedene Orte transportieren können. Portal-Auslöser sind nicht mit Portalen gleichzusetzen, da die Auslöser eines Portals lediglich einen Teil des Gesamtportals ausmachen können. Ein Boot könnte beispielsweise als Portal fungieren, doch wäre der eigentliche Auslöser das Platznehmen auf einer seiner Bänke.
  • Spieler können sich anschließend frei auf der Starter-Insel bewegen und/oder mittels Portalen zu anderen Sicheren Inseln ihres Reiches reisen.
  • Im Zentrum des Landungsbereiches sollte es ein spezielles Portal zu den Umkämpften Inseln geben.
  • Jenes Portal sollte nicht dauerhaft aktiv sein. Die Umkämpften Inseln, seien sie Teil des ****** ****** (redigiert bis wir zu diesem Kapitel kommen) oder nicht, werden nicht rund um die Uhr laufen, weswegen auch das Portal nicht dauerhaft geöffnet sein muss. Zudem können wir das Portal als eine Art Zugangskontrolle bzw. Lobby verwenden, wie im folgenden Punkt erläutert.
  • Wir müssen dazu in der Lage sein, die Portale ohne die Hilfe von Programmierern zu öffnen und zu schließen. Dadurch könnten wir die Portale abhängig von gewissen Testbedingungen öffnen bzw. schließen (wenn es beispielsweise bei der Spielerverteilung auf die Reiche ein Ungleichgewicht gäbe). Die Server müssen während der Beta 1 zwar noch von Programmierern hochgefahren werden, doch hoffe ich, dass dies spätestens zu Beginn der Beta 2 nicht mehr der Fall sein wird.
  • Generell sollten die Portale zu den Sicheren Inseln stets in Betrieb sein, wenn der Server hochgefahren und für Spieler geöffnet ist.
  • Mit Ausnahme der Baumeister-Brigade ist es Spielern nicht möglich, im Landungsbereich zu bauen.

    • Anmerkungen von MJ: Genau wie die Sicheren Inseln, sollen die Landungsbereiche dazu beitragen, der Welt Leben einzuhauchen. Dinge wie NSCs mögen zu diesem Zeitpunkt zwar irrelevant wirken, doch wird uns die Möglichkeit frühzeitig echte NSCs zu haben auf lange Sicht von Nutzen sein.

    Bau-Inseln

  • Bau-Inseln sind eine Art von Sicheren Inseln (zusammen mit den Starter-Inseln), auf denen weder PvP, noch Spieler anderer Reiche erlaubt sind. Diese Einstellung wird nicht unabänderlich, sondern von den Designern einstellbar sein und, falls umsetzbar, wird es CSE möglich sein, diese im laufenden Spiel über das Admin-Portal zu ändern. Eventuell werden im Verlauf der Beta 1 noch zusätzliche Sichere Inseln hinzugefügt, derzeit sind jedoch keine weiteren Arten für den Start der Beta 1 geplant.
  • Bau-Inseln werden häufiger für Spieler geöffnet sein, als die Umkämpften Inseln. Allerdings werden sie nicht so oft verfügbar sein, wie die primäre Sichere Insel, um sowohl die Kosten als auch die Ermüdungserscheinungen unserer Spieler niedrig zu halten. Auch wenn dies ein wenig unfair anmutet, so ist es in Wahrheit sowohl notwendig, als auch fair. Zuallererst sind die Serverkosten, die durch die Bau-Inseln anfallen, weitaus niedriger als die der Umkämpften Inseln. Zweitens werden wir im kommenden Kapitel über ****** ****** noch verraten, was wir für unsere kampforientierte Spielerschaft in petto haben. Ich erwarte jedoch, dass es sich als eine Win-win-Situation für uns alle herausstellen wird.
  • Sie sollten aufs Bauen ausgelegt sein, was soviel bedeutet, dass die Inseln nicht über und über mit tiefem, dunklem Wald bedeckt, sondern leicht zu bebauen und mit ihren Hainen, Seen und hoffentlich Flüssen, welche sich durch die Landschaft schlängeln, auch noch ästhetisch ansprechend sein werden. Die Grundstücksgröße sollte groß genug ausfallen, dass man darauf ein ansehnliches Bauwerk errichten kann. Sie sollte dabei nicht so aussehen, wie auf unseren derzeitigen Bau-Inseln. Um die Sache einfach zu gestalten und Ben nicht derart in den Wahnsinn zu treiben, dass er schreiend in die Nacht entschwindet, sollten alle Bau-Inseln innerhalb eines Reiches überwiegend gleich aussehen.
  • Es sollten ausreichend viele Rohstoffvorkommen an gut zugänglichen Stellen über die Insel verteilt sein. Ausschlaggebend ist hier, dass wir nicht wollen, dass Spieler ihre Zeit damit verschwenden müssen, auf der Suche nach Bau-Rohstoffen über die komplette Insel zu rennen. Diese Rohstoffvorkommen könnten im Verlauf der Beta 1 entfernt werden, je nachdem, was mit den Minen und den Rohstoffzentren passiert.
  • Erschafft „Rohstoffzentren“, die sämtliche Rohstoffvorkommen beinhalten. Platziert sie so, dass Spieler niemals mehr als ein paar Minuten zu Fuß vom nächsten Rohstoffzentrum entfernt sind. ANMERKUNG: Abhängig davon, wie unsere Arbeit an den Minen und den nahtlosen Zonenübergängen voranschreitet, könnten wir auf die Rohstoffzentren verzichten und stattdessen Rohstoffinseln erschaffen, auf denen sich die gesammelten Rohstoffvorkommen eines Reiches befinden. Anschließend könnten wir über die Sicheren Inseln verteilte Portale erschaffen, mit denen die Spieler dorthin gelangen. Minen waren bzw. sind eine DREINGABE für die Beta 1. Sollten wir sie also aus der Beta 1 streichen müssen, so können wir dies bedenkenlos tun. Ich denke zwar nicht, dass es soweit kommen wird, doch habe ich unseren Backern stets klar vermittelt, dass es diese Features möglicherweise nicht in die Beta 1 schaffen.
    • Zu Beginn der Beta 1 sollten Rohstoffe ein sehr geringes Gewicht aufweisen, damit Spieler sie ungehindert zu ihren Baugrundstücken transportieren können. Das Gewicht von Gegenständen sollte ebenfalls zu einem globalen Wert erhoben werden, der von den Designern gesetzt werden kann, damit wir Einstellungen zur Verfügung haben wie: Gewicht an/ausschalten, verändere das Gewicht aller Gegenstände um %, usw.
      • Rohstoffe, die auf dem eigenen Grundstück, oder einem Grundstück auf dem ihr dazu berechtigt seid, abgelegt werden, sind persistent. Rohstoffe, die hingegen irgendwo im Feld abgeladen werden, verschwinden nach (x) Minuten. Dies wird Bestandteil der Berechtigungs-Einstellungen der Grundstücke werden.
  • Die Karten der Bau-Insel sollten es erlauben, dass stets genügend Platz zwischen den Grundstücken ist, sodass Spieler keine Gebiete unzugänglich machen können, indem sie ihre Häuser knapp aneinander anreihen. Die Größe der Grundstücke, der Abstand zwischen ihnen, usw. wird festgelegt, sobald mehr unserer Beta-1 Technologie online geht.
  • Sobald ein Spieler ein Areal betritt, in dem es ihm gestattet ist, Baugrundstücke zu besitzen, wird er die Teile der Insel, die zum Bauen freigegeben wurden, auf einer Karte sehen können. Dies wird zudem mittels Markierungen und optischen Hilfsmitteln innerhalb der Spielwelt ersichtlich sein. Dieses Feature wird im Laufe der Entwicklung des Spiels durch ein Kartenerstellungssystem ersetzt werden, doch für den Augenblick wollen wir, dass sich die Spieler auf Anhieb auf den Inseln zurechtfinden können.
  • Die Statik von Gebäuden wird für die Beta 1 von Camelot Unchained aktiviert sein. C.U.B.E. wird vorerst so bleiben wie es ist, sprich ohne Statik. Den Spielern steht es selbstverständlich frei, ob sie auf den Sicheren Inseln mittels des spielinternen Systems bauen oder ihre Gebäude aus C.U.B.E. importieren.
  • Zu Beginn der Beta 1 wird Spielern auf einer Sicheren Insel nur ein Grundstück pro Account zustehen. Sie können weiterhin Grundstücke auf Umkämpften Inseln einnehmen, doch um die Gesamtzahl der für die Beta 1 benötigten Inseln bzw. Server zu begrenzen, werden wir auch die Grundstücksanzahl begrenzen, die gleichzeitig vom selben Spieler besessen werden kann. Diese Begrenzung sollte allerdings zu einer Variable geändert werden, damit wir diese Einstellung auch während Tests anpassen können.

    • Anmerkungen von MJ: Wie bereits erwähnt, ist es wichtig, die Bau-Inseln in der Beta 1 zu haben. Die Backer und Bots jetzt schon dazu aufzurufen, das System auf Herz und Nieren zu testen, passt hervorragend zu unserer Entwicklungsphilosophie. Die größte Ergänzung zu unseren ursprünglichen Plänen sind selbstverständlich die Minen. Unsere bisherige Arbeit an ihnen stimmt mich zuversichtlich, dass sie für eine Integration in die Beta 1 geeignet sind. Selbst wenn ich mich täuschen sollte, so können sie im Handumdrehen durch die Idee der Rohstoffzentren ersetzt werden, welche dafür sorgen wird, dass unsere Backer beim Spielen unserer Beta 1 nicht bis zu dem Punkt frustriert werden, an dem sie keine Lust mehr haben einzuloggen und Sachen für uns zu testen.

    Ich möchte auch nochmal betonen, dass euch noch haufenweise weitere Informationen erwarten, inklusive der Auflösung für was die „****** ******“ stehen. Es wird für uns alle ein großer Gewinn sein und unsere kampforientierten Backer ganz besonders glücklich machen, würde ich wetten. 🙂

    Grundstücke

  • Jedes Grundstück wird über eine „Maximalanzahl von Blöcken“ verfügen. Die entsprechende Variable sollte Teil der *** *** *** werden. Das Blocklimit steht nicht in direkter Beziehung zum Grundstücksvolumen; das sind zwei verschiedene Dinge.
  • Die Bau- bzw. Zerstörungsgeschwindigkeit auf Grundstücken sollte von den Designern mittels der *** *** *** eingestellt werden können.
  • Auch die Bauhöhe ist auf Grundstücken begrenzt. Wir haben ja zur Genüge darüber gesprochen, dass dies dazu beitragen soll, die Häufigkeit „bestimmter Turm-Arten“ zu mindern. Auf diese Weise können wir zugleich das System zur Begrenzung der maximalen Baublöcke testen, welches ein Teil unseres „Baumeister- und Reichsbelohnungen“-Fortschrittssystems wird. Diese Variable sollte ebenfalls Teil der *** *** *** werden. Zwar ist dies sicherlich noch kein ausreichender Schutz vor einem Missbrauch des Bausystems, aber es ist zumindest ein Anfang. Im LIVE-Spiel werden uns noch weitere Mechaniken sowie die Nutzungsbedingungen zur Verfügung stehen, um Leute vom Errichten solcher Türme und anderem reichsinternen Griefing abzuhalten.
  • Wie bereits in früheren Kapiteln erwähnt, wird die Gebäudestatik für Camelot Unchained, aber jedoch nicht für C.U.B.E. aktiviert werden.
  • Die Eigentumsrechte von Grundstücken werden persistent sein, es sei denn ein Spieler gibt sein Grundstück auf oder wir löschen es. Ab wann ein Grundstück als aufgegeben gilt, werden wir noch anhand des weiteren Designs und den Spielerbedürfnissen festlegen. Wie lange ein Grundstück im Besitz eines Spielers verbleibt, muss variabel sein, damit wir am Ende nicht das gleiche Problem haben, wie Star Wars Galaxies: Tonnenweise leerer Gebäude, welche die Landschaft zumüllen und die Engine-Performance runterziehen. Auch dieser Wert sollte Bestandteil der *** *** *** werden.
    • Sobald ein Grundstück endgültig aufgegeben wurde, zerfallen seine Blöcke. Wir sollten im Verlauf der Beta ermitteln, wie sich das am besten umsetzen lässt. Idealerweise verfielen sie nach und nach in Echtzeit. Sollte sich dies auf einer großen Insel mit tausenden von Gebäuden zu einem Performanceproblem entwickeln, wäre es etwas, dass wir im LIVE-Betrieb stattdessen durch tägliche Serverneustarts erledigen könnten. (Derartige Neustarts sind allerdings nur eine mögliche Option und keinesfalls bestätigt.) So würde es sich zumindest nicht auf den laufenden Spielbetrieb auswirken, es sei denn ein Gebäude würde angegriffen.
    • Wir wollen verhindern, dass Spieler die Welt nur zum Griefen mit Gebäuden befüllen, sie einnehmen, bebauen und aufgeben, insbesondere wenn sie der oben genannten „Penisfraktion“ angehören (was, wie wir alle wissen, garantiert vorkommen wird).
      • Eine mögliche Lösung, die auch der Performance nicht schaden sollte, ist, den höchstgelegenen sowie einigen zufälligen (natürlich wieder genau konfigurierbar) Blöcken eines Grundstücks in regelmäßigen Abständen (einstellbar in Minuten, Stunden, Tagen) Schaden zuzufügen.
    • Das System der Grundstücksberechtigungen sollte:
      • Es Leuten ermöglichen, zum Bauen auf einem Grundstück ein- bzw. ausgeladen zu werden.
        • Man kann nur Mitglieder des eigenen Reiches zum Bebauen seines Grundstücks einladen.
        • Wir sollten Spielern die Möglichkeit geben, ihrer Gilde, Gruppe, usw. automatisch das Recht zu erteilen, auf ihrem Grundstück tätig zu werden. Dies sollte allerdings aus offensichtlichen Gründen nicht die Standardeinstellung sein.
      • Dem Spieler die Wahl geben, ob der Eingeladene berechtigt ist:
        • zu Bauen
        • zu Zerstören
        • Gegenstände auf dem Grundstück abzulegen – Spieler könnten sich durch das massenhafte Ablegen von Gegenständen reichsintern gegenseitig griefen, insbesondere während der Beta.
        • Gegenstände aufzuheben – Gleiches Spiel wie oben, nur anders herum.
      • Spielern, denen gewisse Rechte auf einem Grundstück eingeräumt wurden, mitteilen, sobald sich an diesen Berechtigungen etwas ändert.
    • Grundstücke auf Sicheren Inseln können nicht von anderen Spielern übernommen werden, es sei denn sie wurden aufgegeben oder werden von uns freigegeben.
    • Euer Grundstück bzw. eure Grundstücke werden auf einer Karte angezeigt. Dies geschieht zunächst in Form von schlichten Markierungen, gestaltet sich zukünftig jedoch deutlich komplexer, da sie Bestandteil des grundstückseigenen Verteidigungs– und Informationssystems sein werden.
    • Bei der Inbesitznahme eines Grundstücks erhaltet ihr eine Urkunde als Inventargegenstand. Sie kann nicht an andere Spieler weitergegeben, fallen gelassen, usw. werden.
      • Solltet ihr euer Grundstück an ein feindliches Reich verlieren, so behaltet ihr dennoch die Urkunde. Wechselt es später ins ursprüngliche Reich zurück, seid ihr auch automatisch wieder der Besitzer. Da ihr während der Beta 1 nur ein einziges Grundstück innerhalb eures Reiches besitzen dürft, müsstet ihr euer altes Grundstück erst aufgeben, um ein neues in Besitz nehmen zu können. Die Anzahl der Grundstücke, die ein Spieler gleichzeitig sein Eigen nennen darf, gehört definitiv zu den Werten, welche die Designer jederzeit spontan ändern können sollten.
      • Solltet ihr euer Grundstück aufgeben, verschwindet auch die Urkunde.
    • Die Grundstücksurkunde dient als UI-Element und bietet folgende Funktionen:
      • Grundstücksinformationen durch direkte Interaktion im Inventar.
      • Folgende Optionen im Kontextmenü der Urkunde:
        • Grundstücksinformationen anzeigen
        • Grundstück auf Karte anzeigen
        • Grundstück verwalten (Berechtigungen etc.)
        • Schnellreise zum Grundstück (für die Beta 1 und nur auf Sicheren Inseln)
        • Grundstück räumen (löscht sämtliche Blöcke)
        • Grundstück aufgeben (Eigentumsrecht verwirken)
        • Wir sollten die Bauwarteschlangen der Gebäude sowie die Reparaturoptionen ebenfalls in dieses Menü integrieren.
  • Inbesitznahme eines Grundstücks
    • Die Inbesitznahme eines herrenlosen Grundstücks sollte ein simpler Vorgang sein, den wir im Laufe der nächsten Monate ausarbeiten und dessen Zeitrahmen von den Designern einstellbar sein sollte. Für den Moment reicht es aus, wenn wir das derzeitige System weiterverwenden, aber diverse Einstellungen, wie den vorgesehenen Zeitrahmen einer Inbesitznahme, der *** hinzufügen.
  • Die erste Person – sofern zur Inbesitznahme eines Grundstücks qualifiziert –, die ein Grundstück betritt, ist innerhalb ihres Reiches die einzige, die dieses Grundstück für sich beanspruchen darf, solange der Vorgang der Inbesitznahme aktiv ist. Dies dient als Schutz vor Griefer-Gruppen, die versuchen, ihren eigenen Landsleuten Grundstücke vor der Nase wegzuschnappen. Die Prozedur und benötigte Zeit für die Inbesitznahme eines Grundstücks auf befreundetem Terrain werden sich von denen in umkämpften Gebieten bzw. bei der Einnahme eines Grundstücks, das einem feindlichen Spieler gehört, unterscheiden. Die folgenden Einstellungen sollten in die *** *** *** und/oder das Scripting verlegt werden.
    • Benötigte Zeit für die Inbesitznahme eine befreundeten Grundstücks – Dazu zählen die Sicheren Inseln eures Reiches.
    • Benötigte Zeit für die Inbesitznahme eines neutralen Grundstücks – Die Umkämpften Inseln sind neutral.
    • Benötigte Zeit für die Inbesitznahme eines feindlichen Grundstücks – Bedeutet, dass es sich in feindlichem Gebiet befindet.
    • Ein zusätzlicher Multiplikator für Grundstücke, die Spielern feindlicher Reiche gehören.
  • Spieler anderer Reiche können versuchen, den Wechsel des Grundstückseigentümers zu verlangsamen oder aufzuhalten, solange der Vorgang andauert.
    • Wenn sich Spieler zu Gruppen zusammenschließen, können sie die Inbesitznahme für jenen Spieler beschleunigen, der das Land gerade beanspruchen will. Damit das in der Beta 1 leicht von der Hand geht, werden die Leute im selben Kampftrupp sein müssen, um gemeinsam an der Beanspruchung eines Grundstücks zu arbeiten.

    • Anmerkungen von MJ: Das Eigentumsrecht an Grundstücken wird eines jener Systeme sein, die über die gesamte Lebensdauer des Spiels hinweg einer ständigen Nachjustierung bedürfen. Bei einem Spiel, wie dem unseren, das von dem Besitz, der Einnahme bzw. dem Bebauen von Grundstücken lebt, können wir es uns nicht leisten, dieses System zum Release zu vergeigen. Ohne dabei Namen zu nennen, erinnern wir uns doch alle an bestimmte Spiele, die aus Spielersicht sowohl kurz- als auch langfristig an Anziehungskraft verloren, weil sie am Erscheinungstag mit derartigen Problemen zu kämpfen hatten. Folglich spielt es keine Rolle, welches System wir für die Beta 1 einsetzen, denn es wird in keinster Weise dem endgültigen System des Spiels entsprechen. Wenn ihr euch also darüber Sorgen macht, ob das Beta 1- und das Releasesystem identisch sein werden, gilt wie üblich: „Keine Panik!“

    Wir werden außerdem sicherstellen müssen, dass der Prozess der Inbesitznahme von Ländereien nicht schlussendlich der internen Realm-Pride schadet. Einer unserer Ansätze diesbezüglich wird sein, einen ähnlichen Ansturm auf das verfügbare Land zu vermeiden, wie er in anderen Spielen vorkam. Das Eigentumsrecht wird nicht nach dem „Wer zuerst kommt, mahlt zuerst“-Prinzip funktionieren, da sich Spieler das Recht auf ein Grundstück im eigenen Reich erst einmal durch Taten verdienen müssen!

    Dieses Recht wird nicht allein von der Spielzeit abhängen, da eine solche Vorgehensweise den Leuten mit mehr Freizeit einen zu direkten Vorteil verschaffen würde. Vielmehr geht es darum, was ein Spieler in der ihm zur Verfügung stehenden Zeit alles erreicht. Jemand, der 4 Stunden spielt und eine Menge leistet, wird schneller an eine Urkunde kommen als jemand, der 8 Stunden spielt und nur herumsitzt und sich unterhält. Gleiches gilt auch für die Erweiterung der Urkunde. Anders sieht das Ganze im Grenzland aus: Dort können Spieler neutrale oder feindliche Gebiete in Besitz nehmen, ohne dafür eine Urkunde ihres Königs zu benötigen. Das hatten wir bereits zu Beginn der Kickstarter-Kampagne klar kommuniziert und verkörpert erneut unsere Entschlossenheit sowie unseren Willen, den Prinzipien und Zielen treu zu bleiben, die wir vor vier Jahren festgelegt haben.

    Dieses Dokument befasst sich natürlich hauptsächlich mit der Beta 1, weshalb Dinge wie Immobiliensteuern, Gebäudewartungskosten und andere Mechanismen, die Gold wieder aus dem Spiel nehmen sollen, weiterhin zur Debatte stehen. Darüber sprechen wir mit unseren Backern noch genauer, sobald wir uns mit der tatsächlichen Umsetzung befassen.

    Umkämpfte Insel(n)
  • Wir beginnen mit nur einer Umkämpften Insel und steigern dies dann im Verlauf der Beta 1. Siehe diesbezüglich auch den ************* weiter unten.
  • Die primäre Umkämpfte Insel sollte groß genug sein, um reichlich Gebäude und RvR zu ermöglichen, aber nicht so groß, dass Spieler 30 Minuten bis zur Front benötigen. Die endgültige Inselgröße sowie die Laufwege müssen wir noch anhand (design-)technischer Kriterien bzw. in Bezug auf Features wie dem ************* bestimmen. Ich könnte mich mit großen Inseln und langen Laufwegen anfreunden, sofern wir uns dazu entschlössen, die Inseln mit aktivierbaren Portalen zu bestücken, mittels derer die Leute bei Bedarf im Handumdrehen am Ort des Geschehens ankommen könnten.
  • Umkämpfte Inseln sind nicht rund um die Uhr online, sondern werden nur zu bestimmten Zeiten oder Events geöffnet. Dadurch sollen, wie bereits in früheren Kapiteln erwähnt, die AWS-Serverkosten überschaubar und die Ermüdungserscheinungen unserer Spieler gering gehalten werden.
  • Umkämpfte Inseln verfügen über ein begrenztes Kontingent an Grundstücken, die jedes Reich für sich beanspruchen kann. Für in Besitz genommene Grundstücke gelten die üblichen Regeln.
    • Mitglieder feindlicher Reiche können Blöcke bzw. Gebäude auf den Umkämpften Inseln zerstören und Grundstücke ihrer Widersacher einnehmen.
  • Auf den Umkämpften Inseln wird das erste Mal unsere Technologie zur Geländeanpassung zum Tragen kommen, wenn sich die Reichszugehörigkeit bestimmter Orte auf der Karte oder eines Grundstückes ändert. Dies könnte sich zu einer DREINGABE wandeln, falls es zu technischen Schwierigkeiten kommt.
  • Die erste Umkämpfte Insel wird nicht nur auf Schönheit ausgerichtet sein, sondern auf jene Art von Gameplay-Tests, die wir zu Beginn der Beta 1 durchführen wollen.
  • Auf den Umkämpften Inseln wird es eine Reihe verschiedener Portale geben, je nachdem von wo aus wir die Spieler starten lassen wollen. Diese sollten sich sowohl über ein Tabellendokument als auch über den Zonen-Editor einstellen lassen. Auch auf einer potenziellen Admin-Oberfläche sollte es entsprechende Optionen geben.

    • Anmerkungen von MJ: Diesem Kapitel kann ich eigentlich nicht viel hinzufügen, außer dass es noch jede Menge darüber zu erzählen gibt, was es mit dem „*************“ auf sich hat und was das Ganze für die Beta 1-Tests und unsere Backer bedeutet. Die Auflösung dieses Rätsels folgt in den kommenden Kapiteln. 😊 Bitte verzeiht, dass ich euch so auf die Folter spanne, aber die Bedeutung dieser vier kleinen Silben wird weit über die Beta 1-Testphase hinaus zu spüren sein!

    REDIGIERT

    da DREINGABE.

    Handwerk
  • Für die Beta 1 ist es entscheidend, dass sich das Handwerk nicht wie Arbeit anfühlt, insbesondere wegen dem regelmäßigen, testbedingten Zurücksetzen des Fortschritts. Den Designern werden deswegen wichtige Einstellungsmöglichkeiten bereitgestellt, damit sie alle Aspekte des Handwerkssystems bei Bedarf mühelos beschleunigen bzw. verlangsamen können. Wie groß diese Beschleunigung im Vergleich zur LIVE-Fassung ausfällt, wird von den jeweiligen Tests sowie deren Zielen bzw. Ergebnissen abhängen.
  • Zudem sollten die Designer festlegen können, wie viele Vox (im Plural unverändert, wohingegen eine Gruppe von Vox einen Chor bilden) ein Spieler maximal besitzen kann. Die Spieler sollten mit einer eigenen Vox beginnen, aber vorerst keine weiteren erlangen können. Platzieren sie ihre Vox in der Welt, so sollten sie auch die einzigen sein, die sie wieder aufheben können. Verlassen sie das Spiel, ohne ihre Vox aufzuheben, sollte diese aus dem Spiel verschwinden und in das Inventar des Spielers zurückkehren. Dadurch sollen Vox-Wälder, wie wir sie in früheren Tests erlebt haben, vermieden werden.
  • Sofern wir nicht das Dreingaben-Ziel einer eigenständigen Handwerkerklasse erreichen, wird das dazugehörige Handwerkssystem während der Beta 1 allen Spielern zugänglich sein.

    • Die Vox Magus

  • Das Aussehen der Vox muss für die Beta 1 überholt werden. Das Grundkonzept sollte zwar beibehalten werden, doch müssen wir sie fürs Spiel sowohl optisch als auch akustisch einfach interessanter gestalten.
  • Als Inventar-Icon der Vox Magus müssen wir etwas erstellen, das wie eine Box aussieht. Mir ist natürlich bewusst, dass es für die Spieler dann die Vox in der Box sein wird, aber das ist durchaus so beabsichtigt. 😊
  • Platziert ein Spieler diese Box in der Welt, so hätte ich für deren Verwandlung zur Vox gerne passende Animationen, Effekte und Geräusche. Diese sollten so richtig eindrucksvoll sein und für die Spieler bei gelungener Umsetzung zum Gesprächsthema #1 an der Kaffeemaschine werden. Die umgekehrten Animationen bzw. Effekte sollten beim Wiederaufnehmen der Vox abgespielt werden.
  • Hat sich die Vox vollständig entfaltet und nimmt ihren Betrieb auf, sollte sie durchgängig VFX und SFX abspielen.
    • Wie sich die Kristalle in der Vox bei bestimmten Aktionen der Spieler bzw. dem jeweiligen Handwerksvorgang verhalten, werde ich noch in einem gesonderten Dokument erläutern. Da es sich hierbei um einen essenziellen Bestandteil des gesamten Konzepts handelt, würde es an dieser Stelle den Rahmen sprengen.
    • Die Vox Magus sollte sich mehr nach Fantasy als nach Scifi anhören.
  • Wie bereits in der ursprünglichen Beta 1-Checkliste beschrieben, wäre eine Bedienung per Slash-Befehlen zwar denkbar, aber keinesfalls wünschenswert. Derzeit programmiert unser Backer und Mitglied des Mod Squads Mehuge eine coole Oberfläche, die Slash-Befehle überflüssig machen wird.
  • Auch wenn die Vox ausschließlich von ihrem Besitzer aufgehoben werden kann, so können sie andere Spieler dennoch beschädigen. Unter Umständen erlauben wir es auch Spielern anderer Reiche eine Vox zu stehlen, aber frühestens nach der Beta 1.

    • Gewinnung/Ernten/Sammeln

  • Vorkommen sollten zwar über die gesamte Welt verstreut, die Rohmaterialien des jeweiligen Reiches aber auch auf den Sicheren Inseln in ausreichender Menge vorhanden sein. Wir sollten die Leute nicht dazu zwingen, sich ihre Rohstoffe von mehreren Inseln zusammensuchen zu müssen. Das wäre während der Beta 1 dezent unlustig.
  • Die primäre Umkämpfte Insel sollte mit einigen besonderen Materialien aufwarten, damit es sich für die Spieler auch lohnt, sich dorthin zu wagen.
  • Spieler sollten sich einem Metall-, Holz-, Stein-, Leder-, Stoff- und eventuell Reagens-Vorkommen nähern und Rohstoffe extrahieren können.
    • Wir müssen festlegen, welche Rohstoffe zu Beginn der Beta 1 verfügbar sein werden.
    • Wir müssen Spitzhacken und alle weiteren benötigten Gegenstände hinzufügen, die der Spieler letztlich zum Abbauen von Rohstoffen auch ausgerüstet haben muss.
      • Die endgültige Liste muss zwar noch festgelegt werden, aber momentan reicht uns eine vereinfachte Liste aus Spitzhacke, Säge, usw.
    • Wir benötigen zu den jeweiligen Tätigkeiten passende Geräusche.
    • Wir benötigen zu den jeweiligen Tätigkeiten passende Animationen.
  • Während der Beta 1 sollten wir entweder das Gewicht sämtlicher Materialien reduzieren oder die Belastbarkeit bzw. Tragekapazität der Spieler erhöhen, damit diese unbekümmert craften und bauen können. Dies wird sich im Laufe der Betaphasen ändern und zunehmend dem angepeilten Zustand des LIVE-Spiels annähern. Auch diese Einstellungen sollten in die Haupttabelle bzw. *** *** *** verlegt werden.
  • Spieler sollten Rohstoffvorkommen schon von Weitem erkennen können.
  • Wir sollten Rohstoffvorkommen zu Rohstoffzentren zusammenfassen, damit die Spieler nicht unnötig danach suchen müssen. Bei der Konzipierung dieser Zentren bietet uns unser flexibles System jede Menge Möglichkeiten.
    • Zusätzlich zu den so gruppierten Vorkommen wäre es aber auch akzeptabel, wenn sich Bergbauvorkommen nahe Gebirgen befänden.
    • Man sollte bereits aus der Ferne eine Art Symbol sehen, das auf ein nahes Rohstoffzentrum hinweist.
  • Beim Extrahieren aus einem Rohstoffvorkommen sollten schlichte Animationen und Geräusche abgespielt werden, die wir auch für andere Vorkommenstypen einsetzen können.
  • Gesammelte Rohstoffe sollten im Spielerinventar als ein Stapel mit eigenem Icon, eigener Textbeschreibung (Roheisen, ungegerbtes Leder usw., je nach Art des Rohstoffes), Mengenangabe, und zusätzlichen Informationen beim Mouseover angezeigt werden. ANMERKUNG: An allen genannten Aufzählungspunkten wird derzeit bereits gearbeitet.
    • Die Gegenstandsbeschreibungen sollten in der Beta randvoll mit verwertbaren Informationen sein, auch wenn wir einige davon im fertigen Spiel schlussendlich ausblenden werden. Wie so vieles anderes in Bezug auf unser Spiel, haben wir unseren Backern versprochen, dass wir ihnen alle nötigen Informationen bereitstellen, damit sie uns während der verschiedenen Testphasen effizient bei der Fehlersuche und dem Testen des Spiels helfen können, auch wenn das LIVE-Spiel letztlich anderen Regeln folgen wird.

    • Aufbereitung

  • Hierbei handelt es sich lediglich um einen Platzhalter für eine kommende Version der Aufbereitung.
  • Spieler legen Materialien in die Vox Magus. Die Vox verarbeitet diese und gibt die aufbereiteten Materialien wieder aus.
  • Wie im Aufbereitungs-Dokument beschrieben, geschieht hin und wieder etwas unerwartetes. Für die Beta 1 sollten wir es unkompliziert angehen. Manchmal beschleunigt oder verlangsamt sich der Vorgang und manchmal erhöht sich der Ertrag an aufbereiteten Materialien.
    • Dass sich aus aufbereiteten Materialien auch Blöcke fürs Bauen herstellen lassen, ist zwar für die Beta 1 bestätigt, folgt derweil aber einem minimalistischen Ansatz. Das kann sich später ändern, doch für den Augenblick ist es wenig komplex.
  • Genau wie die anderen Elemente unseres Handwerkssystems soll auch das das Aufbereitungssystem während der Beta 1 nicht zum Zeitfresser werden.

    • Formung

  • Das Herstellen von Legierungen soll während der Beta 1 und darüber hinaus zu einem der interessantesten Aspekte unseres Handwerkssystems werden. Es wird zum jetzigen Zeitpunkt zwar noch nicht das vollständige „Eins + Eins = Irgendwas“-System umfassen, aber bereits Rezepte und Reagenzien beinhalten. Es wird dem angestrebten Design schon recht nahe kommen und besser sein, als wir es ursprünglich für die Beta 1 geplant hatten. Das ist einer der Aspekte, die mitunter aufgrund der Verzögerung reifen konnten.
  • Dank des Legierungs- bzw. Reagens-Systems stehen Spielern fast unbegrenzt viele Kombinationen zur Verfügung.
    • Während der Beta 1 können Spieler diverse Materialien zu Legierungen verbinden.
    • Um ihnen dabei zusätzliche Optionen zu bieten, wird es ihnen das System schon bei der Herstellung der Legierung erlauben, Reagenzien beizumischen.

    • Herstellung

  • Der Herstellungsschritt des Handwerkssystems wird in der Beta 1 absichtlich die unwichtigste Rolle spielen. Trotzdem wird es wegen der Verzögerung und dank des Fleißes unserer Programmierer leistungsstärker ausfallen, als ursprünglich geplant. Derzeit verfügen wir bereits über ein System, mit dem wir ein Schwert aus „Griff + Klinge“ erzeugen können. Da sich diese Regel einfach auf „Erzeuge eine Waffe aus einer Legierung“ ausweiten lässt, unterstützt es bereits die Funktionen, die wir zukünftig geplant haben. Falls wir uns dazu entscheiden, den Rezepten für Schwerter, Pfeile, oder ähnlichem bereits all die schicken Unterkomponenten zuzuweisen, sollten wir auch die für die Gegenstandseigenschaften verantwortlichen Skripte entsprechend anpassen.
    • Vernetzungs- und Gruppenbildungssysteme

    1. Übersicht

    Das Bilden von Gruppen und die Vernetzungssysteme sind wichtige Bestandteile eines jeden MMORPGs, ob sie nun Old School sind oder nicht. Während der Beta 1 werden wir uns auf gewisse Schlüsselelemente dieser Systeme konzentrieren und zugleich die Grundlagen dafür legen, im Verlauf der restlichen Beta eine noch weitaus ausgefeiltere Version zu implementieren. Wir wollen damit verdeutlichen, dass wir im Vergleich zu vielen unserer Vorgänger einiges anders machen, unserem Old School-Ethos dabei aber treu bleiben.

    2. Leitprinzipien

    Einem System gewisse Leitprinzipien vorzugeben ist eine Vorgehensweise, die MJ nun schon länger anwendet, als er gerne zugeben möchte. Sie hat ihm immer gut gedient und aus seiner ursprünglichen Vision für diesen Teil des Spiels sind ihm die folgenden Punkte die wichtigsten.

  • Charaktere können nur einer Gilde beitreten – Das sagten wir bereits während der Kickstarter-Kampagne, und daran müssen wir uns auch halten. MJ ist der Meinung, und das spiegelt sich auch in unzähligen Zuschriften bzw. Posts wieder, dass die Möglichkeit mehreren Gilden gleichzeitig beizutreten maßgeblich dazu beigetragen hat, dass Gilden in MMORPGs an Bedeutung verloren haben.
  • Wiederherstellung des Gildenstolzes – Ungeachtet der Größe eines Ordens, müssen wir dazu beitragen, dieses besondere Gefühl wiederherzustellen, das man als Teil eines erfolgreichen Ordens verspürt. Dabei geht es aber um mehr als das bloße Aushändigen von Belohnungen und Fortschrittsrängen. Wir müssen außerdem darauf achten bzw. verhindern, dass Einzelne etwa die Gildenbank ausräumen und so dem Gildenstolz schaden können.
  • Ob groß oder klein, ein jeder wird willkommen sein – Dieses Spiel kann nicht allein auf dem Prinzip von Mega-Gilden (wie es diverse andere Spiele getan haben) oder Gilden allein fußen, wenn wir dauerhaft neue Spieler anlocken und bei uns behalten wollen. Wir müssen anerkennen, dass manche unserer Spieler solo, manche in Kleingruppen mit Freunden und andere in Orden spielen wollen. Das müssen wir verstehen, fördern, und die Vorteile eines jeden Gruppentyps so maßschneidern, dass jeder seinen bevorzugten Spielstil genießen kann, sei es nun in der Gruppe oder alleine.
  • Auch unsere Inhalte müssen wir auf jegliche Ordensgrößen zuschneiden – Das hört sich nun vielleicht leicht an, ist es aber nicht. Beispielsweise können nicht alle coolen Sachen den größeren oder erfolgreicheren Orden vorbehalten sein. Weder können wir den größeren Orden einfach Vorteile geben, noch diese Vorteile für die kleinen Orden so schwer erreichbar machen, dass es sie frustriert. Die Größe sollte Relevanz haben, aber Hingabe und Durchhaltevermögen ebenso.
  • Ein reines RvR-Spiel muss einige Dinge anders handhaben als ein PvE basiertes Spiel und wir müssen das akzeptieren und uns zu eigen machen.
  • Wir müssen Ordensmitgliedern ein Gefühl der Zugehörigkeit vermitteln und eine heimatliche oder gar familiäre Atmosphäre erzeugen – Stattet Orden mit allen nötigen Werkzeugen aus, damit sich ihre Spieler optimal vernetzen können. Wenn euch das gelingt, werden die Leute von unserem Ordenssystem begeistert sein, auch wenn es weniger protzig ausfällt als vergleichbare Systeme.

    • 3. Gruppentypen

    Camelot Unchained wird mit fünf Gruppentypen veröffentlicht. Eine genaue Erläuterung zu jedem einzelnen findet ihr zwar weiter unten, doch werde ich sie nun vorab auflisten, damit ihr euch schon einmal mit den Namen vertraut machen könnt:

  • Einzelspieler – Wenn ihr euch nun fragt, was ein Einzelspieler-Konzept in einem Dokument über Gruppen zu suchen hat, dann erinnert euch einfach daran was MJ bereits vor Beginn der Kickstarter-Kampagne sagte: Wir wollen sowohl den Einzelspieler- als auch den Gruppen-Spielstil unterstützen.
  • Gefolgschaft – Stellt euch darunter Gruppen mit gewissen Vorzügen vor. Die mit Gruppen verbundenen Features zielen auf diejenigen Spieler ab, die zwar mit ihren Freunden zusammen spielen, jedoch nicht die Mühen einer Ordensgründung (Gilde) auf sich nehmen wollen.
  • Heer – Ein vorübergehender Zusammenschluss von Gefolgschaften, um im RvR gemeinsam zu agieren.
  • Orden – Die Primärgruppe in Camelot Unchained . Wir alle wissen um die bedeutende Stellung von Gilden während der vergangenen Jahrzehnte des MMORPG-Gamings. Ihre Zahl mag in der jüngeren Vergangenheit abgenommen haben, doch wir wollen diesen Trend in unserem Spiel wieder umkehren. Gilden waren in erheblichem Maße für den Erfolg von Dark Age of Camelot mitverantwortlich und bei WAR versuchten MJ und Mythic, sie durch das „Lebendige Gilden“-Konzept auf ein ganz neues Level zu hieven. Das hier ist zwar nicht WAR (welches übrigens pro Jahr so viel Geld verschlungen hat, wie uns hier insgesamt zur Verfügung steht), aber wir glauben, dass wir einige innovative Ideen und Förderungsfunktionen haben, die spannend für diejenigen sein werden, die wollen, dass Orden in Camelot Unchained eine tragende Rolle spielen.
  • Kampagne – Eine vorübergehende Allianz aus Gruppen, um Ziele mittels Missionen zu erreichen, die das Mitwirken mehrerer Gruppen und/oder einer Masse an Spielern aus dem eigenen Reich voraussetzen. ☺

    • 4. Was euch in der Beta 1 erwartet

    Während der Beta 1 konzentrieren wir uns auf einige Schlüsselelemente des Gruppenbildungs- und Vernetzungssystems: Gefolgschaften, Heere und Orden, sprich unseren Gegenstücken zu Gruppen, Raidgruppen und Gilden. Wie angekündigt, wird es sich bei der Umsetzung dieser Gruppentypen zu Beginn der Beta 1 um das Äquivalent eines „minimal überlebensfähigen Produktes“ handeln. Im weiteren Verlauf der Beta werden wir dann bestimmte Features für die Releasefassung des Spiels in Stein meißeln, aber das geschieht frühestens gegen Ende der Beta 3. Genießt in der Zwischenzeit die Reise, während der wir ein Gruppenbildungssystem zu erschaffen versuchen, dass in Sachen Nützlichkeit und Tiefe seinesgleichen sucht. Das werden wir tun, ohne dabei auf das Hinzufügen von massenhaft Features oder kosmetischer Kinkerlitzchen zurückzugreifen, sondern das System stattdessen auf die Bedürfnisse unserer Spieler maßschneidern. Wir werden dies umsetzen, indem wir es einfacher machen, koordinierte Angriffe im RvR durchzuführen. Dennoch werden wir die gesamte Bandbreite von Spielstilen abdecken, angefangen bei Solisten bis hin zu der Art von koordinierten Massenangriffen (keine Keeptrading-Zergs), die aus Camelot Unchained das nächste große RvR-MMORPG machen werden.

    5. Persönliche Features

    Hier gibt es so viel zu behandeln, dass wir uns nur auf diejenigen Features unserer Vernetzungssysteme konzentrieren werden, die auch auf alle Spieler zutreffen.

  • 5.1 Freunde / Feinde / Verbindungen / Blocklisten
    Wir sind doch alle Freunde hier, richtig? Nicht nur, dass es in Camelot Unchained eine Freundesliste geben wird, wir werden sogar Listen für Verbindungen, Feinde und eine Blockliste bieten.

    Die Freundesliste im Spiel ist zu einem Großteil selbsterklärend und ihr werdet jede Menge Möglichkeiten haben, die Liste mittels des nachfolgend erklärten Berechtigungssystems nach euren Vorstellungen zu gestalten.

    Die Feindesliste funktioniert prinzipiell wie eine Freundesliste, mit der Ausnahme, dass sie für Mitglieder eines gegnerischen Reiches gedacht ist. Doch damit nicht genug! Ihr werdet auch in der Lage sein, ganze Gegnergruppen in eure Feindesliste aufzunehmen. Ihr werdet zwar nicht in der Lage sein, mittels irgendeiner In-Game-Möglichkeiten Kontakt zum Feind aufzunehmen – sprich: ihr werdet nicht in der Lage sein, einem Gegner über diese Liste eine Private Nachricht oder Post zu schicken – jedoch werdet ihr anhand dieser Liste sehen können, wie oft ihr euren Widersacher bereits niedergestreckt habt – oder er euch. Ihr werdet auch sehen können, ob ihr euch gegenseitig auf die Feindesliste gesetzt habt und es wird deutlich leichter, ein Kopfgeld auf jemanden auszusetzen, wenn er sich auf eurer Feindesliste befindet. So wie auch bei der Freundesliste, werden die Spieler sehr viel Kontrolle über dieses Feature haben.

    Die Verbindungsliste wird euch beispielsweise anzeigen, mit welchen Spielern ihr euch in der Vergangenheit zusammengetan habt, oder wer auf eine andere Weise mit euch interagiert hat, egal ob es über einen Handel stattfand, oder ihr euch gemeinsam in die Schlacht gestürzt habt, uvm. Diese Liste kann dazu genutzt werden, dieses richtig guten Spieler wiederzufinden, mit dem ihr unlängst in einer Gruppe wart. Ihr könnt ihn anschließend auf eure Freundesliste setzen und ihn in eure Gefolgschaft oder euer Heer einladen, solltet ihr das bei eurem ersten Zusammentreffen vergessen haben. Dies spielt wunderbar in unser System der Tagesbelohnungen hinein und wird auch noch mit anderen Systemen interagieren.

    Die Blockliste erlaubt es euch, einen Spieler eures Reiches zu Blockieren. Auch hier sind wieder etliche Konfigurationsoptionen verfügbar. So könnt ihr ihren Text- und Sprachchat blockieren, ihre Pinnwandeinträge, oder überhaupt die gesamte Kommunikation zwischen euch unterbinden.
  • 5.2 Persönliches Schwarzes Brett
    Euer Schwarzes Brett ist der Ort, an dem ihr eure ganz persönlichen Berichte, Nachrichten, Texte, Bilder und Videos posten, sowie eine konsolidierte Fassung der Pinnwandeinträge anderer Spieler lesen und kommentieren könnt. Das Schwarze Brett wird es euch gestatten, Berichte und Einträge all eurer Freunde und aus jeder Gruppe, in der ihr Mitglied seid und die dieses Feature aktiviert hat, zu sehen.

  • 5.3 Persönliches Aktivitätenprotokoll
    Das Aktivitätenprotokoll eines Spielers enthält eine Zusammenfassung jener Aktivitäten, an denen der Spieler in der Vergangenheit teilgenommen hat. Um seine Bedienung zu erleichtern und gut durch die dargebotenen Informationen navigieren zu können, wird dieses Log sowohl durchsuch- als auch filterbar sein. Dieses Protokoll wird unter anderem folgendes beinhalten: bekämpfte Spieler, Kills, gefertigte Gegenstände, aufbereitete Materialien, gesammelte Rohstoffe und vieles mehr. Das persönliche Aktivitätenprotokoll kann sowohl öffentlich zur Schau gestellt, als auch nur für ein bestimmtes Publikum einsehbar gemacht werden. Standardmäßig ist diese Einstellung jedoch auf Privat gesetzt. Mehr zu unserem Berechtigungssystem findet ihr in der Rubrik „Gemeinsame Gruppenfeatures“.
  • 5.4 Persönlicher Posteingang
    Jeder Spieler wird über seinen eigenen persönlichen, spielinternen Posteingang verfügen, an den andere Spieler des selben Reiches Briefe verschicken können. Das Formatieren dieser Nachrichten wird insofern ähnlich funktionieren wie bei den Pinnwandeinträgen, als dass sie zusätzlich zum Text auch eingebettete Bilder und Videos enthalten können. Diese müssen jedoch von zugelassenen Quellen oder direkt aus der Screenshot-Funktion des Spielclients stammen. Briefe werden keine Anhänge enthalten und es wird nicht möglich sein, Geld, Gegenstände, oder Schokoplätzchen per Post zu versenden. Wenn ihr handeln wollt, so müsst ihr entweder einen Handelsvertrag aufsetzen oder den Handelspartner im Spiel treffen.

    Um dies noch einmal zu verdeutlichen: Es wird über keines der von CSE zur Verfügung gestellten Systeme möglich sein, mit Spielern anderer Reiche zu kommunizieren. Dies gilt auch für die Post. Ihr könnt Briefe ausschließlich an Angehörige eures Reiches auf dem selben Spielserver versenden.

    • 6. Gemeinsame Gruppenfeatures

    All unsere Beta 1-Gruppenbildungssysteme haben gewisse Vernetzungsfeatures gemeinsam. Damit sich die folgenden Informationen nicht in jeder Gruppentyp-Beschreibung wiederholen, werden sie hier gesondert gelistet.

  • 6.1 Berechtigungen und Berechtigungsverwaltung
    Verwendet von: Alle Gruppentypen
    Wir haben oft davon gesprochen, dass wir eine Flut an Informationen über das Spiel und seine Spieler über unsere API-Server veröffentlichen wollen. Camelot Unchained wird eine noch nie dagewesene Menge an Daten über Internet-Dienste zugänglich machen, über die Spieler und Entwickler von Drittanbieter-Software in der Lage sein werden, externe Inventar-Verwaltungswerkzeuge, detaillierte Statistiken und vieles mehr zur Verfügung zu stellen. Das geht sogar so weit, dass ihr in der Lage sein werdet, eurem Charakter Ausrüstungsgegenstände anzulegen, ohne selbst im Spiel eingeloggt zu sein. Diese Funktion ist bereits heute über unsere API verfügbar.

    Mit einem solchen Grad an Datenverfügbarkeit muss die Privatsphäre aller Spieler und Gruppen an absolut oberster Stelle stehen. Um diese zu gewährleisten, wird ein robustes Berechtigungssystem im Herzen von Camelot Unchaineds Vernetzungssystem-Technologie arbeiten.
  • 6.2 Gruppenränge
    Verwendet von: Alle Gruppentypen
    Um die Berechtigungsverwaltung für Untergruppen zu vereinfachen und anwenderfreundlicher zu gestalten, können Ränge erstellt werden, die direkt einem Berechtigungsschema zugewiesen sind. Jeder Gruppentyp kann eine große Anzahl an benutzerdefinierten Rängen erstellen (die genaue Anzahl wird von der Art der Gruppe abhängen). Jede Rangbezeichnung kann editiert werden und in manchen Fällen kann Personen, die einen bestimmten Rang bekleiden, ein Symbol oder anderes optisches Identifikationsmerkmal zugewiesen werden. Ränge können von jedem Gruppenmitglied editiert oder erstellt werden, das über die entsprechenden Berechtigungen verfügt.
  • 6.3 Chat
    Verwendet von: Alle Gruppentypen
    Was wäre Camelot Unchained eigentlich für ein MMO, wenn es nicht über einen Chat verfügen würde? Die Features, die hier zur Sprache kommen, werden darauf beschränkt sein, inwieweit sie mit Gruppen interagieren. Wie bei den meisten der Vernetzungssysteme, die wir für unser Spiel erstellen, wollen wir den Spielern hierbei so viel Kontrolle und Flexibilität geben, wie es uns möglich ist.

    Jede Gruppe wird standardmäßig über ihren eigenen privaten Textchat- als auch Voicechat-Kanal verfügen, sowie über die Möglichkeit, nach Bedarf weitere Chatkanäle zu erstellen. Üblicherweise sind diese Kanäle so gestaltet, dass automatisch alle Mitglieder der Gruppe auf sie zugreifen können. Dies kann jedoch von jedem Gruppenmitglied eines Rangs mit den entsprechenden Berechtigungen geändert werden. Gruppenränge können auch mit besonderen Chat-Berechtigungen ausgestattet werden, um ihnen die Moderation des Chats zu ermöglichen, zu bestimmen, wer sprechen darf und wer nicht uvm. Die Chat-Kanäle können so weit den Bedürfnissen einer Gruppe angepasst werden, dass in ihnen bestimmte Features, wie das Einbetten von Bildern/Videos in den Chat, explizit gestattet oder verboten werden können.

    Während ein einzelner Spieler in mehreren Textchat-Kanälen gleichzeitig aktiv sein kann, wird es ihm nicht möglich sein, mehrere Voicechat-Kanäle auf einmal zu betreten. Es ist uns ein Anliegen, den Zugang zum Sprachchat so einfach wie möglich zu gestalten. Dabei wird grundsätzlich jeder Textchat-Kanal einen zugehörigen Voicechat-Kanal unterstützen und jeder Spieler kann mit einem simplen Tastendruck diesen zugeordneten Sprachkanal betreten. Jedes der Gruppeninterfaces wird zudem über einen 1-Klick-Knopf verfügen, über den der Standard-Voicechat-Kanal der Gruppe betreten wird!
  • 6.4 Statistiken
    Verwendet von: Einzelspieler, Gefolgschaften (permanent), Orden, Kampagnen
    Sowohl um die Tagesbelohnungen auszugeben als auch um unsere internen Protokollsysteme zu füttern, werden wir alle wesentlichen Aktionen des Tages protokollieren, die von einem Spieler oder einer Gruppe durchgeführt wurden. Viele dieser Daten werden in unsere unterschiedlichen Gruppenbildungs-Systeme fließen, inklusive Einzelspielern, die als Ein-Mann Gruppe fungieren. Ebenso können und werden sie dazu benutzt werden, den Gruppenfortschritt zu ermöglichen, aber mehr dazu später.

    Jetzt haben wir also diese Unmengen an Daten, die verfolgt, aufgezeichnet und in unseren Datenbanken protokolliert werden. Wäre es da nicht toll, wenn man sie auch selbst sehen könnte? Oder man könnte eine tolle Website damit machen, vielleicht eine Art Herald, über den man sich die ganzen sexy Daten ansehen kann? Natürlich wäre es das! Nun, eben darum wird ein großer Teil dieser Daten über unsere API-Server öffentlich zugänglich gemacht. Wichtig ist dabei, zu verstehen, dass nicht alle dieser Daten gleichwertig behandelt werden können. Während wir also so manches direkt veröffentlichen können, so werden sensible Gameplay-Daten vermutlich erst verzögert verfügbar sein, um nicht in den aktuellen Spielverlauf einzugreifen. Zusätzlich könnten manche Daten, je nach Spieler- oder Gruppeneinstellung, auch redigiert werden.
  • 6.5 Wappen
    Verwendet von: Gefolgschaften (permanent), Orden
    Wie könnte man seine Gruppe besser repräsentieren als durch das Tragen ihres Wappens? Wappen können von Mitgliedern mit den entsprechenden Berechtigungen innerhalb des Vernetzungs-UIs entworfen werden. Dieses Wappen könnt ihr mittels bestimmter Umhänge, Wappenröcke und Schilde zur Schau stellen! Ihr wollt auch eure Burg dekorieren? Lasst euer Wappen in Form verschiedenster Banner und Flaggen überall auf eurem Grundstück wehen.

    Auf Gegenständen könnt ihr euer Wappen mit sämtlichen Dekorationen verschmischen, die ihr als Mitglied einer Gruppe erlangt habt. Beispielsweise könnt ihr einen Umhang und Wappenrock mit eurem Ordenswappen darauf tragen, während euer Schild die Insignien einer Gefolgschaft trägt. Unterschiedlichen Gruppen werden unterschiedliche Wappenstufen zur Verfügung stehen, je nachdem zu welchem Gruppentyp sie gehören. Orden (Gilden) werden hier die facettenreichsten Einstellungsmöglichkeiten haben, inklusive besonderen, von CSE in Auftrag gegebenen Arbeiten.
  • 6.6 Ehrungen & Errungenschaften
    Verwendet von: Gefolgschaften (permanent), Orden, Kampagnen
    Wer bekommt nicht gerne Einsen mit Sternchen? Sowohl Gruppen als auch Gruppenmitgliedern können diverse Ehrungen und Errungenschaften verliehen werden. Diese können aus verschiedensten Quellen stammen, wobei sich dieses Dokument auf die beschränken wird, die mit Gruppenbildung zusammenhängen.

    Ehrungen werden in der Form von Fahnenbändern und Wappenanpassungen erfolgen. Diese werden dann sowohl im spielinternen Profil des Spielers als auch auf der Statistikenseite des Spiels angezeigt, sofern dieser sein Profil auf öffentlich gestellt hat.

    Die Leitung einer Gruppe kann Ehrungen selbst erstellen und sie nach Belieben an Mitglieder verleihen. Nehmen wir beispielsweise an, eure Mitglieder haben sich richtig viel Mühe gegeben: Dann könnt ihr sie mit einer Eins mit Sternchen auf ihrem Wappen belohnen!

    Ehrungen und Errungenschaften können zudem durch die Erfüllung von Aufgaben innerhalb einer Kampagne verdient werden. Weitere Einzelheiten zu Kampagnen findet ihr im späteren Verlauf dieses Dokuments.
  • 6.7 Gruppeninterface-Features
    Verwendet von: Gefolgschaften (permanent), Orden, Kampagnen
    Kommunikation ist in jeder Gruppe, die gemeinsam irgendein Ziel erreichen will, lebensnotwendig, ungeachtet ihre Größe. Da reichen die Instant-Kommunikationsmethoden Texte oder Voicechat nicht aus, um sich mit einer Gruppe von Spielern zu koordinieren, von der vielleicht gar nicht alle gleichzeitig online sind. Um diesen zusätzlichen Kommunikationsbedarf zu decken, werden wir diverse UI-Features erschaffen.

    Gruppen werden über ein spielinternes Interface verfügen, das einem die üblichen Informationen wie Mitgliedernamen, Ränge, Berechtigungsverwaltung und andere administrative Werkzeuge anzeigt. Zudem wird jede Gruppe über eine Pinwand verfügen, an der Mitglieder mit den entsprechenden Berechtigungen Nachrichten für die Gruppe hinterlassen können. Wer einzelne Nachrichten sehen darf, kann ebenfalls über Berechtigungen geregelt werden. Da das UI des Spiels webbasiert ist, könnt ihr auch Bilder und Videos an die Pinwand heften, welche direkt im Spiel eingebettet und abgespielt werden können! Zudem können Mitglieder der Gruppe eure Posts kommentieren und eine Diskussion darüber führen. Ganz recht, im Prinzip gleicht es dem, was einige der großen Social Media-Seiten bieten, die jeder kennt.

    Gruppen werden Zugang zu privaten E-Mail-Listen haben, wodurch man E-Mails entweder an alle Mitglieder der Gruppe oder nur an bestimmte Ränge senden kann.

    Gruppen werden Zugang zu einem integrierten Kalender haben, mit dem sie Events planen können. Man kann diese Eventeinträge dann auch mit der dazugehörigen Diskussion verlinken. Wer ein Event sehen darf, kann vom Rang des Mitglieds abhängig gemacht werden.

    Das Gruppeninterface wird zudem über eine hervorragende Mitgliederkartei verfügen. In dieser Kartei wird man suchen, sortieren, und Spieler anhand bestimmter Kriterien, wie etwa Name, Rasse, Klasse, Dauer der Gruppenmitgliedschaft, Onlinezeit, geleisteter Beiträge und mehr filtern können.

    • Anmerkungen von MJ: Über die Vernetzungssysteme bzw. -features von Camelot Unchained zu sprechen, kann etwas heikel sein. Wir möchten uns auf die Features konzentrieren, welche die meisten unserer Spieler als förderlich für ihren Spielspaß empfinden werden, anstatt auf die, die wirken könnten, als gehörten sie zu einer völlig anderen Art Spiel. Wir sind der Meinung, dass sich dieser Fokus während der Beta 1 zunächst auf eine begrenzte Anzahl von Systemen (in diesem Fall drei) beschränken muss, die dann im Verlauf des gesamten Betaprozesses sukzessive um weitere Systeme ergänzt und verbessert werden. Zudem hoffen wir, wie so oft, dass wir die altbekannten und „oldschooligen“ Systeme, wie z.B. Gilden/Orden, um neue und/oder ergänzende Features erweitern können.

    7. Gefolgschaften

    Die Größe spielt in Vernetzungssystemen durchaus eine Rolle und bei den Gefolgschaften handelt es sich um unsere kleinste Gruppengröße. Sie sind allerdings mehr als bloße „Gruppen“, die bisher in MMORPGs lediglich einen vergänglichen Zusammenschluss von Spielern darstellten, den man wegwerfen konnte wie benutzte Taschentücher. Das geht in unserem Spiel zwar immer noch, doch sobald man ihnen einen Namen verleiht, werden sie permanent. Ihr könnt sie euch als semi-permanente Einsatztruppe, Freischar o. Ä. vorstellen, die etwas mehr mit Gilden gemein hat als mit den für MMORPGs üblichen Gruppenkonstrukten, dabei aber über fast keine der Vorteile von Gilden bzw. Orden verfügen, inklusive Dingen wie dem Besitz von Grundstücken. Das stellt aus vielerlei Gründen eine große Bereicherung für das Genre dar, weil es etwa für Spieler so einfach wie nie sein wird, sich mit diversen Freunden bzw. Reichsangehörigen zusammenzuschließen, ohne dabei jedes Mal eine neue Gruppe bzw. Gefolgschaft erstellen zu müssen. Zudem bedeutet es für die kompetitiven unter euch, dass nun selbst Gefolgschaften einen gewissen serverweiten Ruhm erlangen können, ohne dafür zwangsweise einer größeren Organisation wie einem Orden angehören zu müssen. Es ist wichtig, anzuerkennen, dass die Leute MMORPGs im Jahre 2017 und darüber hinaus anders spielen, als sie es noch 1999, 2001, 2004 usw. getan haben. Auch wenn wir also ein Spiel der alten Schule kreieren, so haben wir doch stets gesagt, dass wir auch neue Features hinzufügen werden, welche die Erfahrung des RvR insgesamt verbessern, ohne dabei das Genre „runterzudummen“ oder unnötiges Händchenhalten zu betreiben. Indem wir den Leuten ermöglichen, mit ihren Freunden und Familien Kleingruppen zu bilden und dafür auch noch Anerkennung zu erlangen, erfüllen wir alle diese Kriterien.

    Gefolgschaften sollten in der Beta 1, zusätzlich zu den zuvor genannten Punkten, über folgende Features verfügen:

  • Spieler können sowohl temporäre als auch permanente Versionen einer Gefolgschaft erstellen. Letztere müssen einen Namen tragen.
  • Die maximale Größe der Mitgliederkartei von permanenten Gefolgschaften wird auf eine Zahl begrenzt sein, die groß genug ist, damit spontaner Mitgliederschwund kein Problem ist, aber zu klein, um wirklich mit Orden mithalten zu können. Wie eingangs erwähnt, werden sie im Vergleich zu Orden auch weit weniger Vorteile genießen.
  • Gefolgschaften werden zu Beginn der Beta 1 bis zu 8 Spieler fassen. Wie bereits in diversen News erwähnt, werden wir mit verschiedenen maximalen Gruppengrößen experimentieren, bis wir – wie das gute Goldlöckchen bei ihrem Brei – sagen können: Die ist genau richtig!
  • Die Trefferpunkte und der Zustand aktiver Gefolgschaftsmitglieder wird in-game auf dem Bildschirm angezeigt werden und sich in Echtzeit aktualisieren. Wie schon häufiger erwähnt, werden wir dieses und andere UI-Features dazu einsetzen, den Spielern alle relevanten Informationen mitzuteilen, die sie benötigen, um uns beim Testen bzw. Debuggen des Spiels zu helfen. Es gibt jedoch keine Garantien, dass diese Features dauerhaft im Spiel verbleiben, insbesondere da wir uns nach Beginn der Beta 1 mit der sogenannten „Heilersicht“ auseinandersetzen werden.
  • Ein Spieler kann sich zwar mehreren Gefolgschaften anschließen, aber nur jeweils in einer aktiv sein. Der Aktivstatus dient gewissen Gameplay-Mechaniken: Aktive Spieler werden im Gefolgschafts-UI-Widget auch als Teil der Gruppe angezeigt, wodurch ihre Trefferpunkte sowie ihr Zustand in Echtzeit an die Gruppe übermittelt werden und Fähigkeiten- bzw. Gruppeneffekte anfangen auf sie zu wirken. Als ein „inaktives“ Mitglied einer Gefolgschaft kann man weiterhin am Chat der Gefolgschaft teilhaben bzw. -nehmen und sich in jeder beliebigen Gefolgschaft, der man angehört, auf aktiv schalten, sofern diese einen Platz frei hat.

    • Anmerkungen von MJ: Die Möglichkeit Gefolgschaften dauerhaft aufrechtzuerhalten ist für unsere Spieler eine wichtige Neuerung. Sollten wir damit recht haben, dass wir die ersten mit solch einem Feature wären (bitte lasst es uns wissen, falls uns ein anderes MMORPG zuvor gekommen ist), gehen wir davon aus, dass es uns bald andere Studios bzw. Spiele gleichtun. Bei einem Spiel wie dem unseren brauchen wir zu Release ein Gefolgschaftssystem, das den Spielspaß unserer Spieler fördert und erhöht.

    8. Heere

    Bei Heeren handelt es sich um unsere Fassung typischer MMORPG- „Raidgruppen“ für Camelot Unchained. Ein Heer besteht aus einer unbegrenzten Anzahl von Gefolgschaften. Im Gegensatz zu Gefolgschaften können sie allerdings keine Permanenz erlangen: Sie existieren allein als Organisationshilfe für den vorübergehenden Zusammenschluss von Gefolgschaften.

    Heere dienen in Camelot Unchained dazu, größeren Gruppen von Spielern, egal ob sie sich einander über andere Gruppentypen nahestehen oder nicht, einen gemeinsamen (Voice-)Chat sowie Werkzeuge zur Berechtigungsverwaltung zu geben.

    Heere können temporäre Gefolgschaften gründen und verwalten, um so auch Spieler unterbringen zu können, die nicht bereits als aktives Mitglied einer Gefolgschaft dazustoßen.

    Zu den Heeres-Features der Beta 1 zählen:

  • Spieler können ein Heer erstellen.
  • Es können unbegrenzt viele Gefolgschaften in ein Heer eingeladen werden.
  • Wir werden ein Heeres-UI implementieren, das – mindestens – den Namen des Heeres sowie die Namen der angeschlossenen Gefolgschaften und ihrer Mitglieder anzeigt.
  • Chat, wie unter dem Eintrag zu den Gemeinsamen Gruppenfeatures beschrieben.
  • Vereinfachtes Ranglistensystem.

    • Anmerkungen von MJ: „Raids“, wie man sie üblicherweise im MMO-Genre nennt, gibt es in Camelot Unchained nicht, da sich unser Spiel ausschließlich ums „raiden“ feindlicher Ländereien dreht. Dementsprechend brauchen wir eine effektive Methode, mit der die Leute auch in größeren Verbänden als einer Gefolgschaft kommunizieren können. Die Art wie wir es umsetzen sowie der Vernetzungsgrad unserer Spieler und unserer Gruppentypen wird dazu beitragen, unsere Vernetzungssysteme von denen der meisten anderen MMORPGs abzuheben, insbesondere der älteren, auf die wir gemeinhin wohlwollend zurückblicken. Schließlich betonten wir stets, dass wir zwar ein Spiel der alten Schule machen wollen, uns dabei aber durchaus auch bei den Features moderner Spiele bedienen werden, wenn sie unseren Spielern einen Mehrwert und zusätzlichen Spielspaß bieten.

    9. Orden (a.k.a. Gilden)

    Die Orden von Camelot Unchained ähneln den Gilden anderer MMORPGs. Ein Orden ist ein Zusammenschluss von Spielern, der unter anderem seine eigenen permanenten Gefolgschaften erstellen und verwalten kann. Für die Beta 1 befinden sich Orden allerdings auf dem Pfad eines „minimal überlebensfähigen Produktes“, da sie zu diesem Entwicklungszeitpunkt weit weniger wichtig sind als die anderen Gruppentypen. Andererseits wissen wir natürlich, dass wir schon einmal das Fundament für das legen müssen, was im späteren Verlauf der Beta 1 relevant wird. Gilden waren in großem Maße für den Erfolg früherer MMORPGs verantwortlich und obwohl wir nicht davon ausgehen, dass sie heute noch den selben Stellenwert wie damals erreichen werden, bedeutet das nicht, dass wir sie nicht mit einem ausgefeilten System unterstützen wollen. Was wir, sobald wir mit den Einzelheiten zum Ordenssystem an euch herantreten, erreichen wollen, ist, dass uns die Gilden-Fans da draußen ansehen und sagen: „Gut gemacht, Schwein. Gut gemacht.“ [Anm. d. Übersetzers: Schweinchen Babe Filmzitat] Aber wie gesagt, in die Beta 1 starten wir mit einem MVP was Orden betrifft.

    Orden sollten in der Beta 1 über folgende Features verfügen:

  • Spieler können einen Orden gründen.
  • Die Mitgliederzahl eines Ordens wird begrenzt sein. Über die genaue Obergrenze wird zusammen mit einigen anderen Überraschungen erst später entschieden.
  • Der Ordensname wird gemeinsam mit dem Charakternamen angezeigt.
  • Ein Spieler kann nur einem einzigen Orden beitreten.
  • Chat, wie unter dem Eintrag zu den Gemeinsamen Gruppenfeatures beschrieben.
  • Ränge haben sowohl eine symbolische als auch eine optische Bedeutung für Spieler, da sie von physischen Gegenständen begleitet werden, die anzeigen, welchen Rang sie innehaben.

    • Nun gut, das klingt jetzt alles gar nicht so spannend, oder? Nicht wirklich, aber vergesst nicht, dass die Orden in der Beta 1 das minimalst überlebensfähige von unseren minimal überlebensfähigen Produkten ist. Da wir euch Backer aber so sehr lieben und weil wir verhindern wollen, dass sich Leute mit brennenden Fackeln vor unserem Studio versammeln und „Bringt uns die Köpfe von JB und MJ!“ rufen, werden wir euch noch ein paar zusätzliche Infos darüber spendieren, wie es im Verlauf der Beta mit den Orden weitergeht.

  • 9.1 Vorteile
    Zu den Vorteilen einer Mitgliedschaft in einem Orden zählen:
    • Grundstücke – Orden, die eine bestimmte Stufe erreicht haben, können Grundstücke beanspruchen. Im Vergleich zu anderen Gruppentypen, handelt es sich hierbei um die größten Grundstücke, die zudem mit den meisten kosmetischen Optionen aufwarten.
    • Banken – Gildenbanken waren schon in anderen MMORPGs nützlich, aber zuweilen auch problematisch. Hier müssen wir ein besseres System entwickeln.
    • Läden – Orden können sowohl für ihre eigenen Mitglieder als auch für Außenstehende Läden eröffnen.
    • Ordenswappen – Siehe oben.
    • Fortschrittssystem – Wir wollen hier zwar noch keine Einzelheiten preisgeben, doch das Fortschrittssystem für Orden wird dem der Einzelspieler ähneln. Hierzu versteckt sich ein Hinweis in den Leitprinzipien.
    • Karawanenstraßen – Orden können, abhängig vom Umfang der Lieferung, Einzelpersonen oder Karawanenführer damit beauftragen, ihnen Versorgungsgüter mittels Karawane zu liefern.
    • Kleidung – Orden sollten ihre eigene Kleidung entwerfen und beim Ordensregistrar des Reiches eintragen lassen können. Um jedoch ein solches Kleidungsabzeichen registrieren zu können, muss der Orden eine gewisse Stufe im Spiel erreicht haben und das Abzeichen sich von allen bestehenden unterscheiden.
    • Ordenshalle – Weitere Einzelheiten hierzu erhaltet ihr während der Beta
    • Kalender – Erklärt sich von selbst, oder?
    • Private E-Mails – Das ebenso.

    • Aber moment, es gibt noch mehr, und zwar jede Menge! Allerdings werden wir unsere Plappermäuler vorerst halten, da die Nachbarn große Ohren haben und sich auch nicht davor scheuen, Monate oder gar Jahre nach unseren Ankündigungen plötzlich zu behaupten, sie hätten es erfunden. Andererseits glaube ich, dass unsere bisherigen Enthüllungen klar unseren Willen demonstrieren, sicherzustellen, dass Gilden bzw. Orden eine wichtige Stellung in Camelot Unchained einnehmen werden, jetzt und für immer. Aber lasst es euch gesagt sein: Wir haben noch einiges auf Lager, das die Leute überraschen wird und unserem geplanten Ordenssystem einen Platz unter den interessantesten Systemen der MMORPG-Geschichte sichern wird, ohne dass wir dafür all die kosmetischen Kinkerlitzchen usw. auffahren müssen, die man in Spielen mit deutlich höherem Budget gesehen hat.

    Anmerkungen von MJ: Wie oben erwähnt, werden wir den Orden im Verlauf der Beta noch jede Menge Aufmerksamkeit schenken. Wir mögen zwar nicht die Mittel haben, um ein System zu erschaffen, dass sich mit den besten des Genres messen kann, aber dafür wird es auf unser RvR-fokussiertes Spiel maßgeschneidert sein. Unsere entsprechenden Pläne werden wir dann im weiteren Verlauf der Beta 1 mit euch besprechen, doch für den Moment sei einfach noch einmal betont, dass wir hier mit einem MVP in die Beta starten, das mehr als Dreingabe betrachtet werden sollte.

    10. Kampagnen (nicht zu Beginn der Beta 1)

    Auch wenn Kampagnen zu Beginn nicht Teil der Beta 1 sein werden, so wollen wir sie dennoch in diesem Dokument vorstellen, um ein vollständigeres Bild der Gruppenbildungssysteme von Camelot Unchained zu vermitteln.

    Bei Kampagnen handelt es sich um ein eigens für Camelot Unchained entworfenes, neuartiges System. Eine Kampagne ist ein vorübergehender Zusammenschluss von Spielern, die gemeinsam ein oder mehrere Ziele erreichen wollen. Sie sind eine flexible Gruppe, der Mitglieder aller anderen permanenten Gruppentypen beitreten können. Dazu zählen Einzelspieler, Gefolgschaften und Orden. Kampagnen dienen dazu, um Ziele mittels Missionen zu erreichen, die das Mitwirken mehrerer Gruppen und/oder einer Masse an Spielern aus dem eigenen Reich voraussetzen.

    Man kann eine Kampagne starten, um groß angelegte Kriege auszufechten, Belagerungen durchzuführen oder gewaltige Burgen zu errichten. Darüber hinaus kann man sie auch für einfache Zwecke verwenden: Etwa könnte sich eine Gruppe von Freunden zum gemeinsamen Gegenstände herstellen zusammenschließen und mithilfe der Kampagne ihre jeweiligen Ziele im Auge behalten und vielleicht sogar etwas gesunde Wettkampfatmosphäre aufkommen lassen. Sie wurden dazu entworfen, um die Kooperation im eigenen Reich zu fördern, um sowohl vom Spiel als auch von Spielern erstellte Zusatzinhalte zu ermöglichen und dabei Spielerorganisationen sichere, ins Spiel eingebaute Features zur Verfügung zu stellen. Außerdem werden sie es den Anführern einer Kampagne erlauben, große Mengen an Ressourcen, Waffen, Burgen und Belagerungsgerät als Leihgaben für große Events bereitzustellen. Dadurch müssen sie ihre Güter nicht auf „Vertrauensbasis“ an andere Spieler weitergeben, sondern bekommen sie garantiert zurück.

  • 10.1 Bildung
    Kampagnen werden von Spielern erstellt, indem sie in der Hauptstadt mit einem NSC reden, um die Kampagne einzutragen. Untrennbar mit der Erstellung einer Kampagne verbunden sind gewisse Kosten, das Festlegen eines Startdatums, einer Dauer und die Wahl der Sichtbarkeit (entweder öffentlich oder privat).

    Eine öffentliche Kampagne ist für alle Mitglieder des Reiches sichtbar und kann von ihnen ohne Einladung betreten werden. Eine private Kampagne wird hingegen nicht gelistet sein und Einladungen müssen einzeln erfolgen und/oder von der Kampagnenführung abgesegnet werden.
  • 10.2 Güter, Grundstücke, und Berechtigungen
    Eine Kampagne kann zwar niemals selbst Güter besitzen, wohl aber deren Nutzung vorübergehend regeln, solange sie existiert. Dazu werden Grundstücke, die Bauwerke darauf sowie große Gegenstände wie etwa Belagerungsausrüstung zählen.

    Wer zur Verwendung des geliehenen Eigentums berechtigt ist, kann über die Ränge innerhalb der Kampagne geregelt werden.

    Sobald eine Kampagne abgeschlossen ist, gehen alle von der Kampagne verwendeten Güter und Grundstücke an ihre ursprünglichen Besitzer zurück. Dazu zählen allerdings keine Einweg-Gegenstände wie etwa Schwerter, Rüstungen, Pfeile usw. Diese Art von Einweg-Gegenständen werden im Besitz der Spieler verbleiben, an die sie während der Kampagne ausgehändigt wurden. Aus diesem Grund haben wir das Konzept eines Kampagnenladens samt Währung erdacht, die wir zu einem späteren Zeitpunkt näher besprechen werden und mithilfe derer solche Gegenstände sicher verteilt werden können.
  • 10.3 Ränge
    Wie bei den anderen Gruppentypen, kann man auch in einer Kampagne eigene Ränge mit klar definierten Berechtigungen erstellen und Mitgliedern zuweisen. Ränge können entweder einer ganzen Gruppe oder einzelnen Mitgliedern zugewiesen werden.
  • 10.4 Missionen & Aufträge!
    Die Feldherren einer Kampagne können Missionen für Spieler erstellen und für den Abschluss und/oder die Teilnahme an einer solchen Mission Belohnungen ausgeben. Eine Kampagne kann eine oder mehrere Missionen gleichzeitig umfassen und auf eine Mission, die eine Abschlusskondition aufweist, kann nach dem Abschluss eine Folgemission folgen, wodurch sich eine Missionskette erstellen lässt. Es wird viele verschiedene Arten von Missionen geben, die von einer Kampagne konfiguriert und angeboten werden können, doch welche das sind, wollen wir an dieser Stelle noch nicht verraten.
  • 10.5 Währung, Fortschritt & Läden
    Üb diese einzigartigen Features eines einzigartigen Systems erfahrt ihr mehr während der Beta 1.
  • 10.6 Belohnungen, Ehrungen & Trophäen
    Bei all dem Gerede über Missionen müssen wir noch klären, was man für deren Abschluss eigentlich bekommt!? Den Feldherren einer Kampagne wird es möglich sein, alle möglichen Belohnungen für den Abschluss von Missionen oder die allgemeine Teilnahme an einer Kampagne auszugeben. Weitere Einzelheiten hierzu erfahrt ihr im Verlauf der Beta.

    • 11. Gruppen-FAQ

    Um einigen unausweichlichen Fragen zuvorzukommen:

  • „Kann ein Orden eine permanente Gefolgschaft erstellen und darin Leute aufnehmen, die keine Ordensmitglieder sind?“ Ja.
  • „Können diese Externen der Gefolgschaft auch permanent beitreten?“ Ja.
  • „Kann ein Spieler der Eigentümer mehrerer Gefolgschaften sein?“ Ja.
  • „Wird das Erstellen einer Gruppe etwas kosten?“ Nicht während der Beta 1.
  • „Muss man mit einem NSC sprechen, um einen dieser Gruppentypen zu erstellen?“ Nicht während der Beta 1.
  • „Habt ihr vor das Ganze mit Facebook, Twitter und anderen sozialen Netzwerken zu verknüpfen?“ Derartiges steht derzeit nicht auf unserer Agenda.
  • „Kann ich mehreren Orden beitreten?“ Nein. MJ vertritt die Ansicht, dass dies in modernen MMORPGS maßgeblich dazu beigetragen hat, den Reiz von Gilden zu schmälern und somit zu entwerten.
  • „Angenommen mein Orden heißt „Die arturischen Ritter von Camelot“, kann ich Leute davon abhalten, das Wort „Ritter“ in ihren Ordensnamen zu verwenden?“ Nein. Sofern ihr diesen Ordensnamen im Vorfeld reserviert habt, wird ihn niemand anders für Gefolgschaften oder Orden verwenden können, doch das gilt nicht für die einzelnen Begriffe im Namen. Auf diese Weise könnt ihr zwar euren vollständigen Ordensnamen schützen lassen, die darin vorkommenden Worte aber trotzdem noch von anderen Spielern für andere Namen verwendet werden. Andernfalls gäbe es nur ein unnötiges Wettrennen um bestimmte Worte. :)
  • „Angenommen ich reserviere einen Ordensnamen, kann ich Leute davon abhalten, ihn durch minimale Abänderungen nachzuahmen? Ein Beispiel wäre etwa Das Syndikat und Das Sindikat?“ Ja. Das ist dann zwar ein Fall für die Kundenbetreuung, aber grundsätzlich werden wir so etwas nicht dulden. Der Schutz reservierter Namen erstreckt sich allerdings nicht auf Abkürzungen, Leetspeak, usw.
  • „Werden Spieler zügig zwischen Gefolgschaften wechseln können, um sich in der Schlacht einen taktischen Vorteil zu verschaffen?“ Nein, das wäre viel zu leicht und zuviel Händchenhalten für uns.

    • 12. Abschließende Gedanken

    Wie eingangs erwähnt, handelt es sich bei diesem Dokument nicht um die finale Fassung und es gibt keine Garantie, dass es alle Features in die Releaseversion von Camelot Unchained schaffen werden. Während der Betatestphasen werden durchweg Änderungen vorgenommen werden. Uns mögen die Mittel der meisten MMORPGs fehlen, doch sind wir dennoch dazu in der Lage, ein richtig gutes und robustes System mit wenig Aufwand zu entwickeln, zumindest wenn man den Aufwand mit den anderen Dingen vergleicht, die wir für dieses Spiel erschaffen. Und wenn auch sonst nichts dabei rumkommen mag, werden uns die Slash-Befehle zumindest erlauben, diese Funktionen früher ins Spiel zu bringen und zahlreichen Spielern ein „Deja-Who?“-Erlebnis zu bescheren. ☺

    P.S.: Vergesst nicht dem Mann mit dem coolsten Namen in der Spielebranche, Mr. James Brown (damit meine ich natürlich JB), zu danken, der dieses Dokument nicht nur verfasst hat (während ich es lediglich aufbereitet und etwas ausgeschmückt habe), sondern auch für das Design dieser Systeme verantwortlich ist. Bald folgen weitere!

    Überblick - Das Betatesten und der Drachenzirkel
  • Hier geben wir einen Überblick über die Dinge, auf die sich unsere Testdurchläufe während der Beta 1 (und darüber hinaus) konzentrieren werden, sowohl was die Hintergrundgeschichte des Spiels als auch einige Systeme und Mechaniken angeht, mit deren Hilfe wir in – und durch – die Beta 1-Testphase kommen werden.
  • Welche Spielelemente die Beta 1 genau umfassen würde, ließen wir gegenüber unseren Backern bisher stets absichtlich etwas offen. Dieses „absichtlich“ betonten wir auch regelmäßig (weswegen die folgende Aussage also niemanden überraschen sollte), damit wir unter anderem sicherstellen konnten, dass wir nichts versprechen, was wir nicht einhalten können. Angesichts der bisherigen Verzögerungen bei der Entwicklung des Spiels, wollten wir uns nicht in eine Lage manövrieren, in der wir unsere Ambitionen für die Beta 1 herunterfahren müssen, um deren Start zu beschleunigen. Zudem gab es noch andere wichtige Gründe, wieso wir diverse Dinge für uns behalten wollten.
  • Wie unseren Backern bekannt sein dürfte, befindet sich das Team seit einigen Wochen in einem Sprint bzw. Push, mit dem die Fertigstellung einiger benötigter Elemente beschleunigt werden soll, die wir in den folgenden Kapiteln dieses Dokuments vorstellen werden. Diese Arbeiten gehen gut voran und sind inzwischen weit genug fortgeschritten, um sie ruhigen Gewissens mit unseren Backern besprechen zu können.
  • In den Pre-Alpha-Tests drehte sich alles um ein kleines Areal mit jeder Menge spaßigem Gameplay. Ein derartiges Gebiet und eine derartig unterhaltsame Erfahrung hatten wir nicht mehr, seit wir diese Phase verlassen und die Neu-Befähigung begonnen haben. Dies muss sich während der Beta (insbesondere der Beta 1) wieder ändern. Nicht nur, um die Geduld unserer derzeitigen Backer zu entlohnen und ihr Vertrauen in uns wiederherzustellen, sondern auch, um mehr Leute zum Mittesten zu ermuntern. Auf diese Weise können wir uns einerseits bei unseren Backern bedanken und unsere Systeme andererseits einer höheren Belastung aussetzen, was sowohl die Technik als auch das Design angeht.
  • Als Teil des Betatestprozesses werden wir den Spielern einige hochspezialisierte Testbereiche/-inseln/-spiele präsentieren. Entworfen werden sie anhand der Hintergrundgeschichte über den “Drachenzirkel“, der unsere Version der Olympischen Spiele darstellt. Widmet euch für weiterführende Informationen der entsprechenden Becoming™-Geschichte (erscheint bald) bzw. den nachfolgenden Kapiteln.
  • Während der Beta 1 sollten zwar an jedem Wochenende Tests stattfinden, doch ändern wir dafür unsere bisherige Vorgehensweise. Um sowohl Kosten einzusparen als auch das Team zu entlasten, werden die Testserver nicht mehr rund um die Uhr laufen, sondern zu bestimmten Zeitfenstern an Sams- und Sonntagen. Ergänzend kann es bei Bedarf auch Werktags zu Fokustests kommen, insbesondere je näher die Beta 2 rückt. Wie bereits in anderen Abschnitten dieses Dokuments erwähnt, bilden die Bauzonen hier eine Ausnahme. Diese könnten wir öfter und länger zugänglich machen.
    • Natürlich bleiben wir unserem Prinzip treu, unsere europäischen Brüder und Schwestern niemals als Bürger zweiter Klasse zu behandeln und werden dafür Sorge tragen, dass die Tests auch „ihren“ Samstagabend umfassen und nicht nur den nordamerikanischen. Zudem werden wir manche Tests auf europäischen Cloudservern abhalten.
  • Mindestens einmal im Monat brauchen wir einen „Schrotte den Client“-Test mit ARCs und Backern, um sicherzustellen, dass sich im vergangenen Monat keine unerwünschten Fehler in die Codebasis eingeschlichen haben. Um die größtmögliche Spieleranzahl zu gewährleisten, werden diese Tests meist am Wochenende stattfinden. Wir könnten sie zwar ausschließlich mit ARCs durchführen, doch am effektivsten ist es, wenn die Spieler auch mithelfen, insbesondere wenn wir irgendwann verkünden wollen, dass 2000 echte Spieler an einer Schlacht teilgenommen haben.
    • Auch Werktags sollten wir einmal pro Woche in der Lage sein, einen „Schrotte den Client“-Test ausschließlich mit ARCs durchzuführen, um die Wahrscheinlichkeit zu minimieren, dass wir gravierende Fehler erst am Wochenende finden.
  • Nimmt ein Spieler an unseren Betatests teil, so sollte dies in seinem Account vermerkt und für uns leicht einsehbar sein. Wir wollen so viele Informationen wie möglich. Was wir genau brauchen, muss zwar noch bestimmt werden, doch von einem (klassenunabhängigen) Meta-Standpunkt aus gesehen, sollten wir die folgenden Informationen erfassen können:
    • An wie vielen Tests hat der Spieler teilgenommen?
    • Welche Tests waren das?
    • Wie lange hat er jeweils teilgenommen?
    • Wie viele Aktionen hat er durchgeführt?
  • Anhand derartiger Informationen werden wir Spieler für ihre Mithilfe während der Beta 1 belohnen. (Das Protokollsystem und die andern Werkzeuge, die Ben und ich zum balancen des Spiels und der Klassen benötigen, werden nicht von diesem Teil des Dokuments erfasst, sind für die Beta 1 aber ebenfalls erforderlich.) Diese Belohnungen werden sowohl temporäre als auch permanente kosmetische Gegenstände, Upgrades des Backerpakets bis hin zu Barauszahlungen umfassen. Natürlich werden einem die während der Beta verdienten Gegenstände weder Spielvorteile bescheren, noch werden sie zu Release oder später in irgendeiner Form von Cash-Shop für Camelot Unchained angeboten werden. Diese Belohnungen sind eine der Möglichkeiten, wie wir unseren Backern dafür danken können, dass sie uns dabei helfen, Camelot Unchained releasefertig zu machen.

    • Anmerkungen von MJ: Dieses Kapitel mag zwar relativ kurz ausfallen, doch zählt es mitunter zu den wichtigsten in diesem Dokument. Auf den hier besprochenen Prinzipien fußen ein Großteil der Aktivitäten, an denen Spieler während weiter Strecken der Beta 1 teilnehmen können werden. Wir haben uns vor langer Zeit dazu entschieden, den Spielern in der Beta einen höheren Spaßquotienten zu bieten als sie vielleicht vermuten würden, insbesondere nach einer derartigen Alpha. Wie wichtig es für den Erfolg dieses Spiels sein würde, während des gesamten Betaprozesses so viel Spielerfeedback und -input wie möglich zu sammeln, betonten wir bereits vor Beginn der Kickstarter-Kampagne. Viele andere Studios hatten mit dieser Vorgehensweise wenig Erfolg, solange ihre Spiele noch nicht feature-complete, soll heißen inhaltlich nahezu vollständig, waren. Wir sind definitiv noch nicht feature-complete und etwas anderes haben wir auch nie behauptet. Deswegen müssen wir uns deutlich cleverer anstellen und uns mehr Mühe im Umgang mit unseren Backern geben, um sie zur Teilnahme an unseren spaßigen Tests zu ermuntern. Wie wir das genau anstellen wollen, beschreiben die folgenden zwei Kapitel. Das wichtigste Leitprinzip für die Beta 1 ist und bleibt aber unsere Bereitschaft dazu, uns zusätzlich ins Zeug zu legen, um unsere Backer für ihre Geduld, ihr Verständnis und ihre Unterstützung zu entlohnen – und genau das machen wir auch.

    Der Drachenzirkel
    Dragon Circle
  • Beim Drachenzirkel handelt es sich um eine storybasierte Idee, die alle unsere Testbereiche in der Beta miteinander verbinden soll. Sie sollte nur einen minimalen Mehraufwand für das Programmiererteam im Vorfeld der Beta 1 bedeuten. Die Kurzfassung (für diejenigen, die gleich zum nächsten Kapitel übergehen wollen) ist, dass der Drachenzirkel eine Mischung aus der Olympiade und den Hunger Games ist, die im Prinzip ein storybasiertes „Kostüm“ für unsere Beta 1-Tests darstellt.
  • Wir werden den Spielern eine Reihe von Gebieten, Arenen und Szenarien zur Verfügung stellen. Die Tatsache, dass sie sich hervorragend in die Story des Spiels einfügen lassen, soll aber nicht davon ablenken, dass ihr Hauptziel das Testen der verschiedenen Aspekte des Spiels sein wird. Der Drachenzirkel ist kein Marketing-Instrument, sondern ein hervorragender Weg, um unsere Systeme Belastungstests zu unterziehen und gleichzeitig unsere Spieler zu unterhalten. Die Szenarien des Drachenzirkels werden Drachenprüfungen genannt und können von Zweikämpfen bis hin zu groß angelegten Belagerungen alles umfassen.
    • Der Drachenzirkel soll natürlich nicht die primäre Umkämpfte Insel ersetzen, sondern spezialisierte Testbereiche bieten, die unseren Spielern zudem mehr Abwechslung beim Betatesten ermöglichen. Er schafft außerdem ideale Rahmenbedingungen für das Einfügen weiterer Testumgebungen, die dabei auch noch mit der Hintergrundgeschichte im Einklang sind.
    • Der Drachenzirkel sowie seine Prüfungen dienen ausschließlich dem Betaprozess und sind nicht als Teil des finalen Spiels gedacht. Manche Ideen könnten allerdings für die während der Kickstarter-Kampagne angesprochenen „Schlachtfelder für neue Spieler“ wiederverwendet werden.
  • Die Leitprinzipien dieser Spiele lauten wie folgt:
    • Match-basiert, mit variabler maximaler Spieleranzahl je Reich
    • Durchschnittliche Matchdauer von weniger als 30 Minuten
    • Eine Reihe verschiedener Siegbedingungen, die selbst im laufenden Betrieb mit Leichtigkeit von den Designern angepasst werden können, ohne dass Programmierer dafür groß behelligt werden müssen.
  • Diese Spiele werden allesamt dazu entworfen, die verschiedenen Aspekte des Hauptspiels zu (play-)testen. Für ihre Umsetzung sollte nur geringfügig neuer Code geschrieben werden müssen. Ihre zugrundeliegenden Mechaniken sollten weitestgehend mit denen des Hauptspiels identisch sein, abgesehen von offensichtlichen Ausnahmen wie der Reisezeit.
  • Es folgen einige Beispiele der erwähnten „Drachenprüfungen“:
    • Samstagnacht-Belagerungen (SNBs) – Diese sollten wir als erste Prüfungen implementieren. Bei ihnen dreht sich alles um den Angriff auf eine Festung. Wir können diesen Modus auch vorerst mit deaktivierter Gebäudezerstörung einführen und diese dann im weiteren Verlauf der Tests zuschalten. Mehr Details über die SNBs findet ihr im nachfolgenden Kapitel.

      • Zu weiteren möglichen Prüfungen für den Drachenzirkel gehören:

    • DREINGABE: Karawanenkonflikt – Bei dieser Disziplin versucht eine Karawane eine Festung zu erreichen. Hier treten zwei Seiten gegeneinander an, von denen die eine die Karawane beschützt und die andere sie angreift.
    • DREINGABE: OdM Eroberung – Ein Konflikt zwischen drei Parteien, die alle versuchen einen Ort der Macht zu erobern und für eine gewisse Zeit zu halten.
    • Burgen-Bashing! – Drei Burgen, haufenweise Belagerungswaffen und das wars: Es kann nur einen Sieger geben.
    • DREINGABE: Die Mine ist mein! – Reichsbasierte Donnerkuppel mit Minen. Mit anderen Worten: „Drei Reiche gehen rein, ein Reich kommt raus!” Die Spieler starten bereits in der Mine und nur ein Reich kann sie siegreich verlassen.
    • DREINGABE: Mörderisches Versteckspiel – Diese Karte wurde für die tiefen, dunklen Wälder entworfen. Die Spieler werden zu Beginn über diesen TDW verstreut und das letzte noch lebende Reich gewinnt.
    • DREINGABE: Jeder gegen jeden! – Diese Prüfung erklärt sich wohl von selbst.
  • Die hier aufgeführten Prüfungen stellen nur einen Bruchteil der Ideen dar, die uns für den Drachenzirkel vorschweben und decken die eher groß angelegten Disziplinen ab. Andere Prüfungen werden einen kleineren Umfang haben und sich auf das Testen bestimmter Gruppen und Situationen konzentrieren. Auf diese Weise können wir Tests abhalten, die spezifische Szenarien nachstellen, wie etwa: „Was passiert, wenn man eine Achtergruppe aus diesen Klassen gegen eine Achtergruppe aus anderen Klassen antreten lässt“ sowie weitere Prüfungen berücksichtigen. Daraus können wir enormen Nutzen ziehen, schließlich entwerfen wir ein Stein-Schere-Papier-Spiel mit nicht gespiegelten Klassen. Ein derartiges System wird sich in Kombination mit dem Protokollsystem als unschätzbar wertvoll erweisen, wenn es um das Balancen der Klassen vor Release geht.
  • Die Verknüpfung dieser Spiele mit den Fortschritts- und Reichsbelohnungssystemen wird sowohl uns als auch unseren Backern bzw. Spielern zum Vorteil gereichen. Es wird ihnen neben ihrer Hilfsbereitschaft uns gegenüber noch weitere Anreize liefern, an den Tests teilnehmen und sie dafür entlohnen.
  • Teile der technischen Voraussetzungen für die SNBs sowie den anderen Drachenprüfungen werden unseren Spielern bekannt vorkommen. Einige der Dinge, die wir für die Beta 1 benötigen, sind:
    • Countdown vor Matchbeginn (Hält die Spieler im Sammelbereich).
    • Matchbeginn (Startet den Timer, entlässt Spieler aus dem Sammelbereich).
    • Match zurücksetzen (Bringt die Spieler zurück in den Sammelbereich und setzt anschließend alle Gebäude/Gerätschaften etc. zurück, startet den nächsten Matchbeginn-Countdown).
    • Ziele und Siegbedingungen sollten von den Designern mit Leichtigkeit angepasst werden können.
    • Ein spielinterner Punktestand, der – wie in der Vergangenheit bereits geschehen – zusätzlich auch auf einer Webseite eingesehen werden kann.
    • Anzeige des Endstands nach Beendigung des Matches (s. o.)
    • Vorgefertigte Charaktere (mit festgelegtem Inventar sowie Fähigkeitsfortschritten), damit die Spieler für bestimmte Tests keine Zeit auf die Charaktererstellung verschwenden müssen.

    • Anmerkungen von MJ: Die Verwendung des Drachenzirkels als Kulisse für diese Art von Tests ist zwar etwas klischeehaft, wird unseren an der Story von MMORPGs interessierten Spielern aber das bisschen Extra an Atmosphäre liefern, insbesondere da der Drachenzirkel auch für diverse Hintergrundgeschichten relevant sein wird.

    Doch auch für die restliche Spielerschaft gibt es Vorteile: Der Drachenzirkel wird es ihnen nicht nur ermöglichen, uns beim Testen bzw. Verfeinern unseres Spiels zu helfen, sondern dabei auch noch Spaß zu haben. Zudem werden wir ein wenig unserer künstlerischen und finanziellen Ressourcen darauf verwenden, die Teilnahme auch anderweitig lohnenswert für unsere Spieler zu gestalten. Das mag zwar bei einigen Backern, die weniger Zeit zur Verfügung haben, auf Kritik stoßen, doch müssen wir die Entwicklung dieses Spiels in die Gänge bringen und dies ist eine der Möglichkeiten, wie wir dies tun können. Wenn wir mehr Leute dazu motivieren können, am Betaprozess teilzunehmen, dann können wir durch das Sammeln der erforderlichen Daten mit unserem Protokollsystem das Spiel nicht nur schneller, sondern auch in deutlich besserem Zustand abliefern.

    Ich habe das zwar vorhin bereits angesprochen, doch kann hier eine Wiederholung nicht schaden: Ein wichtiger Teil unserer Motivation hierbei besteht darin, dass wir unseren Backern im Gegenzug für ihre Zeit und Geduld etwas zurückgeben möchten. Dabei ist dieser Ansatz nur einer von vielen, wie wir das tun werden. Damit machen wir zwar die Verzögerung nicht wieder gut, können unseren Backern aber erneut beweisen, dass wir es nicht nur mit der zeitigen Fertigstellung dieses Spiels ernst meinen, sondern auch mit der frühzeitigen Bekämpfung von klassen- bzw. situationsbedingten Problemen während der Beta 1 und darüber hinaus, anstatt das alles erst nach dem Release zu beheben. Mit diesen Geschenken an die Spieler wollen wir ihnen für ihre Unterstützung und Hilfe danken.

    Eine Frage, die bei den Besprechungen zum Drachenzirkel immer wieder aufkam, war die der Zweikämpfe und wie weit wir mit ihnen gehen wollen. Uns ist klar, dass wir zu Testzwecken reichsinterne Duelle bis zu einem gewissen Grad ermöglichen müssen. Das Problem daran ist, dass wir diese Art des Kräftemessens im Allgemeinen nicht zum Teil des Spiels machen wollen, da es dem Klima der Kameradschaft schaden könnte, das für den Erfolg unseres Spiels so essenziell ist. Während der Beta 1 müssen wir aber ganz konkrete Daten sammeln können und den Spielern ermöglichen, daran mitzuwirken. Zwar sollten wir erfassen, wer ein Duell gewinnt oder verliert usw., müssen aber sorgfältig darüber nachdenken, wie viele von diesen Statistiken wir den Spielern zugänglich machen und wie viele der Prüfungen insgesamt aus Duellen bestehen dürfen. Dementsprechend wird es abseits des Drachenzirkels nur wenige Zweikampf-Prüfungen geben und wenn es welche gibt, werden sie enden, noch bevor jemand stirbt.

    Samstagnacht-Belagerungen
    SNS Logo
  • Auch wenn der Begriff Samstagnacht-Belagerungen eher das Bild von John Travolta im weißen Anzug bei einem Tanzwettbewerb heraufbeschwört, sprechen wir natürlich von der Fortsetzung unserer Freitagnacht-Kämpfe aus früheren Tests. Wie der Name schon sagt, sollen sie Samstagnacht stattfinden.
  • Bei den SNBs geht es nicht nur darum eine Burg zu erobern (manchmal wird das Ziel ein völlig anderes sein), vielmehr sollen uns diese Testreihen und Szenarien die Möglichkeit geben, verschiedene Aspekte des Spiels zu testen und unseren Backern (meistens) Spaß zu bereiten.
  • Im Kern mögen SNBs zwar Arenakämpfe mit bestimmten Siegbedingungen und Zeitvorgaben sein, aber wir wollen, dass diese Schlachten etwas Besonderes im Vergleich zu anderen Spielen sind. Natürlich wird es auch hier vertraute Spielelemente geben, allerdings wird der Weg zum Erfolg um einiges vielschichtiger sein, als man es von anderen Spielen kennt. So geht es z. B. nicht nur darum, das Match zu gewinnen, sondern auch mit welcher Teamkomposition das erreicht werden kann (wie ich bereits zuvor erläutert habe). Dadurch werden wir umso mehr wertvolle Informationen während der SNBs erhalten.
  • In Übereinstimmung mit den Vorgaben aus der Hintergrundgeschichte des Drachenzirkels, werden die einzelnen SNBs auf verschiedenen Inseln bzw. in unterschiedlichen Gebieten stattfinden.
  • Die Belagerungen können auf allen Umkämpften Inseln mit geeigneten Gebäuden stattfinden. Diese Gebäude können entweder mit C.U.B.E erstellt worden oder vorgefertigte Strukturen sein. Falls es sich um bereits vorgefertigte Gebäude handelt, können diese selbstverständlich nicht zerstört werden. In einem solchen Match liegen die Schwerpunkte dann eher auf PvP, Fähigkeiten und anderen Aspekten der Belagerung.
    • Um die Belagerungen aufregender und fokussierter zu gestalten, werden die dafür geeigneten Gebäude vom Rand der Inseln aus schnell erreichbar sein.
  • Während der Beta 1 Phase (und auch später) können die Gebäude während einer Belagerung sowohl beschädigt, als auch repariert werden oder gar komplett einstürzen.
    • Die Designer können die Schadensmenge/Modifikation der Trefferpunkte bei der Belagerung während eines Testlaufs nach Bedarf regulieren. Die genaue Art und Weise für Reparaturen muss noch festgelegt werden. Zu Beginn der Beta 1 wird es aber mindestens einen Slash-Befehl ( /) zum Reparieren geben.
  • Wie bereits in früheren Kapiteln erwähnt, werden die Umkämpften Inseln nicht rund um die Uhr zur Verfügung stehen und wir werden die Belagerungen als Teil der SNBs und des Drachenzirkels einplanen, unter anderem um die Kosten einzugrenzen. Uns ist es wichtig, dass wir nicht die Zeit der Spieler während der ruhigeren Phasen des Tages vergeuden und ihnen den bestmöglichen Unterhaltungswert bieten können.
  • Zu Beginn der SNBs erhält jedes Reich mindestens zwei Belagerungsgeräte. Eines wird der “Skorpion” sein, den wir bereits implementiert haben. Als zweite Option stellen wir uns so etwas wie "Magische Mörser" vor oder eher eine traditionelle Waffe wie ein Katapult. Den Begriff "Magischer Mörser" (MM) benutzen wir als Grundkonzept für alternatives Belagerungsgerät, das einfacher ergänzt werden kann als einige herkömmliche Belagerungswaffen. Natürlich möchten wir euch eine große Auswahl an Belagerungsgerät während der SNBs zur Verfügung stellen, uns ist es aber genauso wichtig , dass sie beeindruckend aussehen und sich gut bedienen lassen. Falls wir uns für die Option des “Magischen Mörsers" entscheiden, könnte die Spielfassung wie folgt aussehen:
    • Magische Mörser können handwerklich erstellt werden und im späteren Verlauf der Beta durch die Kraft von Magiern angetrieben werden.
    • Sie werden keine weiteren technischen Voraussetzungen benötigen.
    • Der Gegenstand selbst wird von einem Handwerker erstellt und kann im Anschluss von der entsprechenden Magierklasse bedient werden (sobald Magier zum Spiel hinzugefügt worden sind). Bis dahin werden wir es so einrichten, dass jeder die MMs verwenden kann.
    • Es wird sie in verschiedenen Größen geben, ihre Wirksamkeit hängt allerdings von dem Magier ab, der sie verwendet.
    • Magier beeinflussen durch ihre Macht bzw. Opfer die Anzahl der Aufladungen. Hierbei sind MMs, die mit Seelenenergie angetrieben werden, am ergiebigsten, während sie sich mit Blut am schnellsten abnutzen.
    • Für das Testen mit Bots müssen die MMs sowohl automatisch als auch manuell auf ein Ziel feuern können.
    • DREINGABE: Weiteres Belagerungsgerät wird hinzugefügt.
    • DREINGABE: Alle Belagerungswaffen können automatisch von NSCs bedient werden, nicht nur von Bots bzw. ARCs. Abhängig davon, wie lange es dauern würde, eine solche Option zu ergänzen, würde ich dies zu einem festen Bestandteil der Beta 1 machen. Zu ihrem Start wäre Belagerungsgerät, das von alleine feuert, eine mögliche DREINGABE.
  • Als Teil der SNBs sollten die Spawnpunkte von den Designern bestimmt werden können, ohne auf die Unterstützung von Programmierern zurückgreifen zu müssen.
    • Die Designer sollten die Respawnzeiten im laufenden Betrieb anpassen können. So kann flexibel entschieden werden, ob Spieler nach ihrem Ableben sofort wieder in die Schlacht eingreifen können oder erst mit Verzögerung.
  • Während der restlichen Alphatests finden die SNBs auf einer gesonderten Insel mit Burg im Zentrum statt.
  • Nutzt die Baumeister-Brigade, um auf dieser und weiteren Inseln zusätzliche Gebäude für die Belagerungen hinzuzufügen. Die technischen Voraussetzungen hierfür müssen noch geschaffen werden.
  • Spieler werden für ihre Teilnahme am Drachenzirkel während der SNBs eine Belohnung erhalten, da sie uns geholfen haben das Spiel zu testen und zu verbessern.

    • Anmerkungen von MJ: Die Samstagnacht-Belagerungen sind ein äußerst wichtiger Bestandteil unsers Plans für die Beta, insbesondere die Beta 1. Unser Betatestprozess soll euch Spaß machen und nicht nur aus Einloggen und zum Wohle des Spiels hindurchquälen bestehen. Das ist zwar sicherlich eine mögliche Herangehensweise, doch haben wir uns bewusst gegen sie entschieden. Unter idealen Umständen werden sich unsere Spieler nicht nur der Belohnungen wegen, sondern dank des hohen Spaßfaktors auf die SNBs freuen. Die zusätzlichen Belohnungen schaden natürlich nicht, machen aber auch keinen großen Unterschied, wenn die SNBs sowie die Drachenprüfungen keinen Spaß machen. Das ist mir auch persönlich wichtig, denn schließlich werde ich auch selbst wieder an den SNBs teilnehmen, genauso wie ich es bereits getan habe, bevor die Neu-Befähigung über uns hereinbrach. Als wir die Rohfassung dieser Technologie in den vergangenen Tagen hier im Studio ausprobierten, haben sich die Leute richtig gefreut statt einer Engine endlich wieder ein Spiel zu spielen. Auf diesen Tag habe ich sehr lange gewartet.

    Fortsetzung folgt...

    schon nächste Woche!