Combat in Second Life Teil IV: Combatsysteme 
Freitag, den 01. Januar 2010 um 09:00 Uhr
Combat in Second Life Teil IVSecond Life bietet eine breite Palette unterschiedlichster Möglichkeiten, sich in Form von Kampfsport zu messen. Der Oberbegriff „Combat“ umfasst dabei jegliche Formen des Wettbewerbs, der mit Hilfsmitteln ausgeführt wird, die im weitesten Sinne als „Waffe“ gelten können. Dazu zählen in einer virtuellen Welt ebenso die Fäuste.

In den vorangegangenen Artikeln haben wir uns auf das Linden-eigene System und die daraus resultierenden Combat Gruppen konzentriert. Der folgende Abschnitt ist den komplexen Systemen gewidmet, welche den Schritt in ein MMORPG zu vollziehen versuchen.

 


TEIL IV: ENDEMISCHE SYSTEME UND COMBAT RP

Das von Linden Lab zur Verfügung gestellte Damagesystem erlaubt im Grunde nur eines: eine Sim kann auf „Schaden“ gestellt werden und in SL hergestellte Waffen sind somit wirksam, ob das dem Player nun passt oder nicht. Mehr als ein Rückteleport an den Homepoint (das Zuhause) wird allerdings durch den virtuellen „Tod“ nicht ausgelöst. Wir haben euch gezeigt, dass selbst dieses einfache Prinzip bereits eine große Community ermöglicht, deren Regeln nicht im System festgeschrieben sind, sondern durch Einsicht und Integrationsbereitschaft funktionieren. Der Vorteil dieses Systems: es funktioniert gridweit immer gleich und viele Gruppen können sich als Teil eines großen Ganzen betrachten. Der Nachteil: es gibt kaum Entwicklungsmöglichkeiten.


Der Wunsch nach Vielfalt

Diesen durchaus gravierenden Nachteil versuchen Residents schon seit langer Zeit durch die Entwicklung eigenständiger – zumeist webservergestützter – Hudsysteme auszugleichen.

Die ersten kleinen Huds versuchten zunächst nichts anderes, als das Problem der Safe Sim zu lösen: Schaden sollte nur möglich sein, wenn das System verwendet wird, die Sim musste nicht auf Schaden geschaltet werden – und auch das Rezzen von Objekten kann man an Gruppenmitgliedschaft binden, anstatt die Sim generell freizugeben. Dies bietet einen wichtigen Primärschutz gegen Griefer. Die einfachste Variante dieses ersten Kampfsystems ist ein Hud mit dem schlichten Namen „HP“ (Healthpoints) von Burke Prefect. Dieses Freebietool wird in aller Regel herumgereicht, ein offizieller Verkaufsort ist nicht bekannt. Der HP Hud funktioniert denkbar einfach. Wenn getragen, reagiert der Player auf gescriptete „Bullets“ aus herkömmlichen Waffen mit einer Schadensanzeige. Erreicht die Schadenmenge den Wert 0, „stirbt“ der Player: eine Sterbeanimation wird ausgeführt, der Player liegt 45 Sekunden auf dem Boden und eine entsprechende Meldung wird ausgegeben. Nach Ablauf der „Death Penalty“ wird der Zähler wieder auf 100% gesetzt und die Animation aufgehoben.

Mehr tun der HP-Hud und all seine Derivate aber nicht. Es ist weder möglich, verschiedene Kampfstärken anhand von Levelstufen zu  regeln, noch können „Rollen“ definiert werden. Der Wunsch vieler Sim-Betreiber nach Funktionen, welche einem echten MMORPG gleichkommen, führte zur Entwicklung komplexer Systeme mit teilweise recht steilen Lernkurven. Bevor wir uns diesen Systemen zuwenden, erarbeiten wir zunächst mal eine Definition dessen, was sie leisten sollten.



Was muss ein MMORPG leisten?


Ein MMORPG (Massively Multiplayer Online Role Playing Game) besteht meist aus folgenden Komponenten:

1) Der Spieler kann aus einer Liste vorgegebener Rollen eine von ihm favorisierte Rolle auswählen. Die Rollen selbst sind vom Genre des Games abhängig.
2) Die Rolle des Spielers definiert sich durch Eigenschaften und Fähigkeiten, die sich im Lauf des Spiels dynamisch verändern.
3) Bestimmte Gegenstände oder Waffen können sich auf die Fähigkeiten und Eigenschaften eines Spielers auswirken (Buffs und Debuffs).
4) Spielleiter können Spieleraccounts verwalten
5) Es gibt unterschiedliche Möglichkeiten, über „Erfahrungspunkte“ (XP) die Kampfstärke von Playern zu erhöhen.
6) Es gibt ein Levelsystem, die Level wirken sich auf die Kampfstärke aus.

