Entwicklungsblog zum Game

13 Beiträge / 0 neu
Letzter Beitrag
Entwickler
Bild des Benutzers Entwickler
Entwicklungsblog zum Game

In der Hochphase der Corona-Zeit haben sich viele Veranstalter eine Menge Gedanken zu neuen LARP-Formen gemacht; wie man trotz einer Pandemie die Gemeinschaft von Spielleitung und Spielern aufrechterhält, wie man trotz Abstandsgeboten und in den kleinsten noch zulässigen Gruppen irgendwie spielen kann, und so manches mehr. Ein verbreiteter Ansatz waren Online-RPG-Runden, die sich wohl meist auch bewährt haben. Ob und was Dria in dieser Hinsicht macht, ist Thema eines anderen Threads. Hier soll es um die wahnwitzige Idee gehen, einen vielleicht überschaubaren Teil von Dria als Spiel anzubieten.

Und zwar kostenlos.

Im Browser, also ohne daß irgendeine Installation erforderlich ist.

Auch für Nichtmitglieder.

Es dürfte klar, sein, daß ein solches Spiel in eigentlich keiner Hinsicht mit modernen Rollenspielen mithalten können wird. DIe werden von Firmen mit Dutzenden, wenn nicht hunderten von Mitarbeiten über Jahre hinweg mit einem stattlichen Budget entwickelt. Es wird euch nicht wundern, daß wir das nicht haben. Doch darum geht es auch nicht. Wir wollen einen kleinen Ausschnitt von Dria erlebbar machen.

Wir? Also... ich. Das Ganze ist aktuell ein Soloprojekt, schon weil sich andere natürlich um die "echten" LARPs kümmern und das hier nur einen experimentellen Charakter hat. Aber ich habe vor langer Zeit schon mal ein derartiges Spiel entworfen, und mit diesen Erfahrungen sowie denen, die ich in der Zwischenzeit angesammelt habe, könnte das ganz interessant werden.

Alle erfahrenen Spieleentwickler raten auf der GDC und sonstwo regelmäßig davon ab, allein ein Rollenspiel mit den typischen Funktionen auf die Beine zu stellen, weil das einfach ein zu großes Projekt sei. Und noch habe ich Features vor, an die sich nicht mal große Publisher heranwagen. Mal sehen.

Aber das alles mag sich bislang noch recht vage anhören. Daher zähle ich erst mal auf, was dieses Spiel nicht ist:

  • Pay to win
  • First Person Shooter
  • eine Schleife von "Kill monster, get loot"
  • ein schnelles Spiel, auf dem man seine Figur auf dem Bildschirm steuert

Und was ist es nun?

  • Eine Gelegenheit, sich von daheim aus schon virtuell mit einer Ecke von Dria vertraut zu machen - durchaus in Form eines Abenteuers. Oder mehreren Abenteuern.
  • Es ist retro. Der Verein ist samt Vorläufer ca. 25 Jahre alt, und das Spiel sieht aus, als sei es auch so alt...
  • Es ist ein hybrides Textadventure. Okay, da sehe ich schon die ersten Interessenten weglaufen... wenn sie überhaupt bis hierhier durchgehalten haben. Es ist ein Textadventure, weil es zugbasiert aufgebaut ist und die gesamte Verarbeitung auf dem Server stattfindet. Und es ist ein hybrides Textadventure, weil es dennoch für Standardaktionen eine Mausbedienung anbietet, mit welcher z.B. die Navigation wesentlich intuitiver durchgeführt werden kann. Und es wird auch Grafiken geben.

Und was kann man damit machen?

Primär kann man die alte und mysteriöse Stadt Motrolostigo (im Land Vim) erkunden. Stadtabenteuer sind ja etwas, das es im LARP nur selten gibt. In einem Spiel hingegen kann man jeden beliebigen Ort als Handlungsort verwenden. Das Spiel füllt damit eine Lücke, die auf normalen Cons ohnehin nicht adressiert würde. Somit hat man eine problemlose Koexistenz. Langfristig soll ganz Vim zu bereisen sein.

Erfolge im Spiel werden allerdings getrennt von Erfolgen auf LARPs behandelt. Egal, was euer Charakter im Spiel anstellt oder schafft, es führt nicht zu anrechenbaren Erfahrungen für kommende LARPs. Und auch nicht zu Geld, Gegenständen, Leveln etc. Dafür ergeben sich auch keine Nachteile beim LARP, wenn man sich im Spiel in Probleme gebracht hat. Wir arbeiten vorerst ohne eine entsprechende Verzahnung.

Die Erfahrungen und das Wissen, das dein Spielcharakter (der nicht notwendigerweise dein LARP-Charakter sein muß), können jedoch durchaus eingebracht werden. Kurz man kann Vim kennenlernen, Abenteuer erleben und Spaß haben.

Dafür wird das Spiel rund um die Uhr zur Verfügung stehen (abgesehen von routinemäßigen Wartungsfenstern). Somit kann man in einem LARP-Land ein wenig erleben, ohne zeitlich oder räumlich abhängig zu sein... und das ist gerade in einer Pandemie schon praktisch.

Das war's zur Einführung. Ich werde in unregelmäßigen Abständen Neues eintragen, wenn es etwas zu berichten gibt. Aktuell arbeite ich an den Grundlagen (Karte, Navigation, Charaktererstellung etc.).

Was ist eure Meinung? Haltet ihr die Idee für total unzeitgemäß (was sie natürlich ist ) oder wollt ihr die geheimnisvolle Stadt so schnell wie möglich erkunden?

 

Eichohrkatz
Bild des Benutzers Eichohrkatz
Motrolostigo Textadventure Game

Ich bin schon sehr gespannt darauf...  es ist eine interessante Idee und nette Ergänzung zu normalen LARPs.

Man kann hierbei sicher viele Dinge umsetzen, die im LARP schwierig bis gar nicht darstellbar sind.

Bisher wurde Vim - ein Land der Magier, Gelehrten und Bürokraten - relativ wenig bespielt.

