Java basierte Browsergames

Hallo Zusammen,

dieser Beitrag ist das Gegenstück dieser Umfrage

http://galaxynews.de/groups/1_browsergames_community/forums/6921_bereitschaft_zu_java_spielen.html

für uns Entwickler.

Wie seht Ihr die Chancen und Akzeptanz von Java basierten Browsergames, bestehend aus Java-Server und Java-Applet? Der Client setzt ja dann die installierte JRE (6) voraus, welche beim Spielstart geladen werden muss.

Habt Ihr bereits Erfahrungen mit Java-Applets und/oder der Verbreitung und Bereitschaft zu Java?

Die Vorteile für (uns) Entwickler wären u.a.: Persistente Echtzeit-Verbindungen, 2D + 3D Hardware-Beschleunigung, nahezu unbegrenzte Freiheit bei der Gestaltung und Umsetzung des Spiels (browser- und systemübergreifend), Quellcode- und Grafikdiebstahl sowie Manipulation der Spiellogik sehr schwierig

Nachteile: v.a. Verbreitung und Akzeptanz von Java

Grüße,

D. Craig

naja mittlerweile denke ich dass die casual browsergamer über ihren Iphone , HTC usw online gehen.. läuft denn java drauf? weil flash tut es ja nicht

Java-Applets laufen leider nur bei Browsern mit vollwertigem Betriebssystem (Windows, Mac, Linux).

Es muss schon einen wahnsinnigen Vorteil - sprich: es muss "die" Killerapplikation sein - versprechen, damit jemand einen Java-Client [!] akzeptiert. Die Verbreitung (eines aktuellen) ist geringer als Flash und kann auch geblockt werden. Und leider haben einige Java-Programmierer absolut keinen Schimmer, wie man eine UI erstellt, so dass viele Leute schon mit Vorurteilen dasitzen (heutzutage muss einem Programm nicht mehr sofort ersichtlich sein, dass es mit Java erstellt wurde).

Der Trend geht aktuell bzw. langfristig eher in die native Unterstützung; allenfalls so Exoten wie Quake mal außen vor. Für richtige Spiele (Shooter, Autorennen) ist ein Plugin mit echter, nativer Grafikunterstützung u.U. noch relevant. Aber nicht mehr für den Großteil der Spiele.

Für den Server sieht das ganz anders aus; das ist vollkommen transparent zum Client. Da wird schon heute mehr Java eingesetzt, als mache glauben. Und andere Frameworks oder Sprachen. Man sieht es eben nicht bzw. es ist eine Mischung, je nach dem was passt (etwa auch: PHP-Web-Frontend + Java/C(++)-Backend).

Wenn ich das so betrachte, liegt der einzige Vorteil von Flash & Java gegenüber dem bewährten HTML-CSS-JavaScript Gespann in den Socketverbindungen, die performanten Datenaustausch in Echtzeit ermöglichen, ohne großen HTTP-Overhead.

Zwar ist das mit AJAX schon besser geworden, aber leider gibt es immernoch keine Möglichkeit, dass der Server unaufgefordert Daten an den Client sendet. Gerade das ist aber bei Multiplayer-Spielen aber sehr wichtig!

Wie anderswo bereits gesagt: Die HTML5-Family macht's möglich -- irgendwann. Derzeit ist die Socket-API aufgrund API-Fehlern im Review, wenn man mal absieht, das es eh noch nicht final war.

Comet gibt es auch noch, für großen und viel Echtzeittraffic natürlich limitiert.

So gesehen: Derzeit hat Flash oder Java dort einen Vorteil, der auch in den nächsten Monaten nur durch die neusten Browser nativ und wohl als Entwicklungsversion möglich wird.

Wenn man jetzt mit der Entwicklung eines Browsergames beginnt, ist es ein Fehler nicht auf neue Technologien wie HTML5 zu setzen. Am einfachsten kann man Seiten mit JavaScript manipulieren, mit dem es lange nicht mehr so schwierig ist zu entwickeln wie es früher einmal war. Es gibt Entwicklungsumgebungen und Debuggingtools als auch Testframeworks.

Wenn man dann sowieso einen javascriptlastigen Client hat, bietet es sich an den Server auch in JavaScript zu implementieren. Mit den Engines die in einem Wettkampf zwischen den Browsern immer weiter verbessert werden kann man auf Serverseite noch mehr Performance erzielen. Kompiliertes JavaScript ist deutlich schneller als interpretiertes PHP.

NodeJS ist noch im Entwicklungsstadium, hat aber durchaus Potenzial PHP durch JavaScript abzulösen.

Ich würde nicht auf Java setzen, dafür spricht zuviel dagegen.

Original von Phoscur

Ich würde nicht auf Java setzen, dafür spricht zuviel dagegen.

Da du von Servertechnologien sprichst, bin ich jetzt sehr gespannt, was dort gegen Java spricht.

