Handyversion von Freewar [W1-14]

[bwoebi]

Ja, ich hab auch mal mit Sotrax darüber geredet ingame; er meinte das sei zu viel Arbeit: würde eine immense Zeit von einem bis zwei Monaten einnehmen - eine Zeit in der für den oberflächlichen Benutzer nichts neues hinzukommt

(btw. xml transportieren bei xhr ist datenlastiger als das jetztige)

[hanuta]

Habs heute mal mit meinem Sony Ericsson Vivaz probiert... is ätzend, da unten immer massig leerer platz ist... und wenn ich auf items klicke, kommt immer die karte drunter und mein Inventar is ungefähr 0,5cm groß....

[Sotrax]

@itgchris: Ich weiß sehr gut, wie AJAX, JQuery und Websockets funktionieren, siehe www.blockyblocks.com das genau diese Techniken nutzt und das ich in letzter Zeit geschrieben habe.

In FW ist die Sache jedoch bei weitem nicht so einfach, wie es auf den ersten Blick klingt, weil die Struktur vieler Unique-Items da sonst einfach nicht mehr funktioniert und nicht den richtigen Reload triggert. Sprich um FW komplett auf sowas umzustellen, müsste ich fast jedes Item und fast jeden Ort ändern. Es reicht nicht, die Dinge einfach in ein Div zu packen. Gerade durch die ganzen Uniques wäre das eine enorme Arbeit.

Besser laufen würde es für die Leute aber nicht, da die Pakete eh alle komprimiert über die Leitung gehen und oft komplett in die MTU passen. Man merkt dann speed-mässig keinerlei Unterschied.

Davon abgesehen wir haben bereits eine HTML5 Version von FW in Welt 1, einfach statt frset.php mal auf frtest.php gehen. Diese kommt komplett ohne Framesets aus. Aus verschiedenen Gründen wollte ich die bisher aber noch nicht online schalten.

FW benutzt von dem her keine Technik die Deprecated ist, außer den Framesets und auf die kann ich jederzeit verzichten, das ist alles schon fertig programmiert und geht dann auf iFrames die sehr wohl im Standard drin sind.

Technisch haben websockets aber noch ganz andere Nachteile, man kann Sockets und PHP praktisch vergessen, dass ist nicht wirklich schön, viel besser ist es dann gleich auf NodeJS zu setzen, wie ich es in blockyblocks.com gemacht habe. NodeJS und PHP mischen ist kein Problem (wenn auch schöner mit EJS), aber da kommen dann andere Probleme auf, z.B. muss die Webseite 2 IPs oder Subdomains verwenden wenn man die Websockets über Port 80 routen will (sonst läuft FW nicht mehr hinter Firewalls). Man kann zwar auch einen Reverse-Proxy in Apache verwenden, aber das ist ehrlich gesagt extrem buggy und führt zu Verbindungen die sich einfach aufhängen etc, wie ich in mehreren Tests feststellen musste.

Übrigens verwenden wir in FW nicht nur Compression sondern zusätzlich Keep-Alive TCP/IP Connections. D.h. im Klarstext wenn nur mal der Mainframe reloadet geht kein komplettes TCP-Handshake mehr übers Netz, sondern es werden nur die paar Daten geholt, die er braucht und fertig, alles in der MTU, kein bisschen langsamer als über einen Socket (der zudem schwerer zu komprimieren ist).

Sorry, für das Ausholen, aber ich hoffe damit besser begründen zu können, wieso eine neuere Technik für die Spieler in FW derzeit eigentlich keinerlei Vorteile bringt, nur den Nachteil, dass es mehrere Monate keine Neuerungen gäbe und danach im besten Fall alles sich so anfühlt wie bisher auch. Die Notwendigkeit für diese Neue Technik ist da einfach enorm gering. (Und Clients die nicht cachen werden dann sogar massiv langsamer, weil sie dauernd die 40kb große JQuery Bib laden.)

Wenn es nur darum geht HTML5 Standardkonform zu sein, das kann ich bereits jederzeit umschalten, siehe frtest.php in Welt 1. Aber nur Standardkonform zu sein, bringt den Spielern ja jetzt derzeit keinerlei Vorteile, deswegen habe ich das zwar programmiert, bisher aber nicht umgeschaltet.

So, ich hoffe, ihr könnt jetzt besser verstehen, wieso ich die Dinge so mache wie ich sie mache und dass ich definitiv über all diese Techniken nachgedacht habe und da verschiedene Tests gefahren habe. Die Vorteile davon sind derzeit einfach irre gering, sie rechtfertigen den Arbeitsaufwand derzeit einfach nicht. (In DF bemerkt ja auch eigentlich niemand, dass die Karte dort mit Ajax läuft ).