Es gab bisher 6 Dria-Cons, die in Vim spielten:

  1. Mysticon 2b - Die Diriallumfseier (21.12.1996)
  2. Weggefährten 5a - Die Erbschaft (03.11.2002)
  3. Weggefährten 9b - Wider jeden Zweifel (19.02.2006)
  4. Ludus Imagine 2 - Das Arkanum von Lyssath (05.05.-07.05.2006)
  5. T'Ailun-Con 1 - Elmares in Lyssath (17.08.-19.08.2007)
  6. T'Ailun-Con 2 - Mo'Befaj (07.08.-09.08.2009)

 

Beim Stöbern in alten Unterlagen habe ich übrigens noch ein sehr seltenes Wörterbuch "Eine Einführung in die askilische Sprache" gefunden (mit kurzer Übersicht über die verschiedenen Sprachen Drias, Grammatik und Wortlisten für Askilisch).

Askilisch war ja die ursprüngliche Sprache der Siedler der ersten Einwanderungswelle, welche sich im Zeitalter OS im Südwesten Drias ansiedelten und dort das Land Pretana gründeten (heutige Länder Vim und Wasal) - sie wird heute nur noch als Gelehrtensprache verwendet.

Bei Interesse kann ich dir dies schicken (z.B. für Sprach- / Übersetzungsrätsel oder als Flair für alte Inschriften).

Wir hatten dieses Wörterbuch damals in 2007 für den Con Weggefährten-10 als Hilfsmittel zur Entschlüsselung der Inschrift auf dem Schrein der heiligen Bendara den Spielern zur Verfügung gestellt.

Wobei diese Inschrift als zusätzliche Gemeinheit im alten askilischen Alphabet geschrieben war, dessen Symbole im Wörterbuch nicht beschrieben waren (also fremde Schrift + fremde Sprache). Das war was für die Hardcore-Rätselknacker / Code-Entschlüsseler. Als Start zum Entschlüsseln der Symbole konnte man - mit etwas Überlegen - den Namen BENDARA nehmen, der relativ fett und prominent in der Mitte des Textes stand. 

Entwickler
Bild des Benutzers Entwickler
Unterlagen und Rätsel

Was für eine blitzartige Antwort! Und ich hatte fast gedacht, daß es Wochen dauert, bis jemand meinen Eintrag findet...

Ja, schick mir die Unterlagen gerne noch zu. Im Spiel selbst werde ich wohl keine derartigen "Hardcore-Rätsel" einbauen - zum einen gehört sowas "zum Anfassen" ja besser auf LARPs, und zum anderen läßt es sich in der Gemeinschaft besser lösen. Ein paar Ideen für zumutbare Rätsel gibt es aber schon.

Übrigens ist dieses Forum auch für Gäste lesbar, daher bitte keine öffentlichen Details vorab.

Parallel zur Entwicklung des Spiels - und eng damit verflochten - verläuft die Konkretisierung von Vim über das bisher Bekannte hinaus zu einer Basis, die tiefer begründete Plots für das Spiel und ggf. auch künftige LARPs erzielen soll. (Einen Einblick wird es in absehbarer Zeit auf der Vim-Seite unter Dria > Die Länder Drias geben.) Es geht darum, nicht irgendwelche generischen Plots - die praktisch überall stattfinden könnten - nach Vim zu bringen, sondern welche, die sich organisch aus den Eigenarten des Landes und seiner Geschichte ergeben. Überwiegend. Manche Probleme allerdings sind so verbreitet, daß es sie eben nicht nur in einem speziellen Land gibt.

Heute habe ich erst mal auf der Homepage die Styles etwas optimiert, damit die Footer-Blöcke mit den neuen Inhalten besser lesbar sind.

So, ich bin auf weitere Nutzer*nnen des Forums gespannt. smiley

Entwickler
Bild des Benutzers Entwickler
Kleine Fortschritte

Chris, danke für das Wörterbuch. Es ist schön gemacht und gut verständlich, allerdings werde ich es erst einmal zurückstellen. Rätsel sind eine Sache, eine ganze Fremdsprache schon eine ganz andere.

Was gibt es Neues?

Hauptsächlich habe ich an der Oberfläche gearbeitet, damit es ein wenig ansehnlicher aussieht und auch ein wenig "phantastischer". Für die gängigsten Befehle gibt es sogenannte FastIcons, so daß man sich viele Eingaben sparen kann. Die Navigation kann einerseits klassisch mit Befehlen wie "Gehe nach Norden", "Norden", einfach "n" - oder andererseits intuitiv über einen anklickbaren Kompass erfolgen. Außerdem wurde ein Umgebungsüberblick hinzugefügt, so daß man sich besser orientieren kann. Zusätzlich wurde der Parser erweitert (hier wird noch sehr viel passieren) und die Verarbeitung von Umlauten konsequent auf UTF8 eingestellt.

Das sind alles notwendige Vorarbeiten; so richtig machen kann man allerdings noch nichts, außer erfolgreich herumlaufen. Aber damit beginnt es immer.

Nebenbei habe ich mich wieder in die verschiedenen Aspekte des Game Design begeben. Hier hat sich viel getan, und jeder Vortrag gibt einem nicht nur viele neue Ideen, sondern zeigt auch auf, auf was man alles achten muß und daß die Aufgabe doch weit größer ist als sie erst aussieht.

Parallel wächst Vim als Konzept immer weiter. Dabei ist mir wichtig, daß sich der Hintergrund in der Story widerspiegelt und es einen plausiblen Grund gibt, warum einige Dinge, die man im Onlinespiel erleben können wird, nicht im LARP wiederzufinden sind.
An dieser Stelle möchte ich noch auf einen Konzeptgedanken eingehen: das Spiel soll kein isoliertes Erlebnis sein, also nicht nur einen Bezug zu Dria & Vim, sondern zum LARP als Ganzes haben. An manchen Stellen mag es zwar Zugeständnisse geben (die sich zum Vorteil der Spieler auswirken), aber Dinge, die man im LARP nicht macht oder dort abwegig sind, möchte ich in das Onlinespiel auch nicht einbringen. Etwa:

  • Crafting
  • Mining
  • Housing
  • Farming

