können Sie einen Blick auf die Dokumentation von FishFodder werfen.

System Name:
Fish Fodder
Course Number: 119320a
Course Name:
User Interface Design
Felix Beifuß
Marcel Schmitt
Benedikt Hensle
fb055@hdm-stuttgart.de
ms343@hdm-stuttgart.de
bh041@hdm-stuttgart.de
Einführung
Please add a quick introduction of the system, the domain and your reasons for picking domain and system.
Dieses Dokument beschreibt die Konzeption des User Interface eines Android-Games namens „Fish Fodder“.
„Fish Fodder“ ist ein Single&Multiplayer Tower Defense Game für mobile Android-Geräte. Der entscheidene
Unterschied von „Fish Fodder“ ist, dass der Spieler den Weg, den die gegnerischen Einheiten entlanglaufen,
selbst beeinflussen kann indem er seine Tower geschickt auf dem Spielfeld platziert und somit der Weg der
gegnerischen Einheiten nicht vorgegeben ist. So ist es möglich einfache Verteidungsanlagen zu errichten, als
auch komplexere Strategien zu erlernen und zu perfektionieren. Ebenso ist ein Multiplayermodus geplant,
da es keine vergleichbaren Spiele mit Multiplayermodus für mobile Geräte gibt.
Zweck dieses Dokuments
Please define the purpose of this report e.g. this report includes… or excludes…. Because…
Dieses Dokument dient dazu, die Spielidee und vor allen Dingen unser User Interface Design genauer zu
verstehen und zu erklären. Grafikdesign, Implementierung und vor allem User Interface Design Aspekte
werden in diesem Dokument weiter erläutert und begründet. Es handelt sich bei diesem Bericht um eine
Spezifikation über die Funktionalität und das Design des Spiels.
Team / Personal Objectives


Please add personal or team objectives or goals…
E.g. design a state of the art “location based games”

E.g. advance my knowledge in the area of “Flash game development”

E.g. gain experience in the area of user interface design

