Alternative Echtzeit-Methode

Hi!
Angenommen, ich möchte ein Browserspiel entwickeln, in welchem der Kampf zwischen zwei Spielern nahezu in Echtzeit dargestellt werden soll. Das heisst, es wird nicht einfach ein statischer Kampfbericht eingeblendet, sondern der rundenweise Schlagabtausch soll für den Spieler verfolgbar sein.
Gibt es dafür irgendwelche Alternativen zu Flash, JavaScript, JavaApplets oder ActiveX?
Vielen Dank schon im Vorraus,
mats

Ich bin gerade dabei genau das umzusetzten.
Aber eine andere Sprache als die von dir genannten wüsste ich auch nicht.
Ich benutze für Echtzeit einen Flash-Clienten und einen Java-Server

Hi!
Naja, Flash fällt auf jeden Fall für mich flach, ich komme damit einfach nicht zurecht. Ich bin sogar zu doof, ein einfaches Tweening richtig hinzubekommen, Flash bringt mich regelmäßig an den Rand des Wahnsinns. Die Technologie, die mir bis jetzt am meisten zusagt, ist JavaApplets, aber da müsste ich mich dann erst einarbeiten. Bekomme mein Testapplet bisher nicht zum Laufen, mein Browser schmiert jedes Mal ab. Mal schauen.
Gruß,
mats

Ich hatte genau das selbe Problem.
Habe anfangs auch versucht, das Kampfsystem mit einem Java-Applet umzusetzten und ich rate dir: lass es
Java ist einfach viel zu langsam für sowas, der loader im Browser frisst Ressourcen ohne Ende und Java ist nicht annähernd so weit verbreitet wie Flash.
In Flash zu programmieren find ich auch grausam. Erinnert mich irgendwie immer wieder an Photoshop, nur dass man statt den tausend Ebenen tausen Movieclips hat.
Der Quelltext ist in vielen Schnipseln verteilt , in jedem Movieclip steht ein bisschen was.
Aber Flash ist halt einfach die schnellste und praktischste Methode sowas umzusetzten

ich benutz dafur canvas (in einer relativ schlechten variante .. hätte da noch viel zu tun) in kombination mit 10-sek.-ajax-polls (10 sec ist bei mir eine runde), die nur die daten im json-format aus dem c++-daemon saugen.
an sich alles ganz nett, aber in der praxis auch noch suboptimal und verbesserungswürdig - aber eine anregung.
bei kürzeren kampfrunden kann man auch per ajax einen server-push machen (hab ich bei einer js-chat-applikation gesehen, läuft super. man darf nur eben nicht auf request.finished warten, sondern muss schon in den vorherigen request-stages einsteigen und die daten parsen).
damit umgeht man ganz gut diesen flash/java-krams (mit beidem konnte ich mich noch nie anfreunden)

Hi!
Javascript ist im Grunde auch nicht wirklich das, wonach ich suche, weil ich Funktionen zur Kollisionserkennung benötige. Und mir dafür C++ UND Ajax anzueignen, fehlt mir die Zeit und die Lust. Bin doch nur ein armer kleiner PHP-Programmierer.
Es läuft alles leider auf Flash hinaus, mal sehen, werde mal einen weiteren Versuch starten, mich in Actionscript einzuarbeiten. Mir graut jetzt schon davor.
Gruß,
mats

Javascript ist im Grunde auch nicht wirklich das, wonach ich suche, weil ich Funktionen zur Kollisionserkennung benötige.

Von der Algorithmik her kannst du mit JavaScript alles erledigen, was auch in Java oder Flash geht. Auch eine Kollisionserkennung ist in JS möglich.
Die Frage ist: Kannst du es mit JS auch darstellen. Dort sehe ich noch die größten Schwierigkeiten, aber in den neuen Browsern (IE 8, FF 3 und AFAIK auch Opera 9.5) sollte die JS-Performance drastig erhöht worden sein.

Hi!
Kollisionserkennung in JavaScript? Hättest Du da vielleicht ein paar Links/Infos zu? Das wäre wirklich optimal.
Gruß,
Mats

www.gamedev.net/reference/list.asp?categoryid=45#199

