Handyversion von Freewar [W1-14]

[LuBuLegend]

(bitte Post zusammenfassen. Dient nur zu Pushzwecken)

Habs jetzt einmal eine gute Stunde mit Chrome ausprobiert:

- Bug mit den verschobenen Links ist dort gefixt
- "Spam-Bug" ist gefixt. Verursacht aber wahrscheinlich weitere Probleme (siehe unten).
- Headframe passt sich nicht den Styles an
- Gibt öfters noch refresh-Probleme, wenn NPC's spawnen oder jemand das Feld betritt. Das liegt aber glaub eher noch an Chrome.

Und zu den Nachrichten - ich würd den Button einfach mit "Original" tauschen. Ist viel komfortabler.

[Nelan Nachtbringer]

@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).

Hm. Daran habe ich nicht gedacht. Ein zweischneidiges Schwert. Schade.^^

[itgchris]

@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.

Nun da will ich gerne darauf eingehen, ich selbst bin Student und habe auch eine Tätigkeit in dem Bereich, kenne mich also sehr gut aus. Und ich setze viel in dem Unternehmen wo ich Arbeite auf diese 'neue' Technologien.

- Der Traffic wird bei Richtiger Programmierung sehr wohl geringer, was eigl. einen Desktop User vielleicht nicht wirklich merkt oder auch stört, aber einen Handybenutzer eben schon.
- iFrames sind unschön und nunja auch ein etwas älterer Standard was man höchstens noch für Polling benutzt.
- Man kann eben mehr Interaktivität einbauen und wenn man ein kleines bisschen nachdenkt fallen einem auch Ideen ein und es gibt auch tolle Beispiele dazu. Ein krasses Beispiel wäre der APE-Server ähnlich wie node.js Jedoch ist basisiert er auf einer speziellen Pushing Technik will ich garnicht weiter erläutern.
- Wenn jemand per STRG - Linksklick einen Link öffnet, sollte bei Ajax auch dies noch funktionieren, ist umständlich aber eben machbar.
- PHP nunja ist im Vergleich zu nativen Lösungen oder node.js bzw. bei spezieller node.js Konfiguration lastiger, als diese nonblockI/Os
- Mit interaktiv meine ich solche Späße: http://www.ape-project.org/demos/7/mmorpg.html
Es gibt eben viele Möglichkeiten, ich hab da auch schon Träume, bzw. Visionen in Sachen Dungeons.
- Je nachdem wie du es programmierst kriegen deine Server eben einen Performance schub. Ob du es glaubst oder aber PHP ist einfach in Sachen Performance das letzte. Wobei es eben wahrscheinlich für Freewar damals mehr als ausreichend war.
- Real World Example wäre bspw. ein spezielles Kampfsystem bei neuartigen 'Unique-NPCs'

Negativ wäre also nurnoch der extreme Umbau und der würde wirklich umbauen, besonders wie du sagst, alle Links / Framesets, STRG+Link alles möglich muss speziell gehandelt werden, teilweise muss man auch vielleicht einen PUSH-to-Client Server aufziehen, denn man eben über node.js realisiert oder eben nativ da gibts eben auch viele Möglichkeiten, bei WebSockets muss noch ein Fallback to PUSH her. Du musst ein JavaScript Framework kreieren oder eben eines der vorgegeben nutzen und diese erweitern. Und es wäre wirklich ein schwerer Umbau, viele User könnten dann erstmal im Forum sich ausheulen das es erstmal kein neues Schwert oder Gebiet gibt, das ähnlich ist wie schon vorhandene und von den Features auch ähnliche Sachen mit sich bringt.

Ich könnte natürlich noch mehr Punkte anführen, aber bisher hast du ja nicht welche gebracht die gegen eine Umwandlung sprechen und ich meine du weisst denke ich selbst, dass Freewar in der Entwicklung wirklich nicht viel neues bringt, ich meine Chaoslabor etc. ganz schön und so, aber im Grunde sind das alles Dinge die irgendwie eher wie verwerteter Inhalt aussehen, ich denke da gibts ein paar die würden mir zustimmen und manche nicht.

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?

Diese Hype-Technologien nennt man Fortschritt und diese Verbessern das Web und machen PHP Anwendungen und auch andere wesentlich performanter, da man viel Logik auch auf die Clients abwälzen kann.

Ein HTML Formular per JavaScript submitten ist ganz normal, dazu submittet man es erst an eine JavaScript Anwendung und überprüft die Felder, sind die Okai, leitet man es weiter zum Server, ist wesentlich sicherer. Problematischer sind eher Anwendungen die kein HTTPS einsetzen. Zumal man mit JavaScript eigl. garnicht submitten kann.

Ajax ist weder zu sehr im Fluß noch sonst etwas. Ajax ist jetzt schon eine gut 6 Jahre 'alte' Technik.
Nur weil du es nicht machst und eben noch auf statische Anwendungen setzt heisst, es aber nicht das Sotrax das nicht machen kann, außerdem werden Websites nicht träger, eher performanter, natürlich kann man Ajax auch schlecht programmieren. Aber ich denke wenn Sotrax es macht, dann Richtig.
Daten hat man noch nie in XML abgespeichert und auch nicht in JSON, informier dich mal lieber über Blobs.. Aber darauf will ich nicht eingehen. Da dies mir als reines Trolling erscheint.