Etc.
Als die Teambildungsphase beendet war, haben wir uns schnell darauf geeinigt, ein Multiplayerspiel für
mobile Endgeräte konzipieren zu wollen. Der Grund ein Spiel designen zu wollen, entsprang unseren Plänen
ein Spiel dann auch als Projekt im Studium umzusetzen. Alle Informationen die wir dieses Semester
gesammelt haben, sind somit ein riesiger Vorteil für uns. Die Wahl auf Android als Betriebssystem unseres
Spieles fiel aufgrund der Tatsache, dass unser Team nur Androidgeräte besitzt und wir bereits mehr Erfahrung
mit Java als mit Objective C haben.
Die Entscheidung, ein Towerdefense Game zu entwickeln, war jedoch eher spontan. Wir hatten viele Ideen,
die wir jedoch nach kurzer Zeit verworfen hatten, bis wir unseren gemeinsamen Nenner gefunden hatten:
Towerdefense. Und als wir uns einig darüber waren, dass State-of-the-art Towerdefense Games dem Spieler
relativ wenig Freiraum geben und keine Multiplayerpartien anbieten, wollten wir dies mit unserem Spiel
ändern.
Wir wollten die wesentlichen Grundprinzipien des User Interface Designs erlernen, und diese auch bei Spielen
einsetzen können. Oft ist bei guten Spielen die Menüführung, Farbgestaltung und die Bedienung, vor allem
bei mobilen Spielen, verbesserungswürdig. Außerdem erhielten wir Einblick nicht nur in das User Interface
Design, sondern mussten uns auch viele Gedanken und Prinzipien der Spieleentwicklung aneignen, um nicht
nur ein optisch ansprechendes Spiel zu entwickeln, sondern ein optisch ansprechendes und inhaltliches gutes
Spiel zu konzipieren und entwickeln.
Außerdem wollten wir versuchen, ein anderes Setting als die meisten Towerdefense Games anzubieten, die
gerade auf dem Markt sind. Es geht andauernd um Zombies, Skelette, Fantasy und Sonstiges. Daher wollten
wir ein buntes, witziges Setting entwickeln, das sowohl die Seriousgamer als auch die Casual Gamer
anspricht, aber ohne eine der beiden Spielergruppen zu bevorzugen. So soll es keine ingame Purchases geben,
die Spielernm die bereit sind Geld für dieses Spiel auszugeben, irgendwelche Vorteile im Spiel gewähren. So
soll Fish Fodder ein einfaches, klassisches Spiel werden, ohne irgendwelchen Trends in Sachen Vermarktung
oder pay-to-win Mechaniken zu folgen.
The System and it’s Users
Please add a general introduction to the system.
„Fish Fodder“ besitzt einen klassischen Singleplayer Modus, in dem der Spieler durch das Setzen von Towern
einen Pfad vorgibt, den die creeps ablaufen und Schaden von den Towern bekommen. Ziel ist es, eine
gewisse Anzahl creepwaves abzuwehren, ohne eine vorgegebene Anzahl an Leben zu verlieren. Man verliert
ein Leben, wenn ein creep einen Punkt am unteren Rand des Levels erreicht. Eine creepwave besteht aus
mehreren creeps, im Falle von Fish Fodder sind dies alles Fische. So gibt es auch verschiedene Arten von
Fischen die sich in ihren Eigenschaften unterscheiden sollen. Der gemeine Goldfisch, der unser Logo ziert,
ist das erste creep und hat wenig Lebenspunkte und seine Bewegungsgeschwindigkeit ist niedrig. Andere
creeps haben andere Eigenschaften, wie zum Beispiel die Kugelfische. Diese explodieren wenn ihre
Lebenspunkte auf 0 gesunken sind, und fügen den Türmen des Spielers ein wenig Schaden zu. So muss der
Spieler immer die Augen offen halten und möglicherweise Türme reparieren. Weitere Ideen für andere
Fische gibt es genug, doch gehören diese nicht in die Spezifikation für ein User Interface Design, sondern in
ein detailierteres Gameskript.
Der Multiplayermodus zeichnet sich dadurch aus, dass man gegen einen menschlichen Spieler spielt. Man
muss wie im Singleplayermodus Tower zur Verteidigung aufbauen, allerdings schickt man dem Gegner
creepwaves, die uns zwar Geld kosten, dafür aber ein zeitliches Income geben. Mit dem Geld, dass man von
der Abwehr der gegnerischen creeps bekommt und dem des Incomes gilt es, eine gute Balance zwischen
Verteidigung und Angriff zu finden. Verloren hat der Spieler, der zuerst alle Leben verloren hat.
Die Multiplayerpartien sollen über Bluetooth oder lokales WLAN gespielt werden können, um so vor allem
spontanes Spielen ermöglichen zu können. Ebenso ist es denkbar, eine Multiplayerpartie ortsunabhängig
über einen Server im Internet zu ermöglichen. Hier muss allerdings erst überprüft werden, ob die
auftretende Latenz den Spielspaß trübt.
Domain
Please add a Domain list and some explanation how they might be related to your system
Domain Cloud
State of the art
Design
• Zombies
• Aliens
• Fantasy
• Mittelalter
• futuristische Festungen/Türme
• Laserwaffen
Da alle ähnlichen Spiele nach den obigen Themen designed wurden, ist die Reaktion bei den
Spielern dementsprechend die gleiche: „Nicht noch ein Mittelalter Spiel!“. Somit haben wir das
Design anders gestaltet um so ein uniques Design zu erschaffen und dadurch auch Leute für das
Spiel interessieren können, denen das state of the art Design nicht zusagt.
Gameplay
• Single Player
• Tower sind statisch
• Creeps in Bewegung
• Towers richten Schaden nur in vorgegebenem Radius an
• Spieler muss mit Towern von Hand auf gewisse Gegner zielen
• Weg der Creeps vorgegeben (statischer Weg)
Da das Gameplay eines Towerdefense Spieles nicht allzu stark veränderbar ist, wollen wir durch die
Abkehr von statisch vorgegebenen Pfaden der creeps dem Spieler mehr Freiraum geben. Da er
durch sein Towerplacement den Pfad vorgibt, kann er so auf die verschiedenen Levels, Tower und
Creeparten besser reagieren und kann so verschiedene Strategien ausarbeiten. Dies ist das
Alleinstellungsmerkmal von Fish Fodder, da kein anderes Spiel diese Art der Towerdefense
anbietet.
Ob man von Hand auf spezielle Gegner zielen muss, dieso also antippen damit die Tower diese
angreifen, kann zwar interessante Spielzüge ermöglichen, ist allerdings erst bei einem
funktionierenden Prototypen auf die Effektivität und Akzeptanz der Spieler überprüfbar.
Plattformen
• überwiegend Apps für die Mainstream-Plattformen (iOS, Android, Windows Phone)
• auch als Web-Anwendungen oder als Communitymodifications in großen Spielen integriert
(Warcraft III)
Beispiele
• „Wintermaul Wars“ Mod for Warcraft 3 The Frozen Throne
• Plants vs. Zombies
• Trolls 'n' Orcs
Wie bereits erwähnt wurde, sind die Spiele oft alle „gleich“. Lediglich das Setting beeinflusst ihr
Design, die grundsätzlichen Spielprinzipien sind jedoch die gleichen. Als Ursprung für Fish Fodder
kann man „Wintermaul Wars“, eine Modifikation einer Community des Spieles Warcraft III
ansehen, da man hier den Weg der Creeps durch das Towerplacement beeinflusst, und man das
Spiel über das Internet in Echtzeit gegen andere menschliche Spieler gespielt hat.
Plants vs. Zombies ist ebenso zu erwähnen, da hier zwar ein Teil des Design dem genretypischen
Zombiesetting entnommen wurde, jedoch passen die Tower, hier Pflanzen, überhaupt nicht ins
Setting, dennoch macht das Spiel nicht nur wegen diesem Bruch sondern auch wegen des
neuartigen Gameplays für eine Towerdefense viel Spaß. Wir versuchen also quasi mit Fish Fodder
die alten, erfolgreichen Prinzipien aus den Communitymods von Warcraft III auf ein mobiles Gerät
zu portieren.
Personas
Please consider using the provided templates such as the table and maybe some explanations.
Kevin Kryziak
Alter
14
Geschlecht
Männlich
Bildung
Realschüler
Bildungsmotivation
Schwach, ist nicht motiviert zu lernen
IT-Kenntnisse
Nutzt Computer um zu spielen und mit Freunden verbunden zu sein
(Social Networks)
Motivation für Nutzung der UID Möchte gegen seine Freunde gewinnen und der Beste sein.
Anforderungen an die UID
Bedienung sollte intuitiv durch ausprobieren erlernt werden können. Er
möchte sich das Spiel nicht von jemand anderem erklären lassen
müssen.
Patrick Richter
Alter
19
Geschlecht
Männlich
Bildung
Student
Bildungsmotivation
Durchschnittsstudent. Investiert ein paar Stunden die Woche um zu
Lernen.
IT-Kenntnisse/Nutzung
Nutzt IT hauptsächlich um sich zu informieren (Nachrichten,
Vorlesungsskripte etc.). Gelegentlich auch um zu spielen.
Motivation für Nutzung der UID Unterhaltung z.B. während U-Bahnfahrt oder Vorlesung.
Anforderungen an die UID
Einfache Bedingung, möchte sich nicht lange einarbeiten müssen
Gangolf-Peter Wöllner
Alter
29
Geschlecht
Männlich
Bildung
Studiert Naturschutz/Landschaftsplanung
Bildungsmotivation
Sehr motiviert, möchte etwas verändern können.
IT-Kenntnisse/Nutzung
Sehr selten. Besitzt einen alten Desktop-PC zu Hause, den er selten
benutzt. Wenn dann um Umweltkampagnen im Netz zu starten oder
sich über spezielle Themen zu informieren. Dafür setzt er sich meistens
mit Freunden zusammen.
Motivation für Nutzung der UID Er spielt es auf dem Smartphone eines Freundes, weil dieser vermutet
hat, dass das Spiel eine kritische umweltschützende Botschaft hat
(Fische müssen durch Angler hindurch ins offene Meer fliehen).
Anforderungen an die UID
keine
Context of Use
// Persona Geschichte
Please describe the context of use (e.g. using storytelling or use cases)
Patrick hat verschlafen. Wie jeden Montag fällt es ihm schwer, aus dem Bett zu kommen. Als er es endlich
geschafft hat und sich auf dem Weg zur S-Bahn schnell sein Frühstück-to-go mitnimmt, trifft er in der SBahn auf seinen ebenso verschlafenen Kommilitonen Marc. Da den beiden jetzt eine 20 minütige Fahrt
bevorsteht, schlägt Marc vor eine Runde FishFodder zu spielen. Patrick holt sein Handy aus der Tasche, lädt
die App schnell herunter und Marc erklärt ihm während der Wartezeit das Spielprinzip. „Ach so, das ist ja
wie bei Warcraft III früher, das habe ich während der Schulzeit immer gespielt“, entgegnet ihm Patrick, und
er weiß sofort wie das Spiel funktioniert. Die beiden spielen über Bluetooth, und nach 10 Minuten gewinnt
Patrick bereits. „Das gibt es doch nicht, ich spiele das Spiel bereits seit 2 Wochen, und du gewinnst?“
entgegnet Marc. Während den Vorlesungen, die Patrick und Marc nur wegen dem Gewissen besuchen,
spielen die beiden weiter, bis Marc aufgrund einer neuen Strategie gewinnt. „Komm, gehen wir was essen.
Wir können heute Abend aber gerne nochmal spielen, das macht einfach mehr Spaß als Lernen“, schlägt
Patrick vor. Dies tut er aber nicht nur aufgrund seines Hungers, sondern auch um sich eine bessere Strategie
auszudenken.
Environments
Please describe the selected environments and add some justification for the selection.
Fish Fodder soll in jeder Umgebung gespielt werden können. Spielt man alleine, kann man das Spiel in jeder
Situation und Umgebung spielen, die man sich vorstellen kann. Die einzige Einschränkung hierfür ist, dass
man beide Hände zum spielen benötigt, da man das sein Gerät im Querformat halten muss. Somit kann
man das Spiel in der S-Bahn, zuhause oder sogar in Vorlesungen spielen.
Spielt man hingegen im Multiplayermodus benötigt man entweder einen W-LAN Accespoint
(Internetverbindung ist nicht notwendig, Spieldaten werden lokal geroutet), oder der Mitspieler muss sich
in einer für Bluetooth geeigneten Reichweite befinden. Zwar soll eine durschnittliche Multiplayerpartie ca.
10-15 Minuten dauern, dennoch sind längere Spiele möglich, falls die Spieler die selbe Strategie verfolgen
oder beide erfolgreiche Fish Fodder Spieler sind. Sollte die Zeit knapp werden, muss es möglich sein das
Spiel zu speichern und zu einem späteren Zeitpunkt wieder aufzunehmen, da ansonsten spontane Spiele
während der Wartezeit auf die S-Bahn kaum stattfinden.
Graphic Design Requirements
Please add a detailed graphic design documentation using the provided headlines e.g. gestalt psychology,
form’s, colors, etc. etc.
Gestalt Psychology
Wir haben uns beim Skizzieren und Ausarbeiten aller Spielgrafiken an einen cartoonmäßigen Stil orientiert.
Dies sieht man vor allen an den Fischen, da diese über eine starke runde Form und dicke Konturen verfügen.
Mittels dieser Überzeichnung wirken die Fische humorvoll und passen so in das gesamte Spieldesign. Die in
unserem Mockup verwendeten Tower müssen nochmal überarbeitet werden, um dem Cartoonstil der Fische
ähnlicher zu werden, um so ein durchgehendes Designprinzip einzuhalten.
Forms
Für Fishfodder nutzten wir ausschließlich runde und elliptische Formen, da diese lebendig, weich und
dynamisch wirken. Außerdem unterstützen diese Formen den Cartoonstil und vervollständigen so den
humorvollen, spielerischen und drolligen Look unserer Grafiken.
Color
Die drei Hausfarben des Indie-Garage-Unternehmens „Fish Fodder Silo“ sind Orange, Grün und
Blau. Die selben Farben werden bei der Gestaltung des Games verwendet. Diese Auswahl der
Farben basiert auf dem Konzept der complementation (Komplementierung). Im unteren Bild ist das
Drei-Farben-Schema abgebildet.
http://www.colorschemedesigner.com
Diese Farben werden hauptsächlich im Logo des Spiels (Fish Fodder) und im Hauptmenü des Spiels
verwendet. Für die Gestaltung der bildhaften Game-Elemente (z.B. Fische, Felsen etc.) gibt es
keine Farbspezifikationen, welche beachtet werden müssen. Lediglich die UI-Komponenten
müssen sich an die Design Spezifikation halten.
Buttons und Label verwenden die Farben
Symbols and signs
Die Symbols und Signs werden wie für Games typisch skeuomorph gestaltet.
Da das Setting des Spieles über Fischen und Angeln verfügt, bieten sich viele Symbole aus der
Fischerei an. So wollen wir einige spielhafte Metaphern nutzen, die das gewisse Etwas des Spieles
ausmachen und gleichzeitig die Bedienmöglichkeiten eines Gerätes mit Touchscreen ausnutzen.
So soll der erste Screen den der Spieler nach Öffnen der App sieht erst nur aus dem Logo des
Spieles und einem animierten Wasserhintergrund bestehen, und sobald der Ladevorgang
abgeschlossen ist, fallen zwei Angelhaken vom oberen Rand des Bildschirmes in den unteren. Der
eine Haken hat die Aufschrift „play“, der andere „options“. Sobald der Spieler nun einen der Haken
antippt, öffnet der Fisch des Logos seinen Mund und seine Blickrichtung zeigt in die Richtung des
Hakens. Um das Spiel zu starten, schiebt der Spieler den „play“ Haken in den Mund des Fisches,
und gelangt so zum nächsten Screen, bei dem er sich für ein Singleplayer oder Multiplayerspiel
entscheidet.
Layout
Hauptmenü
Die Navigation im Hauptmenü hat eine hierarchische Struktur mit geringer Tiefe.
Das Navigationsmodell im Hauptmenü ist eine Multi Level Navigation. Das Layout des Hauptmenüs ist sehr
einfach, da das Spiel schnell gestartet werden soll und der Spieler sich so nicht lange in einem tiefen Menü
durchklicken muss. Die Buttons werden zentriert platziert und umlaufen sich horizontal.
Game-Menü
Das Layout des Games ist ein 3-Spalten Layout. Die linke und rechte Spalte haben jeweils eine
Breite von etwa 15% des Bildschirms. In diesen beiden äußeren Spalten werden die Zustände des
Spiels (z.B. Zeit, Geld, Gegner, Mini-Map) angezeigt. In der mittleren Spalte befindet sich das
eigentliche Spielfeld. Dort interagiert der User mit den Game-Elementen.
Logos
Technical Requirements
Please add a short description of the type of device(s), underlying system(s) or database(s) necessary for
the prototype system. Did you use any templates or design guidelines?
Fish Fodder ist eine App, die auf allen neueren Smartphones und Tablets mit einem Android Betriebssystem
lauffähig ist. Fish Fodder wird mit Unity entwickelt.
Um Fish Fodder zu implementieren muss man einige technische Voraussetzungen beachten. Darunter fällt
natürlich die Spielmechanik, also das Towerplacement, das automatische Angreifen der Türme und die
korrekte Schadensberechnung sowie die Wegfindung der creeps und deren Bewegung.
Ein wichtiger technischer Aspekt ist weiterhin das Netzworking. Alle spielrelevanten Informationen wie
Position und Lebenspunkte der creeps müssen mittels Pakete und über ein Netzwerkinterface auf den
Geräten synchronisiert und ausgetauscht werden. Es muss also sichergestellt werden, dass die
Kommunikation der Geräte untereinander fehlerfrei und zuverlässig abläuft.
Wichtig für den Spielspaß ist ein gutes Balancing der Creeps und der Tower, da sonst gewisse Taktiken
leichter und billiger sind als andere und dennoch immer zum Erfolg führen. Hierfür gilt es einen guten Weg
zu finden um so ein spannendes und unterhaltsames Spiel zu ermöglichen, und es dabei trotzdem
transparent und nachvollziehbar für den Spieler zu gestalten.
Wir haben keine Vorlagen oder Anleitungen genutzt, da wir selber viele derartige Spiele gespielt haben und
somit bereits ungefähr wissen, wie diese zu entwickeln sind. Ebenso flossen in die Konzipierung von Fish
Fodder das Wissen, dass wir aus anderen Vorlesungen wie Praxis der Spieleentwicklung oder Theory of
Game Development bekommen haben ebenso mit ein.
Detailed System Description
Dieses Schaubild hat sich im Laufe des Semesters als grober Plan für „Fish Fodder“ entwickelt. Da wir
Informatiker sind, sind Baumdarstellungen für uns das geeignete und bekannte Mittel um jeglichen
Sachverhalt darzustellen. Die Knoten des Baumes entsprechen den einzelnen Screens und Buttons im
Spielmenü. Die Blätter sind die Funktionalitäten, die für den jeweiligen Elternknoten notwendig sind. Dieses
konzeptionelle Design ist zwar nicht komplett detailiert, allerdings ist es leicht erweiterbar und eine gute
Grundlage für eine spätere Implementierung. Weiterhin ist es eine Art von paper based Functional Design,
da dieses Schaubild auch anhand des von uns in der Vorlesung erarbeiteten Functional Design entstand.
System Design Approach
Please outline the tools and techniques you used to design your system e.g. “cognitive or mental walk
through”) and justify using that particular tool e.g. used it to ensure completeness of the system because it
helps to look at every step involved in the interaction.
Wir nutzten einen mental walkthrough, um unser System auf completness zu überprüfen. Da wir alle schon
viele Spiele, egal ob auf dem Desktop-PC, auf einer Konsole oder einem Smartphone gespielt haben,
wussten wir bereits grob wie unsere Menüführung und Interaktion im Spiel aussehen muss. Wir haben uns
dann beim Betrachten unseres Mockups gefragt, ob und wie Fehler bei der Bedienung auftreten können,
und ob man diese vermeiden oder leicht rückgängig machen kann.
So ist uns zum Beispiel aufgefallen, dass wir vergessen haben, eine Möglichkeit anzubieten einen bereits
gebauten Tower verkaufen oder verschieben zu können. Daher soll es möglich sein, einen Tower anzuklicken
und diesen über einen Verkaufen Button zu verkaufen, oder mit einem Antippen auf ein Ankersymbol
diesen frei verschieben zu können.
Da unsere Menüführung jedem Spieler und selbst Nutzern mit wenig Erfahrung geläufig ist, muss diese
nicht weiter getestet oder verbessert werden.
Ein weiterer Aspekt den wir erst mithilfe des walkthroughs erkannt hatten ist die Notwendigkeit eines
Tutorials. Spieler, die bereits Erfahrungen in diesem Genre haben, fällt der Umgang mit dem Spiel leicht,
aber Nutzer ohne diesem Vorwissen müssen wissen, was sie ihre Aufgabe ist und vor allem wie sie ihre
Verteidigungsanlage bauen müssen, wie viel Platz im Grid die Tower benötigen und wie viel Platz die Creeps
benötigen. Diese Notwendigkeit ist uns besonders klargeworden, da wir bei unserem Prototypen während
des Usabilitytests genau diese Beschreibungen vergessen hatten und die Tester, die keine Erfahrung mit
diesem Genre hatten, erst nach Beantworten dieser Fragen die Aufgabe lösen konnten.
UID & GUID Principles
Please describe how you integrated UID or GUID Principles (Please provide information about all principles,
if you didn’t use them please justify why)
An dieser Stelle muss zwischen einem Game und z.B. einer Website unterschieden werden. Bei
Games setzen wir voraus, dass sich der Spieler etwas mehr Zeit nimmt sich in die Bedienung des
Games einzuarbeiten. Es gibt zum Beispiel einen Unterschied ob ein Button einer Website intuitiv
zu bedienen ist und das Ausführen einer Aktion in einem Spiel.
Visibility
Das Grid lässt darauf schließen, dass es Spielelemente gibt, welche ein Feld oder mehrere Felder
einnehmen. Zudem erkennt man anhand des Grid die Spielfläche und wo die Tower und Creeps
sich bewegen werden. Den Zustand seines aktuellen Spiels kann der Spieler am rechten
Bildschirmrand einsehen. Icons machen dem Spieler klar um welche Zustände es sich handelt (z.B.
Geld, Leben, Timer).
Affordance
Zu Beginn des ersten Levels sind ein paar Tower auf dem Grid bereits platziert. Dadurch wird
deutlich wo die Tower platziert werden und wie viel Platz sie einnehmen. Durch eine schon fast
vorgegebene Strategie für die Defense würden die meisten Spieler intuitiv den nächsten Tower
neben dem am weitesten rechts gesetzten Tower platzieren. Dadurch würden sie meistens auch
intuitiv auf das Feld neben diesem Tower klicken.
Durch die Aufteilung des Spiels in ein 3-Spalten-Layout und Gestaltung der Icons wird dem Spieler
klar, dass die Interaktion in der Mitte abläuft und am rechten und linken Bildschirmrand nur
Informationen angezeigt werden.
Feedback
Wenn der Spieler einen Tower platzieren möchte, aber dafür nicht mehr genügend Geld zur
Verfügung hat, werden die Tower im Menü ausgegraut. Klickt der User dennoch auf den
ausgegrauten Tower leuchtet das Geld-Icon rechts oben rot auf.
Die Zustandsanzeigen am linken Rand zeigen dem Spieler an wie viele Creeps der Gegner noch
besitzt, wie viel Geld er hat, wann die nächste Attacke des Gegners startet und wie viele Leben er
noch hat.
Der Spieler bekommt Feedback, wenn er eine Aktion ausführen möchte, welche wegen dem
aktuellen Zustand des Spiels nicht möglich ist. Beispiel: Er möchte einen Tower platzieren, wenn
der Gegner angreift. Dann leuchten die Felder beim Klick auf ein Feld des Grids, rot auf.
Wenn der User scrollt erscheint am linken Bildschirmrand eine MiniMap, welche dem User anzeigt
wo er sich gerade auf dem Spielfeld befindet und dass er gerade die Ansicht des Spielfeldes
verändert hat.
Simplicity
Simplicity im Sinne von einer einfach gestalteten UI ist bei einem Game natürlich nicht sinnvoll, da
es sich negativ auf das „Feeling“ des Games auswirken kann.
Die Aufgaben beim Platzieren eines Towers werden in Schritte eingeteilt. Zunächst muss der
Spieler das Feld auswählen wo er den Tower platzieren möchte. Anschließend öffnet sich ein Menü
in dem er auswählen kann, welchen Tower er platzieren möchte. Nachdem Platzieren
verschwindet das Menü wieder.
Structure
Durch die Verwendung eines 3-Spalten-Layouts kann klar zwischen dem Zustand des Spiels und
dem eigentlichen Spiel unterschieden werden. In der rechten Spalte wird der Zustand des Spiels
angezeigt (Geld, Leben, Timer etc.). Die Zustände werden durch die Nähe und die visuelle
Unterscheidung vom eigentlichen Spiel getrennt. In der Mitte läuft das eigentliche Spiel und die
Interaktion mit dem User ab.
Consistency
Consistency wird nur minimal in unserer App verwendet. Die verschiedenen Unterseiten im
Hauptmenü haben das gleiche Layout. Das bedeutet die Buttons und Überschriften werden an der
gleichen Stelle platziert und der Back-Button befindet sich immer an der selben Stelle. Im Spiel gibt
es nur eine Spielumgebung und keine verschiedenen Ansichten, weswegen sich das Interface an
dieser Stelle nicht ändert und damit das Prinzip Consistency nicht relevant ist.
Tolerance
Ein Punkt wäre, dass er nicht das von ihm gewünschte Feld anklickt, weil z.B. die Felder zu klein
sind.
Die Felder sind deswegen 44mmx44mm groß, was nach den Apple Guidlines für die optimale
Größe eines Button entspricht.
Zudem kann der Spieler strategische Fehler beim Platzieren der Tower machen, könnte er diese
allerdings rückgängig machen, würde das Game seinen Reiz verlieren.
Completeness
Dieser Aspekt ist für Games nicht relevant, da der User keine Aufgaben erledigen möchte (wie z.B.
eine User Interface Dokumentation zu schreiben), sondern er möchte unterhalten werden.
Bricht man Completeness herunter auf eine Aktion des Spiels, so könnte man sagen, dass das
Platzieren eines Towers schon sehr schnell möglich ist.
Prototype Description
Please add a description of the prototype developed, is it paper based, on a device or one the web? Was it
developed using Photoshop, illustrated, a Wireframing tool, etc. Remember a prototype is always an
unfinished version of a system so it should differ from the detailed system description.
Der Prototyp ist ein PDF-basiertes Mock-Up. Durch Interaktivität im PDF wird ein Szenario wie es
im späteren Spiel vorkommen kann, durchgespielt (Vertical Prototype). Es wird in diesem Prototyp
nur ein Single-Player Szenario durchgeführt, da es schwierig ist für ein Multiplayer-Game einen
geeigneten Prototyp zu erstellen, welcher auch effektiv und gewinnbringend evaluiert werden
kann.
Functional Design
Please add wireframes and annotations- if you didn’t develop any please add a good justification for it.
Es macht keinen Sinn ein Wireframes o.ä. für unser Spiel zu entwerfen, da die Interaktion mit dem
Benutzer nicht über klassische UI-Komponenten läuft, sondern mit Elementen der Spielumgebung.
Der Nutzen eines Wireframes wäre sehr gering. Außerdem ist unser konzepzionelles Design eine
Weiterentwicklung unserer paper based Functional Design, und ein Wireframe für unser Spiel nur
für die Menüführung Sinn machen würde. Da aber unser Menü nicht sonderlich anspruchsvoll
oder tief ist haben wir kein Wireframing genutzt.
Mockup’s
Please add screenshot of your prototypes incl. annotations.
Spielstart (mit Mini-Map)
Creeps greifen an
Tower Place Menu
(Mock-Up nach Redesign)
Evaluation and Recommendations
Die Evaluation fand im Usability-Labor der HdM statt. Die Aufgabe der Probanden war es ein
Szenario des Spiels durchzuspielen. Fast alle Probanden kannten das Spielprinzip von Tower
Defense Games. Die Probanden waren keine UID-Experten, sondern mögliche spätere Benutzer.
Evaluiert wurde ein Prototyp, der in Form eines interaktiven PDF-basierten Mock-Ups vorlag.
Zudem wurde eine Eye-Tracker verwendet. Es wurde vor allem die Qualität der Interaktion mit dem
Tower Place Menü, welches im Single Player Modus die einzige Interaktion mit dem Benutzer ist,
evaluiert.
Evaluation Strategy
Please add your evaluation strategy, I suggest you use the provided table.
e.g. explore the overall functionality
Why am I evaluating?
Which usability requirements am I exploring?
Um herauszufinden ob das entwickelte
Design Konzept für das Spielfeld (Grid) und
das Spielmenü (Tower platzieren) intuitiv
und zufriedenstellend bedienbar ist.
e.g. affordance &feedback of the main
navigation
•
•
Visibility, Affordance und Feedback
des Spielfeldes (Grid)
Affordance, Feedback und Structure
des Tower Place Spielmenüs
e.g. sound, text and video
What type of data do I want to collect?
Videos, Heat-Maps, Scan Paths
What am I evaluating?
e.g. the tasks of navigating to a specific submenu
item
•
Die Aufgabe einen Tower auf das
Spielfeld zu platzieren
◦ das Tower Place Spielmenü
öffnen
◦ Navigation des Tower Place
Spielmenü
e.g. time, equipment, low fidelity prototype
What constrains do I have?
•
•
Das Szenario sollte im späteren Spiel
nur 30 Sekunden dauern, dies kann in
einem PDF-Prototyp nicht simuliert
werden.
Interaktivität des PDF-Mock-Ups
funktionierte in Eye-Tracker-Software
nicht, deswegen mussten wir die
Interaktivität simulieren (durch
Navigation mit Tastatur, Proband mit
Maus)
Evaluation Plan
Here is also a template for an evaluation plan you should add.
Evaluation Technique
The Evaluators
• Observation
• Eye-Tracking
Den Pilot Test hatten wir zuvor ohne EyeTracker mit Experten (Kommilitonen)
durchgeführt. Beim Eye-Tracker Test hatten
wir 4 externe Probanden, welche bis auf
einen mit Tower Defense Games vertraut
waren.
The tasks descriptions
Bitte baue das Labyrinth logisch sinnvoll
weiter bis die Creeps angreifen.
The Session
How did you plan the session? Did you set it up
so you can see the face of the user?
Der Proband saß vor dem Bildschirm mit
Eye-Tracker und Webcam. Unmittelbar
daneben saß ein Evaluator, der während des
Tests u.a. seine Gestiken und Mimik
beobachtet hat. Die anderen Evaluatoren
befanden sich hinter ihm und verfolgten
seine Aktionen auf dem Bildschirm.
Evaluation Material
Please describe your evaluation material. E.g. Briefings, introductory material, pre-session questionnaire or
interview plan, task descriptions etc.
Briefing
Den Probanden, von denen die meisten mit Tower Defense Games vertraut sind wurde vorab kurz
das Spiel erklärt. Dass es sich um ein klassisches Tower Defense Game handelt, bei denen die
Angler die Tower und die Fische die Creeps repräsentieren. Den Probanden wurde vorab mitgeteilt
welche Größe des Grids (Spielfeldes) ein Creep (Fisch) und welche die Tower (Angler) benötigen.
Zudem das man 30 Sekunden Zeit hat bis der Gegner angreift bzw. die Creeps angreifen, die Zeit
aber im PDF-Mockup nicht simuliert werden kann. Während der Gegner angreift kann man keine
Tower setzen.
Aufgabenbeschreibung
Bitte baue das Labyrinth logisch sinnvoll weiter bis die Creeps angreifen.
The Pilot Tests
Did you change questions or approach after the first pilot tests? If yes why?
Nachdem ersten Pilot Test haben wir festgestellt, dass wir den Probanden vor der Bedienung des Prototyps
mitteilen müssen, welche Größe ein Creep und welche Größe ein Tower auf dem Grid einnimmt. Die
Aufgabenstellung wurde jedoch nicht geändert.
Evaluation Main Findings
Please add a general description of the main findings in your own words.
Die Probanden, die schon einmal ein Tower Defense Game gespielt hatten kamen mit der
Navigation gut zu recht. Der Anfangszustand des Prototyps hatte eine vorgegebene Strategie und
das grün markierte Feld. Dadurch haben die meisten intuitiv auf das grüne Feld geklickt und kamen
somit in das Towerplacement Menü. Der Proband, der nicht oder kaum auf dem Smartphone spielt
wollte zunächst die Icons am rechten Bildschirmrand anklicken. Die Icons machten wohl für ihn
den Eindrucks als wären sie Buttons, also anklickbar. Deswegen wurden diese Icons anschließend
noch skeuomorpher gestaltet (siehe letzter Mock-Up Screenshot). Mit etwas Unterstützung fand er
dann doch noch ins Towerplacement Menü. Dieses war für alle Probanden verständlich und intuitiv
zu bedienen. Es wurde verstanden, dass wenn die Auswahl im Spielmenü „ausgegraut“ war kein
Heat
ScanMap:
Path Alle
Probanden
Screenshot: User ohne Tower Defense Erfahrung
Geld mehr zur Verfügung stand. Wenn die Probanden ein Feld auf dem Grid angeklickt haben und
es rot aufgeleuchtet hat, haben die meisten Probanden verstanden, dass sie dort nicht bauen
dürfen, weil sie den Creeps den Weg versperren würden.
Detailed Findings
Please add a list of the findings based on the previously selected tasks.
TASK
RESULT
Position auf dem
Grid auswählen
und dadurch das
Tower Place
Spielmenü öffnen
Usability
Anforderungen
wurden bei fast
allen getroffen
Im Tower Place
Spielmenü einen
Tower platzieren
Usability
Anforderungen
wurden getroffen
Accessing video
Usability
requirement hasn’t
been met
SEVERITY CODE
Low
DESCRIPTION
Severe*
User did not find video or did
not understand how to access
video
Recommendations for a Redesign
Please add a list of the recommended change requests
Benutzer mit Tower Defense
Erfahrung hatten keine
Probleme. Derjenige ohne
Kenntnisse war zunächst
etwas verwirrt, da er
wahrscheinlich an klassische
Menüs von Websiten oder
Software gewöhnt ist.
Jeder Benutzer hat das
Spielmenü verstanden und
konnte schnell einen Tower
platzieren
TASK
Position auf dem Grid
auswählen und dadurch das
Tower Place Spielmenü
öffnen
Im Tower Place Spielmenü
einen Tower platzieren
Recommendation
Icons die den Zustand des Spiels
angeben am linken Rand noch
skeuomorpher gestalten.
CHANGE REQUEST
SHOULD HAVE
Wenn kein Geld mehr vorhanden
und kein Tower mehr platziert
werden kann sollte der Anker in
der Mitte des Spielmenü statt
grün rot hinterlegt sein.
SHOULD HAVE
TASK
Größe eines Feldes des Grids
Recommendation
Vergößern der Feldgröße auf
44mmx44mm laut der Apple
Guidelines.
Der Zustand eines Towers sollte
immer sichtbar sein
Diesen Button löschen und neues
Konzept erarbeiten, weil dieses
Konzept unklar ist.
Visuelle Unterscheidung der
eigenen und gegnerischen Fische
CHANGE REQUEST
MUST HAVE
Zustand des Towers
Fish Attack Button
Unterscheidung zwischen
eigenen und gegnerischen
Fischen
SHOULD HAVE
MUST HAVE
NOT REQUIRED
Future Developments
How might state of the art developments change future functionality of your system?
Lessons Learned
Please let me know the lessons you learned and which tools techniques or methods you are planning to use
in the future and why.
Primär sind uns die Unterschiede zwischen der Entwicklung eines User Interface für ein Spiel und
anderer Software oder Websites aufgefallen. Man kann bzw. greift meistens nicht auf vorgegebene
UI-Komponenten zurück, sondern nutzt spezielle Spieledesignprinzipien.
Weiterhin ist uns aufgefallen, dass man jede Idee und jeden Einfall, einfach alles was man während
der Konzeption und Ausarbeitung auch nur kurzfristig für sinnvoll erachtet, sofort aufschreiben
sollte. Und all diese Skizzen, Sätze und Wörter gilt es im Nachhinein sauber und strukturiert auf
Blatt zu bringen, da man so seinen Teammitgliedern bei Unklarheiten oder Fragen sofort
antworten und ihnen bereits Skizzen oder Ähnliches vorlegen kann. Ebenso hilft ein derartiger
strukturierter Aufschrieb auch bei Verbesserungen, da man Probleme und Sackgassen frühzeitig
erkennt und diese noch vor der Implementierung verbessern kann.
Bei Spielen greift man meistens nicht auf UI-Guidelines und klassische UI-Komponenten zurück.
Dadurch war für uns die Verwendung von Wireframes-Tools wie MyBalsamiq nicht notwendig bzw.
sinnvoll. Trotzdem haben wir dieses Tool in einem kleinen Exkurs (Entwurf der Website des GarageUnternehmen) benutzt und würden es in einem anderen passenden Kontext verwenden, da man
sich sehr schnell einen bildhaften Eindruck der Funktionalität z.B. der Website verschaffen kann.
//Hier noch was zu welche Methoden wir in der Zukunft weiterhin nutzen werden. Vllt diese
klickbaren Prototypen auch für kleinere Ideen oder Mybalsamiq weil bla bla des is so geil.
References
http://www.digitalsurvivors.com/profile/digitalsurvivorfds.php