[Sotrax]

@=snigg=: Ich werde mich auf jedenfall um die Android 4 Umsetzung noch kümmern, leider kam ich bisher aber nicht dazu. Grober Zeitplan ist, dass die Sache im Mai stehen sollte und unter Android 4 gut funktionieren sollte

[itgchris]

Das mit JQuery hab ich nur erwähnt weil es eine gute Bibliothek ist. Jedoch ermöglicht AJAX einiges und kann die Welt beleben. Ich meine die User kriegen von dir momentan Content geliefert, der eigl. nichts anderes ist als Aufbereitung von altem. Klar unterscheidet sich das etwas, aber es ist halt alles irgendwie ähnlich. Neue Techniken können neue Ideen hervorbringen und ja NodeJS ist gut, vor allem wegen der non-blocking I/O, auch Google GO ist hier relativ stark.
Mit AJAX kannst du eigl. soviel machen.
Ich finde trotz allem, du solltest es angehen.

Zum Thema Websockets. Du kannst dein Apache auf 81 legen und ein NGINX vorhauen, der die beiden dann handelt. Als Reverse, ist zudem auch performanter wenn du dann gleich den statischen Inhalt mit NGINX handelst.

Gibt viele Möglichkeiten eigl. das zu bewerkstelligen. Wie gesagt du musst ja kein Code Refactoring machen und 90% deines PHP Codes raushauen oder verändern, es reicht immer wieder ein kleinen Schritt zu gehen und das nach und nach umzubauen, womöglich das ganze viel. mit neuen Features verknüpfen.

[Sotrax]

@itgchris: Das Problem daran ist, es mag technisch cool sein, ändert am Spiel erstmal aber überhaupt nichts. Schon jetzt ist FW ja komplett dynamisch, man sieht live wenn sich irgendwas ändert, wie sich die Phasenenergie auflädt etc etc. Und auch das Problem mit den Frames die bei Reload hochscrollen ist mittlerweile nicht mehr vorhanden, z.B. wenn jemand neu aufs Feld kommt.

Man muss also letztendlich abwägen, was hätten die Spieler davon genau für Vorteile und wieviel Arbeit kostet es und könnte man in der Zeit nicht auch etwas machen, was mehr Effekt hätte. (Ganz so einfach lässt es sich letztendlich nicht umsetzen, Items etc müssten definitiv geändert werden, da sie in DIVs derzeit nicht funktionieren würden.).

Wie gesagt, versuche die Sache aus Sicht der Leute zu sehen, die sich nicht für die Technik dahinter interessieren. Was würde sich für diese Leute letztendlich ändern? Die meisten würden den Unterschied vermutlich noch nichtmal bemerken.

(Wegen der Reverse-Proxy Sache auch über NGINX, das klappt leider nicht halb so sauber wie es sein sollte bei hohem Traffic aufkommen. Habe da einige Tests gefahren, das sauberste ist derzeit in der Tat noch einfach eigene IP und eigene Subdomain und fertig.).

Weiterhin muss man beachten, dass immer noch 2% der Spieler (leider, leider) den IE6 für FW einsetzen.

So oder so, es stellt sich halt die Frage was kann ich mit NodeJS und Websockets machen, was gerade dringend für FW benötigt wird.

Versteh mich nicht falsch, ich liebe diese neuen Techniken und kenne mich auch gut in ihnen aus uns setze sie gerne ein, wie man in blockyblocks.com sieht, aber vieles ist bei den Techniken noch nicht so 100% stable wie man es gerne hätte. (Session-handling bei NodeJS ist z.B. so eine Sache die lange alles andere als sauber war und mittlerweile so halbwegs geht, aber bei weitem noch nicht "rock-stable" ist.). Nur aus Liebe zur Technik FW umzubauen wäre denke ich falsch (denn sowas führt immer auch zu neuen Bugs die man kaum vorhersehen kann). Daher muss man sich immer die Frage stellen, was ganz konkret haben die Leute dadurch für Vorteile?

