AJAX Karte: Ein Beispiel

Ich bin dabei immer mehr AJAX Funktionalitäten in meinem Spiel The West einzubauen. Das dies auch sehr einfach geht möchte ich mit diesem Beispiel zeigen:
www.the-west.org/west2/jsp/ajaxmap.jsp
Prototype und scriptaculous werden eingesetzt.
Es werden zwei div Objekte verwenden. Das 1. Objekt wird angezeigt, das 2. kommt beim Scrollen zum Einsatz.
1. Das 2. Objekt wird gelöscht und neu Erstellt:

removeChild(document.getElementById(map_old));

map_old=map_current;
map_current='scrollmap'+map_x+'_'+map_y;
element = Builder.node('div',{id:map_current,style:'position:absolute; left:'+(x*-1)+'; top:'+(y*-1)+'; width:650px; height:650px; background:#bfb;'});
$('containermap').appendChild(element);
2. Via AJAX wird das 2. Objekt mit Daten gefüllt:

var url = 'drawmap.jsp';

var pars = 'map_x=....';
var myAjax = new Ajax.Updater(map_current,url, {method: 'get', parameters: pars});
3. Die beiden Objekte werden verschoben:

new Effect.Move (map_current,{ x: x, y: y, mode: 'relative'});

new Effect.Move (map_old,{ x: x, y: y, mode: 'relative'});
4. Dann wird das 1. Objekt wieder gelöscht und neu Erstellt, usw...

Sieht gut aus. Die Koordinaten werden hier (FF 1.5.4 WinXP SP2) aber nicht aktualisiert, ist aber nur Pillepalle. Außerdem kann man über den Kartenrand hinwegscrollen, das sollte warscheinlich auch nicht sein. Ansonsten aber sehr hübsch, gefällt mir gut.

Mein Beispiel ist natürlich nicht Fehlerfrei. Es ist auch erst der erste Wurf :-) Die Koordinaten werde ich in einem nächsten Schritt auch aktualisieren.

Viel zu viel Traffic wenn du mich fragst.
Ich hab mir mal den Response angeschaut (lässt sich ja mit der Firebug extension wunderbar machen) und du verschickst gleich den kompletten HTML/JS Quelltext ... was spricht dagegen einfach nur die Url des Image zu requesten und evl. ein paar Feldinfos?
Auch sind dafür die Biblioteken die du verwendest überflüssig ...als Response kannst XML oder JSON verwenden aber so ist das unschön.
developer.mozilla.org/de/docs/AJAX:Getting_Started
Solltest dir mal anschauen, viel mehr machen die Bibliotheken auch nicht ... die lohnen sich erst wenn du Drag&Drop oder sortierbare Listen haben willst.

Gefällt mir sehr gut, zuerst dachte ich: 'O mann, noch so ne AJAX-Map', aber diese ist zumindest vom ersten Anblick her sehr angenehm.

Original von TheUndeadable
Gefällt mir sehr gut, zuerst dachte ich: 'O mann, noch so ne AJAX-Map', aber diese ist zumindest vom ersten Anblick her sehr angenehm.

Was hat das Aussehen mit AJAX zu tun?

@LeoManiac
Ich wollte ein einfaches Beispiel. Da kommen mir JS Bibliotheken sehr gelegen. Dieses Beispiel nutzt natürlich nur ein Bruchteil der Möglichkeiten von Prototype + Co. Im Spiel verwende ich aber noch anderen Funktionen.
Zum Traffic: Das Scrollen via Client Javascript braucht schon recht CPU, darum will ich den Client nicht noch mehr belasten und aus Feldinformationen eine Karte aufbauen. Die Daten die via AJAX nachgeladen werden kommen komprimiert an und sind so etwa 3KBytes gross. Die Bilder hat man im Browser Cache, also auch kein Problem

> Was hat das Aussehen mit AJAX zu tun?
Diese Art der Navigation wäre ohne Ajax nicht möglich. Zumindest nicht ohne die komplette Karte vorzuladen.
Und wenn ich manchmal höre: 'Schaut mal her, die Site ist Ajax-Enabled', habe ich meistens sehr grausame Dinge gesehen.
Gerade das Navigieren mit dem sanftem Scrolling ist nett.

Original von Fasi
Die Daten die via AJAX nachgeladen werden kommen komprimiert an und sind so etwa 3KBytes gross. Die Bilder hat man im Browser Cache, also auch kein Problem

