können Sie einen Blick auf die Dokumentation von FishFodder werfen.
Transcription
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 [email protected] [email protected] [email protected] 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