Hallo allerseits! Ich bin ein UI / UX-Designer, der sich auf Gaming-Interfaces spezialisiert hat. Ich bin auch Humanist: Alles, was mit dem Kodex zu tun hat, führt zu angeborener Angst und Misstrauen, die ich nicht überwinden kann. Angst vor einem Proger zu haben, ist für einen Designer normal. Aber es gibt ein Problem, das das Leben sehr verkompliziert.
Tatsache ist, dass wir als Interface-Designer bei unserer Arbeit oftmals in die Nähe der internen Sites und Anwendungen kommen und uns sogar ein wenig damit befassen müssen. Diese Anforderung ist besonders in der Phase des frühen und schnellen Prototyping relevant, wenn Sie etwas auf Ihrem Knie sammeln möchten, das eine Vorstellung vom Endprodukt vermittelt, die erforderliche Mindestfunktionalität aufweist und auch anständig aussieht. Die meisten Designer (einschließlich meiner selbst) verfügen jedoch nicht über die erforderlichen Kenntnisse, um einen eigenen Schnittstellenteil des Prototyps mithilfe von Code zu erstellen und zu bearbeiten. Und das ist auch branchenüblich.
In Kenntnis dieser humanitären Funktion haben mitfühlende Programmierer (zusammen mit anderen guten Leuten) eine ausreichende Anzahl von Tools erstellt, um ein Design zu erstellen und es auf realen Geräten zu testen, ohne eine einzige Codezeile zu schreiben. Diese Tools können auf Anforderung des Typs „Interface-Prototyping-Programm“ einfach gegoogelt werden. Dies sind Sketch, Adobe XD, Figma, Principle, InVision, Marvel usw. Sie sind großartig. Sie retten Millionen von Nervendesignerzellen (und möglicherweise ein paar Leben). Es wurden Hunderte von Artikeln über sie geschrieben, die von UI / UX-Designern auf der ganzen Welt zu Recht gelobt werden.
Diese Tools sind jedoch in erster Linie auf Entwickler von Web- und Mobilanwendungen zugeschnitten. Für Spieleentwickler (und wir beschäftigen uns hier ausschließlich mit Spieleentwicklern) sind sie schlecht geeignet.
„Moment mal, was ist der Unterschied?“, Fragst du. Spiele sind auch Anwendungen, oder? Nicht wirklich. Spielspezifikationen korrigieren den Produktionsprozess erheblich.
Lass es uns richtig machen.
Erstens basieren „gewöhnliche“ Nicht-Gaming-Anwendungen meist auf dem Prinzip der einfachen Lösung von Benutzerproblemen. Zum Beispiel möchte ich ein bestimmtes Problem lösen - Geld auf die Karte von Serege überweisen - und dazu eine Bankanwendung öffnen. Wie schnell ich meine Frage lösen kann, hängt davon ab, wie zufrieden ich mit dieser Interaktion bin. Nach der Übertragung schließe ich die Anwendung und vergesse sie für eine Weile. Ich bin zufrieden, die Bank ist zufrieden, Seryoga ist zufrieden. Dies ist ein verständlicher, linearer Weg von Punkt A nach Punkt B.
Die Bank ist wie ich daran interessiert, Benutzeraufgaben so schnell wie möglich abzuschließen. Er schafft sie nicht speziell. Schematisch sieht es so aus:
In der Unterhaltungsbranche (wo das Haupteinkommen aus Werbung stammt) kann ein Nutzer umso mehr Gewinn erzielen, je mehr Zeit er in einem Dienst verbringt. Aus diesem Grund startet YouTube selbst ohne Aufforderung das nächste Video und stiehlt sich über die Algorithmen, die dieses Video für Ihre Interessen auswählen. Bei Handyspielen das gleiche. Der Wunsch, Spaß zu haben und gewissermaßen eine Dosis Dopamin zu bekommen, ist eine benutzerdefinierte Aufgabe. Aber sie hat keine definitive, endgültige Lösung, die Content-Produzenten verwenden. Wir möchten, dass Sie sich nicht von unseren Spielen lösen. Im Allgemeinen.
Daher verwenden Spiele Zyklen, in denen die Spieler neue Aufgaben ausführen und diese geschickt von einer Aktivität auf eine andere übertragen. Es sieht ungefähr so aus:
Eine solche Struktur ist bereits wesentlich schwieriger zu prototypisieren. Nennen Sie dieses Spiel Feature
Hinterhalt Nr. 1 . Es gibt noch andere.
Hinterhalt Nr. 2 Das Spiel ist in erster Linie ein Gameplay. Das Interface ist nur eine Bindung, ein Rahmen für einen Diamanten (obwohl in einigen Spielen das Interface = Gameplay, aber lassen Sie uns nicht über traurige Dinge sprechen). Ohne dieses Juwel in der Mitte ist es oft schwierig zu beurteilen, wie gut oder schlecht Ihre Benutzeroberfläche ist (und jetzt spreche ich nicht über das Aussehen). Das Problem ist, dass das Gameplay nicht in Tools für das Prototyping integriert werden kann, sondern in verschiedenen Programmen, in verschiedenen Welten. Und wenn es kein Gameplay gibt, gibt es auch kein Spiel. Es wird kein Kontext benötigt.
Hinterhalt Nr. 3 In Spielen gibt es sehr ungewöhnliche Elemente und / oder Animationen. Die Palette der Elemente ist viel breiter als auf Websites oder in Büroanwendungen. Nicht jedes Prototyping-Programm kann sie überhaupt neu erstellen.
Hinterhalt Nr. 4 Spiele werden auf Game-Engines gemacht. Prototyping-Tools werden mit ihnen über ... nichts synchronisiert. Sie sind einfach nicht dafür ausgelegt. Alles, was in * dem Namen des Programms für das Prototyping * getan wurde, werden Sie (oder Ihr armer Kollege) dann erneut in der Engine erstellen. Von Grund auf neu. Und es ist keine Tatsache, dass es gleichzeitig möglich sein wird, alles mindestens so zu wiederholen, wie es im Prototypen war: Die Fähigkeiten der Programme sind unterschiedlich. Aus diesem Grund stapeln sich große Player wie Game Insight (
Video ) oder Pixonic (
Artikel ) in internen Tools, die Photoshop irgendwie synchronisieren, Sprites ausschneiden, sie in der Engine zusammenbauen, Stile verwalten usw.
Ja übrigens. Randbemerkung. Ich habe nur mit Flash- oder Unity-Spielen gearbeitet. Flash ist bereits gestorben, es wird also hauptsächlich um Unity gehen. Ich gehe davon aus, dass alles Plus oder Minus in Bezug auf andere beliebte Spiele-Engines zutrifft, aber dies ist nicht korrekt.Was führt eine solche Verdoppelung der Arbeit? Die Bemühungen, mehr oder weniger
komplexe Interface-Prototypen zu entwickeln und zu unterstützen, nehmen natürlich rasant zu. Lass es relativ billige Designer-Humanuhren sein (sorry Leute), aber trotzdem.
Ich möchte nicht sagen, dass Prototyping von Spieloberflächen mit Standardwerkzeugen dumm ist. Natürlich nicht: Vorbereitende Arbeiten bei der Herstellung der Schnittstelle sind besser als deren Fehlen. Es ist nur so, dass die Art und Weise, wie wir Designer kennen, Einschränkungen und Probleme aufweist, die vermieden werden können. Dazu später mehr.
Da ist so ein Typ,
Om Tandon . Er hat viele Artikel über Gaming UI / UX veröffentlicht, und im Allgemeinen scheint es in dieser Angelegenheit eine Art Fummelei zu sein. Zumindest schreibt er sehr selbstbewusst (von ihm habe ich übrigens Bilder und einige Ideen für diesen Artikel gezeichnet). Ich rate Interessenten, den entsprechenden Zyklus seiner Artikel auf LinkedIn zu lesen (VPN nicht vergessen): den
ersten ,
zweiten und
dritten Teil. Sie können sich auch sein
Video von einer Konferenz in London ansehen. Es ist besser, sofort damit aufzuhören, bevor Sie mit dem Lesen dieses Artikels fortfahren Ich werde mich stellenweise auf sein Material verlassen.
Trotz der Tatsache, dass Ohms Idee, Prototypen so schnell und billig wie möglich an die Endprodukte heranzuführen, im Allgemeinen gefällt mir, kann ich ihm nicht zustimmen. Er behauptet zum Beispiel, dass es im Vergleich zum „Designer“ um ein Vielfaches mehr Zeit und Mühe kostet, um dasselbe Ergebnis im Gameplay-Prototyp (Ohm nennt es Dev-Prototyp) zu erzielen. Konkrete Zahlen sind angegeben: Die Erstellung
dieses Prototyps mit Principle (einem der gängigen Prototyping-Tools) dauert
5-7 Tage , und laut Ohm benötigt das Team
20-30 Tage , um die gleiche Funktionalität im Motor zu implementieren. Und es geht nicht darum, „alles der Schönheit entsprechend zu machen“, sondern nur darum, am Ausgang ein identisches Ergebnis zu erzielen. Meiner Meinung nach ist die Zahl stark übertrieben.
Zweitens sind Oms zitierte Prototypenbeispiele noch immer größtenteils linear. Hierbei handelt es sich entweder um Tutorials mit einer Abfolge der einzig wahren Aktionen oder um eine Reihe von Bildschirmen, auf denen Sie in die Richtungen "dort" und "hier" navigieren können, oder um eine Imitation der lokalen Mikrointeraktion. Ja, sie sehen köstlich aus, aber ich habe dort keine Spielzyklen oder komplexe Logik gesehen.
Drittens gibt es in Ohms Prototypen, die im Prinzip hergestellt wurden, aus den bereits beschriebenen Gründen kein Gameplay und es kann nicht das Gameplay selbst sein. Es gibt nicht einmal 3D als solches! Es handelt sich nur um eine flache Benutzeroberfläche / UX, die vom Spiel selbst isoliert ist. Meiner Meinung nach verringert dies ihren Wert. Obwohl Om behauptet, dass solche Lösungen geeignet sind, ungefähr 80% der Spielgenres überzeugend zu emulieren.
Viertens ist der spätere Einsatz von Om in der Usability-Forschung einer der Hauptgründe für die Entwicklung eines Schnittstellenprototyps. Das ist großartig und richtig, aber wie oft sind Sie auf kompetente (zumindest einige) Usability-Studien bei einheimischen Spieleentwicklern gestoßen? Werden solche Prototypen für kleine Teams und Studios benötigt, die nicht dieselben Studien durchführen? Wenn der
Gameplay- Prototyp ein offensichtlicher und obligatorischer Bestandteil der Entwicklung eines Spiels ist (vorausgesetzt, Sie erstellen kein Transparentpapier aus einem anderen Projekt), ist es sinnvoll, sich mit
"Designer" -Prototypen zu beschäftigen - dies ist eine offene Frage.
Nach meiner Erfahrung löst die einfachste nicht-interaktive
Karte von Bildschirmen in Form eines starken Bildes die allermeisten Probleme bei der Interaktion und den Verbindungen zwischen Bildschirmen. Dieses Bild wird in einer halben Stunde gesammelt und nur die in Photoshop (Illustrator) gezeichneten Modelle werden dafür benötigt. Dies ist am häufigsten zu stoppen.
In welchen Fällen ist es sinnvoll, zu einem interaktiven und sehr detaillierten (Ohm nennt das
High-Fidelity ) Prototyp überzugehen? Nuuu ... Zum Beispiel, wenn Ihr Kunde die meisten visuellen Materialien und nicht das BW-Schema benötigt, um die Arbeit anzunehmen. So etwas passiert.
Oder wenn Sie einen schönen Demo-Build erstellen möchten, den Sie den Anlegern zeigen und am Telefon fahren können.
Oder wenn das Gameplay des Projekts oder seines Einzelteils so neu ist, dass es im Allgemeinen unklar ist, wie man eine Interaktion damit aufbaut, und ständige Zyklen von Hypothesentests erforderlich sind.
Oder wenn Sie den Versuch und die Störung in den Schnittstellen beschleunigen möchten, die Programmierer währenddessen entladen.
Oder wenn Sie ein simuliertes Produkt für Usability-Tests benötigen.
Kurz gesagt, ich würde nicht empfehlen, standardmäßig einen detaillierten Prototyp eines Spiels mit einer Benutzeroberfläche zu erstellen, aber es gibt Fälle, in denen dies wirklich erforderlich ist. Entscheiden Sie einfach, warum Sie Ihre Ressourcen dafür ausgeben und welche Art von Auspuff Sie erhalten möchten.
Also nochmal kurz. Ich sehe
drei Hauptmöglichkeiten, um die Spieloberfläche zu prototypisieren:
1) Beschränkt auf eine Karte von Bildschirmen. Kümmern Sie sich nicht um interaktive Prototypen, wenn Sie nicht verstehen, was und wie Sie sie testen möchten.
2) Machen Sie aus einem primitiven (buchstäblich gleitenden Bild mit Übergängen) einen interaktiven Prototyp in dem Programm, in dem es sich schneller entwickeln wird. Dies ist eine Variante für diejenigen, die verstehen, was und wie sie überprüfen möchten, und die nicht besonders detailliert sein oder die Benutzeroberfläche mit dem Gameplay verbinden müssen (Sie interessieren sich beispielsweise nur für den Meta-Teil des Spiels). Es kann auf dem Gerät angesehen werden.
Wenn Sie jedoch objektiv etwas benötigen, das dem tatsächlichen Produkt näher kommt, ist dies die dritte Option, auf die wir näher eingehen. Erstellen Sie dazu einen
Prototyp der Benutzeroberfläche direkt in Unity , lieber Freund-Designer. Es ist einfacher als Sie denken.
Tatsache ist, dass Einheit ein ganzes Ökosystem ist, ein riesiger Mähdrescher. Teilweise beängstigend, manchmal monströs und unangenehm, aber definitiv mit seinen Pluspunkten. Unabhängig davon, welches zusätzliche Feature Sie an der Engine befestigen möchten, steht es wahrscheinlich bereits im
Asset Store zum Download zur Verfügung. Manchmal sogar von anständiger Qualität. Designtools sind keine Ausnahme.
Ich persönlich mag
DoozyUI , mit dem Sie ohne großen Aufwand separate Bildschirme erstellen, Verknüpfungen und Übergänge zwischen ihnen hinzufügen und Schnittstellenanimationen schnell erstellen können. Da für Werbung keine zusätzlichen Kosten anfallen, sage ich, dass dies keineswegs das einzige auf dem Markt erhältliche Tool ist. Und wahrscheinlich auch nicht das Beste. Er bestach mich mit einer Vielzahl von Tutorials, einer reichen Geschichte und seinem eigenen System zur Anzeige von Verbindungen zwischen Bildschirmen. Schau dir diese Schönheit an!
Es gibt jedoch auch andere großartige Lösungen für die Erstellung komplexer Bildschirmsysteme in Unity ohne fundierte Codekenntnisse. Sie müssen lediglich einen kleinen Teil Ihrer Zeit in die Suche investieren und tiefer in den Asset Store eintauchen.
Grundsätzlich können Sie auf Erweiterungen verzichten und das verwenden, was Unity standardmäßig anbietet. Nur für die humanitäre Psyche wird es viel schmerzhafter sein. Sie müssen verstehen, dass der Unity-Neuling zu Beginn in jeder Situation NN Stunden Training beobachten muss (oder ständig Programmierer ziehen muss, wie in meinem Fall). Trotzdem ist der Motor nicht für Designer konzipiert, sondern eine Umgebung, die anfangs unserem Bruder feindlich gesinnt war. Aus diesem Grund betrachten viele Spiele-UI / UX-Designer Unity-Funktionen nicht einmal als Werkzeug für ihre Arbeit. Aber du bist nicht einer von denen, oder?
Was haben Prototyping-Interfaces für Spiele in Unity noch einmal davon?
Sie lassen sich leicht in den "Gameplay" -Prototyp integrieren und vermitteln ein umfassenderes und eindrucksvolleres Bild des zukünftigen Produkts.
Teile von Prototypen, die in Unity hergestellt wurden, können direkt in einem Abschlussprojekt wiederverwendet werden. Es wird nicht vollständig funktionieren - Programmierer werden höchstwahrscheinlich anbieten, Ihre Designerweiterungen für Unity an einem tieferen Ort anzubringen, aber in Teilen und auf separaten Bildschirmen ist dies sehr gut möglich.
Solche Prototypen funktionieren auf Geräten genau so, wie Sie es möchten. Wird richtig gedehnt und skaliert. Betrachtet Pony und sichere Bereiche. Keine Unstimmigkeiten mit dem Endergebnis, Schönheit!
Solche Prototypen können einfach und schnell "on the fly" bearbeitet werden. Es ist nicht notwendig, dasselbe Werk zuerst im Prinzip, dann in der Einheit zu wiederholen. Sie können sogar etwas tun, ohne Photoshop zu durchlaufen.
Owning Unity ermöglicht dem Designer den Zugriff auf dreidimensionale Schnittstellen und die Steuerung der Schnittstelle vom Inneren der Engine aus.
Neben direkten Prämien gibt es begleitende: Das Kennenlernen des Motors erleichtert das Leben im Allgemeinen erheblich und steigert Ihren Wert als Spezialist auf dem Arbeitsmarkt.
Im Allgemeinen wollte ich das alles sagen.
Kolleginnen und Kollegen, haben Sie keine Angst zu experimentieren! Schauen Sie sich die Motoren, mit denen Sie arbeiten, und ihre Fähigkeiten genau an. Mach mehr, kümmere dich, sei interessiert. Das zahlt sich aus.
Und dafür muss man kein Technikfreak sein.