- eben all die Tätigkeiten, die man um des Geldes oder des Levels willen macht, die aber weder die Story voranbringen noch im Kern interessant sind. Würde jemand auf ein LARP gehen, um einen Tag in einer Mine zu arbeiten? Oder um 20 metallene Beinschienen herzustellen? Wohl nur die wenigsten.

Oh, und dabei sind wir beim Thema, was es sonst noch nicht gibt:

Es gibt keinen externen Shop.
Keine Mikrotransaktionen.
Keine Lootboxen.
Keine Monetarisierung.
Keinen Battle Pass.
Keine kosmetischen Rüstungssets.
Keine Premiumwährung - eigentlich überhaupt keine abweichenden Währungen.
Keine monatlichen Abos.
Keine zusätzlich erwerbbaren Belohnungen für Stufenaufstiege.
Keine Sparangebote.
Kein Auktionshaus.
Wenn ihr all das möchtet - viel Spaß bei Diablo Immortal und anderen derartigen Spielen. Laut eines neueren GamePro-Artikels könnt ihr dort "für die beste Ausrüstung des Spiels bis zu 100.000 Euro bezahlen" oder "stattdessen ungefähr zehn Jahre täglich farmen". Nein danke.

Statt dessen befinden wir uns in der Nische der Interactive Fiction mit einem Hauch von Roguelikes und einem guten Schuß Ultima. All diese Elemente haben ihre eigene Community; die Ultima-Serie war zudem ein Meilenstein der Computer-RPGs. Und - was für mich einen besonderen Dria-Bezug darstellt - ich habe damals beim Initiator der allerersten Cons auf Dria, den Mysticons, Ultima VI und VII gespielt. Er war ein begeisterter Fan der Serie und hat auch mich dafür gewonnen. So schließt sich quasi der Kreis.

 

Entwickler
Bild des Benutzers Entwickler
Regelwerk

Jedes Spiel benötigt ein eingebettetes Regelwerk, nach dem es funktioniert.
Bei einfachen Würfel- oder Kartenspielen gewinnt meist der höhere Wert, bei komplexen Spielen können es auch Positionen, Zustände, Anzahl der Spielelemente und vieles mehr sein, die über den Ausgang des Spiels entscheiden.
In einem Rollenspiel soll jedoch die (Spiel-)Welt abgebildet, erfahrbar gemacht werden, und hier ist das Regelwerk dafür da, die Zustände jener Welt so zu konkretisieren, daß sie überhaupt erst bespielbar (meßbar, vergleichbar) werden. Und dies orientiert sich an den Erfahrungen und dem Wissen der Beteiligten.
Nehmen wir als Beispiel einen Troll. Es gilt als bekannt, daß Trolle größer, zäher und stärker als Menschen sind. Ein Kampf gegen Trolle dürfte also eine riskante Sache sein. Üblicherweise wird dies intern durch Zahlen abgebildet: der Troll hat mehr Lebenspunkte und/oder einen stärkeren Rüstungsschutz als der Mensch. Mit dieser Grundlage kann man auch Zahlen für Trefferwahrscheinlichkeiten, für Waffenschaden usw. festlegen. Das alles ist bisher nichts Neues. Auch in Dria Online wirkt ein darunterliegendes Regelwerk, das sich um all das kümmert. So können alle Figuren und Objekte erwartungskonform agieren.

Man bräuchte eigentlich gar nicht viel mehr dazu sagen, aber ich möchte auf einen konzeptionellen Unterschied hinweisen, denn ich hatte ja in einem früheren Artikel erwähnt, daß dieses Spiel einen deutlichen LARP-Bezug aufweisen soll. Da wäre es auf den ersten Blick naheliegend gewesen, das in Dria etablierte Kobold-Regelwerk zu verwenden, nach dem bisher alle Cons abgelaufen sind.
Doch es gibt zwei grundlegende Unterschiede.

  • Zum einen gibt es in LARP-Regelwerken keine Konzepte von Trefferwahrscheinlichkeiten (oder Initiative, Aufmerksamkeit, Charisma, Diplomatie etc.), weil all dies ja von den Spielern (hoffentlich) ausgespielt wird.
  • Zum anderen sind LARPs grundsätzlich Gruppenerlebnisse. Steht ein Einzelner vor einem Problem (sei es eine verschlossene Tür oder eben ein Troll), dann ist der übliche (erwünschte/empfohlene) Weg, sich bei anderen kompetenten Charakteren Hilfe zu suchen. Es wird auch von niemandem erwartet, einen Troll oder eine Räuberbande allein zu besiegen.

In einem Single-Player-Computerspiel jedoch gibt es keine Hilfe durch andere Spieler (allenfalls durch NPC, aber das ist noch Zukunftsmusik). Der Spieler muß also in die Lage versetzt werden, solche Situationen allein zu lösen, auch wenn sich das unrealistisch anhört. Hier kann das Regelwerk helfen, indem es Möglichkeiten bietet, die im LARP nicht vorhanden sind. Und daher muß es über die Regeln des LARP hinausgehen.
Das ist der Grund, warum manches bei Dria Online anders funktionieren wird als im LARP. Natürlich wird es etliche Ähnlichkeiten geben, denn etliche LARP-Regelwerke ähneln im Kern wiederum Pen&Paper-Rollenspielen, so wie viele Computerspiele.
Was man sich aus diesem Artikel mitnehmen kann, ist folgendes: es gibt einige Änderungen und Erweiterungen des Aktionsfeldes, die den Spielern dienen sollen, indem sie die Möglichkeiten eines Computerspiels besser zugänglich machen. Sie gelten aber nur für dieses Spiel und sind nicht aufs LARP übertragbar. Was man hingegen geistig mitnehmen kann, ist das Wissen, das man sich erarbeitet hat. (Und hoffentlich die Erinnerung an ein gutes Erlebnis.)