- HTML5 Kompatibilität kriegt man auch über iFrames, diese werden auch im Standard bleiben.
- Vorteil wäre sicherlich eine schnellere Aktualisierung des Chats, die könnte man aber auch leicht anders erreichen (simples Longpolling nur für die Chatabfrage).
- Traffic wird nicht geringer, da man andere Nachteile hat. Websocket-Stream ist schwerer zu komprimieren und man braucht auch Clientseitig viel mehr Bibliotheken wie SocketIO etc. Die jetzige Version von FW kommt fast ohne Includes aus, was FW auch ziemlich schnell macht. Traffic ist eh in FW sehr viel harmloser als man denkt, das meiste machen teils die Bilder aus, die sich gut cachen lassen. Die eigentlichen Webseiten passen eigentlich immer in die MTU, sogar wenn sie also 1kb kleiner sind, wird der Traffic gleich hoch sein. Rein traffic-mässig sind auch Sockets nicht zu unterschätzen, sehe ich ja bei BlockyBlocks das mehr Traffic pro User der drauf ist zieht als FW, was auch an den ganzen Hartbeats etc. die SocketIO sendet, liegt. Und Sockets stürzen auf dem Iphone Browser z.B. immer mal wieder ab, das Problem haben wir bei Blockyblocks noch nicht 100% in den Griff bekommen.
- FW läuft schon jetzt eigentlich sehr interaktiv und flott. Für kritische Punkte wie dem Chat wird auch jetzt schon Ajax-Polling verwendet. FW war übrigens bereits ein interaktives Browsergame bevor es den Begriff Ajax überhaupt gab
- Das Umbauen würde wirklich sehr lange brauchen. Denke alleine an die tausenden von Links überall im Spiel, die müssten alle verändert werden. Ein Link auf main.php würde so einfach nicht mehr klappen sondern müsste durch eine Javascript Funktion ersetzt werden etc etc.
- Alle vorhandenen Custom-Framesets von Leuten würden nicht mehr funktionieren.
- Das ganze hätte auch handfeste Nachteile in der Bedienung. Viele Leute öffnen die Schriftrolle der Lebenden etc. gern mit STRG-Klick in einem eigenen Fenster. Sowas wäre dann nicht mehr so einfach möglich. Die Frames und auch Iframes haben den Vorteil, dass man sie einzeln in einem Extra-Fenster öffnen kann, was gerade bei manchen Items enorm praktisch ist.

Wie gesagt, aufgrund all dieser Dinge, bin ich derzeit einfach nicht davon überzeugt, was dadurch für FW besser werden würde. Wenn ihr da aber gute Argumente habt, wieso sowas dringend geändert werden muss, nur her damit Daher einfach die Frage, was versprecht ihr euch bei FW besseres durch solch eine Technik was derzeit nicht möglich wäre?

Für neue Projekte setze ich diese Techniken aber auch sehr gerne ein, ich bin da durchaus offen, wie gesagt, siehe blockyblocks.com was komplett auf Websockets aufsetzt.

[eiersalat]

Bin ich froh, daß Sotrax genau diese Einstellung hat. Und genau deswegen läuft freewar so stabil.

Ich kenn diese Helden, die in den IT-Buden sitzen und sich an neuen Technologien aufgeilen und das überall reinpressen, egal, ob es sinnvoll ist oder nicht. Purer Selbstzweck. Diese Hype-Hörigkeit tut ihr übriges (Kann sich noch jemand hier an den XML-Hype erinnern? Nicht? Seid froh. Ich musste mich mit diesem Müll rumplagen.)

Grundregel: Immer die einfachste Lösung.
Mir stellen sich z.B: die Nackenhaare auf, wenn ich erlebe, daß ein stinknormales HTML-Formular mit Javascript submitted wird. Leute!

Zu Ajax: Gut und schön, aber
1. ist das noch zu sehr im Fluß, da würde ich nix ernsthaftes mit machen und
2. werden die Seiten träger.

Das Beste, was uns Ajax gebracht hat, ist JSON. Damit kann man nun endlich die größten XML fan boys davon überzeugen, zum Abspeichern von strukturierten Daten nicht XML zu verwenden. Wenigstens etwas.

@itgchris: Was hat Google Go mit der Sache zu tun?

[NeZ]

Cheffe, das waren jetzt die Nachteile. Und was wären die Vorteile?

Welche Arten von Unique-NPCs könntest du damit einbauen, die jetzt technisch nicht möglich sind?
Welche Funktionen bezüglich der Map, des Chats, des Mainframes, des Inventars hast du im Kopf, die aber derzeit nicht umsetzbar sind?

Wenn hier auch für den stinknormalen User (der höchstens mal amateurhaft mit css/html herumbastelt) keine Vorteile herausspringen und ein Wechsel derzeit noch nicht einmal möglich ist (Stichwort veraltete Browser), gibt's eigentlich nicht viel zu diskutieren hier.

[Sotrax]

@NeZ: Die Technologie hat definitiv auch Vorteile, garkeine Frage.

Ganz simpel ausgedrückt ist der Hauptvorteil, dass z.B. der Chat über Sockets einfach reaktiver läuft. Je nach Anwendung gibt es nur die Möglichkeit Sockets zu verwenden, da alles andere nicht reaktiv genug wäre.

