User-Interface

Nach dem öffentlichen Thread will ich das Thema mal im Entwicklerbereich ansprechen.
Wobei ich jetzt keine Features wie Bauschleifen besprechen will sondern mal das Userinterface besprechen will. Auch das Thema ob nun simples HTML, XML/XSL oder was auch immer, möcht ich mal außer acht lassen, weil wir sonst wieder rumstreiten und vom Thema abkommen.
Dynamik
Grade in Kunden/Admininterfaces von Hosting-Betreibern findet man solche dynamischen Interfaces immer wieder. Hilfe-Layer, Rechtsklickmenüs, Hovereffekte und dynamische Formulare. Alles was sich mit Javascript verwirklichen lässt um ein Desktop-Ähnliches Interface zu gestallten. Solche Scripts sind zwar immer sehr aufwendig, doch wäre das nicht auch ein Feature was die Spieler "beeindrucken" würde? Persönlich jedenfalls finde ich es immer interessant wenn man mal keine Standard-HTML Seite präsentiert bekommt, sondern mal ein wenig rumklicken und zuschauen kann wie ein Semi-Futuristisches Interface einem dem Weg durch die Artikeldatenbank weisst.
Grafik
Grafik hat in vergangenen Monaten deutlich an Bedeutung gewonnen und auch wenn immer noch BGs rauskommen wo nichtmal HTML4 erfüllt wird so biten die grossen BGs inzwischen fast alle aufwendige Designs. Selbst bei neuen BGs kommt es immer häufiger vor, dass diese zwar kein anständiges Konzept aber 3D-Renderbildchen integriert haben. Paralelles Problem ist dann wieder der Traffic der dann gerne mit Grafikpacks gesenkt werden soll. Das die Grafikpacks aber gegen das Prinzips eines überall zugänglichen BGs wiedersprechen - und zumindest ich keine Packs installieren kann weil ich min. zu Haus und auf der Arbeit spielen will - ist vielen Admins leider auch noch egal.. es ist ein Feature was jedemfalls dem Admin Vorteile bringt.

Die Beschaffenheit des Interfaces hängt in meinen Augen, wie immer, stark vom Spiel und der Zielgruppe ab. Will man die Zahlenmäßig mit sicherheit beeindruckendste Zielgruppe der 12 bis 16-jährigen ansprechen kann man ohne Hemmungen JavaScript, Flash und alle anderen Spielereien verbauen, die man im Netz finden kann. Aber selbst ein Großteil dieser (meistens) Schüler wird sich über kurz oder lang beschweren, dass Beispielsweise am Schul-PC kein Flash geht, oder vielleicht sogar kein JavaScript (kommt vor). Schon ist einer der für mich größten Vorteile eines Browsergames (wie oben auch mit den Grafikpacks erwähnt) verloren, nämlich dass ich es immer und überall spielen kann. Viele Firmenrechner sind auf maximale Sicherheit getrimmt, "Schnick-Schnack" wird zur "Produktivitätsteigerung" oft mit Absicht deaktiviert. Aber wie ja auch Wirtschaftsinstitute festgestellt haben, werden Browsergames "viel zu viel" am Arbeitsplatz gespielt, und diese Möglichkeit wollen wir unseren Kunden ja nicht vorenthalten .
Bei der Grafik ist es meines Erachtens reine Geschmackssache. The-Pimps (oder wie das heißt) wäre ohne seine Bombastgrafik sicher garnichts, Galactic-Tales braucht sein einzigartiges Layout als Charakteristikum und die Spieler von unserem AirlineSim haben nicht nur nichts gegen Tabellen, sie wollen sie auch. Unsere Spieler freuen sich, wenn sie stundenlang durch Flugpläne klicken können, was genau genommen nichts anderes als Listen mit Daten sind. So hat jedes Spiel seinen Stil und seine dazu passende Clientel. Und daher ist eben unser Spiel praktisch JavaScript-frei und XHTML-komform und sollte damit auf jedem PC mit vernünftigem Browser spielbar sein. Natürlich werde auch ich hier und da mal JavaScript nutzen, aber es wird immer optional sein. Wenn der User kein JS nutzen kann, dann wird er das Spiel genauso spielen können wie ohne.