Was Google GO damit zutun hat? Nun ganz einfach, da man mit Golang eine relativ performante Lösung hat, die selbst an natives C/C++ in Sachen Website Performance rangeht und man weder Blocking I/O hat noch Nachteile was Multithreaing angeht, es ist eine Sprache die optimiert ist für das Web und auch Websockets nativ unterstützt. Klar ein Code-Refactoring nach node.js oder Technologien wie Golang sind eher Quatsch und wäre viel zu viel Arbeit jedoch würden Sie in Sachen Performance nur so trotzen.
Das übrigens node.js PHP überlegen ist sollte auch Sotrax klar sein. Und ich denke damals als er mit FW angefangen hat, war es halt trend alles in PHP zu machen, aber heutzutage sieht man ja, dass dies viel. nicht _die_ Lösung ist. JavaScript kann mehr und ist besser, von nativen Lösungen will ich garnicht erst reden.

Nunja genug geredet, ich denke das hier hat im Forum nichts verloren und ich will Sotrax eigl. garnicht beeinflussen nur zum nachdenken anregen. Ich denke aus Developersicht könnte ich hier viel reden, aber das stört die 'normalen' User wohl eher.

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

Wenn man von einem Code-Refactoring ausgeht und Sotrax alles neu schreiben würde ( was er natürlich nicht tut, etc..) kannst du in etwa vom Faktor 50 ausgehen. Sprich alles wird 50 x schneller. Das ist so in etwa die Theorie bzw. Vergleiche zwischen größeren Softwarepakten von PHP zu node.js wenn er es in node.js machen würde. Gibt natürlich auch effizientere Wege und naja am Ende kommts wohl eher darauf an was Sotrax als Limit/req drin hat bzw. wieviel deine Leitung Up/Down hat.

[Sotrax]

@itgchris: Ich weiß, dass PHP sehr viel langsamer als z.B. NodeJS ist, ich setze ja beides ein. FW 50mal schneller damit machen für die Server wäre aber nicht drin aus verschiedenen Gründen:

1. Wir verwenden bereits einen PHP Beschleuniger (derzeit APC) der die Sache schneller macht. Mit Techniken wie HipHop könnte man noch mehr rausholen, allerdings verwende ich die derzeit nicht (hat andere Gründe). Wie auch immer, reines PHP ist viel lahmer als NodeJS. Das muss aber nicht immer so bleiben, gerade Firmen wie Facebook stecken derzeit große Energie darin hinein, PHP zu beschleunigen. Technisch spricht nichts dagegen PHP genau so schnell wie Javascript hinzukriegen. Sogar Asynchrones I/O wird in Zukunft mit PHP gut gehen, siehe Closures in PHP 5.3 etc.

2. PHP ist nicht der eigentliche Flaschenhals, es ist die Datenbank. Nur etwa 15% der Rechenzeit entfallen auf PHP, der Rest ist MySQL. Selbst wenn PHP garkeine Zeit mehr brauchen würde, wären die Server kaum schneller. Dabei muss man sagen, dass MySQL auch nicht wirklich lahm ist, da wir teilweise weit über 1000 SQL Queries pro Sekunde pro Server verarbeiten. Und in FW gibt es in den meisten Welten mittlerweile mehrere Millionen Items und Millionen von Chatzeilen jede Woche. Wenn man also mehr Server-Performance will, bringt einem die Optimierung von PHP derzeit so gut wie nichts.

3. Die Server sind eigentlich bereits viel zu schnell, in der Regel liegen sie bei 98% idle. Sprich rein Speedmässig langweilen sich die meisten Server. Das einzige wo sie zum laggen kommen, ist bei I/O Operationen wie Backups wo mal kurz mehrere Gigabyte hin und herkopiert werden müssen. Sprich es gibt derzeit überhaupt keine Notwendigkeit den Code selbst zu beschleunigen, es hätte überhaupt keinen Effekt. Eher müsste ich mal überlegen SSDs für die Server einzusetzen um die I/Os zu beschleunigen, denn die ziehen sozusagen an der Last. Auch MySQL lässt sich nur recht schwer beschleunigen weil wir diese bereits enorm optimiert haben.

Du siehst, das wirklich wichtige ist da anzusetzen wo es Sinn bringt und man irgendeinen Effekt merkt. Ich mache hier eine Menge Profiling um die wirklichen Flaschenhälse (und die lahmen SQL-Queries zu finden). Interessanterweise war übrigens einer der Hauptlaggründe die Statistik die erzeugt wurde

Ansonsten hast du natürlich völlig Recht, für Browsergames wie BrowserQuest von Mozilla etc. braucht man Sockets und dafür sind die neuen Techniken super. Nur ich denke in FW werden wir ja bei dem feldbasierten Ansatz bleiben und da ist die jetzige Technologie recht ausreichend.