Hi!
Ich dachte eher so an Anleitungen oder Beispiele direkt mit JavaScript. Gamedev kenne ich natürlich, und habe schon viele Aspekte daraus in meine Ideen einfliessen lassen. Trotzdem danke für den Link.
Gruß,
mats

Original von mats
Hi!
Ich dachte eher so an Anleitungen oder Beispiele direkt mit JavaScript. Gamedev kenne ich natürlich, und habe schon viele Aspekte daraus in meine Ideen einfliessen lassen. Trotzdem danke für den Link.
Gruß,
mats

In JavaScript funktioniert es vom Prinzip genauso, nur dass Du eben den JS-Syntax und Befehle verwenden musst. Vielleicht solltest Du dich zuerst einmal in JS einarbeiten.

Was benutzt Du denn als Backend Sprache? Wenn es Rails ist, gibt es den Juggernaut Push Server mit dem Du Echtzeit Updates über eine persistente Verbindung an die Clients schicken kannst: juggernaut.rubyforge.org/

Er erwähnte doch er sei PHP-Programmierer.
>Gibt es dafür irgendwelche Alternativen zu Flash, JavaScript, JavaApplets oder ActiveX?
Ein iframe, dass den aktuellen Stand mittles Refresh Anzeigt. Aber das ist wirklich poor mans Alternative.
Wenn du schon was lernen willst dann wäre meine persönliche Gewichtung in diesem Fall:
Javascript > Flash > Java
Edit: Achja, da wäre noch Silverlight. Aber das Plugin ist so verbreitet wie Wurstwasser...

Original von Klaus
Ein iframe, dass den aktuellen Stand mittles Refresh Anzeigt. Aber das ist wirklich poor mans Alternative.

Oh, ich glaube zu solchen Methoden könnte Undead auch noch ein paar Sachen erzählen.

Hi!
Also die Sache mit dem Iframe vergessen wir am besten gleich wieder
Werde mich, wie gesagt, mit Flash eingehend beschäftigen. Irgendwann werde ich diesem Teufelsprogramm schon meinen Willen aufzwingen, ist wohl alles eine Frage der Geduld.
Besten Dank nochmal an alle, bin aber trotzdem für weitere Anregungen immer offen!
Gruß,
mats

Wenn dich an Flash vor allem das Programmieren in der Flash-Umgebung stört, dann kannst du auch per Plugin in Eclipse arbeiten. Wir arbeiten jetzt seit 4 Monaten mit Actionscript und haben Flash noch kein einziges Mal gebraucht.
Allerdings benutzen wir Bitmap-Animationen und kein Tweening - nur etwas irgendwie vergleichbares wie Tweening bietet sowieso keine der Alternativen oder hat sich daran was geändert in den letzten Monaten?

Hi!
Tweening brauche ich auch nicht zwingend, war nur ein Beispiel. Flash versucht mit vielen verschiedenen Funktionen (/Bugs?), mich völlig kirre zu machen.
Gruß,
Mats