Entwickler
Bild des Benutzers Entwickler
Responsivität

In den letzten Tagen habe ich das CSS-Framework ausgetauscht. Das alte funktionierte zwar grundsätzlich und war natürlich bereits auf Responsivität ausgelegt, aber im Detail gab es dann doch Schwierigkeiten bei niedrigeren Auflösungen. Also mußte ein leistungsfähigeres her.

Zur Erklärung: Responsivität bedeutet, daß eine Website (und das Spiel ist technisch nichts anderes) auf jedem Endgerät, unter jeder Auflösung vernünftig lesbar ist und alle Elemente ordentlich dargestellt werden. Klingt naheliegend und einfach, ist es aber nicht. Wenn man reinen Text hat, mag das noch angehen. Aber sobald Bilder dabei sind oder man ein Layout mit mehreren Spalten verwendet - was eben der Normalfall ist - wird es knifflig. Wäre ich beim reinen Textadventure geblieben, hätte das alte Gerüst auch noch ausgereicht. Aber nein, es soll ja auch gediegen aussehen, angenehm zu bedienen sein und Icons als Alternative für häufige Eingaben haben. Schon wird alles komplizierter.

Schriftgrößen müssen sich je nach Position der Spalte anpassen, Bilder müssen skalieren. Spalten müssen ihre Position verändern, sobald die Auflösung oder Fenstergröße das erfordert. Das kann man heutzutage erwarten und es ist auch nötig, denn niemand weiß im voraus, auf welchem Gerät das Spiel gespielt wird: einem Smartphone, einem Tablet oder doch am PC. Oder Mac. Oder ob das Gerät hochkant gehalten wird oder quer. Daher ist der ganze Aufwand gerechtfertigt, und man verbringt Stunden damit, Abstände abzugleichen, Schriftgrößen zu testen, CSS zu optimieren und Varianten zu testen.

Dabei sind wir in 2022. Im Prinzip ist die heilige Kuh "Responsivität" oder der "mobile first"-Gedanke eine Kuh von gestern. Als die ersten Tablets und webfähigen Smartphones herauskamen, hatten deren Displays schlechtere Auflösungen als ein PC von 1985. Man ging mit WAP auf spezielle, dafür optimierte Websites, um das Manko durch vereinfachte Strukturen und kleinere Bilder (wenn überhaupt welche dabei waren) auszugleichen. Man nutzte Geräte mit Auflösungen zwischen 320 x 200 und 800 x 600, später dann immerhin 1024 x 768. Yeah.

Aber das ist schon einige Zeit her. Die neuen Iphones haben Auflösungen, die über FullHD hinausgehen, etwa das 11 Pro Max mit 2688 x 1242. Kommt euer PC-Monitor da mit? Tja, und Tablets? Das Google Nexus 10 glänzt mit 2560 x 1600 Pixeln. Und wer am PC sitzt, dürfte wohl auch FullHD (1920 x 1080) oder etwas in der Nähe haben. Das ganze Bemühen, eine Website auch "auf kleinen Auflösungen" darstellbar zu machen, läuft ziemlich ins Leere, wenn moderne Displays alle keine Schwierigkeiten mehr mit hohen Auflösungen haben.
Ist die Kuh damit tot?

Natürlich nicht. Denn zum einen gibt es noch genug Geräte, die eben nicht diese guten Werte aufweisen, und zum anderen ist es einfach guter Stil, sein Werk responsiv zu machen. Es ist halt professionell, daß eine Website nicht am elenden Endgerät scheitert, sondern sagt: "Na gut, dann passe ich mich eben an" und trotzdem unter allen Umständen ordentlich darstellbar bleibt.

Aber der Preis dafür ist eben mehr Vorbereitungsarbeit. Und es geht... nun, weitgehend. Je mehr ich mit absonderlichen Altgeräten teste, desto mehr kleine unschöne Grenzfälle entdecke ich im Layout. Die Arbeit ist noch nicht vorbei.

Entwickler
Bild des Benutzers Entwickler
Ein winziger Meilenstein

Die im letzten Beitrag erwähnten Änderungen ziehen sich durch sämtliche Seiten und Darstellungsmodi, vorwiegend wirken sie sich allerdings auf die gängige EIngabeseite aus: das primäre Interface. Und das ist nun im Wesentlichen fertig.

Das bedeutet, ich kann die gewünschten Elemente jetzt an allen notwendigen Orten unterbringen und das Interface in jeder Auflösung und Orientierung verwenden, ohne daß es zu Überlappungen oder dem Verschwinden von Elementen oder Teilen davon kommt. Insbesondere der Footer, der vier verschiedene Informationsbereiche enthält, hat sich tagelang erfolgreich gegen eine responsive Darstellung gewehrt, bis ich ihn schließlich hinbekommen habe. Sowas ist lehrreich, aber auch zeitaufwändig. Und für jeden User sieht es hinterher ganz normal aus, wenn sich alles zusammenschiebt oder kleiner wird, wenn man das Fenster verkleinert. Es sieht nicht nach einer Leistung aus, sondern wird als selbstverständlich erwartet. Was letztlich ja auch zutrifft. Nur macht man meist sowas nicht mehr manuell, sondern setzt größere Frameworks ein, die all das bereits als Theme oder in einer Engine mitbringen. Damit umzugehen, wäre allerdings ein noch größerer Aufwand gewesen.

Okay, wie haben also ein stabiles primäres Interface. Da kommt doch direkt die Frage nach den sekundären Interfaces auf. Das sind Zusatzfunktionen, die man nur bei Bedarf aufruft, etwa das Inventar, den Onlinestatus oder die Charakterübersicht. Manche davon sind weniger aufwändig, aber je mehr Komfort hineingelegt werden soll, desto komplexer werden sie noch.