Übrigens zu iFrames: Sie sind zwar alt, aber keinesfalls veraltet. Dass sie im Standard bleiben ist aus Sicherheitsgründen äußerst wichtig, so kann man mit iFrames z.B. Werbebanner in seine Seite einbinden, was viel mehr Sicherheit bietet als irgendein Javascript-Include. (Ein Javascript Include könnte einfach Passwörter etc. auf der Seite auslesen, wenn der Werbevermarkter gehackt wird, ein iFrame kann das nicht wegen der Same-Origin-Policy. Das alleine wird dafür sorgen, dass alleine aus Sicherheitsgründen iFrames defakto im Standard bleiben müssen. Allerdings hast du natürlich recht, das hat recht wenig mit den Frames in FW zu tun, da die ja alle aus FW kommen )

So oder so, die neuen Techniken sind sehr spannend und ich mache eine Menge damit und werde auch immer schauen, was man für FW dafür gebrauchen kann und wo es Sinn bringt.

[itgchris]

@itgchris: Ich weiß, dass PHP sehr viel langsamer als z.B. NodeJS ist, ich setze ja beides ein. FW 50mal schneller damit machen für die Server wäre aber nicht drin aus verschiedenen Gründen:

1. Wir verwenden bereits einen PHP Beschleuniger (derzeit APC) der die Sache schneller macht. Mit Techniken wie HipHop könnte man noch mehr rausholen, allerdings verwende ich die derzeit nicht (hat andere Gründe). Wie auch immer, reines PHP ist viel lahmer als NodeJS. Das muss aber nicht immer so bleiben, gerade Firmen wie Facebook stecken derzeit große Energie darin hinein, PHP zu beschleunigen. Technisch spricht nichts dagegen PHP genau so schnell wie Javascript hinzukriegen. Sogar Asynchrones I/O wird in Zukunft mit PHP gut gehen, siehe Closures in PHP 5.3 etc.

Das ist eben falsch, Firmen wie Facebook beschleunigen nicht PHP, sie crosscompilern nach C++.
https://github.com/facebook/hiphop-php/wiki/
Und das C++ wesentlich schneller ist als node.JS sollte auch klar sein, jedoch: http://fabricengine.com/ bietet hier auch noch etwas an Verfeinerung. Und nein Nonblocking I/O ist in PHP nicht möglich. Closures sind kein besonderes Feature, desweiteren ist PHP fail by Design, könnte man sagen, wie gesagt HipHop bietet hier aber eine Möglichkeit alles nach C++ zu übersetzten. g++ sei dank.

2. PHP ist nicht der eigentliche Flaschenhals, es ist die Datenbank. Nur etwa 15% der Rechenzeit entfallen auf PHP, der Rest ist MySQL. Selbst wenn PHP garkeine Zeit mehr brauchen würde, wären die Server kaum schneller. Dabei muss man sagen, dass MySQL auch nicht wirklich lahm ist, da wir teilweise weit über 1000 SQL Queries pro Sekunde pro Server verarbeiten. Und in FW gibt es in den meisten Welten mittlerweile mehrere Millionen Items und Millionen von Chatzeilen jede Woche. Wenn man also mehr Server-Performance will, bringt einem die Optimierung von PHP derzeit so gut wie nichts.

Klar das mit der Datenbank muss man dann auch anders lösen, aber da gibt es eben auch Möglichkeiten. Erfodert jedoch sehr viel KnowHow. NoSQL wäre hier ein Stichwort, aber wie gesagt man stellt da nicht einfach um und NoSQL erfordert sehr viel Experternwissen und nunja in meiner Firma gibts da extra ein paar Typen die sich um gerade so Sachen kümmern.

3. Die Server sind eigentlich bereits viel zu schnell, in der Regel liegen sie bei 98% idle. Sprich rein Speedmässig langweilen sich die meisten Server. Das einzige wo sie zum laggen kommen, ist bei I/O Operationen wie Backups wo mal kurz mehrere Gigabyte hin und herkopiert werden müssen. Sprich es gibt derzeit überhaupt keine Notwendigkeit den Code selbst zu beschleunigen, es hätte überhaupt keinen Effekt. Eher müsste ich mal überlegen SSDs für die Server einzusetzen um die I/Os zu beschleunigen, denn die ziehen sozusagen an der Last. Auch MySQL lässt sich nur recht schwer beschleunigen weil wir diese bereits enorm optimiert haben.

Nunja Performance ist ja nicht alles, aber gerade wenn du zuwenig Auslastung drauf hast, kannst du eben mit neuen Techniken spielen, ohne das es Probleme geben könnte.

Du siehst, das wirklich wichtige ist da anzusetzen wo es Sinn bringt und man irgendeinen Effekt merkt. Ich mache hier eine Menge Profiling um die wirklichen Flaschenhälse (und die lahmen SQL-Queries zu finden). Interessanterweise war übrigens einer der Hauptlaggründe die Statistik die erzeugt wurde