Das Thema dynamik halte ich nicht für verkehrt. Ich nutze das auch an einigen Stellen wo nicht jedesmal die Seite komplett neu geladen werden soll.
Beispiel Karte: klickt jemand auf ein Gebäude kommt der Inhalt (Produkte/Stationierte Einheiten etc.pp), via AJAX nachgeladen, in einem Div-Fenster.
Beispiel Flottenauftrag: jemand gibt das Ziel ein. Die Zieldaten werden nachgeladen und sofort im gleichen Fenster dargestellt. Man muss sich nicht, wie z.B. bei OGame, durch 3 Seiten klicken um ein paar Einheiten zu verschicken.
Beispiel diplomatische Abkommen: Auf der Seite gibt es zwei Tabelle, einmal abgeschlossene Bündnisse und einmal Bündnisanfragen anderer Spieler. Klickt einer bei einer Bündnisanfrage auf "Akzeptieren" wird das via AJAX dem Server kundgetan und der Eintrag via Javascript aus der "Bündnisanfragen anderer Spieler" Tabelle in die "Abgeschlossene Bündnisse" verschoben.
Das geht an vielen Stellen so weiter. Ich sehe den Sinn darin, die Benutzeroberfläche schneller reagieren zu lassen. Wenn jemand ein Bündnis akzeptiert will ich, nur um den Eintrag in einer anderen Tabelle erscheinen zu lassen, nicht eine komplette Seite neu laden. Auch für Gimmiks wie kontextsensitive Hilfen machen dynamische Features Sinn: klassischerweise hat man dafür ein Browserfenster als Popup aufgemacht (träge). Sowas als Div einzublenden, am besten noch genau an der Stelle in der Seite auf die sich die Hilfe bezieht, erscheint mir da sinnvoller.

Ich versuche aktuell, einen Voll-AJAX-Ansatz zu fahren, d.h. das alles komplett mit AJAX gestaltet wird und die Seite quasi wie ein Frameset wirkt/reagiert.
Entsprechend will ich dann natürlich auch all die Möglichkeiten benutzen, die AJAX so bietet.
Ergo soll es keine Klickorgien mit Dauer-Reloads geben und ich möchte natürlich auch viele Gimmicks anbieten können.
Zum Grafikpaket: Spricht doch generell nichts dagegen, sofern man es richtig macht (z.B. beim Login eine Möglichkeit anbietet, sich auch ohne lokales GP einzuloggen).
Ich seh ein GP auch eher als Möglichkeit, die Seite noch schneller zu machen, ich hatte lange ISDN und bin auch jetzt noch nicht mit DSL gesegnet, da hilft es schon, wenn man die Grafiken lokal gespeichert hat. Wobei ich eher das Problem habe, das ich noch keinen Designer hab...
Na ja, ich denke schon das der Trend zu mehr Dynamik gehen wird, einfach weil das IMHO weniger nervig ist. Aktuell spiele ich ein BG, wo nach fast jeder Aktion eine neue Seite mit einer Bestätigung geladen wird. Das nervt einfach nur und macht das Spiel auch zäh. Sowas will ich vermeiden, wenn möglich.

AJAX ist ja Momentan voll im Trend. Aber es gibt auch noch immer Browser, die das nicht unterstützen. Daher sollte man da etwas aufpassen.
Zum Thema Grafik: Die die Internetverbindungen immer schneller werden, sehe ich da in naher Zukunft auch kein Problem mit dem Grafiken. Grafikpakete werden auch nicht umbedingt nicht nur wegen des Traffics, vielmehr wegen der Ladezeit angeboten, da die Daten lokal natürlich schneller geladen werden können. Muss aber jeder selber entscheiden, ob er ein GP nutzen will, oder nicht.
Die Entscheidung, ob GP oder nicht, sollte man in den Optionen bzw. im Spielerprofil selber wählen können und sollte kein muss sein.

