Wieviel ajax verträgt ein spiel?

Hallo!

Ich bin momentan im Rahmen eines Projektes im laufe meines Studiums mit 3 anderen an einem Browsergame dran... Das spiel ist in PHP/MySQL, HTML/CSS/Javascript, man kennt das ja alles... Es handelt sich um ein Aufbaustrategiespiel, tut aber nicht wirklich viel zur sache...

Um ein bisschen Innovation bieten zu können arbeiten wir massiv mit Ajax, die einzigen reloads sind beim Einloggen und Ausloggen, eventuell wenn man in die Useroptionen will...

Mal kurz zum beschreiben wann eine Anfrage gemacht wird...fett sind Ajax-requests

User ist eingeloggt... karte laden ... User bewegt sich auf der Karte weiter ... karte laden ... user klickt auf ein haus... hausdaten laden... user baut aus... mögliche Ausbaustufen laden... user baut aus ... ausbauanfrage...

Und so weiter... jetzt meine frage: Ist das zuviel? Sowohl für den Armen Server als auch für den User, der bei hoher Serverbelastung oder schwachem anschluss ein bisschen warten könnte... Oder ist das eh egal, weil ob ich jetzt eine XML lade oder eine Seite neu lade macht da auch keinen Unterschied?

Wir sind da noch geteilter meinung, daher frag ich ma hier in die Runde was die meinung ist... zuviel? unmöglich für nen server? ok?

mfg

Phi

Der Vorteil von Ajax ist ja u.a. das der Server eher entlastet wird,

weil durch den Ajax-Request wird nur der benötigte Code geladen wird,

anstatt die ganze Seite.

Theoretisch schon, praktisch kommt man erst durch Ajax auf so seltsame Ideen wie eine scrollbare map, dynamisch geladene Vorschläge etc ;). Denke aber auch nicht, dass man zu viel Ajax nutzen kann... der Traffic sollte doch vergleichsweise gering sein zb zu einem Bild oder einer kompletten Seite.

hi phi,

wie meine vorredner schon gesagt haben, entlastet ajax eher den server.

vor ca 3 jahren haben wir das spiel: www.uniteria.de entwickelt, welches ebenfalls nur über ajax läuft.

neben den user events haben wir auch dauer event, die alle par sekunden stattfinden, wie z.B. Chatanfragen, Map neuladen, usw...

Serverprobleme haben wir bisher noch keine feststellen können, bzw. steigt der load kaum an.

Na fein, danke für die meldungen, dann bleib ich auf meinem Weg, ist mein erster Versuch, ein Browsergame mit Ajax zu verbinden, funktioniert auch schon bisher ganz fein...

Ich mache mir ähnliche Gedanken für mein Browsergame. Mich hat das soweit gebracht, dass ich nicht nur viel Ajax, sondern auch einfach viel JavaScript einsetzten werde. Da es hier nur um Ajax geht: die Neigung dazu weit mehr Abfragen an den Server zu stellen ist mit Ajax vorhanden, deshalb sollte man natürlich zusehen, dass man nicht unnötige Abfragen stellt. Evtl. willst du auch über Ajax Pollen, wenn du meinst, dass das alle 3 Sekunden nötig ist, steigt dabei die Serverbelastung schon enorm.

Ich würde einfach aufpassen, dass du nicht arg viel mehr Abfragen stellt, als du normalerweise würdest.

ich hab mit ajax hier die komplette bedeutung einbegriffen asynchronous javascript and xml, ich hab auch eine menge javascript dahinter, lässt sich alles angenehm mit jQuery verfeinern... nachdem meine eigenen XHTTP-requests ein bisschen buggy waren bin ich auf die jQuery.get umgestiegen, wirklich feines teil...

Der grosse Haken bei "viel Ajax und DHTML" ist die Grösse der Javascriptdateien.

Diese müssen beim Seitenaufruf geladen werden, was,  viel Scripting vorrausgesetzt, in den Sekundenbereich kommen kann.

Abhilfe bringt da das Packen von Javascript: YUI Minifier, JS Packer und der Closure Compiler können sowas recht gut.

Eine andere Möglichkeit ist es, wenn du JQuery benutzt, die Google JS Api zu nutzen, sprich JQuery von den Google Server laden lassen.

Original von tkdmatze

Der grosse Haken bei "viel Ajax und DHTML" ist die Grösse der Javascriptdateien.

Diese müssen beim Seitenaufruf geladen werden, was,  viel Scripting vorrausgesetzt, in den Sekundenbereich kommen kann.

Abhilfe bringt da das Packen von Javascript: YUI Minifier, JS Packer und der Closure Compiler können sowas recht gut.

