Mission on Mars: erste GUI

Lesezeit: 5 Minuten

Da ich sehr visuell bin, möchte ich schnell etwas sehen, um Dinge besser beurteilen zu können. Daher erarbeite ich mir hier meine erste GUI zum Testen – natürlich projektorientiert.

Grundüberlegungen

Der Spieler landet irgendwo auf dem Mars. Daher muss also eine virtuelle Welt dargestellt werden, die so ähnlich aussieht, wie es auf dem Mars aussieht.

Weiterhin sollen andere Spieler in der selben Welt landen, natürlich an anderen Standorten, aber man kann sich vielleicht gegenseitig besuchen.

Dass heißt, dass die Welt für jeden Spieler, der sich die selben Stelle ansieht, auch gleich aussehen soll (impliziert folglich eine zentrale Speicherung).

Der Mars ist groß – und daher ist auch die Spielwelt groß. Wenn nicht sogar riesig. Es gilt also das Problem zu lösen, wie man so eine große Welt zentral allen Spielern bietet, aber nur die Teile davon dem Spieler anzeigt, die er gerade benötigt: wahrscheinlich seine unmittelbare Spielumgebung.

Diese Problematik ist ja schon vielfältig gelöst worden – z. B. durch Google Maps

Weiterhin möchte ich aber diese Welt in 3D anzeigen lassen – sieht halt besser aus…

Auch das gibt es schon, wenn auch nicht alles 3D ist – z. B. bei Google Earth

Zwischen-Ziel-Definition (ein Satz)

Mein erstes Ziel soll also sein: „Zeige eine Karte von einer Spielwelt in 3D an und ermögliche dem Benutzer darin zu navigieren.“

Problemanalyse

Das Zwischen-Ziel zeigt schon auf, dass ich eigentlich zwei Ziele habe: die Darstellung und die Navigation. Allerdings scheint mir beides sehr stark miteinander verwoben, also splitte ich das Problem zwar in zwei Bereiche, bearbeite aber beide Bereiche gleichzeitig.

Problemvereinfachung

Ich vernachlässige zunächst die Karte und stelle sie mir erst mal nur als platte Ebene dar. In etwa schwebt mir das so vor:

Damit ich mich besser orientieren kann, male ich einen Pfeil für die nördliche Richtung auf. Eine Umrandung in einer knalligen Farbe ist ebenfalls hilfreich, wenn ich die Größe der Ebene abschätzen möchte. Das Ergebnis sollte dann perspektivisch so aussehen:

GUI

GUI steht für Graphical User Interface und beschreibt im Grunde:

  1. was der Benutzer sieht und
  2. wie er mit dem System interagiert (es also bedient)

Navigation

Ich erkenne schon drei Interaktionen mit dem System:

  1. sich über der Karte bewegen (pan)
  2. sich Details ansehen oder wieder einen Überblick verschaffen (zoom in/zoom out)
  3. sich Dinge aus anderem Blickwinkel anzeigen zu lassen (rotate)

Wie kann ich diese Interaktionen in der App umsetzen?!

pan

Das Panning möchte ich mit der linken Maustaste bewerkstelligen. Bewege ich die Maus mit gedrückter linker Maustaste, bewegt sich die Karte entsprechend meiner Bewegung unter mir her.

Das funktioniert auf den mobilen Geräten in dem ich den Finger auf das Display setze und hin und her bewege.

zoom in/zoom out

Habe ich eine Maus mit mittlerem Mausrad, so kann ich darüber rein und rauszoomen.

Auf mobilen Geräten klappt das nicht – da entscheide ich mich für die „Zwei-Finger-Lösung“: toucht man zwei Punkte auf dem Display gleichzeitig an und zieht die beiden Punkte auseinander, so zoomt man heran; zieht man sie enger zusammen, zoomt man wieder heraus.

Diese Funktion soll auch durch einen Schieberegler auf dem Bildschirm bewerkstelligt werden können.

rotate

Mit rechter Maustaste kann ich dann den Blickwinkel verändern. Für mobile Geräte will ich wieder auf zwei Finger heraus: toucht man zwei Punkte auf dem Display gleichzeitig an und dreht die Punkte, verändert man auch den Blickwinkel.

Diese Funktion soll auch durch einen Knopf auf dem Bildschirm bewerkstelligt werden können.

Konzept

Eine erste Skizze des Layouts:

Ich möchte noch ein paar Informationen über meine Position einblenden. Daher stelle ich noch drei Status-Werte dar (x, y und Zoom-Faktor):

Layout-Überlegungen

Jedes Gerät hat seine eigene Auflösung. Retina und AMOLED sprengen fast täglich Auflösungsrekorde. Als Entwickler kann man nicht mehr für eine spezielle Auflösung planen, sondern muss sich auf die Geräte anpassen: responsive sein und designen…

Von kleineren Auflösungen zu großen ist dabei der schlechtere Weg – verpixelt es doch einem gruselig das Spielvergnügen.

Ich gehe immer von hohen Auflösungen zu niedrigen – das macht vieles einfacher.

Für das Malen von Spielelementen benutze ich Photoshop – und meine Source-Dateien für Spielgrafiken sind derzeit am Pixel 2 XL von Google orientiert: satte 1440 x 2880 (Höhe x Breite) bei 560dpi

Einen guten Überblick über die Entwicklungen im Bereich Display und Auflösungen findet man auch im Internet. Zum Beispiel hier: https://deviceatlas.com/blog/most-used-smartphone-screen-resolutions-in-2017

Ebenfalls ist das Verhältnis der Displays zu beachten: 5:4, 16:10, 16:9 und was es nicht alles gibt…

Für querformatige Apps designe ich in 16:9 mit einer Höhe von 1440, das ergibt folglich eine Breite von 2560. Das hat sich in der Praxis bewährt.

Arbeitet man dann final beim Programmieren nicht mit absoluten Pixeln sondern mit Prozentwerten, erreicht man nahezu immer sein Ziel.

Mein Entwurf für die beiden Controls ist:

Im Detail also zwei Komponenten, die es zu programmieren gilt.

Kompass

 

Zoom-Slider

Weiterführende Links

Bevor ich jetzt die Designs in „belastbaren“ Programmier-Code umsetze, mach ich im nächsten Schritt noch ein paar Anpassungen für meine App um dann die Layouts entsprechend umzusetzen.

Das wird noch mal ein wenig langweilig hier: Mission on Mars: Anpassungen Cocos2dx-Grundstruktur

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.