Original von progs
AJAX ist ja Momentan voll im Trend. Aber es gibt auch noch immer Browser, die das nicht unterstützen. Daher sollte man da etwas aufpassen.

Stimmt schon. Aber ich gehe einfach davon aus, das man gewisse Sachen vorraussetzen kann/darf. Wer heute ein aktuelles Spiel kauft, darf sich auch nicht beschweren, wenn das nicht auf einem 386er läuft.
Ok, eventuell sperre ich ein paar Leute aus, aber das lässt sich nie ganz vermeiden.
Wenns halbwegs problemlos auf den "Großen 3" läuft, soll mir das genügen.

Die Entscheidung, ob GP oder nicht, sollte man in den Optionen bzw. im Spielerprofil selber wählen können und sollte kein muss sein.
Full ACK!

Welche nennenswerte Zielgruppe (das ist jetzt ernst gemeint) verfügt denn noch über einen Browser, der mit Ajax nicht klarkommt? Denn, das ist eben ja das "besondere" daran.. es ist eine alte Technik und damit so verbreitet, das es fast überall zu nutzen ist*.
* Ausnahmen: Zugänglichkeit und Barrierefreiheit (Fallbacks?)

PDA, die neuen UMTS-Handys z.B.
Ignorieren kann man diese Gruppen zwar, wenn man aber sieht was Jamba und Co. mit den Handyspielen verdient...

Also Handies sollte man schon halbwegs außer acht lassen. Bzw man diese unterstützen will, dann sollte man hier wohl spezielle Seiten anbieten.
Ein 1024x768-Layout mit Tabellen und Mapgrafiken dürfte auf einem Handybildschirm sicher nicht so berauschend rüberkommen.
Wie gesagt.. wenn dann soll man ein paar WAP-Seiten erstellen und den Spielern so die Möglichkeit geben auch unterm Klassentisch zu spielen.

Ein 1024x768-Layout mit Tabellen und Mapgrafiken dürfte auf einem Handybildschirm sicher nicht so berauschend rüberkommen.

Der Opera für Windows Mobile hat das sogenannte "Small Screen Rendering". Damit verkleinert er das Layout selbstständig auf eine lesbare breite für den PDA und man hat dadurch kein breites, sondern ein langes Layout. Funktioniert sehr gut und hab damit auch noch keine Probleme gehabt.
Für alle die es interessiert: www.opera.com/products/mobile/smallscreen/

WAP ?
*hust*
Die aktuellen Handys haben alle brauchbare Browsern. Und den Opera-Mini bekommt man auch für Lau.
Also mit WAP würde ich mich echt nicht mehr beschäftigen.

Original von MrMarco
PDA, die neuen UMTS-Handys z.B.
Ignorieren kann man diese Gruppen zwar, wenn man aber sieht was Jamba und Co. mit den Handyspielen verdient...