Man kann vorher immer noch das ganze mit gzip durch den Server versenden lassen und die Dateien minifizieren (Whitespaces entfernen), was die Dateigrösse bereits um einiges reduziert. Wobei diese beiden Massnahmen praktisch Standard sein sollten...

Original von tkdmatze

Abhilfe bringt da das Packen von Javascript: YUI Minifier, JS Packer und der Closure Compiler können sowas recht gut.

Eine andere Möglichkeit ist es, wenn du JQuery benutzt, die Google JS Api zu nutzen, sprich JQuery von den Google Server laden lassen.

Einmal, zu Beginn, die JS-Dateien vom Server geladen ist nicht sehr fatal... Insbesondere wenn man sieht wie lange ein User auf einer Website verweilt.

Die Daten von Google laden? Damit du die komplette Benutzungsstatistik deiner Website wieder Google übermittelst oder gar Google die Kontrolle über den Browser all deiner Benutzer gibst? Da fehlt mir etwas Offenherzigkeit.

Bei kleinen Seiten hat es Sinn, weil: Das gleiche Script für alle verwendet wird. Der klassischer Effekt, der mit der Anzahl der Teilnehmer wächst.

Das Komprimieren (oder "Recompilen", wenn man so will..) bringt nochmal mehr als nur Whitespaces entfernen oder GZip.

Original von TheUndeadable

Original von tkdmatze

Abhilfe bringt da das Packen von Javascript: YUI Minifier, JS Packer und der Closure Compiler können sowas recht gut.

Eine andere Möglichkeit ist es, wenn du JQuery benutzt, die Google JS Api zu nutzen, sprich JQuery von den Google Server laden lassen.

Einmal, zu Beginn, die JS-Dateien vom Server geladen ist nicht sehr fatal... Insbesondere wenn man sieht wie lange ein User auf einer Website verweilt.

Die Daten von Google laden? Damit du die komplette Benutzungsstatistik deiner Website wieder Google übermittelst oder gar Google die Kontrolle über den Browser all deiner Benutzer gibst? Da fehlt mir etwas Offenherzigkeit.

ich mag die idee nicht ganz, daten von einem fremden server zu laden...
Wegen der javascriptsdateiensache... einmal geladen hat der users ja für die ganze session... und soo groß sind ein paar dateien auch nicht... momentan, bei 2/3 vom grundprojekt liegt die größe bei 200kb, und da kommen noch einige dateien weg...

Ich hoffe ich wärme hier ein nicht zu altes Thema erneut auf:

Ich Rahmen der Neuprogrammierung eines meiner Games wollte ich "nur" vermehrt auf AJAX setzten. Allerdings auch noch einige normale Weiterleitungen und Reloads drinnen lassen (vielleicht weil ich dieses vorgehen eher gewohnt bin).

Aber wenn ich mir das hier so durchlese, scheint es wohl dann doch besser zu sein, diese Schritte auch per AJAX zu machen.

Wie ich mir das ursprünglich dachte:

Formulare, Statusnachrichten, neue PNs, Restzeiten von Upgrades, Bauten und einkommen werden alle über AJAX validiert und aktualisiert. Allerdings wollte ich dann zum Beispiel das Absenden von Formularen als weiterleitung mit Parametern machen. Man ist z.b. im "Auktionshaus" mit der Datei auktionshaus.php und schickt über ein Formular dann sein Gebot ab. Das Formular leitet einen dann auf "auktionshaus.php?action=bit" weiter.

Würdet ihr sowas auch eher über AJAX regeln? Ich bin mir bei sowas noch unsicher, weil mir damit die Erfahrung fehlt. Aber wenn ihr sagt, dass sich das auf jeden Fall rentiert, werde ich mich mit so einem System wohl mehr auseinander setzten.

Dazu gleich die nächste Frage: Würdet ihr die Requests an für jede aufgabe spezielle php-Skripte senden oder an einen zentralen SKript, der dann die Anfragen Zentral verarbeitet? Zum Beispiel eine ajax_request.php, der man per $_GET sagt, was angefordert wird. Im letzteren sehe ich den Vorteil, dass die Absicherung leichter gehen sollte (keine Requests von unbefugten etc).

Hoffe ihr könnt dem Unwissenden ein bissl helfen^^

Original von NeoArmageddon

Formulare, Statusnachrichten, neue PNs, Restzeiten von Upgrades, Bauten und einkommen werden alle über AJAX validiert und aktualisiert. Allerdings wollte ich dann zum Beispiel das Absenden von Formularen als weiterleitung mit Parametern machen. Man ist z.b. im "Auktionshaus" mit der Datei auktionshaus.php und schickt über ein Formular dann sein Gebot ab. Das Formular leitet einen dann auf "auktionshaus.php?action=bit" weiter.

