hallo,
sinn dieses threads ist es, festzustellen ob sich unser konzept umsetzen lässt oder nicht. für uns macht es keinen augenscheinlichen sinn, ein derartig umfangreiches projekt wie ein browsergame in einer scriptsprache wie php zu entwickeln. die objektorientierung ist - php5 hin oder her - mehr als mangelhaft und es fehlt an entwicklungswerkzeugen und designpatterns.
dennoch konnten wir keinerlei informationen über ein in java realisiertes browsergame finden. was sind die gründe hierfür?
da unser konzept keine datenbank vorsieht wird am ehesten der speicherbedarf eine rolle spielen. java darf auf keinen fall daten swappen müssen, das kann es einfach nicht gescheit
von der execute-performance her sollte eine enterprise lösung doch wohl bedeutend schneller sein als php, allein schon weil nicht permanent neue prozesse gestartet werden müssen und es sich um komplilierten code handelt.
es würde uns sehr helfen, wenn wir von einem gut besuchten System (min 2.000 aktive User) Performance werte erhalten würden, insbesondere speicherbedarf und prozessorauslastung.
vielen dank
edit: leider funktioniert die suche dieses forums nicht, wenn es schon so einen thread gibt tut es mir leid
Php vs java servlets /j2ee
gepostet vor 18 Jahre, 11 Monate von mow
gepostet vor 18 Jahre, 11 Monate von Crafty-Catcher
Original von mow
dennoch konnten wir keinerlei informationen über ein in java realisiertes browsergame finden. was sind die gründe hierfür?
edit: leider funktioniert die suche dieses forums nicht, wenn es schon so einen thread gibt tut es mir leid
Die tut bei mir sehr wohl und ja es wurde auch schon über BGs mit Backends in C++ oder Java gesprochen.
gepostet vor 18 Jahre, 11 Monate von TheUndeadable
Ein Grund liegt daran, dass die BG-Programmierszene hauptsächlich aus jungen Programmierern besteht, die mit einem BG ordentliche Programmierung gelernt haben.
PHP ist die erste wirklich gute Skript-Sprache für Web-Anwendungen, die schnell erlernt ist. Man hat selten Lust sich in die Konzepte von OOP, Java oder ASP.Net einzuarbeiten, wenn man ein Ergebnis sehen möchte.
Mir persönlich würde ein BG auf der Basis von ASP.Net oder J"EE mehr zusagen.
PHP ist die erste wirklich gute Skript-Sprache für Web-Anwendungen, die schnell erlernt ist. Man hat selten Lust sich in die Konzepte von OOP, Java oder ASP.Net einzuarbeiten, wenn man ein Ergebnis sehen möchte.
Mir persönlich würde ein BG auf der Basis von ASP.Net oder J"EE mehr zusagen.
gepostet vor 18 Jahre, 11 Monate von Chojin
Tolle frage...
super antwort...
mow, erzähl etwas darüber was du umsetzen willst und die leute hier werden dir sagen ob es möglich ist und womit am besten.
Wenn du die Frage stells, ob euer Projekt umsetzbar ist und dir das nicht selber beantworten kannst, dann musst du wohl etwas genauer werden.
Kann ich nicht nachvollziehen, für hunderte anderer Browsergames klappt das bestens.
Browsergames sind ganz spezielle webanwendungen. Wenn du von anderen umfeldern bessere entwicklungswerkzeuge gewohnt bist, dann solltest du besser die finger vom programmieren im web lassen.
(werkzeuge die ich benutze: PHPDesigner2005, DBDesigner etc.)
Aha. Ich weiß ja nicht von welchen "enterprice lösungen" du sprichst aber ich würde sagen du liegst daneben.
Prekompilierung von PHP code ist im BG umfeld absolut keine Seltenheit.
Was soll den das Vergleichsystem machen? Ohne zu wissen was der Server machen soll kann ich dir da keinen Vergleich raussuchen.
Ich denke allerdings nicht, dass ein spiel erfolgreich sein kann, wenn man sich schon vor beginn der arbeit mehr sorgen um die serverperformance als über das spielkonzept macht.
Reg4rds
chojin
super antwort...
mow, erzähl etwas darüber was du umsetzen willst und die leute hier werden dir sagen ob es möglich ist und womit am besten.
Wenn du die Frage stells, ob euer Projekt umsetzbar ist und dir das nicht selber beantworten kannst, dann musst du wohl etwas genauer werden.
für uns macht es keinen augenscheinlichen sinn, ein derartig umfangreiches projekt wie ein browsergame in einer scriptsprache wie php zu entwickeln.
Kann ich nicht nachvollziehen, für hunderte anderer Browsergames klappt das bestens.
es fehlt an entwicklungswerkzeugen und designpatterns.
Browsergames sind ganz spezielle webanwendungen. Wenn du von anderen umfeldern bessere entwicklungswerkzeuge gewohnt bist, dann solltest du besser die finger vom programmieren im web lassen.
(werkzeuge die ich benutze: PHPDesigner2005, DBDesigner etc.)
von der execute-performance her sollte eine enterprise lösung doch wohl bedeutend schneller sein als php, allein schon weil nicht permanent neue prozesse gestartet werden müssen und es sich um komplilierten code handelt.
Aha. Ich weiß ja nicht von welchen "enterprice lösungen" du sprichst aber ich würde sagen du liegst daneben.
Prekompilierung von PHP code ist im BG umfeld absolut keine Seltenheit.
es würde uns sehr helfen, wenn wir von einem gut besuchten System (min 2.000 aktive User) Performance werte erhalten würden, insbesondere speicherbedarf und prozessorauslastung.
Was soll den das Vergleichsystem machen? Ohne zu wissen was der Server machen soll kann ich dir da keinen Vergleich raussuchen.
Ich denke allerdings nicht, dass ein spiel erfolgreich sein kann, wenn man sich schon vor beginn der arbeit mehr sorgen um die serverperformance als über das spielkonzept macht.
Reg4rds
chojin
gepostet vor 18 Jahre, 11 Monate von mow
Original von Crafty-Catcher
Die tut bei mir sehr wohl und ja es wurde auch schon über BGs mit Backends in C++ oder Java gesprochen.
entschuldigung,sie tut es. ich hatte das suchen-formular oben benutzt, dort kommt 404-not found.
die threads bezüglich der backends waren leider nicht so informativ. für die oben angefragten speicher/prozessor werte wären wir sehr dankbar.
.NET kommt aus mehreren gründen für webbasierte dienste bei uns nicht in frage.
mow, erzähl etwas darüber was du umsetzen willst und die leute hier werden dir sagen ob es möglich ist und womit am besten.
Wenn du die Frage stells, ob euer Projekt umsetzbar ist und dir das nicht selber beantworten kannst, dann musst du wohl etwas genauer werden.
siehe ganz unten
Kann ich nicht nachvollziehen, für hunderte anderer Browsergames klappt das bestens.
vermutlich wird unser konzept sehr viel mehr rechenzeit erfordern als "normal". siehe unten
Aha. Ich weiß ja nicht von welchen "enterprice lösungen" du sprichst aber ich würde sagen du liegst daneben.
Prekompilierung von PHP code ist im BG umfeld absolut keine Seltenheit.
Gut, werden wir testen.
Ich denke allerdings nicht, dass ein spiel erfolgreich sein kann, wenn man sich schon vor beginn der arbeit mehr sorgen um die serverperformance als über das spielkonzept macht.
Nun, es macht keinen sinn ein geniales Spielkonzept zu haben ohne zu wissen ob es mit den verfügbaren Resourcen umsetzbar ist.
Das ganze soll weg vom klassischen BG in richtung Realtime Taktik
Daraus resultieren viele Pageimpressions insbeondere auf die Schlachtfeld -Seite
Eckpunkte /key-features die wir auf jeden fall wollen:
-die ganzen standardgeshichten, forschen,bauen,flotten
-intaktives schlachtfeld aus 2048*2048 kacheln
-schnelles gameplay, kurze runden(1 monat?), all-time-stats
-schwerpunkt auf taktischer anordnung und zusammensetzung von flotten
-rohstoff gewinnung durch externe sammler, welche geschützt und zerstört werden müssen (schlüssel zum erfolg in viele RTS)
-individuell zusammenbaubare schiffe aus rumpf,geschützen,antrieb,specials etc
[abschweif]
2048*2048 Kartenfeld Objekte mit jeweils x bytes Daten macht insgesamt
4*x MB allein für die Speicherung der Welt, realistisch für x in byte
2+2 position
6*4 rohstoffe
pointer(4byte):
liste gegenstände
liste aktive spieler für ereignisverwaltung/benachrichtigung
Basis oder null
=~50 byte
=>200mb für karte, das lässt genügend spielräume
[/abschweif]
so erstmal feierabend. schönes wochenende
gepostet vor 18 Jahre, 11 Monate von None
Mein Gott ist es denn nicht möglich eine ernstgemeinte Frage ohne irgendeinen besserwisserischen Unterton oder Sarkasmus zu beantworten?
Manchmal kommts mir echt so vor als wär ich im Kindergarten. Entweder normal antworten oder schreibts ins heise Forum, da finden sich für sowas immer Leser...
Doch zurück zum Thema:
die Vorteile von Java, C++ & .NET sind nicht von der Hand zu weisen. Bei einem BG stoße ich an die Grenzen von PHP.
Grund ist nichtmal so sehr die Performence sondern das "Wischi-Waschi" OOP, die abartige Typlosigkeit (wenn mans so nennen will) und das Datenbankhandling, und und und
Der Grund das es (allgemein) so wenige JSP & Beans im Web gibt, liegt sicher an der Arbeit die man damit hat. Es lohnt sich Logik, Design und Datenbankhandling strikt getrennt zu haben, keine Frage. Aber wie schon gesagt bis man etwas sieht dauert es eine ganze Weile.
Dazu kommt noch das man tieferes Verständnis der Materie braucht als bei PHP. Das Programm muss tiefer durchdacht sein, man bennötigt wirkliche Projektplanung. Ein weiterer Contrapunkt ist die Literatur. Sie ist doch sehr begrenzt. Zumindest bei JSP's und Beans. Ohne gutes Englisch kommt man bei java.sun.com und in der Literatur dazu nicht weit.
Das sind so meine Erfahrungen die ich mit Java im Zusammenhang mit BG's gemacht habe...
Manchmal kommts mir echt so vor als wär ich im Kindergarten. Entweder normal antworten oder schreibts ins heise Forum, da finden sich für sowas immer Leser...
Doch zurück zum Thema:
die Vorteile von Java, C++ & .NET sind nicht von der Hand zu weisen. Bei einem BG stoße ich an die Grenzen von PHP.
Grund ist nichtmal so sehr die Performence sondern das "Wischi-Waschi" OOP, die abartige Typlosigkeit (wenn mans so nennen will) und das Datenbankhandling, und und und
Der Grund das es (allgemein) so wenige JSP & Beans im Web gibt, liegt sicher an der Arbeit die man damit hat. Es lohnt sich Logik, Design und Datenbankhandling strikt getrennt zu haben, keine Frage. Aber wie schon gesagt bis man etwas sieht dauert es eine ganze Weile.
Dazu kommt noch das man tieferes Verständnis der Materie braucht als bei PHP. Das Programm muss tiefer durchdacht sein, man bennötigt wirkliche Projektplanung. Ein weiterer Contrapunkt ist die Literatur. Sie ist doch sehr begrenzt. Zumindest bei JSP's und Beans. Ohne gutes Englisch kommt man bei java.sun.com und in der Literatur dazu nicht weit.
Das sind so meine Erfahrungen die ich mit Java im Zusammenhang mit BG's gemacht habe...
gepostet vor 18 Jahre, 11 Monate von runemaster
Yahoo hat ihr Portal vor langer Zeit auf PHP4 umgestellt.
Sie hatten eine Performance Analyse gemacht und Java wäre da um einiges schneller gewesen, allerdings meinten sie die Community von PHP sei viel besser und das war letzten Ende das Ausschlaggebende.
Mit PHP hat man sehr schnell Erfolge. Wobei es im Fall von Object-Orientierter Programmierung etwas langsam ist.
Da viele ihre BGs in PHP realisieren kann man leichter Hilfe bekommen, wenn man ein Problem hat, aber es gibt auch diverse BGs, die in Java realisiert sind.
Schau dir einfach große Foren an. Die Systeme dafür sind in PHP umgesetzt und bei einigen sind mehere 1000 Leute gleichzeitig online, ohne irgend welche Probleme.
Sie hatten eine Performance Analyse gemacht und Java wäre da um einiges schneller gewesen, allerdings meinten sie die Community von PHP sei viel besser und das war letzten Ende das Ausschlaggebende.
Mit PHP hat man sehr schnell Erfolge. Wobei es im Fall von Object-Orientierter Programmierung etwas langsam ist.
Da viele ihre BGs in PHP realisieren kann man leichter Hilfe bekommen, wenn man ein Problem hat, aber es gibt auch diverse BGs, die in Java realisiert sind.
Schau dir einfach große Foren an. Die Systeme dafür sind in PHP umgesetzt und bei einigen sind mehere 1000 Leute gleichzeitig online, ohne irgend welche Probleme.
gepostet vor 18 Jahre, 11 Monate von Teonas
In diesem Thread haben wir ein anderes Thema diskutiert, sind aber am Ende auch auf den Vergleich PHP/JSP aus Performance-Sicht geschwenkt.
Die Diskussion PHP-anderes nimmt manchmal pseudo-religiöse Züge an, weshalb ich da auch einen wissenschaftlichen Performance-Vergleich gepostet habe. Ich denke die Sachlage gestaltet sich beim etwas nüchterneren PHP-JSP-Vergleich so:
Viele Leute haben irgendwann mal angefangen, als JSP noch indiskutabel, weil zu unausgereift und wenig verbreitet war. Zudem ist es auch heute noch schwer, billigere Angebote für Webspace mit einer Servlet-Engine zu bekommen.
Deshalb nimmt man logischerweise PHP, weil es quasi bei jedem Mini-Hoster zu bekommen ist (und das billig - auch das kann zunächst wichtig sein). Die Programmiererfahrung spielt wohl oft auch eine Rolle, die ist wohl oft geringer vorhanden als der Enthusiasmus. Da machts PHP auch einfacher, weil es überall im Netz die "für Dummies"-Anweisungen gibt - und einer späteren Programmiertechnischen Entwicklung wird auch Raum geboten.
In Bezug auf Spracheffizienz und sauberer Codegenerierung ist Java/JSP IMO PHP immer noch überlegen, Gründe wurden genannt.
Zum Thema Performance ist dieses Paper noch zu empfehlen. Die etwas aussagekräftigere und optisch schönere finale Version ist leider bei der ACM und deshalb für Nichtmitglieder nicht zu bekommen.
Den Einwand mit der mangelden Literatur kann ich nicht wirklich verstehen, JSP-Bücher gibts inzwischen auch in großen öffentlichen Bibliotheken, für bessere Aktualität ist natürlich wie immer die Englischsprachige Version anzuraten.
Die Diskussion PHP-anderes nimmt manchmal pseudo-religiöse Züge an, weshalb ich da auch einen wissenschaftlichen Performance-Vergleich gepostet habe. Ich denke die Sachlage gestaltet sich beim etwas nüchterneren PHP-JSP-Vergleich so:
Viele Leute haben irgendwann mal angefangen, als JSP noch indiskutabel, weil zu unausgereift und wenig verbreitet war. Zudem ist es auch heute noch schwer, billigere Angebote für Webspace mit einer Servlet-Engine zu bekommen.
Deshalb nimmt man logischerweise PHP, weil es quasi bei jedem Mini-Hoster zu bekommen ist (und das billig - auch das kann zunächst wichtig sein). Die Programmiererfahrung spielt wohl oft auch eine Rolle, die ist wohl oft geringer vorhanden als der Enthusiasmus. Da machts PHP auch einfacher, weil es überall im Netz die "für Dummies"-Anweisungen gibt - und einer späteren Programmiertechnischen Entwicklung wird auch Raum geboten.
In Bezug auf Spracheffizienz und sauberer Codegenerierung ist Java/JSP IMO PHP immer noch überlegen, Gründe wurden genannt.
Zum Thema Performance ist dieses Paper noch zu empfehlen. Die etwas aussagekräftigere und optisch schönere finale Version ist leider bei der ACM und deshalb für Nichtmitglieder nicht zu bekommen.
Den Einwand mit der mangelden Literatur kann ich nicht wirklich verstehen, JSP-Bücher gibts inzwischen auch in großen öffentlichen Bibliotheken, für bessere Aktualität ist natürlich wie immer die Englischsprachige Version anzuraten.
gepostet vor 18 Jahre, 11 Monate von Kampfhoernchen
Das mit der Literatur kann ich auch nicht bestätigen.
Und die, bei denen der Enthusiasmus größer ist als die Programmiererfahrung, werden auch mit PHP kein vernünftiges Spiel hinbekommen.
PHP mag zwar für kleine Sachen (Gästebücher ect.) leichter sein, aber wenn man es wirklich professionell einsetzen will, sind auch hier fundierte Grundkenntnisse wie iin jeder anderen Programmiersprache auch notwendig.
Da braucht man noch ein gewisses Maß an Selbstbeherrschung, dass man wirklich objektorientiert arbeitet. Dann funzt das schon.
die abartige Typlosigkeit (wenn mans so nennen will) und das Datenbankhandling, und und und
Die Typlosigkeit hat sowohl Vor-, als auch Nachteile, die beide ungefähr gleich stark aufwiegen. Für mich persönlich (subjektive Meinung) ist sie jedenfalls nicht hinderlich, wenn man ordentlich codet.
Und PHP hat grade wegen bei guten Datenbankanbindung seine Vorteile, was es daran zu meckern gibt, weiß ich wirklich nicht.
Das verlinkte Papier ist sehr umfangreich, was mir dabei aber fehlt, ist der Quelltext. Ich kann ein "Hallo Welt" mit 1 Zeile Code erzeugen oder mit 300 LoC. Am Ende kommt das gleiche raus, aber ist deshalb die Rechenzeit gleich?
Bei einem Test von mir sahs nämlich ein wenig anders aus, und ich habe praktisch überall den fast gleichen Code eingesetzt.
Und die, bei denen der Enthusiasmus größer ist als die Programmiererfahrung, werden auch mit PHP kein vernünftiges Spiel hinbekommen.
PHP mag zwar für kleine Sachen (Gästebücher ect.) leichter sein, aber wenn man es wirklich professionell einsetzen will, sind auch hier fundierte Grundkenntnisse wie iin jeder anderen Programmiersprache auch notwendig.
"Wischi-Waschi" OOP
Da braucht man noch ein gewisses Maß an Selbstbeherrschung, dass man wirklich objektorientiert arbeitet. Dann funzt das schon.
die abartige Typlosigkeit (wenn mans so nennen will) und das Datenbankhandling, und und und
Die Typlosigkeit hat sowohl Vor-, als auch Nachteile, die beide ungefähr gleich stark aufwiegen. Für mich persönlich (subjektive Meinung) ist sie jedenfalls nicht hinderlich, wenn man ordentlich codet.
Und PHP hat grade wegen bei guten Datenbankanbindung seine Vorteile, was es daran zu meckern gibt, weiß ich wirklich nicht.
Das verlinkte Papier ist sehr umfangreich, was mir dabei aber fehlt, ist der Quelltext. Ich kann ein "Hallo Welt" mit 1 Zeile Code erzeugen oder mit 300 LoC. Am Ende kommt das gleiche raus, aber ist deshalb die Rechenzeit gleich?
Bei einem Test von mir sahs nämlich ein wenig anders aus, und ich habe praktisch überall den fast gleichen Code eingesetzt.
gepostet vor 18 Jahre, 11 Monate von TheUndeadable
Gerade das Datenbankhandling soll in einer der nächsten Versionen von PHP ordentlich abstrahiert werden.
Das heißt, man arbeitet nicht mehr mit mysql_connect und mssql_connect und postgres_connect etc, sondern man hat einen einheitlichen Connector, der für alle Datenbanktypen ein Interface zurückgibt, mit dem man dann arbeiten kann. Ähnlich wie ODBC, ADO oder JDBC(?).
Auch die Sache, dass PHP auf nahezu jedem Hoster verfügbar ist (wie schon erwähnt wurde), hat die Verbreitung dieser Sprache natürlich gefördert. Für mich persönlich gibt es allerdings keine Gründe auf PHP zu setzen, wenn man auch Java oder .Net zur Verfügung hat. Allerdings muss ich zugeben, dass die Programmierung von PHP eine gewisse Leichtigkeit hat und man evtl schneller am Ziel ist, als mit JSP.
Ein großer Grund ist auch die Community. Es sprechen viel mehr Jugendliche PHP als JAVA und diese haben viel Zeit sich gegenseitig zu helfen. Wenn man eine Frage zu Java hat, muss man sehr schnell auf andere Foren umsteigen, bei denen Anfängerfragen leider sehr schnell nieder gemacht werden. Dies geschieht hier teilweise auch bei PHP-Fragen, aber bis jetzt kam man immer zu einem Ergebnis.
Das heißt, man arbeitet nicht mehr mit mysql_connect und mssql_connect und postgres_connect etc, sondern man hat einen einheitlichen Connector, der für alle Datenbanktypen ein Interface zurückgibt, mit dem man dann arbeiten kann. Ähnlich wie ODBC, ADO oder JDBC(?).
Auch die Sache, dass PHP auf nahezu jedem Hoster verfügbar ist (wie schon erwähnt wurde), hat die Verbreitung dieser Sprache natürlich gefördert. Für mich persönlich gibt es allerdings keine Gründe auf PHP zu setzen, wenn man auch Java oder .Net zur Verfügung hat. Allerdings muss ich zugeben, dass die Programmierung von PHP eine gewisse Leichtigkeit hat und man evtl schneller am Ziel ist, als mit JSP.
Ein großer Grund ist auch die Community. Es sprechen viel mehr Jugendliche PHP als JAVA und diese haben viel Zeit sich gegenseitig zu helfen. Wenn man eine Frage zu Java hat, muss man sehr schnell auf andere Foren umsteigen, bei denen Anfängerfragen leider sehr schnell nieder gemacht werden. Dies geschieht hier teilweise auch bei PHP-Fragen, aber bis jetzt kam man immer zu einem Ergebnis.
gepostet vor 18 Jahre, 11 Monate von mow
guten morgen,
nur damit keine verwechselungen auftreten: jsp's (java server pages) sind grundverschieden von servlets.
jsp' sind von ihrem verhalten her mit php zu vergleichen, das heisst wenn ein request an den webserver kommt läd er das entsprechende jsp und wertet es aus.
servlets sind prozesse die permanent laufen und miteinander komunizieren können. bei einem request führt der server nur eine methode des passenden prozesses aus ("doGet(..),doPost(..)").
daraus ergeben sich viele möglichkeiten, die gerade auch für browsergames sehr interresant sind. zum beispiel kann durch statische objekte, die für alle servlets identisch sind, komplett auf eine datenbank verzichtet werden.
derzeit wird getestet, ob dies tatsächlich schneller ist denn durch den verzicht auf eine persistente datenbank wird eine backupfunktion nötig die alle unabhängigen objekte regelmässig absichert. das ist vermutlich sehr teuer.
wenn dieser test positiv verläuft wird es auf j2ee hinauslaufen, speicher ist jedenfalls kein problem.
themenwechsel:
wie aktzeptiert sind applets in der szene? wie bereits beschrieben soll das gameplay zügig sein. bei der vergabe von kampfanweisungen ("greife jäger an","schütze schiff x"..) oder marschbefehlen ist eine statische htmlkarte vermutllich nicht geeignet bzw diese müsste dauernd neu geladen werden.
nur damit keine verwechselungen auftreten: jsp's (java server pages) sind grundverschieden von servlets.
jsp' sind von ihrem verhalten her mit php zu vergleichen, das heisst wenn ein request an den webserver kommt läd er das entsprechende jsp und wertet es aus.
servlets sind prozesse die permanent laufen und miteinander komunizieren können. bei einem request führt der server nur eine methode des passenden prozesses aus ("doGet(..),doPost(..)").
daraus ergeben sich viele möglichkeiten, die gerade auch für browsergames sehr interresant sind. zum beispiel kann durch statische objekte, die für alle servlets identisch sind, komplett auf eine datenbank verzichtet werden.
derzeit wird getestet, ob dies tatsächlich schneller ist denn durch den verzicht auf eine persistente datenbank wird eine backupfunktion nötig die alle unabhängigen objekte regelmässig absichert. das ist vermutlich sehr teuer.
wenn dieser test positiv verläuft wird es auf j2ee hinauslaufen, speicher ist jedenfalls kein problem.
themenwechsel:
wie aktzeptiert sind applets in der szene? wie bereits beschrieben soll das gameplay zügig sein. bei der vergabe von kampfanweisungen ("greife jäger an","schütze schiff x"..) oder marschbefehlen ist eine statische htmlkarte vermutllich nicht geeignet bzw diese müsste dauernd neu geladen werden.
gepostet vor 18 Jahre, 11 Monate von TheUndeadable
Ich persönlich würde sagen, dass Applets relativ unbeliebt sind. Dann würde ich eher auf Flash setzen. Nur ist Flash dermaßen beknackt zu programmieren, dass ich mich von diesem auch getrennt habe.
Es gibt auch den Ansatz, den einige hier im Forum vertreten, dass das Web nur aus CSS und HTML bestehen darf. Dem schließe ich mich nicht an.
Folgende Probleme sehe ich bei der Verwendung von Applets:
- Runtime muss installiert sein (wesentlich größer als Flash)
- Die richtige Java-Version muss getroffen sein (bei vernünftiger Programmierung sollte ein Java-Applet auf allen Versionen laufen)
- Lange Ladezeit und zumindest ich bekomm regelmäßig Probleme mit Java-Applets, dass diese nicht laufen oder irgendein Klassenpaket nicht gefunden wurde.
- Langsame Ausführung. Dies hat sich aber mit den neuen Rechnern und neuen Java-Versionen gelegt.
Mit DHTML kann man nahezu alles erreichen, was man auch mit Java erreichen kann:
Beispiel:
http://193.151.73.87/games/lemmings/
Es gibt auch den Ansatz, den einige hier im Forum vertreten, dass das Web nur aus CSS und HTML bestehen darf. Dem schließe ich mich nicht an.
Folgende Probleme sehe ich bei der Verwendung von Applets:
- Runtime muss installiert sein (wesentlich größer als Flash)
- Die richtige Java-Version muss getroffen sein (bei vernünftiger Programmierung sollte ein Java-Applet auf allen Versionen laufen)
- Lange Ladezeit und zumindest ich bekomm regelmäßig Probleme mit Java-Applets, dass diese nicht laufen oder irgendein Klassenpaket nicht gefunden wurde.
- Langsame Ausführung. Dies hat sich aber mit den neuen Rechnern und neuen Java-Versionen gelegt.
Mit DHTML kann man nahezu alles erreichen, was man auch mit Java erreichen kann:
Beispiel:
http://193.151.73.87/games/lemmings/
gepostet vor 18 Jahre, 11 Monate von mow
das problem ist weniger die anzeige als vielmehr die komunikation. die seite müsste ja zur laufzeit neue informationen vom server erhalten und auswerten.
gepostet vor 18 Jahre, 11 Monate von TheUndeadable
gepostet vor 18 Jahre, 11 Monate von Chojin
ja, theoretisch kannst du einen regulären updatemechanixmuss mit AJAX umsetzen (XmlHttpRequest + JavaScript + XHtml/Xml). Aber auch damit ist kein "Push" von ereignissen zum spieler möglich. du müsstest dann alle 2 sekunden eine verbindung aufbauen und vom server veränderrungen die seit dem letzten refresh checkpoint eingetretten sind erfragen und per Javascript darstellen (wichtig: nutzung von timestamps). Wenn du die refreshzeiten länger machst, 10sec - 2min kommt man auf eine quasi "runden-zeit-basierte" umsetzung.
Ich bin momentan selbst am umsetzen von dem konzept.
Bei fragen steh ich zu verfügung.
reg4rds
chojin
Ich bin momentan selbst am umsetzen von dem konzept.
Bei fragen steh ich zu verfügung.
reg4rds
chojin
gepostet vor 18 Jahre, 11 Monate von Teonas
Original von mow
nur damit keine verwechselungen auftreten: jsp's (java server pages) sind grundverschieden von servlets.
jsp' sind von ihrem verhalten her mit php zu vergleichen, das heisst wenn ein request an den webserver kommt läd er das entsprechende jsp und wertet es aus.
servlets sind prozesse die permanent laufen und miteinander komunizieren können. bei einem request führt der server nur eine methode des passenden prozesses aus ("doGet(..),doPost(..)").
Bevor das jetzt jemand noch so übernimmt: Falsch. Ich will das jetzt nicht ausgiebig mit Zitaten belegen (ich empfehle für den Einstieg Wikipedia und java.sun.com), aber dennoch die Aussage mal richtig stellen:
Beide Technologien führen zu Java-Klassen, die das HTTPServlet-Interface implementieren (beim Servlet ist das intuitiv, die JSPs werden dazu von einem JSP-Container compiliert). Das heißt, sie können per GET und POST angesprochen werden - und per se erst mal mit nichts anderem ("miteinander kommunizieren" - was soll das sein, wenn der Server nichts zu tun hat, treffen sich die Servlets beim Kaffee und halten ein Schwätzchen...?).
Sobald eine JSP zum ersten Mal angesprochen wird, wird sie Compiler umgewandelt, meist sogar schon vorcompiliert, geladen und dann nur noch als Klasse im Speicher behandelt. Das macht Technologien wie eAccelerator o.ä. bei JSPs überflüssig. Für Belege schaue man standardmäßig mal in /work/standalone/localhost. IDEs legen die Dateien meist irgendwo im Projektpfad ab (z.B. Netbeans: build/generated/classes/org/apache/jsp).
Weitere Zweifler können die Klassen dann mal decompilieren (sieht wie ein langweiliges Servlet aus, lauter system.out's mit HTML-Zeilen - der Grund, warum man JSP zur Erleichterung der Servlet-Programmierung verwendet...) - alternativ kann auch ein Blick in die Fachliteratur (z.B. bei O'Reilley) helfen - und so wie ich das Post interpretieren muss, tut das entweder not oder ihr habt die Einleitungskapitel übersprungen - wenigstens mal durchblättern ;-)
gepostet vor 18 Jahre, 11 Monate von mow
Original von Teonas
Falsch.
zumindest unglücklich ausgedrückt das gebe ich zu. ich bin kein entwickler.
Original von Teonas
("miteinander kommunizieren" - was soll das sein, wenn der Server nichts zu tun hat, treffen sich die Servlets beim Kaffee und halten ein Schwätzchen...?).
servlet a merkt das sich etwas geändert hat das auch servlet b,c interesseriert und teilt es ihnen mit.
wir werden aber wohl eher einen mvc ansatz wählen wo alle servlets auf ein einheitliches modell zugreifen.
Original von Teonas
lauter system.out's mit HTML-Zeilen -
ausgaben mit system.out werden maximal in der logdatei erscheinen - zumindest bei servlets.
Original von Teonas
alternativ kann auch ein Blick in die Fachliteratur (z.B. bei O'Reilley) helfen - und so wie ich das Post interpretieren muss, tut das entweder not oder ihr habt die Einleitungskapitel übersprungen - wenigstens mal durchblättern ;-)
um die ausbildung unserer entwickler brauchst du dir keine gedanken zu machen.
die httpanfragen sehen interessant aus, ich denke damit wird es gehen, push ist nicht erforderlich, die informationen sind klein genug um sie permanent zu übertragen
gepostet vor 18 Jahre, 11 Monate von Teonas
Original von mow
Original von Teonas
lauter system.out's mit HTML-Zeilen -
ausgaben mit system.out werden maximal in der logdatei erscheinen - zumindest bei servlets.
Sorry, sind io.Printwriter, die "out" benannt werden, keine system.out's - das kommt davon, wenn man vor der Mittagspause noch schnell ein Post zuende schreiben will ;-)