Und hier wird schon erkennbar: das sind immer noch Grundlagenfunktionen, die mit den Spielinhalten eigentlich nichts zu tun haben, aber wichtige Bestandteile für jedes Rollenspiel sind (außer dem Onlinestatus, aber der macht bisher die wenigsten Schwierigkeiten). Der Spieler muß natürlich seine gekauften/gefundenen/erbeuteten Gegenstände anzeigen lassen und bewerten können. Und sollte idealerweise auf einen Blick sehen können, welche Waffen und Rüstungen er gerade trägt. Vielleicht auch - falls es Quickslots für Fähigkeiten, Gegenstände oder Zauber gibt - was da griffbereit ist.

Und in einem solchen Moment dreht man sich um, blickt zurück und merkt, wie weit das Konzept des reinen Textadventures bereits hinter einem liegt. Denn dort würde man dafür einen Befehl eingeben und als Reaktion eine Liste erhalten, fertig. Die Inventarliste hatte ich auch schon fertig, aber dann kam die Idee mit der konkreten Darstellung der Dinge am Körper bzw. im Rucksack. Klappt alles wie vorgesehen, wäre es ein Entwicklungssprung von rund zehn Jahren - von den klassischen Textadventures, wie es sie noch in den 80er Jahren gab, zu den frühen grafischen RPG-Abenteuern der 90er wie dem schon erwähnten Eye of the Beholder und Lands of Lore: The Throne of Chaos. Das soll nicht bedeuten, daß ich Dria Online mit diesen beiden Klassikern vergleichen möchte - nur daß das Interface leistungsfähiger und umfangreicher ist als bei typischen Textadventures. Es hat sogar einen Hauch von Diablo I, das aber ansonsten nicht als Vorbild hinzugezogen wird.

Ein unerwarteteter LARP-Bezug ist zudem, daß die oben genannten Spiele, insbesondere Lands of Lore I, von Mháire Stritter, die manchen aus "LARPzeitTV" sowie Orkenspalter TV (neues Fenster) bekannt sein dürfte, auch heute noch empfohlen und in einem achtminütigen Video (neues Fenster) vorgestellt werden.

Ein etwas größerer Meilenstein dürfte die Charaktererstellung werden. Von der erzähle ich aber ein andermal.

 

Entwickler
Bild des Benutzers Entwickler
Charaktererstellung

Das war ein maßgeblicher Abschnitt - gemessen am Gesamtspiel sicher nur ein kleiner Schritt, aber ein notwendiger früher Schritt.

Ich hatte dieses Programm einige Zeit vor mir hergeschoben, weil ich ermöglichen wollte, daß man sich ein Bild seines Charakters aussuchen kann, welches dann bei den Charakterdaten angezeigt wird. Also so wie auf klassischen Pen&Paper-Charakterbögen (wenn man sich die Mühe macht) oder wie in klassischen Computer-Rollenspielen wie eben Lands of Lore oder Icewind Dale. In Ultima konnte man sich ebenfalls ein Bild des Avatars aussuchen, glaube ich. Die Auswahl war früher auf nur wenige Porträtbilder beschränkt, und sie waren obendrein sehr pixelig. Ich wollte wenigstens ein Sortiment halbwegs erkennbarer Bilder anbieten.

Aber da ich nicht auch noch die Grafiken zum Spiel mache, habe ich etliche Quellen durchforstet. Wichtig war dabei auch, daß die Bilder mit einer passenden Lizenz verknüpft waren, durch die später keine Schwierigkeiten entstehen würde. So habe ich etliche Sammlungen mit OGL-, GPL- und CC-Lizenzen (CC3, CC4, CC0) zusammengestellt, aber keine davon gefiel mir so richtig. Entweder waren die Sammlungen noch pixeliger als bei Ultima oder die Auswahl der Bilder war zu gering oder es waren keine weiblichen Charaktere dabei oder die Bilder waren einfach so unansehnlich, daß ich selbst keines davon für meinen Charakter hätte haben wollen. Und es gab noch eine Variante: pixelige niedliche Bilder (und ich spreche von 32 x 32 Pixeln oder weniger). Offenbar sind gerade Autoren von JRPGs großzügig mit ihrem Artwork, und sie geben die Bilder dann frei. Das ist sicher nett, aber die Figuren haben Köpfe, welche so groß wie der Rest des Körpers sind. Dazu sind sie für Animationen für Plattformspiele optimiert, aber ich plane nun mal keines. Kurz gesagt, die größte Auswahl gab es bei kleinen niedlichen Charakteren, deren Unterschiede man allenfalls am jeweiligen Hut erkennen kann und die typischerweise alle sonst das gleiche Gesicht aufweisen. Tja, lieber nicht.

Daher habe ich weitergesucht - und das hat sich schließlich gelohnt. Ich bin auf eine Sammlung gestoßen, welche eine deutlich bessere Auflösung und größere Vielfalt aufwies. Eine so große Vielfalt, daß ich spontan die Völker der Elfen und Zwerge (als Spielervolk, wohlgemerkt) in die Planung des Spiels aufnahm, was vorher gar nicht der Fall gewesen war. Da hatte ich ja noch gedacht, daß ich schon froh sein konnte, wenn ich je ein halbes Dutzend weiblicher und männlicher Gesichter für Menschen-Charaktere anbieten konnte. Doch jetzt hatte ich eine ordentliche Auswahl wirklich schöner Bilder an der Hand, welche die Charaktererstellung deutlich interessanter und reizvoller machen dürfte.

Diese Änderung war folgenreich. Denn jetzt gab neben den bereits Vorhandenen weitere Parameter, welche sich auf den Spielablauf auswirken konnten, was mehr Spieltiefe und einen höheren Grad der Wiederspielbarkeit ermöglichte. Mit diesen Bildern in der Hand konnte ich endlich eine Datenstruktur anlegen und den Character Creator entwickeln. Im Kern ist das ein einfaches Programm, das dem User ein paar Optionen zur Charaktererstellung bietet, eben darunter die Auswahl des Bildes.