Würdet ihr sowas auch eher über AJAX regeln? Ich bin mir bei sowas noch unsicher, weil mir damit die Erfahrung fehlt. Aber wenn ihr sagt, dass sich das auf jeden Fall rentiert, werde ich mich mit so einem System wohl mehr auseinander setzten.

Wie viel ändert sich denn an deiner Seite durch das Bieten? Wahrscheinlich nur der Preis für das nächste Gebot. Und wegen dieser kleinen Änderung lädtst die komplette Seite neu? Das ist für mich auf jeden Fall ein Anwendungsfall für Ajax. Nur den neuen Preis für das nächste Gebot laden statt die komplette Seite.

Dazu gleich die nächste Frage: Würdet ihr die Requests an für jede aufgabe spezielle php-Skripte senden oder an einen zentralen SKript, der dann die Anfragen Zentral verarbeitet? Zum Beispiel eine ajax_request.php, der man per $_GET sagt, was angefordert wird. Im letzteren sehe ich den Vorteil, dass die Absicherung leichter gehen sollte (keine Requests von unbefugten etc).

Hoffe ihr könnt dem Unwissenden ein bissl helfen^^

Eine zentrale Datei ist das Konzept was Zend Framework (und viele andere MVC Frameworks) zum Beispiel verwendet. Das Konzept würde ich auch bei Ajax Requests übernehmen, da somit Zentral wichtige Dinge prüfen kannst ob der Benutzer eingeloggt ist zum Beispiel.

Okay, schon mal direkt vielen Dank. Aber ich meinte ja nicht nur das ändern des neuen Gebotes sondern auch das Senden, dass ein gebot abgegeben wurde. Ist das Sinnvoll? AAlso quasi die Formulareingaben über nen  Asynchronen Request absenden?

Ich würde sagen: AJAX, ja und viel... Wenn ein Spiel das Look-And-Feel einer Desktop Anwendung hat ist das schon was schönes! (Evtl. Geschmackssache aber ich finds toll, und User eigentlich auch) Wenn man irgendwas per Drag-n-Drop irgendwohinschiebt und das dann direkt gespeichert wird ist gut... So soll es sein. Wenn man Handelt muss nicht bei jedem Kauf die Seite komplett neuladen....

Dickes ABER: Alles was reinkommt, muss doppelt und dreifach geprüft werden. Nicht darauf vertrauen, dass wenn du dem Spieler durch JS untersagt hast, dass er nur Zahlen eingeben darf, er das auch tut und nicht evtl. nen Weg findet doch was anderes reinzuschreiben!

Ausserdem musst du dir darüber im klaren sein, dass du einen Nutzerkreis ausschließt. Den der JS-Deaktivierer. Aber das nur der Vollständigkeit halber, ich glaube solche Leute sind eh gestraft ^^ Zumindest wenn sie BGs spielen wollen....

Original von NeoArmageddon

Okay, schon mal direkt vielen Dank. Aber ich meinte ja nicht nur das ändern des neuen Gebotes sondern auch das Senden, dass ein gebot abgegeben wurde. Ist das Sinnvoll? AAlso quasi die Formulareingaben über nen  Asynchronen Request absenden?

Warum nicht? Natürlich delegiert das Ajax/RPC-Script die Anfragen dann nur an die jeweiligen Objekte (man könnte sagen: Services oder Basis) weiter - die gleichen, wie auch die "normalen" Scripte nutzen. Dadurch kann man auch wunderbar einen Fallback ohne viel Aufwand realisieren: von auktionshaus.php geht das Formular auf auktionshaus.php?bit, aber mit Javascript wird das Formular zu einem Request, sagen wir rpc.php?..., umgebaut. Zwar unterschiedliche Controller (Enduserscripts), aber zentraler Basiscode. Kann man natürlich sich simpel stricken, oder auch als Festung bauen.

Meine Meinung dazu ist, dass man das nicht pauschalisiert sagen kann und es sehr auf die Art des Spiels ankommt.