Besonders ein MMORPG, eines der ältesten und am weitesten verbreiteten, hat sich in der Entwicklung der ersten Systeme hervorgetan: Star Wars Role Play, im Folgenden SWRP genannt. Die Fans dieses Rollen- und Combatspiels wollten sich zumindest mal in Jedis und Sith aufteilen können – gefolgt von vielen Subspezies. Sie wollten auch deutlich zwischen dem Einsatz herkömmlicher Waffen (Laserpistole, Lichtschwerter) und dem Einsatz der „Macht“ (telekinetische Kräfte, Suggestion) unterscheiden. Und zu guter Letzt sollte es Unterschiede zwischen den Jedimeistern und ihren Padawans geben. Ging es doch nicht an, dass das Lichtschwert eines Rookies den gleichen Schaden verursacht, wie das eines angesehenen Jedimeisters, wo kämen wir da hin? XP musste her!

Doch all diese Möglichkeiten bietet die Linden-Engine nicht mal ansatzweise. Zur Erinnerung: ab 100% Schaden ist nicht mehr als ein Rückteleport zum Homepunkt drin, mehr nicht, Ende der Fahnenstange. Wie soll man da ein vernünftiges SWRP aufbauen? Durch Zurufe und Absprachen? „He ich bin ein Jedimeister, schau auf meinen Tag, ich darf zweimal zuschlagen und du nur einmal!“ Selbstredend, dass solcherart „RP“ nur Hohngelächter hervorruft, zumal bei den bösen Sith. Es erinnert ein wenig an die Räuber und Gendarm Spiele der Kindheit: „Du bist tot!“ – „Nein, ich bin nicht tot“ – „Doch, ich hab dich erschossen!“ – „Ätsch daneben!“. Danach redete man zwei Wochen nicht miteinander.

Das SWRP brauchte also eine Möglichkeit der Kontrolle. Und diese Kontrolle erfordert es, dass der Status eines Spielers gespeichert werden konnte, um ihn bei jeder Interaktion abrufen und vergleichen zu können. Lindenscript bietet hier aber nur sehr eingeschränkte Möglichkeiten, Daten zwischenzuspeichern. Die einzige Alternative ist hier der eigene Webserver mit einer Datenbank, welche umfangreiche Spielerdaten bereithält und an das System sendet. Der Hud wird somit zur Schnittstelle, der Webserver zur API (Application Interface).

 

Die Role Play API: Wir erfinden ein Spiel

Heutige APIs bewegen sich an der Grenze zur Professionalität. Der Aufwand, eine solche API zu programmieren und zu warten, grenzt an den Betrieb eines echten, konkurrenzfähigen MMORPG. Die Programmierer solcher Systeme sind sicher keine Bastler oder Gelegenheits IT-ler mehr, dazu ist der Aufwand schlicht zu hoch. Eine Gegenfinanzierung ist daher fast immer notwendig, und besteht sie auch nur im Verkauf spezieller Waffen und Ausrüstung. Ein gutes Combatsystem ist demnach in erster Linie ein Geschäft.


Schauen wir uns an, was die API macht, und entwerfen dazu ein einfaches Szenario undInworld-Outworld:die API entwickeln einmal auf die Schnelle ein kleines Game. Nennen wir es „Dark Sun“ (das fiel mir jetzt gerade so ein) und sagen wir, es ist ein Fantasy Game (Das Genre „Fantasy“ bestreitet ohnehin 90% des Gesamtmarktes). In diesem Spiel soll es darum gehen, dass eine dunkle Macht ein friedliches Land bedroht; die bösen nennen wir einfach mal „Darkos“ und die guten heissen „Light’os“. Wer in das Spiel einsteigt, wählt also zunächst seine Organisation oder sein „Realm“ oder wie immer wir das nennen mögen. Ab sofort ist er also ein Guter oder ein Böser. In Second Life wird so etwas selten über die API zur Verfügung gestellt. Die Zugehörigkeit zu einer bestimmten Gruppe innerhalb des Games wird dann doch meist über herkömmliche Gruppenfunktionen geregelt. Eine wirklich gute API sollte das automatisieren können, alle unsere Recherchen konnten ein solches System bisher aber nur im Planungsstadium finden: ZoX.


Danach erfolgt die Wahl der Rolle – der Einfachheit halber bieten wir nur diese zwei: Krieger oder Magier. Dabei ist es unwesentlich, zu welcher Organisation man gehört. Sowohl der Krieger als auch der Magier verfügen im Grunde über den gleichen Satz an Fähigkeiten, nur in unterschiedlicher Balance. Bestimmen wir also zunächst die wichtigsten „Stati“ und danach die Fähigkeiten, die sie beinflussen sollen. Die Stati wären:


- Health (Leben: sinkt es auf 0, ist der Player tot)
- Stamina (Lebenskraft: je höher die Stamina, desto mehr verkraftet der Player an Schaden)


Diese beiden Stati reichen zunächst völlig aus. Hier nun ein paar „Attribute“, welche auf die beiden Stati „Health“ und „Stamina“ einwirken:

- Strength (Kampfstärke. Je höher sie ist, desto mehr Schaden fügt der Player zu)
- Agility (Beweglichkeit: die Fähigkeit, Schaden auszuweichen)
- Willpower (Willenskraft: Je höher, desto exakter häufiger ist die Wahrscheinlichkeit, Schaden zuzufügen)
- Defense (Abwehrkraft: Je höher sie ist, desto weniger Schaden kassiert man ein)