Aber man muß ein paar Schritte vorausdenken, wenn es um Webanwendungen geht. Typischerweise werden Bilder in einer Unterstruktur abgelegt, die von der zentralen Seite aus leicht erreichbar ist. Das ermöglicht einfache Links und auch ein browserseitiges Caching. Hat man hingegen Bilder, die erst nach und nach gezeigt werden sollen, wie etwa die Bilder von NPC, von Handlungsorten oder plotwichtigen Gegenständen, ist es viellelcht nicht die beste Idee, die Bilder so schlicht abzulegen, daß jeder, der mal in den HTML-Quelltext schaut, die Pfade sieht und dann manuell oder mit Scraper-Tools danach suchen kann. Das wäre irgendwas zwischen Cheating und Hacking.

Um das zu vermeiden, mußte die Datenstruktur und vor allem der Zugriff komplexer aufgebaut sein. Hier liegt auch ein wesentlicher Abschnitt des Programms. Es war dennoch innerhalb von rund drei Abenden fertig und bietet dem Cheater keinen Angriffspunkt mehr. Klar, es ist doof, daß man sich bereits über Cheater Gedanken machen muß, bevor das eigentliche Spiel auch nur halbwegs einsatzfähig ist, aber jeder Programmteil soll von Anfang an vernünftig konzipiert sein anstatt nachträglich - wenn man schon an ganz anderen Themen dran ist - nochmal aufgegriffen werden zu müssen.

Und jetzt ist das Tool soweit fertig. Ich kann es später, falls Entscheidungen zum Regelwerk es erforderlich machen, noch weiter ausbauen, aber dann brauchen nur weitere Formularseiten hinzugefügt werden; die Struktur ändert sich dabei nicht mehr. Ach ja, das Regelwerk. Das ist auch noch (mindestens) einen Artikel wert.

Entwickler
Bild des Benutzers Entwickler
Zwischendurch

Da der nächste Meilenstein noch ein wenig Zeit braucht, obwohl die kniffligsten Aspekte davon schon geklärt sind, erzähle ich kurz zwischendurch von den kleineren Dingen: Sachen, die auch wichtig sind, aber keine Hürde aufstellen.

Refactoring. Damit kann man ja nicht früh genug anfangen. Das Hauptprogramm wurde auf einige weitere Module aufgeteilt, und etliche werden noch folgen.

Dateistrukturen. Elemente, die außerhalb des Programms in Greifweite lagen, weil sie nur einzeln vorlagen, sind jetzt doch mehr geworden und wurden in Unterverzeichnisse verlagert. Als Folge stimmten natürlich gleich einige Referenzen nicht mehr. Das hat man nun von relativen Links. Also anpassen.

Optimierungen. Der Character Creator wurde noch etwas erweitert, um ihn sicherer zu machen.

Optische Trennung zwischen der Rolle "Administrator der Homepage" und "Entwickler von Dria Online". Das dürfte für User dann wohl nachvollziehbarer sein. Daher bekam der Entwickler jetzt einen eigenen Account und beide unterschiedliche Avatarbilder.

Recherchen bei den Vorbildern der Branche: es gibt unzählige hervorragende Videos der Game Developer's Conference, und deren Erkenntnisse und Ratschläge sind nicht immer nur für Entwickler nützlich, sondern für Spieldesign im Allgemeinen. Hierzu ein andermal mehr.

Und eine nicht so kleine Sache: ich habe zwei Betatester. Und zwar nicht irgendwen, sondern Mr. Estradam persönlich, der eine Menge an Erfahrungen mit Computerspielen (und natürlich Dria) mitbringt und mir schon im Chat weise Dinge geraten hat. Vor ihm hat sich allerdings bereits Christian bereiterklärt, auf die Reise durch Motrolostigo zu gehen. Schon jetzt meinen Dank an beide! Mit der Spieleerfahrung des ersteren und der umfangreichen Dria-Kenntnis des letzteren habe ich wohl für das Projekt die beiden besten Experten, die man sich denken kann.

Noch gibt es nichts zu betatesten, weil der aktuelle Stand ja eine Pre-Alpha-Version ist, aber sobald es etwas gibt, können sie loslegen.

 

Entwickler
Bild des Benutzers Entwickler
Was im Rucksack geschah

Im letzten Artikel hatte ich ja schon erwähnt, daß der nächste Schritt etwas Zeit brauchen würde. Aber er ist gemacht. Was mich so aufgehalten hatte, war das Inventory. Und das, obwohl es eigentlich schon fertig war - allerdings noch bezogen auf das alte Konzept des reinen Textadventures. Auf die Eingabe des Kommandowortes gab das Spiel eine Liste der Gegenstände aus, die man dabeihatte. Praktisch und schlicht. So wie es in typischen Textadventures halt gemacht wird,

Aber das reichte im neuen Konzept nicht. Denn das Ziel ist es inzwischen ja, eine vollwertige Oberfläche im Sinne der genannten klasssichen Vorbilder abzubilden. Dazu gehört eben auch ein Inventory - also eine grafische Repräsentation des Rucksacks inklusive des Charakters, dem man die Gegenstände "aniehen" kann, wenn es sich um ausrüstbare Gegenstände handelt. Diese Art, seinen Charakter auszurüsten, ist intuitiv und von den 90ern bis in die modernsten Rollenspiele vertreten. Anstatt also zu schreiben

nimm das rostige Eisenschwert in die rechte Hand

kann man einfach das Schwert-Icon auf die passende Stelle in der Symboldarstellung des Charakters ziehen. So einfach, so aufwändig. Denn was bedeutet es tatsächlich?

  1. Man braucht ein Icon für jeden ausrüstbaren Gegenstand, der im Spiel vorkommt (und letztlich für jeden Gegenstand)
  2. Man braucht ein System, das clientseitig mit Drag & Drop umgehen kann und die Verschiebung des Icons an den Server meldet (sonst bekommt das Spiel nichts davon mit)
  3. Man braucht eine Plausibilitätsprüfung, damit Gegenstände nur mit sinnvollen Orten verbunden werden können. Die Hose auf dem Kopf ersetzt keinen Helm, und der magische Ring im Stiefel entfaltet keine Wirkung...
  4. Man muß den Rucksack öffnen und wieder schließen können