Ansonsten hast du natürlich völlig Recht, für Browsergames wie BrowserQuest von Mozilla etc. braucht man Sockets und dafür sind die neuen Techniken super. Nur ich denke in FW werden wir ja bei dem feldbasierten Ansatz bleiben und da ist die jetzige Technologie recht ausreichend.

Wie gesagt Websockets ist ja nicht alles gibt eben genug Sachen, aber ich denke eben neues bringt wieder ein bisschen mehr Pepp in Freewar und man kann beim Feldbasisierten Ansatz bleiben, aber man kann eben damit tolle neue Sachen machen, bspw. das Inventar etwas besser gestalten, vielleicht von dem Strukturieren Ansatz wegkommen. Z.b. finde ich das UI von Freewar relativ unpassend für heutige Zeiten. Naja Custom-CSS würden dann erstmal wegfallen, aber ich denke das kriegt jeder wohl grad noch so verschmerzt.
Aber gerade beim Inventar kannste z.b. einiges machen und auch das UI könntest du mit Ajax sehr gut umgestallten und trotzdem sehr viel neue Funktionalität und vor allem Intuitive Designs reinbringen, die vielleicht auch super und toll auf Android/iOS passen.

Übrigens zu iFrames: Sie sind zwar alt, aber keinesfalls veraltet. Dass sie im Standard bleiben ist aus Sicherheitsgründen äußerst wichtig, so kann man mit iFrames z.B. Werbebanner in seine Seite einbinden, was viel mehr Sicherheit bietet als irgendein Javascript-Include. (Ein Javascript Include könnte einfach Passwörter etc. auf der Seite auslesen, wenn der Werbevermarkter gehackt wird, ein iFrame kann das nicht wegen der Same-Origin-Policy. Das alleine wird dafür sorgen, dass alleine aus Sicherheitsgründen iFrames defakto im Standard bleiben müssen. Allerdings hast du natürlich recht, das hat recht wenig mit den Frames in FW zu tun, da die ja alle aus FW kommen )

So oder so, die neuen Techniken sind sehr spannend und ich mache eine Menge damit und werde auch immer schauen, was man für FW dafür gebrauchen kann und wo es Sinn bringt.

iFrames bleiben im Standard weil man damit ein Fallback machen kann, falls ein Browser eben bestimmte Techniken nicht unterstützt, gerade WebSockets. Wie gesagt ich erwarte kein Code Refactoring, aber wenn du nach und nach einiges umstellst, hast du am Ende viel. 50% des Codes neu geschrieben und eben auf eine neue Technik portioniert und kannst dann immer mehr neues angehen.

Wie schon erwähnt, du musst ja nicht von heut auf morgen eine Umstellung planen, aber umso weniger du neues in PHP neues machst sondern eben auf die neue Technik umschwänkst, wenn du eine Neuerung einbaust, umso eher kannste vielleicht dann auch mal etwas einbauen, dass nur die neue Technik beherbergt.

[Sotrax]

@itgchris:

Ich weiß was HipHop ist, ich habs selbst schon verwendet. Im Endeffekt geht es aber darum PHP zu beschleunigen. Ob das intern über eine VM gelöst wird, über einen Cross-Compiler oder sonstwie, es geht immer um das gleiche Ziel es soll schneller werden. (Ich meine schaue dir dazu mal die ganzen LLVM ansätze an.).

PHP an einige sehr unschöne Dinge im Design, das ist richtig. Allerdings hat die Javascript ebenfalls (Vererbung ohne Objecte zu erzeugen geht kaum und richtig große Projekte in JS sind wirklich hässlich und will man keinem zumuten. Sowas wie phpBB will man kaum komplett in NodejS umsetzen ). Javascript hat einige echte Vorteile aber auch dutzende Nachteile. Alleine Multitasking ist in NodeJS noch immer nicht richtig umgesetzt.

Wenn man richtig professionelle, richtig große Projekte macht geht man besser auf Scala. (Siehe Twitter etc.).

Von der Syntax her ist Scala weit voraus, und auch Java ist besser, ohne Frage.

NoSQL ist super für Flache Hirarchien wie Blogs und Comments und auch Chats. (Ich verwende selbst MongoDB). Aber MySQL kann einfach deutlich mehr, die Funktionalität übersteigt MongoDB bei weitem. Und ich lasse auch ganz gerne auf der DB einfache Berechnungen durchführen und man kann auch sehr viel mit Triggern und Check-Constraints sowie Foreign-Keys machen um die DB Konsistent zu halten. Das ist bei NoSQL sehr viel schwerer. Auch kann man in MySQL leicht einzelne Tabellen Transaktionssicher machen.

Gerade wenn man komplexe Zusammenhänge zwischen den Tabellen hat und so auf komplexere Joins angewiesen ist, hat NoSQL einfach keine Chance gegen eine SQL Datenbank, soll sie ja auch nicht haben. Sind einfach verschiedene Anwendungsgebiete. MySQL ist übrigens sehr viel besser als ihr Ruf, gerade INSERTS gehen bei MySQL wirklich rasend. 50 000 Inserts in einer Sekunde sind kein Problem.