naja rechne das doch einfach mal hoch, als einfaches Beispiel 1000 Spieler ... jeder Spieler scrollt bestimmt öfters über die Karte wobei mitunter über 10 Request pro Spieler am Tag ausgeführt werden das wären dann schon 30mb am Tag und n knappes GB nach einen Monat und das nur durch die Karte. Reduzierst du die Daten nun auf wirklich relevante Daten anstatt den kompletten Quelltext liegst mit sicherheit nur bei einen 1kb ... also locker 2/3 weniger Traffic... unter anderem verbessern sich auch die Antwortenzeiten
Sorry aber ich halte von der Mehtode den "kompletten Quelltext" per Ajax nachzuladen überhaupt nichts.
[edit] und ich glaub nicht das füllen der Karte per JS wirklich so rechenlastig ist ... der Rechner muss doch kaum was rechnen ... wenn du mit JSON arbeitets und dir n Array zurückgeben lässt sollte das sogar recht flott gehen weil du das in ner simplen Schleife abarbeiten kannst ... brauchst noch nicht was was removen oder adden einfach nur das SRC Attribute ändern fertig.

Wenn er nur das src-Attribut ändert, ist das schöne sanfte Scrolling aber weg (und das ich ja gerade der Clou an der Map).
Ich würde ebenfalls nur per JSON Daten übermitteln und vom Client auslesen lassen (einfacher als mit JSON geht das gar nicht), allerdings würde ich dann erstens alle Daten cachen, die irgendwann mal übertragen wurden und im Hintergrund nur nach einer Veränderung der Map beim Server nachfragen und zweitens würde ich die Sektoren rund um den angezeigten Sektor schon vorher laden, denn zur Zeit kommt es immer zu einem kurzen Aussetzer beim Scrollen, da der Server ja nicht innerhalb eines Wimpernschlages antwortet.
Aber alles in allem:
RESPEKT!

sehr schoene karte
zum traffic, der ist egal, traffic wird immer billiger und die angebote beinhalten immer mehr freitraffic und wegen einem gb mehr pro tag würd ich nicht anfangen wertvolle zeit in die trafficoptimierung zu stecken.
wegen den methoden, es ist völlig egal welche man benutzt, hier schaut es mit den benutzten schon sehr gut aus und ich würd daran aux nix ändern. warum auch ? den kunde interessiert es absolut nicht was für eine methode im hintergrund läuft.er will nur gutes aussehn und funktionalitaet

Ich habe auch eine ähnliche Karte mit Ajax Feedback erstellt. Allerdings ist sie isometrisch und das scrollen geht über Drag&Drop. Diese schwer nachvollziehbaren "Klick und du bist sofort woanders" -Sachen müssen doch nicht mehr sein.
Eine Vorschau gibt es aber ganz sicher nicht im Anfänger Forum, dafür war es schon zu viel Arbeit.
[bezgl. cachen]
Darüber mache ich mir natürlich auch Gedanken, aber wie will man Clientseitig rausfinden ob sich was geändert hat? Eine Anfrage an Server muss sowieso stattfinden und nur da kann man z.B. mit Timestamps in der Datanbank rausfinden ob was passiert ist. An diesem Punkt ist schon eine Serveranfrage sowie ein MySQL Query erfolgt und man hat sogut wie nix eingespart. Man kann jetzt höchstens noch das Senden der ungeänderten Daten an der Clienten blocken und etwas Traffic sparen, was bei Nutzung von JSON auch nicht mehr besonders viel ist.
Dagegen kommt auf den Clienten eine ungeheure Datenflut zu, denn er muss nach langen Scrollsessions ja schon ein paar Daten speichern.
Wenn man in die Zukunft blickt ist das langfristige Speichern beim Clienten eine willkommen Neuerung für uns. Somit könnte dann die ganze Map im Browser verfügbar sein und es werden bei jedem Login die neusten Daten übertragen+einen Stream der während des Spielens Änderungen von außerhalb übermittelt. Leider wird es erstmal nur bei Firefox2 verfügbar sein.
Ihr seht ich schweife etwas ab.

Original von HSINC
sehr schoene karte
zum traffic, der ist egal, traffic wird immer billiger und die angebote beinhalten immer mehr freitraffic und wegen einem gb mehr pro tag würd ich nicht anfangen wertvolle zeit in die trafficoptimierung zu stecken.

