Java als Serverseitige Alternative zu PHP (Kampfsystem einen Browsergames)

[Katzehuhn]

Hi ich bin zur Zeit mit der Entwicklung eines Browsergames beschäftigt. Jetzt bin ich kurz vorm beenden der administratorischen Oberfläche und wollte nun mein Hauptaugenmerk auf das Kampfsystem legen, was später ja einmal das Zentrum des Browsergames darstellen soll. Jetzt habe ich aber leider die Befürchtung das PHP nicht optimal geeignet für diese Aufgabe ist und bin daher, auch wegen Javas objektorientierter Struktur, am überlegen dies mittels Java zu lösen.
Dazu hätte ich ein paar Fragen

1.)Welche Möglichkeiten gibt es Java als Serverseitige Sprache zu verwenden? Muss dazu ein Tomcat installiert sein oder gibt es auch hierzu eine Alternative?
-> Das Script bräuchte ja nicht allzuviele Informationen vom Benutzer(halt ausgewählte Attacke und gegnerische Gruppe). Den Rest würde es sich aus der Datenbank hohlen, berechnen und das Kampfergebniss dann zum Browser zurückschicken.

2.)Wieviel schneller ist Java? Würdet ihr mit dazu raten? Normalerweise ist ja die Datenbank der Flaschenhals einer Webseite?

zu mir:
Ich arbeite seit ~ 2 1/2 Jahren mit PHP und hab jetzt seit einem Jahr Java in der Schule.

Danke für die Hilfe

 

[Anime-Otaku]

1. Webservice, JSP in einer html Seite (mit Erweiterung JSF vielleicht), als Servlet...also eine Java Klasse die Anfragen entgegen nimmt und ggf. zurück schickt, ohne direkt html zu benutzen zu müssen, verschiedene Frameworks...JBoss Seam, welches dir vieles vereinfachen kann, Hibernate-> Datenbankabstraktionsschicht
Und ja du brauchst einen mind. einen Tomcat oder einen vergleichbaren "Servlet-Container". Diesen kann man dann durch ein jdk_proxy Modul durch den Apache nach außen schleusen.

2. Schnelligkeit ist mit Java auf jeden Fall gegeben im Vergleich mit anderen Sprachen.
Schwer zu sagen, da der großteil ja schon in PhP programmiert wurde. Von daher ist es fragwürdig jetzt noch mit Java zu experimentieren.

 

[Katzehuhn]

... als Servlet...also eine Java Klasse die Anfragen entgegen nimmt und ggf. zurück schickt...
2. Schnelligkeit ist mit Java auf jeden Fall gegeben im Vergleich mit anderen Sprachen.
Schwer zu sagen, da der großteil ja schon in PhP programmiert wurde. Von daher ist es fragwürdig jetzt noch mit Java zu experimentieren.

Also ein Servlet wäre denk ich hier genau das Richtige, wobei
Der Hauptgrund, für mich, beim Kampfsystem auf Java umzusteigen wäre ein erhofter Geschwindigkeitsvorteil da das Kampfsystem wohl das meist benütze Script wäre. Die Daten müsste sich Java jedoch auch jedesmal aus der Mysql Datenbank hohlen.

Kann niemand einschätzen ob sich das Geschwindigkeitsmässig auszahlt?^^
Laut der Seite: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=php&lang2=java14
ist Java um einiges schneller.

 

[KoMtuR]

Naja ich wäre da ein wenig skeptisch, ob du wirklich so eine Geschwindigkeit raus holst. Du müsstest alles umstrukturieren und eine andere Denkweise im Gegensatz zu php haben.

Php-Seite -> Aufruf -> Ende -> Skript beendet

Java kann dahingehend weiterlaufen und da kommt nun der Vorteil. Ich würde dir raten einen eigenen kleinen Server zu bauen und dann mit php auf den entsprechenden Ports die Sachen zu holen. Gibt glaub ich auch schon eine Erweiterung für php, wo du Java benutzen kannst in einem php-Skript.
Gegen einen Webservice, Servlet, etc. spricht einfach, dass du dann noch viel Mist mit laufen hast (kommt ja immer drauf an, was du bewerkstelligen willst), den du aber nicht brauchst.

Ich würde, wenn dein Kampfscript komplex werden sollte, alles in der Java-Anwendung cachen und nur bei Aktualisierungen die Ergebnisse im neuen Thread zurück an die DB schicken. Wenn du aber nur Rechnungen durchführen willst, die eigentlich recht "simple" Mathematik sind, dann kannst du auch bei php bleiben und vielleicht persistente Datenbankverbindungen zu nehmen. Der Flaschenhals bleibt meiner Meinung nach immernoch bestehen - egal welche Sprache.

PS.: Ich würde die raten vielleicht Python zu nehmen. Genauso objektorientert. Dabei aber leicht zu lernen und wenns nötig ist kannst du es auch noch kompilieren. Extra für nur ein Skript würd ich nicht den Batzen Java laden

 

[Katzehuhn]

Was mir gerde eingefallen ist, würde es nicht gehn das ich mir zuerst einmal alle Einheiten aus der Tabelle hohle und diese dann instanziere? Dann könnte ich die Datenbank abfragen minimieren und der Spieler würde immer auf die Einheiten im Cache zurückgreifen, das meintest du vermudlich auch
Ich werd denk ich sowieso das ganze Frontend in Java lösen, mein
Problem ist nur das ich nicht genau verstehe wie sich der Tomcat verhalten würde. Blieben die Einheiten überhaupt im Speicher? Könnten mehre Spieler gleichzeitig darauf zu greifen? Und verkraftet das der Tomcat//Java das überhaupt wenn ich im Ram 500mb Einheiten hätte?^^ Fragen über Fragen

 

[KoMtuR]

Wenn du die Einheiten in einer statischen Klasse hälst, sozusagen ne Helperklasse baust, die die Dinger dann instanziert, bleiben die auch im Speicher.

Meiner Meinung nach ists Java egal, ob da 500MB Daten sind oder nur 10MB. Es wird sicherlich drauf hinaus laufen, dass du ein Rechner brauchst, der da auch genug RAM hat. Aber 500MB Daten, nur für Einheiten? Wieviel Einheiten hast du denn, dass diese 500MB belegen würden. Wenn du schon 500 Einheiten hättest (was ja schon enorm viel ist), dann wären das pro Einheit 1MB, was doch ein wenig viel ist.
Willst du denn die Bilder auch in Speicher halten?

 

[Katzehuhn]

Ok 500 MB sind einwenig hoch gegriffen, muss ich aber auch mal schaun wieviel Ram Java für ein Einheiten Instanz verwenden. In der Datenbank hat eine Einheit eine größe von 132 Byte, wenn Java da nicht viel größer ist gingen sich sogar einige 100k aus ohne übermässig viel Speicher zu verbrauchen, werd mich ma später einwenig mim Tomcat rumspielen, ma guggn ob ich da was hinkrieg.
servus