Der zweite Punkt war der Trickreiche. Um die Events zu behandeln, war eine Programmbibliothek und letztlich zwei Programme in zwei Programmiersprachen  notwendig, dazu weitere Stylesheets. Die Anpassung des Grids für das Design, der Entwuf der Logik für die Objektbehandlung und vor allem die Tests zogen sich hin, und anfangs gingen immer wieder die IDs der Objekte verloren, bis ich das Hauptprogramm ergänzt hatte. Außerdem mußten drei Varianten berücksichtigt werden:

  1. ein Gegenstand wird aus dem Rucksack entnommen und ausgerüstet
  2. ein Gegenstand wird vom Charakter entfernt und wieder im Rucksack abgelegt
  3. ein Gegenstand wird beim Charakter an eine andere Stelle verschoben (das Schwert wandert z.B. von der linken in die rechte Hand, damit man links einen Schild ausrüsten kann)

Das sind alles Vorgehensweisen, die man in eigentlich allen Rollenspielen als selbstverständlich hinnimmt. Der Umgang mit Gegenständen - und da muß man nicht einmal Loot schreien - ist ein wesentlicher Bestandteil in derartigen Spielen, auch wenn er recht unauffällig erscheint. Aber er ist letztlich die Grundlage von Kampf, Handel und häufig auch Quests. Um endlich irgendwann den ersten Gegner bekämpfen zu können, muß man erst einmal eine Waffe in die Hand nehmen können. Hurra, Inventory!

Und jetzt?  Soweit man sie hat, kann man Rüstung, Helm und Stiefel tragen, Handschuhe oder Ringe anziehen - und mehr.

Als nächstes geht es an die Details des Regelwerks. Das schafft die Grundlagen für das, auf das ihr schon alle wartet: das Kampfsystem.

Nein, das wird kein Actionspiel und Kampf ist auch nicht der zentrale Punkt, weder in Dria Online noch in Dria-LARPs, aber er gehört eben als solide Option dazu. Die schwierigeren Sachen kommen danach.

 

Entwickler
Bild des Benutzers Entwickler
Rund ums Regelwerk, mit einem Exkurs

Jeder, der schon einmal an einem Regelwerk mitgearbeitet hat, weiß, daß es viel Sorgfalt erfordert, damit es fair und ausbalanciert wird. Idealerweise ist es auf die zugrundeliegende Welt abgestimmt und macht deren Konzepte/Möglichkeiten auf einfache Weise zugänglich. Obendrein sollte es nicht zu fremdartig sein, damit man seine frühere Erfahrungen aus anderen Regelwerken gut darauf übertragen kann. Angesichts dieser Anforderungen scheint es nahezuliegen, sich an einem etablierten System zu orientieren.

Aber da ist natürlich sofort der rechtliche Aspekt im Spiel: man darf sowas natürlich nicht einfach direkt übernehmen. Allerdings gibt es inzwischen einige freie Systeme (die oft nicht komplex genug oder auf ganz andere Genres zugeschnitten sind) und einige andere, welche der Open Game Licence unterliegen. Das sieht nach einem Schritt in die richtige Richtung aus.

Nach längerer Suche habe ich mich für eine Basis entschieden, deren Grundlagen nützlich sein dürften. Doch je mehr ich mich in dieses umfangreiche Werk vertiefte, desto mehr Punkte habe ich entdeckt, die für das geplante Spiel ungeeignet sind, weil sie nicht zu Dria passen oder zu einschränkend sind. Also habe ich weitere Quellen hinzugezogen und bin noch dabei, das Beste - und umsetzbarste - davon zu bestimmen. Und letztlich wird es wohl auf ein Gemisch aus Elementen von offenen Systemen, verbunden mit eigenen Konzepten, herauslaufen. Auf diese Weise kann das Land so repräsentiert werden, wie ich es mir vorstelle, aber der Vorteil des perfekt balancierten, weil komplett nach Vorlage gestalteten, Systems ist natürlich dahin. Das ist es mir aber wert, weil ich Dria kein starres System überstülpen möchte, das andere in den Details genauso stutzen läßt wie mich.

Kurz gesagt: die Regelwerkskonzeption ist eine sehr wichtige Grundlagenentscheidung, die sich auf fast alles andere auswirken wird, und daher komme ich damit nicht so schnell voran wie beispielsweise beim Entwurf des Charaktergenerators (der nach Abschluß der Konzeption auch noch dahingehend erweitert wird.)

Kommen wir zum Exkurs.

Meine Grundidee war ja, für jeden aufsuchbaren Ort ein Bild anbieten zu können. Das würde das Spiel auch vom Textadventure näher zur Visual Novel rücken (obwohl es gerade dabei ist, mit großen Schritten zum ausgewachsenen RPG zu werden). Dank weiterer Recherche habe ich noch weitere freie Bildquellen entdecken können, die mir das obige Ziel ermöglichen könnten. Außerdem kann ich natürlich stets auf eigene Bilder von Waldwegen, mittelalterlichen Gassen und alten Gebäuden zurückgreifen - alles Material, das ich in früheren Jahren bei der Recherche nach LARP- oder Filmlocations erstellt habe.

Und manchmal macht es Spaß, zwischendurch Dinge vom Projektende einfach vorzuziehen, wie etwa die Erstellung des Logos. Das motiviert einfach.

 

Entwickler
Bild des Benutzers Entwickler
Wer die Wahl hat...

...hat die Qual. Und wer die Wahl erst ermöglichen möchte, erst recht. Aber der Reihe nach:

Dria Online ist ein Spiel, das alle Daten auf dem Server verwaltet und sich damit wie ein MMO verhält (aus diesem Grund kann man auch keinen Spielstand speichern; es gibt immer nur exakt einen Spielstand, und zwar den jeweils aktuellen). Bei dieser Art von Spielen ist es oft möglich, daß ein Spieler verschiedene Charaktere haben kann, etwa um verschiedene Builds einer Klasse oder einfach verschiedene Klassen etc. spielen zu können. Das war anfangs im Konzept von Dria Online nicht enthalten. Hätte man also mitten im Spiel gemerkt, daß einem der elfische Magier doch nicht so liegt und man lieber einen Zwergenkämpfer spielen würde, dann hätte man einen neuen Charakter erstellen müssen, wodurch der alte überschrieben worden wäre. Nicht schön, wenn man später doch noch mal zum Elfen zurückwollte. Und falls man dann einen elfischen Kämpfer wollte, wäre der Zwerg wieder weg gewesen. Ärgerlich.

Aus diesem Grund bieten Multiplayerspiele die Erstellung mehrerer Charaktere an, die demselben Account gehören. Und da sie schon mal dabei sind, bieten einige gleich kostenpflichtig weitere Charakterslots an. Tja.

Da es in der Handlung von Dria Online auch Spezialwege für Völker und Klassen geben soll, kam mir die Verwendung verschiedener Charaktere sinnvoll vor. Mit nur einem Charakter würde man die Spieler zwingen, das Spiel erst komplett durchzuspielen, bevor man Volk oder Klasse wechselt (oder den Stand eines unfertigen Spiels zu verlieren). Mit mehreren Charakteren kann man sich jedoch bei jedem neuen Einloggen aussuchen, wen man gerade spielen möchte. Dabei haben alle Charaktere natürlich ihren eigenen Stand, also Werte und Erfahrungen. Das erschien mir weit spielerfreundlicher.

Aber es erforderte, die gesamte Datenstruktur umzustellen. Außerdem mußte der Charaktergenerator erweitert werden. Nebenbei war ohnehin ein Loginsystem fällig, gefolgt von einem Programm für die Charakterauswahl. Meine Betatester bewerteten das Ganze als irgendwas zwischen "Spielerei" und "mach's doch, wenn's nicht zu viel Aufwand ist". Und natürlich war dies wieder mal ein Aspekt, der mich von der Entwicklung des Kernspiels abhielt.

Der Haken war nur: wenn ich die Umstellung jetzt nicht machte, würde sie später noch mehr Aufwand bedeuten. Die Datenstruktur gehört zu den Grundlagen eines jeden Programms, und es ist besser, wenn sie gleich solide ist als wenn man später zunehmend viele Funktionen anpassen muß.Also entwickelte und testete ich die neuen Programme, erweiterte die Datensätze, stellte nebenbei das Raumprotokoll auf eine bessere Skalierung um und machte mir Testcharaktere. Ab und zu flog mir das um die Ohren, wenn wieder mal Daten noch nicht portiert waren oder eine Funktion noch nach dem alten System arbeitete, aber schließlich paßte alles zusammen.

Und jetzt kann sich jeder Account bis zu fünf Charaktere erstellen. Das sollte für lange Zeit reichen (aber 640 KB sollten ja auch mal genug für jeden PC sein...). Noch kann man keinen alten Charakter entfernen/überschreiben, aber für eine solche Funktion brauchen dann keine Strukturen mehr angepaßt werden, sondern es wird wohl nach außen hin nur ein Button irgendwo erscheinen, also mache ich das wirklich erst später.

Die wahre Herausforderung ist weiterhin der Einsatz des internen Regelwerks. Ich habe vor, an etlichen Stellen von den freien Vorbildern abzuweichen, weil es mir sinnvoller und spielerfreundlicher vorkommt, zudem ist vieles davon ohnehin nur im Pen&Paper umsetzbar  - außer ich implementiere unglaublich umfangreiche Mechaniken, die es im Übrigen auch bei den Klassikern nicht gab. Nicht umsonst beinhalten selbst die Lizenz-CRPGs der 80er, 90er und selbst danach nur eine vereinfachte Form der Regeln der Bücher. Und auch in den großen modernen Systemen scheint es der Trend zu sein, einfacher und damit massentauglicher zu werden. Das Bethesda-Spiel Elder Scrolls: Daggerfall enthielt zum Beispiel wesentlich mehr Skills und Handlungsoptionen als seine Nachfolger; selbst Skyrim kann da nicht mithalten.

Aber da in bestehenden Regelwerken alles fein aufeinander abgestimmt ist, kann jede Änderung fatale Folgen haben, wenn man nicht genau aufpaßt. Also müssen die Folgen gut durchdacht werden. Obendrein sind die Systeme ja auch nicht direkt für Computerspiele gedacht; manche benötigte Aspekte müssen erst transformiert werden, damit sie passend im Spiel dargestellt werden können. Und all das hält eben auf. Aber es geht stetig voran.

Entwickler
Bild des Benutzers Entwickler
Fälschlicherweise positiv

Gestern morgen hat der Microsoft Antivirus Defender das Programm zur Auswahl der Charaktere gelöscht. Er hielt es für einen Trojaner.

Mir ist es direkt aufgefallen, weil die Datei noch im Editor geöffnet war und dieser mir direkt mitgeteilt hat, daß eine Quelldatei verschwunden sei. Na großartig. Ich sichere den Fortschritt zwar regelmäßig, aber bislang nicht täglich. Doch der Editor hatte den Code noch, also ist nichts verlorengegangen.

Blieb nur die Frage, weshalb der Defender auf eine solche Idee kam. Aber klar, das Programm beschäftigt sich unter anderem mit Logindaten, liest eine Session und verzweigt auf andere Programme. Manche Trojaner machen wahrscheinlich irgendwo auch so etwas, aber ebenso tausende von ganz normalen Webanwendungen wie dieses Spiel eben. Ich habe dem Virenscanner dann beigebracht, den Selektor in Ruhe zu lassen. Damit dürfte die Sache erledigt sein.

Was kann man daraus lernen? Lieber eine fragliche Datei erst mal in Quarantäne schieben lassen als sie direkt löschen zu lassen. Und: der Defender hat eigenwillige Vorstellungen.

Zum Verfassen von Kommentaren bitte Anmelden oder Registrieren.