Es war nur ein Beispiel ... es werden mit Sicherheit mehr anfallen. Wie mein vorredner schon sagt werden da einige Scrollsessions zusammenkommen die wesentlich mehr Traffic verursachen. Nebenbei bemerkt sind das nur Trafficzahlen auf die Karte bezogen der Rest steckt da noch gar nicht drinn. Auch wenn der Traffik billiger wird aber du treibts den Traffic dadurch nur unötig hoch und ist zudem unschönes coding...
ps: ich würde gerne dein Hoster sein, solche Kunden die nicht auf den Traffic achten wären mir als Hoster am liebsten

Original von HSINC

wegen den methoden, es ist völlig egal welche man benutzt, hier schaut es mit den benutzten schon sehr gut aus und ich würd daran aux nix ändern. warum auch ? den kunde interessiert es absolut nicht was für eine methode im hintergrund läuft.er will nur gutes aussehn und funktionalitaet
Schön das soviel Wert gelegt auf sauberes und ordentliches Coding
Sorry aber ich könnt mich über sowas ständig aufregen wenn ich sehe das mit Biegen und Brechen das Ziel erreicht wurde aber der eigentliche Weg absolut daneben.ist..zumal es auch den eigentlichen Sinn vom Ajax wiederspricht...
[Edit] ps: in diesen Beispiel kanns mir zwar eigentlich egal sein aber man siehts desöfteren bei so einigen OpenSourcen Projekten (nicht nur im BG Bereich) und da vergeht einen schon die Lust das Projekt weiter zu entwickeln.

Ich schließe mich HSINC an.
Wenn die Karte ordentlich an einem DSL-Zugang läuft, dann wäre mir die Arbeit zuviel auf jedes Byte zu optimieren.
Es stimmt: Es gibt eine gewisse Nachlässigkeit bzgl optimaler Performance im Gegensatz zu 8-Bit Zeiten. Aber heutzutage ist mir eine gesparte Programmierstunde lieber als eine gesparte Programmsekunde.

Also wäre dir praktisch auch unsauberes Coding egal?
Da würde die selbe Begründung auch greifen.

Sauberes und vor allem nachvollziehbares Coding ist wichtig.
Wenn jetzt aber konkret gesagt wird: Ich übertrage den gesamten Kram als HTML statt als perfekten Datensatz, weil ich dann 5 Stunden Programmierzeit spare UND gleichzeitig dieser HTML-Transfer ordentlich programmiert und dokumentiert ist, habe ich damit keine Probleme.
Wenn dies ordentlich programmiert ist, kann es auch in späterer Phase durch optimierte Routinen ersetzt werden.
Und mir ist es schnurz wofür eine Technologie erschaffen wurde. Mir ist es wichtig, dass es mit dieser geht.

Eine Sekunde Ausführungszeit ist sehr viel, war aber wahrscheinlich nur ein schlechtes Beispiel.
Etwas "irgendwie" zu implementieren sollte man sowieso nicht machen. Erst kommt die Planung, dann dann erste Idee der Umsetung usw.
Hauptsache man kann am Ende sagen: "Das hab' ich gut gelöst".

Jau die Auafürhrungszeit ist wichtig ... aber ich investiere lieber ne Stunde mehr in gutes Coding als später irgendwelche Probleme mit meinen zuvor produzierten Mist zu bekommen.

wenn es nur darum geht, die karte darzustellen, kann man es von mir aus so machen, dass man den fertigen quelltext mitschickt. auch wenns nicht ideal ist.
aber mit den daten muss man ja der client ja auch arbeiten können, wo ist was auf der map, was hat sich geändert etc.
deswegen kommt man um xml, json oder was auch immer für ein format nicht rum .

Daten via HTML oder XML/JSON übertragen:
Also ich finde es kommt sehr stark darauf an was nachgeladen wird. Ich verwende beides. In einem IGM Formular verwende ich z.B. beim Empfänger-Feld die Autocomplete-Funktion um Spielernamen nachzuladen. Die Namen werden als XML übertragen:

Fasi1
11
Fasi2
12