Auch bietet MySQL eigene Möglichkeiten für flache Hierarchien wie Chats die sehr schnell sein müssen, z.B. HEAP Tabellen (und sogar NoSQL Tabellen werden kommen, siehe in MariaDB etc.).

Man muss es einfach realistisch sehen, die Datenbasis in FW ist nicht simpel sondern komplex. Wir haben Personen über denen gibt es Freundschaftsbeziehungen, Clans, Clan-Kriege etc etc. Es gibt da eine Menge zu verknüpfen.

Aber wie gesagt MySQL läuft ja auch super, schau dir jetzt gerade z.B. mal die Auslastung in Welt 1 an:

Cpu(s): 2.1%us, 2.1%sy, 0.0%ni, 95.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st

Der Server langweilt sich zu 95%. Es gibt überhaupt garkeinen Grund derzeit da Serverseitig irgendwas zu beschleunigen. Wozu auch bei nichtmal 5% Last. Ob der Server nachher zu 5% oder zu 3% belastet ist, merkt niemand, wirklich niemand

Wenn du willst, können wir darüber auch gerne per PM weiter fachsimpeln, interessant ist es auf jedenfall ^^

[Sotrax]

@=snigg=: Wie gesagt, evt. mach ich in die Richtung mal tests, aber das ist ja so wie beim Item anwenden:

Wenn man mehrere Items hintereinander anwendet, kommt es zu einem Zwangslag von 0,8 Sekunden pro Item. Technisch kann man das natürlich einfach ausbauen, aber es existiert auch nur, damit man nicht mit einem Bot 100 Diebstahlzauber in 10 Sekunden zünden kann

Genauso ist es mit den Captchas bei der Goldmine etc. Man muss halt einen guten Kompromiss zwischen Komfort und Sicherheit finden.

[Sotrax]

@=snigg=: Bots sind zum Glück ausnahmefälle, aber ganz auf diesen Zwangslag verzichten will ich nicht. Alleine weil es in FW ja nicht nur darauf ankommen soll wie schnell man klickt, es ist letztendlich auch noch ein Rollenspiel

Wie gesagt man muss es halt abwägen, technisch könnte ich den jederzeit entfernen, als es ihn noch nicht gegeben hat, gab es aber viel mehr Beschwerden von Leuten, gerade was Massenanwendung von Zaubern anbelangt. (Leerklauen war da halt dann teils besonders fies). Das ganze ist also auch ein gewisser natürlicher Schutz, dass man nicht zuviele Zauber auf einmal abkriegt.

Und sooo lahm ist der Zwangslag ja auch nicht, den haben wir ja immer weiter verkürzt.

[bwoebi]

mhm, die Diskussion war doch interessant, könnt ihr die nicht hier fortsetzen statt per PN :S

Das Problem ist eben dass man bei großen Datenbanken egal wie nicht schneller wird. Vllt. hat man kurzzeitig 50% Einsparung, aber dann nach ein paar Monaten wieder den alten Stand.

Sowieso glaube ich nicht dass es Sinn hat alles nach HipHop oder so zu kompilieren, denn das geht zu Lasten der Flexibilität… Und NoSQL bringt nicht viel mehr als MySQL, wenn ein anständiges DB-Layout existiert…

Das einzige was ich tatsächlich irgendwie vermisse ist ein layout ohne Frames… Was man da umgestalten könnte mit Styles… *träum*