Nehmen wir diese Attribute als Grundstock unseres gesamten Games. Das ist recht schlicht, würde aber schon eine Menge Spaß garantieren. Die grossen Games bauen im Grunde alle auf genau diesem Konzept auf, mehr oder minder komplex mit vielen Abstufungen und Spezialisierungen, welche aber stets auf das Gleiche hinauslaufen: Schaden verursachen und über den Gegner triumphieren.

Skills und Abilities

Jetzt kommt das Salz in die Suppe: die verschiedenen Skills, die ein Player haben kann. Ein Skill kann auf einen anderen Player „angewendet“ werden, und dies meist über einen simplen Mausklick. Definieren wir mal ein paar davon:

- Schwerthieb (dieser Skill macht einfach nur Schaden)
- Magischer Hieb (dieser Skill wirkt auf Health und zieht aber auch ein wenig Stamina ab)
- Böse Verwünschung (ein magischer Skill, der dem Gegner mächtig viel Stamina wegnimmt, sagen wir mal mindestens 50%)
- Schutzrune (Dieser Skill verusacht zwar keinen Schaden, füllt für den Anwender aber stets die Stamina erneut auf, sagen wir, 90% auf)
- Heilzauber (mit diesem Skill gibt sich der Player selbst 20% Health zurück)


Wir haben eingangs zwei Rollen definiert: Krieger und Magier. Legen wir als Spieleentwickler also fest, wie hier die Attribute verteilt werden. Dem Krieger geben wir einen hohen Grad an „Strength“ (er kann also mächtig zuschlagen) dafür aber nur einen kleinen Wert an „Willpower“ (er haut öfter mal daneben). Der Magier hat von Haus aus eine hohe „Defense“ und etwas mehr „Agility“ (er weicht gut aus), dafür sind seine Schläge längst nicht so hart, da seine „Strength“ geringer ist. 



Buffs und Debuffs


Ein Buff ist nichts anderes als die kurzfristige Erhöhung eines aktiven Skills, ein Debuff genau das Gegenteil: er verringert die Schlagkraft eines Skills. Buffs und Debuffs können auch direkt auf Attribute einwirken. Ein Buff kann durch einen Skill ausgelöst werden (Beispiel: Kraftspruch – durch die Anwendung dieses Skills wird die Lebenskraft eines Mitspielers kurzfristig erhöht) aber auch durch Kleidung (ein magisches Hemd erhöht die Stamina) oder durch eine Waffe (Zauberschwert – in der Hand getragen erhöht es die Schlagstärke). Auch diese Buffs müssen von der API verwaltet werden.

Das nun folgende Duell kann man sich ausmalen: Der geschickte Einsatz der Fähigkeiten, die wohlüberlegte Anwendung von Buffs und Debuffs entscheiden jetzt über Sieg oder Niederlage.



Jedes RP ein eigenes Game


Ability TreeAnhand dieses kleinen Beispiels, in welchem wir schon fast ein Game konzipiert haben, wird deutlich, was eine API leisten und anbieten muss. Nicht nur einfache Spielerdaten müssen verwaltet werden, sondern auch ein ganzer Satz von Stati, Attributen und Abilities. Missionen und Quests, NPC’s (non player characters) mit eigener KI (künstlicher Intelligenz) zur Gewinnung von XP haben wir jetzt mal aussen vorgelassen. Desgleichen die verschiedenen Levelstufen, welche man aufgrund von XP-Gewinnung erhält, und die sich selbstverständlich auch wieder auf sämtliche Attribute auswirken; ein Krieger mit Level 1 braucht sich einem Magier des Levels 20 erst gar nicht zu nähern.

Die API überwacht jede Interaktion, errechnet in jeder Sekunde den gegenwärtigen Spielstand, entscheidet letztlich über Leben und Tod. Nach jedem Duell erhalten die Player dann entweder XP oder sie steigen im Level oder sie erhalten Boni, je nachdem, was sich die Entwickler des Games ausgedacht haben. Inwiefern es in Second Life überhaupt solche APIs gibt und ob sie auch genau das leisten, was wir hier als Grundlagen festgeschrieben haben, werden wir im letzten großen Abschnitt dieser Serie erfahren. Wir können euch aber jetzt schon sagen, dass die Recherche eine Vielzahl von Ansätzen zutage förderte, aber nur wenige, die all die soeben genannten Voraussetzungen zumindest teilweise auch leisten.

Online Games gelten in der Computerbranche als die unangefochtene Königsdisziplin der Programmierkunst; inwieweit diese Königsklasse in Second Life anzutreffen ist, werden wir euch berichten.

Weitere Teile der Serie:
Combat in Second Life Teil I - Einführung
Combat in Second Life Teil II - Military Combat
Combat in Second Life Teil III - Die Armee

 

Bitte Einloggen oder Registrieren um Kommentare zu schreiben.