In der Spiel Hilfe wird mit einem Klick auf ein Menüpunkt der entsprechende Text nachgeladen. Diese Daten werden als HTML übertragen weil ich dort auch Tabellen (für Gebäude und Baukosten) und Formatierter Text verwende.
@Klaus

Ich habe auch eine ähnliche Karte mit Ajax Feedback erstellt. Allerdings ist sie isometrisch und das scrollen geht über Drag&Drop. Diese schwer nachvollziehbaren "Klick und du bist sofort woanders" -Sachen müssen doch nicht mehr sein.

Meine Karte soll auch mal via Drag&Drop verschoben werden können, aber wie du auch sagst, der Aufwand ist da um einiges grösser
ps: Die Koordinaten werden übrigends nun auch aktualisiert.

Viel auf wendiger ist Drag&Drop auch nicht ... man braucht noch nicht mal ne Biblio
SelfHtml erklärt wie:
aktuell.de.selfhtml.org/tippstricks/dhtml/draganddrop/index.htm

Kaum ist man mal kurz aus dem Haus, hält sich jeder für nen AJAX-Experten...
@LeoManiac: Also zuerst mal würd ich mir keine Sorgen wegen Traffik machen, weil 30 MB am Tag einfach lächerlich sind. Sobald es mal 30 GB für die Karte am Tag werden, würd ich mir gedanken über den Traffik machen, aber nicht vorher. Drag&Drop halte ich bei einer Spielekarte für unangebracht aufgrund technischer Einschränkungen. Hast du schonmal 30 positionierte Bilder im Browser mit der Maus verschoben und dich gewundert warum sämtliche Lüfter an deinem PC auf einmal auf hochtouren laufen? So und nun erzähl mir mal warum du umbedingt eine Fat-Client Variante anstrebst für die Darstellung einer Karte bei der eine Quelltextoptimierung etwar 80% des Traffics ohnehin überflüssig machen würde.
Des weiteren wäre es gut wenn du mal selbst ein AJAX-Arbeitsbeispiel zur analyse vorlegst.
@Fasi: Ist eigentlich ne nette kleine Karte, aber der Quelltext ist übelst zusammengewürfelt. Die Koordinaten und das Aussehen deiner div's kannst du komplett in das Stylesheet auslagern und alle 5 Zeilen ein neues Javascript ist vieleicht auch ein wenig übertrieben
Grundsätzlich finde ich es fast schon lächerlich, wie jeder Spieleprogrammierer versucht auf den AJAX-Zug aufzuspringen, ohne sich auch nur ansatzweise über die Möglichkeiten und Beschränkungen der Technologie zu informieren.
reg4rds
chojin

>Drag&Drop halte ich bei einer Spielekarte für unangebracht aufgrund technischer Einschränkungen.
Hast du dir noch nie Gedanken über die Zukunft gemacht? Der Komfort beim Spielen von Browsergames soll doch auch durch dieses Web 2.0 Getue profitieren.
>Grundsätzlich finde ich es fast schon lächerlich, wie jeder Spieleprogrammierer versucht auf den AJAX-Zug aufzuspringen, ohne sich auch nur ansatzweise über die Möglichkeiten und Beschränkungen der Technologie zu informieren.
Was stört dich denn explizit daran? Es ist doch jedem selber überlassen in welchem Maße er das praktiziert.

Grundsätzlich finde ich es fast schon lächerlich, wie jeder Spieleprogrammierer versucht auf den AJAX-Zug aufzuspringen, ohne sich auch nur ansatzweise über die Möglichkeiten und Beschränkungen der Technologie zu informieren. Teufel

Mich störts nicht, muss ich sagen. Soll doch jeder mal Ajax ausprobieren. Man kann doch nur dadurch lernen.
Ich halte es für wichtig, dass man sich als Programmierer umschaut, welche Technologien am kommen sind und welche auch in der Zukunft genutzt werden.
Vor ein paar Jahren war der Firefox noch nicht so verbreitet. Wär ich dabei geblieben und hätte mich beim Erstellen von INetseiten auf den IE beschränkt, stünde ich jetzt ganz schön doof da.
Also ich kann nicht nachvollziehen, warum man kein AJAX nutzen soll, nur weil man das Benutzerhandbuch nicht gelesen hat.