Beispiel: Wenn man jetzt einen Ego-Shooter in 3D mit WebGL machen würde, ist man auf definitiv auf Sockets angewiesen. Alles andere würde nur zu einem ruckligen Spielerlebnis führen.

Für FW selbst bringt es meiner Meinung nach aber nicht viel, da man in Chatsystemen kaum bemerkt, ob eine Chatnachricht jetzt 0,05 Sekunden oder 0,5 Sekunden braucht bis der andere sie liest. (Bei Voice oder Video-Systemen ist das wiederum wichtig, daher verwendet der Voice und Videochat von FW Flashsockets z.B.).

Bei BlockyBlocks war es mir ebenfalls wichtig auf Sockets zu gehen, einfach weil man dort pro Sekunde soviele Blöcke setzen kann und der Live-Effekt nur damit so richtig rüberkommt.

Sinnvoll sind Sockets auch, wenn das Spiel mehr so ist, dass man sich nicht Feldweise wie in FW bewegt, sondern komplett flüssig über eine Karte bewegt (z.B. wie in Spielen wie Zelda).

So wie Freewar grundsätzlich aufgebaut ist, bringt es aber in der Tat eigentlich keinen wirklich großen Unterschied. Mir fällt jetzt auch kein NPC ein, dass damit ginge, das sonst so völlig unmöglich wäre.

Vielleicht übersehe ich aber auch einfach was, wer weiß

Übrigens kann man aber auch durchaus Technologien mischen. So könnte man z.B. nur für den Chat auf Sockets umsteigen und dennoch gleichzeitig bei Frames (oder eben bei iFrames wenn man HTML5 Kompatibilität will) bleiben. Ich schliesse sowas jetzt auch nicht kategorisch aus.

[Nelan Nachtbringer]

0.5 Sekunden machen beim PvP einen riesen Unterschied. O.o

[-=Buzzeron=-]

Mir fällt jetzt auch kein NPC ein, dass damit ginge, das sonst so völlig unmöglich wäre.

Weltenwandler und Baru-Schrecke zu zweit würden einfacher gehen, aber ist auch ohne möglich. (Phili is spitze ) Für alle anderen NPCs wäre die Beschleunigung des Chats unbedeutend.

[Sotrax]

@Nelan Nachtbringer: Im PvP ja, aber genau da hätte es dann auch nicht nur Vorteile für das Spiel. Es würde konkret Bots einen riesigen Vorteil bringen, denn diese können schneller reagieren als jeder Spieler.

Einen Unterschied würde es also machen, ob dieser Unterschied aber nur gut ist, ist mehr als fraglich. (BTW: auch schon jetzt könnte die die Server deutlich reaktiver einstellen ganz ohne Sockets, bisher habe ich davon abgesehen da ich sehr unsicher bin, dass dies das Spiel wirklich verbessert).

[LuBuLegend]

Ohne jetzt den ganzen Thread gelesen zu haben:

Unter Android gibts noch folgende Fehler (bisher nur den Standart Browser genutzt. Wie es z.B mit Opera aussieht, weiss ich nicht):

- Man muss immer die ganze Seite scrollen. Falls man z.B durch den Itemframe scrollt, sind die Links verschoben, können ergo nicht angeklickt werden.
- Falls man versehentlich auf die "Back" Tasta drückt, wird der Chat oftmals regelrecht vom letzten Eintrag zugespammt. Gibts hierfür vlt eine refresh-security?
- Das mobile Menü ganz oben wird nicht durch Styles unterstützt. Mir ist persönlich auch kein css-Code dafür bekannt. Eventuell den Headframe so verlagern, dass dieser den weissen Bereich abdeckt?

Verbesserungsvorschlag
- "Neue Nachrichten" als eigenes Menü anpinnen und nicht erst als Reiter unter "Einstellungen(?)" sichtbar machen.

[Sotrax]

@LuBuLegend: Ich gehe mal davon aus, dass du Android 4 meinst. Das verhält sich da leider ganz anders als Android 3. Leider komme ich an dem Rechner hier gerade nicht dazu, werde das aber nochmal genauer angehen, ich bin zuversichtlich dass man die Probleme da gut fixen kann.

Übrigens einen Trick gibts auch unter Android 4, installier mal den Chrome statt dem Standard Android Browser, damit sollte es perfekt klappen. (Die Chance stehen auch gut, dass der Chrome für Android irgendwann der Standardbrowser wird.)

[LuBuLegend]

Werds die Tage mal mit Chrome testen und sag bescheid.