fuRisk
Dokumentation
Gruppe
S14
Richard Cyganiak , Tobias Jung , Anja Jentzsch
07.07.02
Inhalt
|
Anpassung des Brettspiels für die Realisierung als
Computerspiel |
2 |
|
Regelvereinfachungen |
2 |
|
Usability |
3 |
|
Performance |
3 |
|
Stand des Prototypen |
4 |
|
Eindrücke über VRML als Entwicklungsplattform |
4 |
1. Anpassung des Brettspiels für
die Realisierung als Computerspiel
Risiko ist ein Spiel mit komplexen Regeln. Diese Regeln sind gut durchdacht und
haben sich in der Brettspielpraxis bestens bewährt. Bei der Umsetzung als
Computerspiel geht zwangsläufig eine Menge Flair verloren. Was kann man tun, um
den Benutzer dafür zu entschädigen? Welchen Mehrwert kann man ihm gegenüber dem
Brettspiel bieten?
Wir gehen davon aus, dass schicke Grafik, und die Fähigkeit zum Netzwerkspiel
gegen entfernte Gegner, noch nicht ausreichen.
Die Computer-Umsetzung kann außerdem zwei weitere Dinge leisten: Das Streamlining
mechanischer Abläufe kann den Spielfluss deutlich beschleunigen, und die
Spielregeln können dem Benutzer wesentlich intuitiver vermittelt werden als
beim Brettspiel. Auf diese beiden Punkte wurde beim Design großer Wert gelegt.
2. Regelvereinfachungen
Folgende Regeln wurden vereinfacht, um den Spielfluss zu beschleunigen oder die
Präsentation des Spiels klarer zu machen:
–
Missionskarten wurden
weggelassen. Sie sind beim Spiel mehrerer Menschen am gleichen Rechner ohnehin
nicht realisierbar, da man sie vor dem Gegner geheimhalten muss.
–
Die Risikokarten
wurden aus dem gleichen Grund weggelassen.
–
Beim Angriff und beim
Verteidigen wird immer mit der größtmöglichen Anzahl Armeen gekämpft (3 bzw.
2). Dadurch reduziert sich die Anzahl der Entscheidungen, die vor dem Angriff
getroffen werden müssen, von vier auf zwei, bei nur geringem Verlust an
strategischen Möglichkeiten.
–
Die Würfelergebnisse
werden dem Spieler nicht gezeigt. Er bekommt nur das Ergebnis einer Attacke zu
sehen. Dadurch wird der Benutzer nie mit den recht komplexen Kampfregeln
konfrontiert. Im Brettspiel werden bis zu fünf Würfel geworfen, im
Computerspiel ist es ein einziger Mausklick.
–
Beim
Zwei-Spieler-Spiel wird der neutrale Spieler vom Computer gesteuert.
–
Einer-Armeen werden nicht
angezeigt. Beim Brettspiel muss auf jedem Land zu jeder Zeit mindestens eine
Armee stehen. Wenn nur eine Einheit vorhanden ist, so darf sie nicht wegziehen
und darf nicht angreifen. Vermutlich wurde diese Regel eingeführt, damit die
Spieler den Besitzer jedes Landes leicht erkennen können. Unser Prototyp zeigt
dies jedoch schon durch die Farbe des Landes an. Dadurch können wir auf jedem
Land eine Einheit weniger anzeigen als tatsächlich vorhanden ist. So sieht man
nur die Einheiten, die sich wirklich bewegen oder angreifen können. Man erkennt
dadurch viel besser, welche Möglichkeiten man tatsächlich hat.
3. Usability
Auch hierbei gibt es zwei Designkriterien: Der User soll jederzeit möglichst
genau wissen, welche Möglichkeiten er gerade hat, und er soll diese
Möglichkeiten mit minimalem Aufwand (also möglichst wenigen Klicks,
Mausbewegungen und "Brain cycles") ausführen können.
Ein Beispiel für ein Feature nach Kriterium 1 ist das Blinken der möglichen
Angriffs- und Bewegungsziele. Ein Beispiel nach Kriterium 2 ist der
"Einheiten bewegen"-Dialog, der beim Bewegen von Einheiten zwar oben
links eingeblendet wird, den man aber in vielen Fällen gar nicht braucht, da
man auch direkt durch Anklicken der Länder die Einheiten bewegen kann. Trotzdem
ist der Dialog nicht überflüssig, denn er dient als visuelles Signal, dass man
gerade im Bewegen-Modus ist, und bietet weiterführende Optionen
("Balancing" der Einheiten zwischen zwei Ländern) an.
Ein weiteres Usability-Feature ist der Sound. Hauptziel bei der Implementierung
war es, dem User akustisches Feedback zu seinen Aktionen zu geben. Der
vielleicht wichtigste Sound ist das Fehler-Sample, das abgespielt wird, wenn
man eine illegale Aktion ausführen will. So merkt der User sofort, dass er an
dieser Stelle gerade nicht klicken darf. Dies vermeidet Verwirrungen von der
Sorte "ist durch meinen Klick jetzt etwas passiert oder nicht?"
Weitere wichtige Sounds sind die drei unterschiedlichen Samples für Gewinn,
Unentschieden und Verlust bei einer Attacke. Das einzige optische Feedback bei
großen Kämpfen ist die Veränderung der Zahlen über den Ländern. Dies kann man
leicht übersehen. Nach ein paar Spielen hat der User aber die drei Sounds mit
den verschiedenen Kampfergebnissen assoziiert und muss gar nicht mehr auf die
Zahlen schauen.
So leistet der Sound einen erheblichen Beitrag zur Usability des Produkts.[1]
Weiterhin ist
es in jeder Spielsituation möglich, durch den HilfeButton eine Hilfe zu
starten, die eine Beschreibung der momentanen Phase und der damit verbundenen
Möglichkeiten bietet.
Somit bleibt
es dem Spieler erspart, in einem Regelheft nach der passenden Hilfestellung zu
suchen.
4. Performance
Hier liegen nur unvollständige Daten vor. Auf einem 800 MHz-PC mit
Budget-Grafikkarte läuft die Anwendung in akzeptabler Framerate. Auf
langsamerer Hardware wurden noch keine Tests durchgeführt.
Diese Art der Anwendung hat verschiedene Nachteile in Bezug auf die
Grafikperformance. Es befindet sich grundsätzlich die gesamte virtuelle Welt
mit allen Details im Blickfeld. Die Entfernung zwischen Betrachter und
dargestellten Objekten ändert sich in der Regel nicht, so dass kein Nutzen aus
der Verwendung verschiedener Levels of Detail gezogen werden kann. Die gewölbte
Erdoberfläche führt zusätzlich zu einem hohen Polygon-Count.
Weiterhin trägt der für den Prototyp gewählte Stil zur Verringerung der
Framerate bei, da viele Transparenzeffekte eingesetzt wurden.
Die Möglichkeiten zur Steigerung der Performance sind damit stark
eingeschränkt. Einzig der Verzicht auf einige Transparenzeffekte kommt als
praktikable Lösung in Frage.
Vor der Implementierung weiterer Features müsste also deren Einfluss auf die
Darstellungsgeschwindigkeit bedacht werden.
5. Stand des Prototypen
Der vorgelegte Prototyp ist eine voll funktionsfähige Implementierung des
Spiels. Er ist robust, benutzerfreundlich, optisch ansprechend und in sich gut
geschlossen. Er ist weit genug entwickelt, um realistische Tests zur
Feststellung der Nutzerakzeptanz und Usability durchzuführen, sowie um Feintuning
an den veränderten Regeln vorzunehmen.
Erkenntnisse aus der Verwendung des Prototypen
Erste Tests der Entwickler mit dem frisch fertiggestellten Prototyp haben zu
folgenden Erkenntnissen geführt:
Es gibt noch Usability-Probleme in Verbindung mit der Logik für das Anklicken
und Selektieren der Länder. Nach mehreren Angriffen auf engem Raum verliert man
noch zu leicht den Überblick, von wo nach wo man angegriffen hat, und was ein
Klick auf ein bestimmtes Land jetzt bewirken wird.
Eventuell sollten zusätzliche Informationen angezeigt werden, um für mehr
Klarheit zu sorgen, wie etwa Pfeile vom derzeit aktiven Land zu potentiellen
Angriffs- und Bewegungszielen in verschiedenen Farben.
Hier wird ein Tradeoff zwischen zwei wichtigen Designkriterien – schneller
Spielfluss und intuitive Benutzbarkeit - deutlich. An manchen Stellen kann man
"abkürzen", z.B. schon eine neue Attacke starten während die alte
noch im Gange ist. Ein zusätzlicher Bestätigungs- oder Abschlussklick würde die
Spielmechanik verständlicher machen, aber gleichzeitig den Experten
frustrieren, da es ihn zu unnötigen Mausklicks zwingt. Ein möglicher Ausweg
könnte ein abschaltbarer Anfängermodus sein.
Die 2D-Karte hat eine bessere Usability als die 3D-Ansicht. In der 2D-Ansicht
entfällt das Rotieren der Erde mit der Maus, und der Spieler hat jederzeit alle
Kontinente im Blickfeld. Besonders Personen mit schlechtem räumlichen
Vorstellungsvermögen, und erfahrene Spieler, bevorzugen scheinbar die
2D-Darstellung. Dies wirft die Frage auf, ob die 3D-Darstellung eigentlich nur
überflüssiges und damit störendes Beiwerk ist, und eine reine 2D-Darstellung
vielleicht effektiver wäre. In diesem Fall muss natürlich die Frage gestellt
werden, ob VRML die geeignete Plattform für das Projekt ist.
Es gibt
Alternativen mit größerer Marktdurchdringung, insbesondere Flash.
Diese Frage ist vor weiteren Investitionen genauer zu untersuchen.
6. Eindrücke über VRML als Entwicklungsplattform
VRML ist eine interessante und mächtige Umgebung, in der man sehr schnell zu
sehr ansprechenden Ergebnissen kommen kann. Da sich die Entwickler nicht um
Details der Grafik-Engine kümmern müssen, können sie sich auf Gestaltung und
Interaktion konzentrieren. Viele Probleme, die bei der Implementierung in einer
universellen Programmiersprache nichttrivial sind - "Wie finde ich heraus,
ob der Mauszeiger sich gerade über diesem unregelmäßig geformten Land
befindet?" - sind mit VRML überhaupt kein Thema. Dennoch hat sich die
Entwicklung des Prototyps sehr schwierig und teilweise unangenehm gestaltet.
Ohne VrmlPad,
dass wenigstens die syntaktischen Fehler außerhalb von Scripten verhindert,
wäre die Entwicklung eine Qual. Besonders störend ist, dass es fast keine
Möglichkeit gibt, das Zusammenspiel der vielen Events zur Laufzeit nachzuvollziehen.
Außerdem fällt bei Blaxxun Contact auf, dass die Fehlerbehandlung in Scripten
sehr zu wünschen übrig lässt. Manche Scriptfehler werden gemeldet, andere
werden stillschweigend übergangen, wieder andere führen zum Absturz des
Plugins, und dabei wird gern das ganze System mit in den Tod gerissen. Wenn man
die Arbeit mit Java in einer guten IDE gewöhnt ist, dann ist ECMAscript mit
Blaxxun Contact eine frustrierende Erfahrung. Es sollte daher überlegt werden,
ob man für die weitere Entwicklung die Scripts durch Javaklassen ersetzen kann.
Ein wünschenswerter zusätzlicher VRML-Knoten wäre ein KeySensor, der von jedem VRML-Browser akzeptiert wird. Der von uns verwendete VRML-Browser Blaxxun Contact erkennt diesen zwar, aber aufgrund der Kompatibilität mit anderen Browsern haben wir auf die Verwendung des KeySensors verzichtet.
Die Interaktion über die Tastatur würde zusätzliche Usability bieten. So könnte man z.B. mit der Leertaste die Dimension wechseln um sich schnell einen Überblick über den gesamten Globus zu verschaffen.