Ich werfe einfach mal Silverlight ein. Da kannst du auch mit echten Sockets mit dem Server kommunizieren. Im Gegensatz zu Flash kann man bei SL auch vernünftig Programmieren (C#)... Grafik kann man dort auch viel machen

Wie gesagt, bei SilverLight ist noch der Nachteil, dass das nicht wirklich viele haben.
Da das unter Windows aber nur ~1MB sind, die dafür installiert werden müssen, und dank Novell das auch unter Linux laufen soll, denke ich, dass man durchaus darauf setzen kann.

Hinzu kommt Unterstützung für die sogenannte Duplex-Kommunikation, die es Applikationen erlaubt, Daten per Push an den Client zu senden.

www.golem.de/0806/60249.html

Original von TheUndeadable

Hinzu kommt Unterstützung für die sogenannte Duplex-Kommunikation, die es Applikationen erlaubt, Daten per Push an den Client zu senden.

www.golem.de/0806/60249.html
welche aber im endeffekt auch nur ein pollender webrequest ist, der comet artig verzögert wird.
(Vorteil natürlich, dass man sich um sogut wie nichts kümmern muss dabei)

Sorry, aber Silverlight ist eine Totgeburt. Niemals wird es Flash das Wasser abgraben.

> Sorry, aber Silverlight ist eine Totgeburt. Niemals wird es Flash das Wasser abgraben.
Ziel von Silverlight ist es Flash nicht das Wasser abzugraben, sondern zum Teil eine sinnvolle Alternative zu bieten.
Flash und Silverlight können ohne weiteres koexistieren, ich gehe auch davon aus, dass der Verdrängungskampf nicht beim Kunden stattfindet, sondern im Hintergrund bei den Entwicklern.
Aber der Kunde wird davon wenig mitbekommen. Er wird auch die Unterschiede zwischen Flash und Silverlight nicht merken, da beides hochwertige Produkte sind.

Ich entwickele derzeit mit Silverlight, und muss sagen, das es eigentlich sehr sehr ordentlich ist. Wer im MS Umfeld entwickelt wird schnell glücklich damit.
Die Frage ist nur wie schnell sich Silverlight verbreiten kann. Wenn dort der Vorsprung von Flash eingeholt ist, denke ich ist Silverlight Flash überlegen...
Und da als eins von vielen großen Beispielen NBC die Seite zu den Olympischen Spielen mit Silverlight entwickelt wird auch eine gewissen Verbreitung geben.
/Plugin Flamewar on

Bis Silverlight verbreitet ist können wir warten bis graue Haare wachsen wenn man sich die Verbreitungsgeschwindigkeit der Redmonder Browserupdates mal ansieht.

Original von Klaus
Bis Silverlight verbreitet ist können wir warten bis graue Haare wachsen wenn man sich die Verbreitungsgeschwindigkeit der Redmonder Browserupdates mal ansieht.

Naja Flash bekommt man nichtmal über so nen eingebauten Updater
Silverlight kann ja noch OnDemand (dh wenn man ne Seite aufruft, die Silverlight braucht kann man es auch installieren) verbreitet werden. Also auf die gleiche Art wie Flash wohl bei den meisten PCs installiert wurde!

Original von Klaus
Bis Silverlight verbreitet ist können wir warten bis graue Haare wachsen wenn man sich die Verbreitungsgeschwindigkeit der Redmonder Browserupdates mal ansieht.

Dafür kann den meisten MS aber einfach mit einem Auto-Windows-Update Silverlight unterschieben und die meisten Nutzer werden wohl nicht einmal etwas davon mitbekommen.

> kann den meisten MS aber einfach mit einem Auto-Windows-Update Silverlight
Dies wird nicht der Fall sein, da sich Adobe ansonsten vor der EU ausweint. [1]
Silverlight ist nur als optionales, vom Benutzer auszuwählendes Update per WU verfügbar.
[1] Siehe Problematik mit PDF und MS Word 07, bei dem MS den PDF Export aus Wettbewerbsgründen nur als Plugin ausliefert.

Original von altertoby
Also auf die gleiche Art wie Flash wohl bei den meisten PCs installiert wurde!

Flash wird bereits mit Windows ausgeliefert.

Original von Klaus

Original von altertoby
Also auf die gleiche Art wie Flash wohl bei den meisten PCs installiert wurde!

Flash wird bereits mit Windows ausgeliefert.
Wie bitte was ? Das habe ich aber noch nicht gesehen.
Zudem ist auch dein anderes Zitat unsinnig Webseiten kann man mit jedem MS Browser ansehen, Silverlight Seiten aber nur wenn man das Plugin überhaupt hat.
Auch von Flash haben nur (geschätzt) < 10 % die wirklich aktuellste Version.
Wie gut sich Silverlight verbreitet mag ich nicht prognostizieren, aber so schlecht wie es oft geredet ist wird es sicher nicht

>Wie bitte was ? Das habe ich aber noch nicht gesehen.
Ich habe es selbst nicht geglaubt, bis ich es mit eigenen Augen gesehen habe. Das kriegt man natürlich nicht mit wenn man alternative Browser benutzt.
> Zudem ist auch dein anderes Zitat unsinnig [...]
Was habe ich denn zitiert?
> Auch von Flash haben nur (geschätzt) < 10 % die wirklich aktuellste Version.
Definiere bitte "die aktuellste Version".
Der Flash Player 9 hat eine Verbreitung von über 90%. (Quelle).
Windows XP SP3 liefert nochmal ein Update auf die 9er mit. Umso ärgerlicher dass es kein Update auf den neuesten IE gibt.
Ich möchte hier aber nicht Flash verteidigen...
Nun zurück zum Thema.
Mit Silverlight hat man die angenehmste Methode um stabile und schnelle Verbindungen bereitzustellen. Aber oft wäre es toll die Funktionalität in Javascript zu nutzen. Wäre es da nicht toll mit dem Plugin zu kommunizieren und dieses dann für den Datenaustausch zu nutzen? Wenn kein Silverlight installiert ist kann man dann auf Flash oder sogar Java zurückfallen.

Original von Klaus

 Wäre es da nicht toll mit dem Plugin zu kommunizieren und dieses dann für den Datenaustausch zu nutzen? Wenn kein Silverlight installiert ist kann man dann auf Flash oder sogar Java zurückfallen.

 Das wäre echt Klasse.

Original von the-architect

Original von Klaus

 Wäre es da nicht toll mit dem Plugin zu kommunizieren und dieses dann für den Datenaustausch zu nutzen? Wenn kein Silverlight installiert ist kann man dann auf Flash oder sogar Java zurückfallen.

 Das wäre echt Klasse.

 Bei Java geht das schon ne Weile. Man kann vom Applet Javascript-Funktionen aufrufen und mit Javascript auch aufs Applet und deren öffentlichen Funktionen.

Mit der aktuellen JRE ist das Ganze initialisieren, was das Manko bei dem Applets ist, sehr schnell geworden. Deswegen könnte man dieser Art und Weise auch eine Chance geben. Aber wieso dann mittels JS auf ein unsichtbares Applet zugreifen und die Daten darüber holen. Dann könnte man doch gleich alles mitn Applet umsetzen und man hat ein besseres Ergebnis (und vorallem schneller). Das ganze JS - Java - Konstrukt funktioniert ja dann ohne Plugin ja eh nicht. Das Gleiche ist natürlich beim Flash und bei Silverlight gegeben.

Die gangbarste Methode hierfür wäre vermutlich ein Flashclient und ein RTMP-Server im Backend. Du hast dann die Wahl, ob du den Datenaustausch über RPC's macht oder dir ein shared Object baust, bei dem sich der Server darum kümmert, das clientseitig zu synchronisieren.

Man muß sich da auch nicht unbedingt mit Flex und Actionscript rumschlagen, wenn man das nicht mag, und auch das Sparschwein einem FMS zu opfern bleibt dir erspart, wenn du auf OpenSource Alternativen zurückgreifst.

Voraussetzung wäre in diesem Fall aber vermutlich zumindest ein VPS, der Feldwaldwiesenwebhost bietet n der Regel nicht die technik an um sowas zu betreiben. Alternativ könntest du schauen, ob du einen günstigen Tomcat , Jetty oder wasauchimmer Host auftreibst, damit läßt sich schon eine Menge machen.

saludos

Stefan

Original von Tron

Alternativ könntest du schauen, ob du einen günstigen Tomcat , Jetty oder wasauchimmer Host auftreibst, damit läßt sich schon eine Menge machen.

saludos

Stefan

Jo entweder nen Jetty oder nen Tomcat grizzly nehmen und einfach den genialen Comet-Support nutzen, was nur Long lived Ajax-Requests sind, welche aber (zumindest beim Jetty) ins unendliche gehen können. Nachteil: Du hast nur noch eine offene mögliche Leitung für andere Sache wie Bilder oder sowas. Also wenn alles standardmäßig auf 2 mögliche Verbindungen pro Server eingestellt ist.

Alternativ kannste die Comet-Schnittstelle auf ne Subdomain legen, die dann separat vom Server läuft. Damit sparste dir Flash oder ein Applet und handelst alles mit Javascript ab

oder: Glassfish grizzly. Kommt aber aufs gleiche raus

Original von KoMtuR

Original von Tron

Alternativ könntest du schauen, ob du einen günstigen Tomcat , Jetty oder wasauchimmer Host auftreibst, damit läßt sich schon eine Menge machen.

saludos

Stefan

Jo entweder nen Jetty oder nen Tomcat grizzly nehmen und einfach den genialen Comet-Support nutzen, was nur Long lived Ajax-Requests sind, welche aber (zumindest beim Jetty) ins unendliche gehen können. Nachteil: Du hast nur noch eine offene mögliche Leitung für andere Sache wie Bilder oder sowas. Also wenn alles standardmäßig auf 2 mögliche Verbindungen pro Server eingestellt ist.

Ich habe sowas erst vor kurzem in Jetty mit den Continuations umgesetzt. Ist im Endeffekt sowas ähnliches wie Grizzly, nur etwas simpler Im Endeffekt läuft auf dem Client ein Javascript welches konstant einen Long-Poll-Request aktiv hält um Nachrichten zu empfangen. Jede Nachricht hat einen Typ für den sich eine Javascript-Funktion als Handler registrieren kann. Serverseitig gibts eine Registry für aktive Clients über welche Nachrichtenlisten übertragen werden können. Also falls jemand mit Jetty arbeitet und Implementierungshilfen benötigt kann er mich gerne fragen

Prinzipiell kann man über die API von Jetty auch richtige Streams realisieren. Das hat allerdings den Nachteil, dass man sie nicht mehr über XMLHTTPRequest lösen kann da diese, zumindest im IE, kein Streaming unterstützen. Dadurch müsste man den Stream in einen IFrame einbinden wodurch der Browser aber seine Ladeanimation endlos aktiv hält. Da das ziemlich unschön ist habe ich mich mit Long-Polls zufrieden gestellt.

Original von exe

Original von KoMtuR

Original von Tron

Alternativ könntest du schauen, ob du einen günstigen Tomcat , Jetty oder wasauchimmer Host auftreibst, damit läßt sich schon eine Menge machen.

saludos

Stefan

Jo entweder nen Jetty oder nen Tomcat grizzly nehmen und einfach den genialen Comet-Support nutzen, was nur Long lived Ajax-Requests sind, welche aber (zumindest beim Jetty) ins unendliche gehen können. Nachteil: Du hast nur noch eine offene mögliche Leitung für andere Sache wie Bilder oder sowas. Also wenn alles standardmäßig auf 2 mögliche Verbindungen pro Server eingestellt ist.

Ich habe sowas erst vor kurzem in Jetty mit den Continuations umgesetzt. Ist im Endeffekt sowas ähnliches wie Grizzly, nur etwas simpler Im Endeffekt läuft auf dem Client ein Javascript welches konstant einen Long-Poll-Request aktiv hält um Nachrichten zu empfangen. Jede Nachricht hat einen Typ für den sich eine Javascript-Funktion als Handler registrieren kann. Serverseitig gibts eine Registry für aktive Clients über welche Nachrichtenlisten übertragen werden können. Also falls jemand mit Jetty arbeitet und Implementierungshilfen benötigt kann er mich gerne fragen

Prinzipiell kann man über die API von Jetty auch richtige Streams realisieren. Das hat allerdings den Nachteil, dass man sie nicht mehr über XMLHTTPRequest lösen kann da diese, zumindest im IE, kein Streaming unterstützen. Dadurch müsste man den Stream in einen IFrame einbinden wodurch der Browser aber seine Ladeanimation endlos aktiv hält. Da das ziemlich unschön ist habe ich mich mit Long-Polls zufrieden gestellt.

Jetty hat den Nachteil, dass es Exceptions wirft, um die Verbindung in dem Threadpool zu speichern (RetryException). Grizzly macht das anders. Da ich mit GWT arbeite und nun extra wegen Jetty GWT 1.5 anpassen musste (Das Workaraound gibts leider nur für GWT 1.4). Aber ich arbeite auch mit Jetty, da ich Grizzly nicht ohne weiteres zu mlaufen gebrahct habe und ich einen embedded Server brauche (Initialisierung beim ersten Aufruf eines Servlets ist einfach ma Mist).

Aber ich verfahre genauso wie du. Einen Long Poll und auf Serverseite eine Art "Registry" (Liste der Online-Clienten).

Streaming hab ich noch nicht probiert, aber GWT hat da eh Einschränkungen. Da nehme ich lieber den Overhead des neuen Requests in kauf.

Btw: Grizzly schafft mehr User als Jetty laut Benchmarks *fg*

Original von KoMtuR

Original von exe

Original von KoMtuR

Original von Tron

Alternativ könntest du schauen, ob du einen günstigen Tomcat , Jetty oder wasauchimmer Host auftreibst, damit läßt sich schon eine Menge machen.

saludos

Stefan

Jo entweder nen Jetty oder nen Tomcat grizzly nehmen und einfach den genialen Comet-Support nutzen, was nur Long lived Ajax-Requests sind, welche aber (zumindest beim Jetty) ins unendliche gehen können. Nachteil: Du hast nur noch eine offene mögliche Leitung für andere Sache wie Bilder oder sowas. Also wenn alles standardmäßig auf 2 mögliche Verbindungen pro Server eingestellt ist.

Ich habe sowas erst vor kurzem in Jetty mit den Continuations umgesetzt. Ist im Endeffekt sowas ähnliches wie Grizzly, nur etwas simpler Im Endeffekt läuft auf dem Client ein Javascript welches konstant einen Long-Poll-Request aktiv hält um Nachrichten zu empfangen. Jede Nachricht hat einen Typ für den sich eine Javascript-Funktion als Handler registrieren kann. Serverseitig gibts eine Registry für aktive Clients über welche Nachrichtenlisten übertragen werden können. Also falls jemand mit Jetty arbeitet und Implementierungshilfen benötigt kann er mich gerne fragen

Prinzipiell kann man über die API von Jetty auch richtige Streams realisieren. Das hat allerdings den Nachteil, dass man sie nicht mehr über XMLHTTPRequest lösen kann da diese, zumindest im IE, kein Streaming unterstützen. Dadurch müsste man den Stream in einen IFrame einbinden wodurch der Browser aber seine Ladeanimation endlos aktiv hält. Da das ziemlich unschön ist habe ich mich mit Long-Polls zufrieden gestellt.

Jetty hat den Nachteil, dass es Exceptions wirft, um die Verbindung in dem Threadpool zu speichern (RetryException).

Man kann sich drüber Streiten inwiefern das guter Stil ist, aber ich sehe keinen großen Nachteil der Methode.

Streaming hab ich noch nicht probiert, aber GWT hat da eh Einschränkungen. Da nehme ich lieber den Overhead des neuen Requests in kauf.

Im Endeffekt kann man eine Continuation auch ein zweites (und drittes, und ...) Mal suspenden. Wenn man nach einem Resume die suspend-Methode aufruft resettet sie den internen Status der Continuation. Wenn man dann die Methode nochmal aufruft wird der Thread erneut freigegeben und die Verbindung bleibt erhalten.

Java:

while(true) {
    continuation.suspend();
    // resume bearbeiten
}

Btw: Grizzly schafft mehr User als Jetty laut Benchmarks *fg*

Traue keinem Benchmark das du nicht selbst gefälscht hast

Original von exe

Im Endeffekt kann man eine Continuation auch ein zweites (und drittes, und ...) Mal suspenden. Wenn man nach einem Resume die suspend-Methode aufruft resettet sie den internen Status der Continuation. Wenn man dann die Methode nochmal aufruft wird der Thread erneut freigegeben und die Verbindung bleibt erhalten.

Java:

while(true) {
    continuation.suspend();
    // resume bearbeiten
}

jo serverseitig ist das kein Problem. Aber ich weiß nicht wie das GWT das handhabt. Ich denke die beziehen sich auf status=4 und den erreichste ja nie so wirklich, wenn du die Verbindung offen hälst.

Achja und ich hab noch nichts funktionierendes gefunden, wie man im Javascript mitbekommt, wenn was neues da ist, ausser aller paar Sekunden mal zu schauen, was für mich nciht gerade in Frage kommt

In der aktuellen iX ist ein kleiner Bericht über Silverlight

- Beliebige Ports
- Silverlight auch ohne sichtbares 'Applet' mit direktem Zugriff auf das DOM nutzbar.