Ja - da hast du natürlich recht. Das ganze trifft sogar auf Smartphones zu - evtl meintest du die auch (mit). Selbst die PSP, die ja bereits einen ordentlichen Browser bietet (im Sinne der Features), muss schlussendlich wegen der Darstellgröße scheitern.
Hier muss daher a) ein alternatives CSS gegeben werden (hallo, wofür ist der media-Tag wohl da :twisted oder b) ein ganz alternatives User-Interface (Darstellung).
Weil hier gibt es ganz klar Probleme, die das beste Design (im Sinne des Userinterfaces, nicht Farbgebung) nicht lösen kann: Am PDA & Co. hat man zuwenig Platz (und uU zuwenig Feature a la Ajax, JS (nur beschränkt), Flash etc.pp.), auf dem PC & Co. hat man "zu viel" Platz.
Oder anders: Ich will auf dem PC sofort navigieren können, ich will "viele "Informationen (sofort) sehen". Auf dem PDA bin ich froh, wenn mir nicht sofort alles angezeigt wird, weil ich nicht dauernd scrollen muss und die Ladezeit moderat bleibt.
Das Interface ist wichtig - wichtiger als so manch anderes, denn was nützt einem ein super tolles Spiel, wenn man nicht an die Funktionen kommt? Wenn sie überdeckt werden? Wenn sie nicht sichtbar sind? Der Profigamer kommt damit klar; der weiß wo es lang geht und kennt mit der Zeit jede Abkürzung (die uU ja unbedacht vorhanden sind).
Ich bin derzeit selber auch dabei, das Userinterface zu überholen - denn da wurde meines Erachtens bei uns (im Spiel) nie wirklich dran gedacht. Verwandte Links, Verwandte Hilfestellungen, relevante Zwischeninfos.. gehören für mich zum Interface. Der Benutzer kann einfacher mit diesen Informationen im Spiel interagieren.
Technisch gesehen sind für mich die Spielereien wie "Ajax" Bonifeatures. Die Seite muss auch ohne Javascript operable sein. Mit Ajax aber eben komfortabler. Zum Beispiel: Einloggen mit Ajax: Seite bleibt stehen, aber ein Kasten wird ausgetauscht. Ohne Ajax: Seite wird neu geladen, Redirect, und so weiter. Ein Fallback ist vorhanden, verkompliziert den ganzen Aufwand vom Aufwand, aber ist notwendig.
So etwas einzubauen ist furchtbar simpel.. Hilfestellungen, die per Ajax dynamische Layer einbauen, dagegen schwerer bis zu unmöglich. Hier müsste man den "armen" Spielern dann die Möglichkeit geben, zumindestens eine Liste der Tipps aufrufen zu können. Und natürlich den Link gut platzieren.

Userinteraktion erfolgt (fast?) immer durch Mausklicks, entweder auf Links oder auf Buttons von Formularen. Für Beide kann man sowohl AJAX als auch Klassisch reagieren.
Beispiel Link:
Metallmine
Mit Javascript: der onclick-Handler wird ausgeführt, gibt false zurück und bricht damit das Öffnen des Links ab.
Ohne Javascript: der Client ruft /construction?id=1 auf.
Beispiel Formular:
...
Gleiches Prinzip ...
Ich überlege genau auf diese Art und Weise das Spiel sowohl mit als auch ohne Javascript benutzbar zu machen. Auf der anderen Seite sehe ich Statistiken wie "95% Surfen mit aktiviertem Javascript" und denke darüber nach ob ich die 5% wirklich berücksichtigen sollte (die wahrscheinlich nichtmal zur Zielgruppe der Browsergamer gehören).

Das Problem mit "weniger Farben, niedrigere Auflösungen" gab es früher auch mal.
Zu den 8Bit-Zeiten wurde das auch gelöst. Von daher ist das heute auch machbar.
Die Bedienung muß man halt nach den Möglichkeiten des Endgerätes richten.

Also, ich mache die Unterscheidung großer/kleiner Rechner anhand des User-Agent-Strings. Wenn es erkannt wird wird das JS ersetzt und ein paar Bilder weniger geladen. Klappt ganz gut, wenn ein mobiles Gerät mal nicht erkannt reicht eine Meldung und ich füge es in die Liste hinzu.
Zusätzlich werde ich bald eine Checkbox in das Loginfenster einbauen, mit der man die Entscheidung groß/klein korrigieren kann.
Erspart mir viel Arbeit mit unterschiedlichen Layouts :-)
Mein Testobjekt ist btw der Psion, da habe ich vom framelosen Browser bis Opera 5 mit JS und allem drum und dran freie Auswahl, angeschlossen habe ich es über die serielle Schnittstelle, damit ich auch eine langsame Leitung simulieren kann.

Respekt!
Ich hatte mal testweise mir einen PDA-Emulator für die WinCE Reihe installiert und auch den Nokia Series 60 Emulator gehabt.
Das war eine Fummelei manchmal...
Grundsätzlich ist es möglich fast jedes Spiel auf eine kleinere Darstellung hin anzupassen.
Fast jedes deshalb, weil die Spiele welche auf Flash setzen, oder stark auf Grafiken setzen hier logischerweise so ihre Probleme haben werden.
Aber selbst hier sollte eine Technische Lösung möglich sein.
Wenn ich mir überlege das ich früher oftmals per Handy Travian und Co. gespielt habe... *grussel*