Lange Zeit war ich Fan davon, wenn man innerhalb einer Seite sehr viel AJAX benutzt, quasi für die ingame-Sachen (Items an- und ausziehen, nachrichten verschicken, im Auktionhaus Sachen einstellen). Und für alle NAVIGATIONS-Elemente normale Links benutzt (Klick im Menü, das Auktionshaussortieren, etc). Und zwar aus einem einfachen Grund: Das Spiel läuft im BROWSER. Ich mag es nicht, wenn man versucht, Desktop-Feeling 1-zu-1 in den Browser zu übertragen. Und warum mag ich das nicht? Hat mehrere Gründe, z.B. die Navigation per Vor- und Zurückbuttons (okay, es gibt natürlich auch Möglichkeiten, dies über Ajax zu machen, aber das ist aufwändig). Denn bei vielen  Browseranwendungen ist der Benutzer versucht, nach einem Klick, welcher auf neuen Inhalt weiterleitet auch mal den "zurück" button des Browsers zu benutzen. z.B. bei Ebay, um schnell verschiedene Filter zu vergleichen. Würde man das Auktionhaus per Ajax umsortieren, würde das nicht gehen.

Weiteres Beispiel: GMail vs. Yahoo Mail .. In GMail kann man sehr bequem mit den Vor- und Zurückbuttons zwischen Posteingang und Nachricht lesen navigieren. Super! In Yahoo Mail haben sie versucht, ein Desktopprogramm im Browser nachzubilden. Find ich totaler Murks.

Also Fazit: Ich finde es gut, wenn man die Umgebung "BROWSER" auch als Browser benutzt. Man Seiten Bookmarken kann, man mit den Browserbuttons navigieren kann, etc. Ajax trotzdem gut und viel für Ingame-Aktionen einsetzen. Allerdings NICHT um Desktopfeeling zu simulieren.

Genau so wie buhrmi e sagt, werde ich es in etwa relisieren. Denn ich persönlich bin auch Vor und Zurück Button Fan^^

Werde Formulare etc per JavaScript aufruf und nem Asynchronen Request an ein Zentrales "Verwaltungsscript" senden. Aber jede Unterseite bekommt ihre eigene php Seite spendiert: Also ubersicht.php, auktionshaus,php, charakter,php und co. So das man zwischen den "großen" kategorien bequem wechseln und Bookmarken kann.

Ich möchte an dieser Stelle nochmal direkt loswerden, dass mir der Entwicklerbereich bis jetzt sehr gefällt und ich schon einige sehr interessante Thread entdeckt habe, die mir sehr weitergeholfen haben.

Original von buhrmi

Weiteres Beispiel: GMail vs. Yahoo Mail .. In GMail kann man sehr bequem mit den Vor- und Zurückbuttons zwischen Posteingang und Nachricht lesen navigieren. Super! In Yahoo Mail haben sie versucht, ein Desktopprogramm im Browser nachzubilden. Find ich totaler Murks.

Also Fazit: Ich finde es gut, wenn man die Umgebung "BROWSER" auch als Browser benutzt. Man Seiten Bookmarken kann, man mit den Browserbuttons navigieren kann, etc. Ajax trotzdem gut und viel für Ingame-Aktionen einsetzen. Allerdings NICHT um Desktopfeeling zu simulieren.

Gerade GoogleMail ist aber ein super Beispiel, wie eine nahezu total ajaxifizierte Webanwendung dennoch grundlegende Dinge wie Zurück/Vorwärts unterstützen kann. Will damit sagen: Ob Desktopanwendung oder nicht, das ist für die verwendete Implementierungstechniken irrelevant. Yahoo könnte dies genauso machen, ist nicht unmöglich. 

Es läuft nur leider aus den Gründen "Keine Lust", "Keine Zeit" oder "Keine Ahnung" darauf hinaus, dass es dann nicht drin ist. Ajax weil es Ajax ist. 

Vor und zurück lässt sich relativ schön komplett mit AJAX realisieren, genauso wie Bookmarks, man muss nur die richtige Technik einsetzen, was Yahoo denn wohl nicht tut, was mich wundert.

Ich wollte eigentlich auf dshistory setzen, stelle aber gerade fest, dass es nicht weiterentwickelt wird, kann deshalb nicht mit einem Framework dienen, schätze aber es gibt mittlerweile potente jQuery-Erweiterungen oder Module anderer Frameworks für diesen Zweck, werde mich da demnächst nochmal informieren.

Original von Madman

Ausserdem musst du dir darüber im klaren sein, dass du einen Nutzerkreis ausschließt. Den der JS-Deaktivierer. Aber das nur der Vollständigkeit halber, ich glaube solche Leute sind eh gestraft ^^ Zumindest wenn sie BGs spielen wollen....

 Ich bin so ein JS-Deaktivierer, würde es aber für eine Browsergame problemlos einschalten können.

@knalli: Jawoll du hast recht. Google Mail setzt das extrem gut um. Total Ajaxifiziert, aber nicht aus dem Grund, eine Desktopanwendung simulieren zu wollen. Sondern weil es einfach "Sinn" macht. Auch wenn das sehr schwammig klingt.