Sorry, aber ihr tut alle so als wäre Ajax ein Zauberwerk.
Nur weil das kind einen Namen bekommen hat ist es doch nicht
total neues. Wer vor 2 Jahren noch nichts mit JavaScript zu tun hatte,
der wird heute noch kein Ajax Experte sein.
Ich habe mir vor ca 6 Monaten das erste mal Javascript angesehen und
denke, dass dort viele möglichkeiten drin sind.
Das Beispiel finde ich ganz nett, vielleicht ist der code nicht der beste,
aber das ist nur ein Stilfrage, um die es hier garnicht geht.
Die Idee finde ich toll.
@ Fasi:
Wenn du ein neues Beispiel hast, dann stell es doch bitte
nochmal rein, würde mich interessieren, ob du es schafftst
die Karte Zeile für Zeile zu scrolen und das ohne eine Hintergrund,
sondern dass es so aussieht als wäre es total dynamisch.

Original von Chojin
@LeoManiac: Also zuerst mal würd ich mir keine Sorgen wegen Traffik machen, weil 30 MB am Tag einfach lächerlich sind. Sobald es mal 30 GB für die Karte am Tag werden, würd ich mir gedanken über den Traffik machen, aber nicht vorher.

Les dir bitte meinen Beitrag noch mal genau durch ... es war nur ein Beispiel mit 10 Karten aktualiesierung pro User/ pro Tag und das ist recht wenig verhältnismässig gesehen, außerdem ist der Traffic pro Tag relativ belanglos der Traffic den du am ende des Monats ist entscheidend für deine Rechnung ... wenn du bereit bist für zuvielen Traffic zu zahlen bitte ist deine Sache dein Host wird sich freuen...und nebenbei bemerkt ... es wäre nur der Traffic für einen Bruchteil des Spiels bzw. der Seite
Ich finds nur relative schade das gerade im Browserspiel-Bereich wenig wert gelegt wird auf ordentliches und sauberes Coding welches auch ein wenig die Resourcen schont...
un von wegen Browserunverträglichkeit mit Browsern in den aktuellsten Versionen ist das alles kein Thema mehr ... wenn man sich auf die 4 Hauptbrowsern beschränkt... wer ältere Software Versionen verwendet muss halt damit rechnen das irgendwas nicht oder nicht richtig funktioniert ... ganz klare Sache

web78.silverline-s19.de/kostenpflichtig/Kylaros_karte/test.php
Mal ein kleiner Versuch von mir, würde mich über Feedback freuen, meinetwegen könnt ihr mich auch wegen meines Programmierstils in der Luft zerreisen und auch deswegen, weils im Moment nur im Firefox läuft, solange ihr die Kommentare im Quelltext unbedacht lasst.... War mein erster Versuch und hab viel Wert auf Dynamik gelegt, wollte nun erstmal gerne hören was ihr dazu sagt!
Greetz,
xXx

Original von Progralixx

Grundsätzlich finde ich es fast schon lächerlich, wie jeder Spieleprogrammierer versucht auf den AJAX-Zug aufzuspringen, ohne sich auch nur ansatzweise über die Möglichkeiten und Beschränkungen der Technologie zu informieren. Teufel

Mich störts nicht, muss ich sagen. Soll doch jeder mal Ajax ausprobieren. Man kann doch nur dadurch lernen.
Ich halte es für wichtig, dass man sich als Programmierer umschaut, welche Technologien am kommen sind und welche auch in der Zukunft genutzt werden.
Vor ein paar Jahren war der Firefox noch nicht so verbreitet. Wär ich dabei geblieben und hätte mich beim Erstellen von INetseiten auf den IE beschränkt, stünde ich jetzt ganz schön doof da.
Also ich kann nicht nachvollziehen, warum man kein AJAX nutzen soll, nur weil man das Benutzerhandbuch nicht gelesen hat.
Schön blöd, dass der IE Ajaxtechniken seit Version 5 beherrscht, sei Version 6 auch mit den heutigen Scripten klarkommt, und schön blöd, das "Ajax" quasi von MS erfunden wurde.. wie auch die Grundlagen von DOM.
Schön blöd, die Argumentation von dir ist gerade zusammengebrochen.. wer ist hier besser informiert?
Mit neuen Techniken und Technologien zu spielen, das ist okay. Man sollte nur schaun, das man die Ergebnisse der Spielwiese in Relevanz zum eigentlichen SPiel stellt. Nicht alles ist brauchbar und interessant. Und gerade bei Ajax sollte man auf Dinge wie Erweiterbarkeit, Trafficminierung (XML, CSS JSON) achten. Gerade das zeichnet das ganze ja aus..
Auf die Idee, das ganze mit XSL zu beschleunige, ist hier aber noch keiner gekommen?