Ich arbeite in einem Umfeld, in dem je nach Problemstellung entschieden wird, welche Technologien benutzt werden. Solchen Argumenten bin ich immer offen  gegenüber. Ein generelles "Würde ich nicht drauf setzen" als Einschätzung zeigt dass du dich...vorsichtig ausgedrückt...nicht auskennst.

Maxx

Vor allem: Was spricht für JavaScript auf dem Server? Das ist eine hohe, pauschale Aussage. Genauso wenig kann man MySQL, Oracle oder irgendeine NoSQL-DB in einen Topf werden und "vergleichen". Das funktioniert nicht.

NodeJS? Hat einige Vorteile, aber auch einige dicke Nachteile. Es gibt nun mal nicht *die* Lösung. Sonst würde es ja jeder machen.

Ich sehe bei einem Browsergame, als Webapplication gebaut, viel clientseitiger Code anfällt, der sich stark mit der Serverseite überschneidet. Der größte Vorteil mit JavaScript auf Serverseite liegt darin dass man nicht in zwei Sprachen doppelt implementieren muss.

Wenn dir NodeJS nicht gefällt, dann such dir halt was anderes aus. Du kannst sogar Java und JavaScript auf Serverseite kombinieren, zB. mit Rhino.

Das "ich würde nicht auf Java setzen" ist eine persönliche Meinung. Die darf man doch haben oder?

Original von Phoscur

Ich sehe bei einem Browsergame, als Webapplication gebaut, viel clientseitiger Code anfällt, der sich stark mit der Serverseite überschneidet. Der größte Vorteil mit JavaScript auf Serverseite liegt darin dass man nicht in zwei Sprachen doppelt implementieren muss.

Hinfällig, wenn man (beispielsweise) ein Framework wie GWT nutzt. Alles wird in Java implementiert, aber der Client erhält eine JavaScript-Applikation. Man muss nur Deploy drücken..

Wenn dir NodeJS nicht gefällt, dann such dir halt was anderes aus. Du kannst sogar Java und JavaScript auf Serverseite kombinieren, zB. mit Rhino.

Das "ich würde nicht auf Java setzen" ist eine persönliche Meinung. Die darf man doch haben oder?

Falls sich das auf mich bezog: So meinte ich das nicht. NodeJS ist toll. Es war nur ein Einwand, das man jetzt nicht glauben sollte, mit NodeJS geht alles einfacher und besser und toller und überhaupt. Man sollte zum Bleistift sich vorher erkundigen, was eigentlich NodeJS so besonders macht. Das Neue des Neuen wägen ist nicht gut. 

Beispiel? Ich kann mir spontan nicht vorstellen, dass ein hochrechenintensives oder datenbankoperationsgestütztes NodeJS-Application-Häppchen wirklich sinnvoll wird. Das ist wohl u.U. als Applikationsmodul in Java, C oder ähnlichem wesrntlich besser aufgehoben, wo man Threading hat, wo man MultiCores hat. Ein Echtzeitchat dagegen ist sicher dafür eine prima Spielwiese. => vorheriger Post.

Original von Daniel Craig

Zwar ist das mit AJAX schon besser geworden, aber leider gibt es immernoch keine Möglichkeit, dass der Server unaufgefordert Daten an den Client sendet. Gerade das ist aber bei Multiplayer-Spielen aber sehr wichtig!

 Man bekommt so etwas mit Comet (long polling http) hin. Die Anzahl komerziel einsetzbaren Server ist aber wohl noch recht überschaubar.

Original von Phoscur

NodeJS ist noch im Entwicklungsstadium, hat aber durchaus Potenzial PHP durch JavaScript abzulösen.

Chaos Radio Express hatte zum Thema letztens einen Podcast: http://chaosradio.ccc.de/cre167.html

Original von Daniel Craig

Java-Applets laufen leider nur bei Browsern mit vollwertigem Betriebssystem (Windows, Mac, Linux).

Also auf meinem Nokia ist Java drauf, ob das ganze funktioniert weiß ich aber nicht.

Original von MikeDee

Original von Daniel Craig

Java-Applets laufen leider nur bei Browsern mit vollwertigem Betriebssystem (Windows, Mac, Linux).

Also auf meinem Nokia ist Java drauf, ob das ganze funktioniert weiß ich aber nicht.

Du hast dort nur ein sog. Java ME (Mobile Edition), welcher jeder Hersteller anders implementiert hat. Das bedeutet, als Entwickler kann man theoretisch jederzeit in die Situation kommen, das eine Klasse mit einer ClassNotFoundException oder sogar MethodNotFoundException beantwortet wird, weil der Hersteller der Meinung war, das dieses Feature nicht notwendig ist => fragmentiert.

Ergo bedeutet das, das man neben einer extrem mobil ausgerichteten Anwendung (man muss für mobile Java-Geräte anders programmieren als für Desktop, bspw. Speicherverbrauch) entweder verschiedene Versionen bauen muss, etliche Fallunterscheidungen/Toleranzen implementieren muss oder nur einen kleinen gemeinsamen Nenner nutzen darf.

Da ist die fragmentierte Androidwelt besser dran.