Was ich nicht verstehe, ist dass da ein Problem sein sollte bei den Links?! zumal man ja $().onclick(function(){if($(this).attr("target")) $($(this).attr("target")).load($(this).attr("href"); else { var parents; do { parents = $(this).parent(); } while ($(parents).hasClass("frame")); $(parents).load($(this).attr("href"); }}) und so für die Links machen kann: alle auf einmal, da gibts dann nicht viel Links anzupassen; bei den Formularen kann man ja ähnliches machen. Ist meiner Meinung nach wirklich nicht für mehr als eine Woche Arbeit… Eine Woche nichts anderes ist ja verschmerzbar nehm ich an?

[Sotrax]

@snigg: Es geht da auch ein wenig um die Strategie, dass man nicht beliebig Zauber rausdonnern kann, sondern sich gut überlegen muss, was man auf die schnelle anwendet, weil alles nicht geht. (Ist übrigens bei anderen Online-Games nicht anders, nennt sich dort nur "Global Cooldown" statt Zwangslag. Global Cooldown klingt irgendwie besser ).

@bwoebi: Wie gesagt, letztendlich ist es immer eine Kosten/Nutzen-Rechnung, man muss halb abwägen wieviel Arbeit ist es und wieviel anderes kann dafür nicht reinkommen. Generell könnte man aber auch mal überlegen einfach die Version mit iFrames noch in DIVs packen, die könnte man dann ziemlich simpel stylen. Wie gesagt unter frtest.php gibt es ja schon einen ersten Test mit einer iFrame only Variante ohne Frameset. Wobei ein Custom-Frameset derzeit ja auch nicht wirklich das Problem ist. Sogar eine Seite mit Custom-Iframes klappt recht easy.

Das mit den Links ist aber leider nicht so einfach, weil diese teilweise bereits jetzt dynamisch in den Items per JS zusammengebastelt werden. Sicher wäre, es gäbe erstmal ne Menge Bugs (und Unique-Items sind da eh ein Problem an sich. Klar würde ich FW heute auch anders gestalten, aber vieles ist da einfach völlig ungeplant entstanden. Man kann zwar all das ändern, aber es kostet eben sehr viel Zeit und es führt garantiert zur einer großen Menge neuer Bugs, da man dann sehr viel in sehr vielen Browsern testen müsste.). Wie gesagt es gibt aber auch Lösungen die ebenfalls klappen und sehr leicht zu implementieren sind, siehe einfach iFrames in DIVs reinpacken, da spricht eigentlich nix dagegen.

[itgchris]

@itgchris:

Ich weiß was HipHop ist, ich habs selbst schon verwendet. Im Endeffekt geht es aber darum PHP zu beschleunigen. Ob das intern über eine VM gelöst wird, über einen Cross-Compiler oder sonstwie, es geht immer um das gleiche Ziel es soll schneller werden. (Ich meine schaue dir dazu mal die ganzen LLVM ansätze an.).

Unerheblich ist das nicht zumindest nicht aus Sicht von Großprojekten. Ich habe damals mit C/C++ programmieren angefangen, dass dies die richtige Entscheidung war sehe ich ja. Selbst im Web sind native Sprachen die über CGI/FCGI oder eben über einen eignen HTTP Server ausgeliefert werden extrem im Trend und ich merke das an der Arbeitssituation.
LLVM... das Thema hat eigl. nicht viel mit PHP zu tun, es ist eigl. eher so eine Ersatz für den gcc und g++. Ist eigl. relativ beliebt, da man teilweise mit LLVM sehr viel mehr aus dem nativen Code rausholen kann als mit nem reinen gcc/g++ Compiler, ist aber eher geeignet für HPC.

PHP an einige sehr unschöne Dinge im Design, das ist richtig. Allerdings hat die Javascript ebenfalls (Vererbung ohne Objecte zu erzeugen geht kaum und richtig große Projekte in JS sind wirklich hässlich und will man keinem zumuten. Sowas wie phpBB will man kaum komplett in NodejS umsetzen ). Javascript hat einige echte Vorteile aber auch dutzende Nachteile. Alleine Multitasking ist in NodeJS noch immer nicht richtig umgesetzt.

Das ist so eben falsch, denn erstens ist JavaScript eine reine Scriptsprache und desweiteren ist node.js pures multithreading. PHP hat garkein Multithreading, mal so zum Vergleich. Das man mit node.JS einen Blog bzw. Forensoftware wesentlich besser hinkriegt, solltest du aber Wissen, wenn du mit Node.JS gearbeitet hast und das liegt alleine sogar daran, dass du eben auch nativen Code ausführen kannst und somit gleichzeitig auch ein C/C++ Script mit reinbauen kannst, was man natürlich nicht muss, denn eigl. geht es auch nur mit JavaScript. Ich halte node.js auch nicht für total überragend, aber eine wesentlich bessere alternative zu PHP ist es allemal. Wie gesagt ich mache mehr nativ, weil es eben meine Anforderung ist, besonders wartbaren und gleichzeitig auch sehr schnellen Code abzuliefern.

Wenn man richtig professionelle, richtig große Projekte macht geht man besser auf Scala. (Siehe Twitter etc.).

Von der Syntax her ist Scala weit voraus, und auch Java ist besser, ohne Frage.

NoSQL ist super für Flache Hirarchien wie Blogs und Comments und auch Chats. (Ich verwende selbst MongoDB). Aber MySQL kann einfach deutlich mehr, die Funktionalität übersteigt MongoDB bei weitem. Und ich lasse auch ganz gerne auf der DB einfache Berechnungen durchführen und man kann auch sehr viel mit Triggern und Check-Constraints sowie Foreign-Keys machen um die DB Konsistent zu halten. Das ist bei NoSQL sehr viel schwerer. Auch kann man in MySQL leicht einzelne Tabellen Transaktionssicher machen.

Nunja bei Richtig großen Projekten würde ich eher auf C/C++ setzten, Scala ist zwar auch toll und DSLs erlauben viel wartbaren Code, aber trotzdem muss der Code in der VM ausgeführt werden. Twitter verwendet Scala auch nicht im großen Stil, ein Hauptteil von Twitter besteht aus Java/Ruby. Und naja Java und Ruby sind nett und wie gesagt auch wesentlich schöner wie PHP, aber eben Ruby ist von der Geschwindigkeit relativ mies und Java wird wohl auch nicht mehr als node.js schaffen.
MySQL kann viel mehr ja, skaliert aber dadurch wesentlich schlechter, wie schon gesagt NoSQL kann viel und ist äußerst performant, aber man braucht eben dann auch wirklich jemand, der sich extremst mit der Materie auskennt.

Gerade wenn man komplexe Zusammenhänge zwischen den Tabellen hat und so auf komplexere Joins angewiesen ist, hat NoSQL einfach keine Chance gegen eine SQL Datenbank, soll sie ja auch nicht haben. Sind einfach verschiedene Anwendungsgebiete. MySQL ist übrigens sehr viel besser als ihr Ruf, gerade INSERTS gehen bei MySQL wirklich rasend. 50 000 Inserts in einer Sekunde sind kein Problem.

Auch bietet MySQL eigene Möglichkeiten für flache Hierarchien wie Chats die sehr schnell sein müssen, z.B. HEAP Tabellen (und sogar NoSQL Tabellen werden kommen, siehe in MariaDB etc.).

Man muss es einfach realistisch sehen, die Datenbasis in FW ist nicht simpel sondern komplex. Wir haben Personen über denen gibt es Freundschaftsbeziehungen, Clans, Clan-Kriege etc etc. Es gibt da eine Menge zu verknüpfen.

Aber wie gesagt MySQL läuft ja auch super, schau dir jetzt gerade z.B. mal die Auslastung in Welt 1 an:

Cpu(s): 2.1%us, 2.1%sy, 0.0%ni, 95.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st

Der Server langweilt sich zu 95%. Es gibt überhaupt garkeinen Grund derzeit da Serverseitig irgendwas zu beschleunigen. Wozu auch bei nichtmal 5% Last. Ob der Server nachher zu 5% oder zu 3% belastet ist, merkt niemand, wirklich niemand

Wenn du willst, können wir darüber auch gerne per PM weiter fachsimpeln, interessant ist es auf jedenfall ^^

Naja ich hab ja auch nicht gesagt du musst, aber sieh es doch als Vorteil, wenn du 95% Idle hast, kannst du eben z.b. ein node.JS test angehen, du implementierst einfach eine V2 von Freewar direkt auf dem Server 1 und baust da einfach nach und nach Sachen aus, wenn du grad Zeit hast und implementierst Sie in node.js so das es quasi dann am Anfang 1% node.js ist und 99% php, und dann machst du so weiter wie du zeit und lust hast, außerdem machst du nach und nach die iframes weg, wie gesagt du hast ja zeit und genügend ressourcen und wenn user das testen wollen können sie quasi einfach über testing.welt1.freewar.de das gleich mittesten, dass bringt meistens auch erfahrung und macht manchmal auch relativ spaß, vielleicht wirbst du das ganze auch indem du auf testing.welt1.freewar.de dir ne coole sache einfallen lässt die man mit node.js und ajax relativ gut bewerkstelligen kann dann findest du auch sicher testpersonen denen es gefällt.

Übrigens muss ich ehrlich sagen, habe ich auch lange PHP zusammengefrickelt. Ich habe da aber auch nicht viel in der Richtig gemacht nur kleine Scripte, jedoch immer mehr gemerkt das ist unschön. Klar damals hat man viel in PHP gemacht, Mark Zuckerberg hat auch PHP für Facebook benutzt, hat aber dann gemerkt, dass dies viel. garnicht so klug war. HipHop ist eigl. da schon der Durchbruch und Facebook setzt weiterhin PHP ein, aber eben nicht ausschließlich, viele Sachen wurden in C++ CrossCompiliert. Dazu schreibt er ja auch:

One common way to address these inefficiencies is to rewrite the more complex parts of your PHP application directly in C++ as PHP Extensions. This largely transforms PHP into a glue language between your front end HTML and application logic in C++. From a technical perspective this works well, but drastically reduces the number of engineers who are able to work on your entire application. Learning C++ is only the first step to writing PHP Extensions, the second is understanding the Zend APIs. Given that our engineering team is relatively small — there are over one million users to every engineer — we can't afford to make parts of our codebase less accessible than others.

Die Frontend Seiten können Sie so relativ gut in PHP ausliefern und im BackEnd setzt Facebook sowieso auf C++/Erlang/Java. HipHop ist deshalb ne schöne Sache und gibt auch im Vergleich zu APC nochmal so 20% mehr Performance die du aber nicht brauchst, wie gesagt früher hat man relativ viel in PHP gemacht, jedoch merkt man immer mehr das zurückrudern davon. Und naja eins muss man dir lassen, Freewar ist schon relativ alt und kommt aus der 'Hochzeit' von PHP, dass du selbst es immernoch unterstützt und dran weiterarbeitest ist schön, wenn man eben bedenkt, dass viele Entwickler alte PHP Projekte einfach aufgegeben haben. Ich sehe eben in Freewar auch viel potential und ich denke man kann dort mit neuen Technologien relativ coole Sachen einbauen.

[bwoebi]

Wenn du mir verräts wie ich z.B. die Statusanzeige vom inventar trennen kann per CSS bei iframes, dann bin ich damit einverstanden (also inv bleibt z.B. wo es jetzt ist und statusanzeige kommt an den platz des bannerframes)

[Gangrils]

Was mir bei dieser Sache negativ aufgefallen ist. Lese ich immer öfter (sehr oft) wie gerade Schüler Fw während des Unterichts spielen, das ist natürlich nicht gut. Wobei es wohl neuster Generation wegen, auch nichts bringen würde keine Handy Version zu machen, dann würden Sie etwas langweiligeres Spielen.

Jedoch "ap"eliere ich nutzt diese Zeit lieber zum lernen! Vielleicht mal ein paar Quests mit Mathematik Aufgaben bestücken?

[Sotrax]

@itgchris: Ich muss dir da (leider) widersprechen, in NodeJS läuft alles Javascript single threaded ab, nicht multithreaded. (Die asynchronen externen Calls zur DB etc. sind natürlich multithreded)

(siehe auch http://blog.mixu.net/2011/02/01/underst ... vent-loop/)

NodeJS ist zwar asynchron und z.B. aufrufe zur Datenbank laufen parallel zum Event-Loop ab, aber alles Javascript was in NodeJS ausgeführt wird, ist Single-Threaded und dazu noch atomar, wird also garantiert nicht unterbrochen.

Das ist auch derzeit eine der größten Probleme von NodeJS, NodeJS selbst nutzt nur einen Kern der CPU. Wenn du irgendwo in NodeJS z.B. eine for-Schleife einbaust die 10 Sekunden braucht bis sie durchgelaufen ist, dann hängt der gesamte NodeJS Server für diese 10 Sekunden.

Genau dieses Verhalten hat man so in PHP nicht, wenn da ein PHP Script hängt, können die anderen einfach parallel dazu weiterlaufen. Man muss also Berechnungen in NodeJS derzeit möglichst auslagern und schauen, dass das Javascript sowenig Zeit wie nur möglich schluckt.

Dieses Problem ist in NodeJS aber bekannt und es ist angedacht dass Webworker in Zukunft auch in NodeJS implementiert werden. Damit könnte man dann komplexere Javascript Algorithmen auch parallel in NodeJS durchführen.

Was die Schönheit der Sprachen anbelangt so kann man sich da sicher streiten. PHP kann extrem hässlich sein, muss es aber nicht. PHP hat durchaus auch bedeutende Sprachvorteile gegenüber Javascript (z.B. Type-Hinting, private Member in Klassen etc.). Klar hat man in PHP auch Konstrukte wie "Goto" aber das sollte man ja eh nicht einsetzen . Auch ist Remote-Profiling und Debugging in PHP derzeit noch leichter als in NodeJS, es gibt einfach viel mehr Tools für PHP.

Grundsätzliche Software-Design Pattern lassen sich in PHP genauso umsetzen wie in Java oder NodeJS.

Das Grundproblem von PHP ist, dass es enorm viel syntaktischen Zucker bietet und es zig Ansätze gibt, etwas zu lösen. Auch nerven mich Dinge in PHP wie dass die Sprache nicht Case-sensitive ist. Aber mit einem guten Editor ist PHP und Javascript halb so wild (PHPStorm rockt ).

PHP wird auch in 5 Jahren noch die dominierende Sprache für dynamische Webseiten sein, prophezeie ich einfach mal. NodeJS ist eher für Spezialfälle gut. PHP bietet aber viel mehr Vorteile gerade für Webhoster aufgrund des Sicherheitsmodells und der großen Bibliothek an Funktionen die mit PHP mitkommt. Ich selbst mag eigentlich beides, muss aber auch zugeben, zum Programmieren ist mir sowas wie C++ eigentlich an sich lieber. (Ich komme ja auch eigentlich aus der C++ Schiene).

Einen großen Nachteil gibt es aber noch, Teile in FW mit NodeJS zu realisieren und andere mit PHP: Man hat dann 2 Server am laufen, einen NodeJS Server und einen Apache-Server. Wenn nur einer davon zusammenbricht, ist bereits die Welt weg. Und so schön NodeJS sein mag, es ist noch nicht 100% so stabil wie PHP (was auch daran liegt, dass es ständig läuft, und in PHP nur das script durchläuft und dann beendet ist). Bei Blockyblocks musste ich schon mehrmals den NodeJS Server neu starten, was da mittlerweile ein Daemon macht. NodeJS entwickelt sich da aber rasant, bis zur 1.0 Version tut sich da sicher noch viel.

Wie auch immer, letztendlich ist das Resultat das wichtige, nicht die Technik. Die Leute sollen Spass in Freewar haben, mit welcher Technik das letztendlich realisiert wird, ist den meisten Leuten egal. Wichtig ist halt, dass es schnell genug läuft und stabil genug.

[Sotrax]

@=snigg=: Ein prominentes Beispiel dafür wäre z.B. WoW. Die meisten Spiele beschränken aber die Rate in der man Zauber abfeuern kann irgendwie. Das ist nicht ungewöhnlich. (Sogar die meisten Ego-Shooter lassen einen nicht beliebig schnell feuern).