Entwickelt wurde AJAX, damals hieß es noch XmlHttp-Request, übrigens für Outlook Web Access und wurde schon vor 6 Jahren eingesetzt. Die restliche Entwicklergemeinde hat dieses Feature erst später entdeckt, als Firefox und Opera diese Erweiterung nachprogrammiert haben.
de.wikipedia.org/wiki/XMLHttpRequest

Original von TheUndeadable
Die restliche Entwicklergemeinde hat dieses Feature erst später entdeckt, als Firefox und Opera diese Erweiterung nachprogrammiert haben.
de.wikipedia.org/wiki/XMLHttpRequest

richtig, weils dann erst richtig interesant wurde ...
was auch langsam neben Ajax wieder interesant wird ist Comet was eigentlich auch ne uralte Technik ist
benramsey.com/archives/comet-is-the-new-ajax/
alex.dojotoolkit.org/?p=545

Original von knalli
Schön blöd, dass der IE Ajaxtechniken seit Version 5 beherrscht, sei Version 6 auch mit den heutigen Scripten klarkommt, und schön blöd, das "Ajax" quasi von MS erfunden wurde.. wie auch die Grundlagen von DOM.
Schön blöd, die Argumentation von dir ist gerade zusammengebrochen.. wer ist hier besser informiert?

Du hast meine Argumentation falsch interpretiert, Knalli.
Das Beispiel mit dem Firefox und dem IE sollte verdeutlichen, dass man nicht ewig an einer Technologie hängenbleiben soll, sondern eben mit der Zeit gehen muss. Im Beispiel mit den Browsern heißt das: Wenn ich heute noch Internetseiten mache, die ausschließlich im Internet Explorer darstellbar sind, nur weil der IE vor ein paar Jahren der meistgenutzteste Browser war, sperre ich so alle Nutzer aus, die heute mit dem Firefox unterwegs sind.
Das Beispiel hatte also nichts mit Ajax - geschweige denn mit der Entwicklung von Ajax zu tun und so habe ich deine Kompetenz in diesem Bereich auch nicht in Frage gestellt.

Dann hast du deinen Post aber unglücklich geordnet
Gerade dieses "Ajax-Beispiel" zeigt, was früher schon möglich gewesen wäre, was man aber wegen den anderen Browsern nicht machen konnte. Heute nennt man dies "moderne Technologien" und zeigt auf den IE, wenn er es nicht kann.
Ajax, Dom und Co sind nur deshalb heute populär und in Anwendung zu finden, weil die ursprünglichen Erfindungen von MS (afaik) spezifiziert wurden und "Standard" wurden.
Interessant wird es heute, weil die Standards jetzt in allen gängigen aktuellen Browserversionen implementiert wurden und man sichergehen kann, das es alle können. Also nicht, weil es die anderen können, sondern weil der Standard geschaffen wurde.

Was man früher per unsichtbare (I)frames und JavaScript gemacht hat, hat man nun einfach nur automatisiert und Ajax genannt.
Mehr steckt hinter Ajax eigentlich nicht hinter.

Wen interessiert schon traffic wenn man immer noch in der Entwicklung steckt?
Ist das spiel mal aktiv / traffic ein problem. Einfach einen "Javascript Cache" einbauen. Ist n 10 Zeiler, schon werden gleiche Ajax Requests gecached.
Und wenns immer noch ned hinhaut, DANN kann man das ganze überarbeiten... wird aber sicher auch kein grosses problem sein da einfach den Transport auszutauschen.
Was ich mir eher jetzt überlegen sollte... wo und wie werden allfällige bewegungen dargestellt. Also wenn Einheit von A nach B geht.
Ist jetzt egal obs schnell geht, oder ne Bewegung 1 Stunde dauert - passieren tuts dennoch. Ob Reload Intervall nun 1 Stunde (und der user ist 10h online) oder 1 sec oder realtime.
Wie solls gehen?
Gruss

Wenn man erst optimiert, wenn es nötig ist, sollte man seinen Arbeiststil ändern. Ich kenn das doch von mir, erst schuster ich mir schnell was provisorisches zusammen, was funktioniert, aber Traffic und Zeit kostet wie nichts Gutes und dann lösch ich den ganzen Kram und mach es neu. Lieber gleich richtig durchdacht alles optimiert, das erspart ne Menge Arbeit, auch wenns nur ne Entwicklungsphase ist...
Wie sollen die Bewegungen schon dargestellt werden? Du hast den Lösungsansatz ja schon geschrieben: window.setInterval({...});. Ob das Interval nun ne Stunde oder nur ne Sekunde ist, ist bei vielen Operationen egal (ist ja nicht dein Server, der arbeiten muss).
Edit:
Jetzt hab ich deine Frage erst richtig verstanden...
Ich würde die Bewegung von Einheiten per Javascript dynamisch darstellen (in ausreichenden Intervallen) und wenn eine Einheit sein Ziel erreicht beim Server nachfragen, ob dort dann was passiert (Angriff odr sowas).

Original von schokofreak
Wen interessiert schon traffic wenn man immer noch in der Entwicklung steckt?
Ist das spiel mal aktiv / traffic ein problem. Einfach einen "Javascript Cache" einbauen. Ist n 10 Zeiler, schon werden gleiche Ajax Requests gecached.
Und wenns immer noch ned hinhaut, DANN kann man das ganze überarbeiten... wird aber sicher auch kein grosses problem sein da einfach den Transport auszutauschen.

tolle Einstellung ... naja so sichert man sich vielleicht im Berufsleben die Arbeit der nächsten Wochen nur leider fällt man damit ziemlich schnell auf die Schnauze weil sich das rumspricht das du da ned ganz saubere Arbeit machts ...
Nene lieber von vorne rein versuchen die optimalste Lösung hinzukriegen sparrt Zeit, Arbeit und Ärger...
Wenn ich in Team an einen Project arbeite an dem mir selber was liegt sehe ich das auch nicht gern da einfach was hingeschustert wird...lieber von vorne rein planen und wenn man ned genau so sicher ist welche Lösung man einschlagen soll lieber ruhig n Tag aufschieben und darüber diskutieren ist fast genauso wichtig wie n e gute Organisation um n ordentliches Endprodukt auf die Beine stellen zu können.
Aber scheint wohl in der Softwareentwicklung gang und gebe zu sein das die Funktion im Vordergrund steht und nicht Quallität sowie evl. Erweiterbarkeit.

Original von LeoManiac
tolle Einstellung ... naja so sichert man sich vielleicht im Berufsleben die Arbeit der nächsten Wochen nur leider fällt man damit ziemlich schnell auf die Schnauze weil sich das rumspricht das du da ned ganz saubere Arbeit machts ...

Falsch: Somit reduzierst du den Arbeitsaufwand - reduzierst die Kosten.
Vorausgesetzt es ist jederzeit möglich, hier das ganze zu beschleunigen (sprich man hat es sich überlegt und technisch nachgewiesen; was es ist) muss man es noch nicht implementieren.
Wirds benötigt, lässts sich ohne Probleme implementieren. Wirds nicht benötigt wirds weggelassen.
Zuerst machst das wichtigste am System, danach priorisierst du die Erweiterungen... danach wiederum... danach wiederum... bis du das Ziel erreichst. Ev. wirds diese spezifische Erweiterung benötigen - ev. nicht.
Genau so hält man kosten tief. Vorausgesetzt wie gesagt: man hat die möglichen Risiken im Griff / ne fundierte Entscheidugnsgrundlage ist vorhanden.
Störti: Ich sprech die Übertragung vom / zum Server an.
Sprich ob man da n Push / n Pull durchführt.
DA scheitern momentan sämtliche Karten.

Das sehe ich vollkommen anders ... durch diese Art u. Weise der Entwicklung erschwerst du dir nur jegliche Weiterentwicklung ... und provozierst praktisch schon die Probleme die mit einerevl. Weiterentwicklungen auftauchen werden... klar Kostenreduzierung ist wichtig aber so welchen Preis? Was bringt mir eine Kostenreduzierung wenn ich mir für einen Folgeauftrag den Arbeitswand vergrößere? Sorry aber in der Softwareentwicklung gilt meiner Meinung nach die selbe Regel wie im Straßenverkehr : "vorausschauend handeln" !!!