Flash oder Java

Hallo liebe Spielentwickler,
ich habe gesehen, dass z.B. Bigpoint jetzt vermehrt auf Java zurückgreift, aber wie ich die Java-Spiele z.B. Powerwar und ActionLiga beobachten kann, sind dort immer sehr wenige Online und viele haben technische Probleme damit, wie ich z.B. konnte noch kein Spiel von beiden spielen
Artikelauszug "Bigpoint" auf spieletipps.de,

Ein weiterer Erfolgsgarant ist die optische Überlegenheit. Wie uns Projekt-Manager Christian Godorr versicherte, sei auf Flash-Basis kaum noch mehr möglich, diese Technologie ist inzwischen ziemlich ausgereizt. Neue Möglichkeiten gäbe es mittels der Java-Technik, mit der selbst aufwändigere 3D-Grafiken möglich sind. Hier probiert man gerade sehr viel aus bei Bigpoint, die neue Action-Liga nutzt bereits diese Java-Technik. Das Ergebnis ist überzeugend, die Hockey-Version erinnert an eine nicht mehr ganz aktuelle und vom Gameplay her abgespeckte Version eines NHL Hockey und das mit nur 3,5 MB Dateigröße - erstaunlich.

Da ich auch stark daran interessiert bin, ein eigenen erfolgreiches Brwosergame (Unternehmen) aufzubauen, würde mich Eure Meinung interessieren, ob Java oder Flash (oder vielleicht was ganz anderes?) die Zukunft ist?
Ich mache keine Umfrage, weil ich nicht will dass Leute einfach auf dem Bauch heraus antworten sondern ich wünsche mir fach- und technische Kommentare und Kenntnisse.
Natürlich auch User die schon Probleme/Vorzüge kennen gelernt haben, aber ich will speziell mit einem unternehmerischen Blick auf die Sache schauen.
Ich freu mich auf Kommentare, Tipps und Tricks.

Wen die Mediadaten von Bigpoint interessieren, ich hab das grad' gefunden.
www.adlink.de/localImages/mediadaten/Mediadaten_AdLINK_20061.pdf
Ist das nicht krass wie teuer das ist?

Ich bin in der Technik nicht so versiert, dass ich hier fachlich über Flash und Java reden könnte, aber ich habe zwei Links.
Sherwood Dungeon
Three Rings
Ersteres ist ein extrem zugängliches 3D-MMORPG das Shockwave verwendet, im Browser spielbar ist und sich über Werbung finanziert, zweiteres ein erfolgreiches Indie-Studio das sich auf MMO-Entwicklung mit Java spezialisiert hat.

Ich möchte in dieser Diskussion noch einen weiteren Punkt anmerken, der in Bezug auf die Fragestellung ob Flash oder Java vielleicht auch nicht ganz unwichtig ist:
Ist manchmal weniger nicht mehr?
Das sollte auch diskutiert werden finde ich...
Gruß,
Marc

Original von Bergtroll
Da ich auch stark daran interessiert bin, ein eigenen erfolgreiches Brwosergame (Unternehmen) aufzubauen, würde mich Eure Meinung interessieren, ob Java oder Flash (oder vielleicht was ganz anderes?) die Zukunft ist?

Die Frage ist etwas falsch gestellt. Als ich damals angefangen habe in der Softwareentwicklung zu arbeiten, musste ich ganz schnell lernen, die richtige Technologie für den richtigen Anwendungsbereich zu wählen und persönliche Vorlieben hinten an zu stellen. Auch wenn Programmiersprachen und Technologien immer universeller werden, gilt dieser Ansatz noch immer. Die Frage, die Du Dir stellen musst ist also nicht, welche Technologie die Zukunft ist, sondern die beste Technologie für Deinen Einsatzzweck ist.
Ohne genau zu wissen, was Du vor hast, ist es natürlich schwer, eine Empfehlung zu geben. Hier aber dennoch ein paar Anregungen dazu:
Zu Flash:
Flash ist eine etablierte Technologie die sich über Jahre hin entwickelt hat. Auch wenn die Wurzeln nicht im Web liegen, wird es heute zu den Webtechnologien gezählt. In meinen Augen hat Flash einen entschiedenen Vorteil: Man kann ein grafisches Frontend kreieren, dass nicht durch die heutigen Fähigkeiten des Browsers begrenzt ist, aber man kann dennoch die klassischen WBA Technologien im Backend nutzen. Unter Berücksichtigung modernen Ansätze, in dem man das Backend z.B. RESTful entwickelt, ist es sogar möglich, neben dem Flash Interface Alternativen anzubieten. Was mich direkt zu den Nachteilen bringt.
Der Einsatz von Flash begrenzt die Zielgruppe für das Spiel. Das Spiel wird abhängig von einem Plugin und eventuell sogar von einer Bestimmten Version. Dadurch können Abhängigkeiten von Betriebsystemen und Hardware entstehen. Das lässt sich bei den BP Spielen sehr gut beobachten und es gibt hier im Forum einige Berichte darüber. BP Spiele sind hier auf meinem G4 800 z.B. so gut wie unspielbar. Über Faktoren, wie Barrierefreiheit, brauchen wir gar nicht erst reden.
Zu Java:
Ich nehme mal an, Du redest hier, wegen dem Bezug auf Flash, von clientseitigem Java. Da muss ich ganz ehrlich sagen, dass das für mich nichts mehr mit Browsergames zu tun hat. Der Browser wird dabei nämlich völlig überflüssig. Du entwickelst den Client in Java, machst ihn Java WebStart fähig und gut ist. Kein Browser im Vordergrund, keine klassische WBA Technologie im Hintergrund. HTTP braucht man als Übertragungsprotokoll auch nicht mehr, denn da kann man viel schönere Sachen verwenden. Und schon bist Du eigentlich im Bereich der Clientgames. Mit allen Vor- und Nachteilen. Du kannst die Rechenleistung des Clients verwenden und musst nicht alles Serverseitig machen. Bist abhängig von Version, Betriebsystem, Hardware. Barrierefreiheit gibt es nicht. Und Du musst Dein System gegen Manipulation im Client schützen, um Cheaten zu verhindern. Dafür stehen Dir dann aber auch alle Technologien, die man sich bei der Spieleentwicklung wünscht, zur Verfügung.
Zu Flash und Java:
Wie man bei Spielen, die diese Technologien verwenden, in meinen Augen immer wieder sehen kann, verleiten Sie dazu, ein grafisches Feuerwerk zu veranstalten (deswegen benutzt man es ja). Aber oftmals wird dabei der eigentliche Inhalt vergessen. Was aber auch nahe liegend ist. Diese Technologien, und gerade clientseitiges Java, bewegen die ganze Thematik mehr in die Richtung der Clientgames. Und wenn man sich diesen Bereich ansieht, sieht man ganz schnell, dass kommerziell erfolgreiche Clientgames nicht von einem zwei Mann Team entwickelt werden. Da braucht man schon ein ganzes Team an Entwicklern, Spieldesigner und Grafiken. Daher halte ich die Einsatz dieser Techniken für ein zweischneidiges Schwert. Aber wie am Anfang schon gesagt, es kommt immer darauf an, was für Spiele man entwickeln möchte.
Die Alternativen:
Ich möchte noch die Frage von Rauhfaser aufgreifen. Ich bin auch der Auffassung, das weniger manchmal mehr ist. Die WBA Technologien entwickeln sich stetig weiter. Und gerade die WebGUIs haben mit den aktuellen Technologien, wie Ajax eine Qualität erreicht, die vorher nicht vorstellbar war. Und auf der Roadmap stehen noch viele schöne Sachen, die kommen werden und die GUIs von Browserspielen bereichern. Als Beispiel seien XForms und verwandte Überlegungen genannt. Bei überzeugendem Inhalt und Spielprinzip braucht es kein grafisches Feuerwerk. Es gibt genug Browser Spiele, die dies beweisen (z.B. Travian, Freewars, etc.), aber auch genug Beispiele, die zeigen, dass die Qualität aufgrund von Interface-Spielerein stark leidet (AoP war so ein Fall für mich, als sie angefangen haben, das grafische Interface auch noch mit Ajax aufzupeppen, da ging ja gar nichts mehr. Und auch Travianer ist so ein Kandidat für mich).
Daher meine Empfehlung, überleg Dir erst, was für ein Spiel Du entwickeln willst, welche Fähigkeiten Du hast, ob Du genug finanzielle Mittel hast, um Dir gegebenenfalls Leistungen hinzuzukaufen (Grafiker sind nicht billig), und welche Zielgruppe Du im Auge hast. Dann und erst dann kannst Du Dich für eine Technologie entscheiden.

@Agmemon
Im Bereich Java kann ich Dir nur Recht geben. Also die stehen in direkter Konkurrenz zu DX-Games, und soweit ich weiss, werden die immer noch in C++ geschrieben, werden der höheren Performance.
Ich hab ja Flash auch nicht gemocht, aber ich muss zugeben ich hatte keine Ahnung was Flash drauf hat, jetzt weiss ich mehr, und bin aus dem Staunen nicht rausgekommen, also technisch und grafisch ist das schon beeindruckend.
Warum bigpoint gestern Flash-Entwickler sucht:
TOP-Bezahlung für BG-Entwickler
und heute von einer überholten Technologie redet, kann ich natürlich auch nicht beantworten

Habe versucht, möglichst neutral zu schreiben, aber ich kann scheinbar einfach nicht verbergen, dass ich kein großer Flash-Fan bin. Aber ich akzeptiere, dass es interessante Möglichkeiten bittet. Die Technik entspricht aber nicht meiner angestrebten Zielgruppe und wie bereits ausgeführt, halte ich dies für einen der wichtigsten Gründe, für die Entscheidung, auf welche Zielgruppe man setzt.

Ein alter Kollege von mir hat heute einen Vortrag gehalten und verschiedene Platformen für Webbasierte Anwendungen miteinander verglichen. Die typische, betrachtete Applikation liegt im Bereich Zug-Disposition / Trassendisposition.
Flash:
Vorteile:
- Größere Performanz durch kleinere Datensätze und effizienteres Laden
wesentlich zuverlässiger als Applets
- Kommunikation zwischen Flash und Web-Content über JavaScript möglich
- gute Browser Unterstützung und starke Abdeckung im Web (97%)
Nachteile:
- steile Lernkurve
- Proprietär und damit Kostenpflichtige IDE Adobe Flash (800€)
Java:
Vorteile:
- know-how und Erfahrung mit Java vorhanden
- gute Grafik API (Graphics 2D) & Entwicklung mit Eclipse
- kostenfrei
Nachteile:
- Performanz
- Java Applets wirken insbesondere bei der Initialisierung schwerfällig
- hoher Speicher verbrauch
- Austausch zwischen Web-Content und Applet-Content nicht möglich
- Java Applets laufen in immer weniger Web-Browsern
hth
Todi

Original von Agmemon
Zu Java:
... Und Du musst Dein System gegen Manipulation im Client schützen, um Cheaten zu verhindern. Dafür stehen Dir dann aber auch alle Technologien, die man sich bei der Spieleentwicklung wünscht, zur Verfügung.

Das must Du bei jedem System, bei dem Du nicht Herr über die Clients bist.

Ich bezog das auf den Vergleich zu den klassischen serverseitigen Systemen. In dem Moment, in dem Teile der Geschäftslogik einer Anwendung im Client selbst liegt, bekommt das Ganze eine ganz andere Qualität.

Danke Agmemon.
War sehr interessant das alles zu lesen.

Original von raufaser

Ich möchte in dieser Diskussion noch einen weiteren Punkt anmerken, der in Bezug auf die Fragestellung ob Flash oder Java vielleicht auch nicht ganz unwichtig ist:
Ist manchmal weniger nicht mehr?
Das sollte auch diskutiert werden finde ich...
Das ist schon ein interessanter Punkt, aber es geht hier erstmal um die, die eben nicht der Meinung sind "weniger ist mehr" sondern "mehr ist einfach mehr"
Mich würde stark interessieren, wie wie viel Aufwand so ein Spiel alà Seafight und Co. ist. Ich glaube auch, dass die Leute bei so einem Spiel bereit sind, viel mehr Geld auszugeben als bei einem "Tabellenspiel"
Deswegen würde ich gerne mal ein BIG-LEUCHT-GRAFIK-Spiel entwickeln und beobachten ob die Masse mehr darauf anspringt.
Unser Programmierer überlegt eben gerade, ob er lieber in Java oder in Flash weiter machen sollte, was ist die Zukunft für diese Spiele.
Persönlich glaube ich auch daran, dass die Grafik ein ganz entscheidender Punkt ist um neue User zu finden und schnell für dein Spiel zu begeistern. Aber das ist ja auch wieder ein anderes Thema.

@Bergtroll
Schau Dir doch mal den Fussballmanger von Bigpoint an, also wo man selber sein Team lenken kann, das ist in Java, aber da ist eine KI drin, und Character-Animation usw..., also wie Agmemon schon sagt, ohne ein wirklich professionelles, großes Team nicht umzusetzen.
@Agmemon
Ich kann halt nichts im Vergleich Ajax und Flash sagen, da ich Ajax nicht kenne.
Aber die Zielgruppe Spieler steht auf Grafik, also zumindestens meiner Erfahrung nach, und auch ich davon nicht ausnehmen.

moin moin...
der ein oder die andere haben es sicherlich schon mitbekommen, dass meine einstellung eher "pro flash" ist *gg*
prinzipiell schliesse ich mich aber der dem an, dass beide techniken ihre daseinsberechtigung haben.
zu flash im speziellen:
flash hat eine sehr hohe verbreitung und selbst die jeweilse neue version des plugins ist i.d.r. in weniger wie zwölf monaten zu 80%, 85% und mehr verbreitet und bildet damit schon mal eine riesige mögliche zielgruppe, auch aufgrund der viele OS, für die der player entwickelt wird.
nochdazu läuft eine evtl. notwendige installation / aktualisierung nahezu automatisch, ohne die aufgerufene seite zu verlassen.
flash kann das, was man mit javascript / ajax & co. heute versucht zu realisieren schon seit geraumer zeit.
die programmierung in flash erfolgt mit actionscript, was in der syntax javascript sehr ähnlich ist und damit für viele leicht zu erlernen.
actionscript3.0, seit dem flash-player 9 integriert ist im eventmodel etc. an java, bzw. hochsprachen, angelehnt, und somit ebenfalls für viele leicht zu erlernen.
die leistung von actionscript3.0 hat sich, im vergleich zu actionscript2.0, ungefähr verzehntfacht *gg*
die möglichkeiten, die sich mit AS3.0 bieten sind heute noch gar nicht alle wirklich abzusehen.
die äusserung "flash ist ausgereizt, da kann nichts mehr kommen" zeugt in meine augen nur von unwissenheit.
selbst 3D für ein browsergame scheint mit AS3.0 in greifbare nähe gerückt zu sein.
ich werf da nur einmal schlagworte wie "Papervision" oder "Sandy" in den raum.
flash bietet die möglichkeit:
- GUI zu entwickeln, die denen von vollpreisspielen in nichts nachstehen müssen
- vektorgrafiken _UND_ bitmapgrafiken zu verwenden
- während der laufzeit, bitmapfilter-effekte zu verwenden
- während der laufzeit, angezeigte bitmaps zu manipulieren
- soundeffekte und / oder hintergrundmusiken einzusetzten
- spiele (applikationen) fullscreen darzustellen
und, und, und...
für designer ist die flash-IDE sicher recht schnell zu bedienen
für entwickler / programmierer bietet sich ggf. Flex oder auch Eclipse mit entsprechenden plug-ins an
somit hat "jeder" die möglichkeit, sich in der "richtigen" entwichklungsumgebung wieder zufinden
die entwicklung des plugins scheint auch eine eindeutige richtung eingeschlagen zu haben.
so wurde in der aktuellen beta-version des flashplugins z.b. das mipmapping verbessert oder multicore-unterstützung integriert
und, auf serverseite gibt es auch (kommerzielle und open-source) projekte, die ein data-push zum clienten ermöglichen, um z.b. realtime-spiele zu realisieren.
ich sage nicht, dass flash die ultimative antwort auf alle (browserspiel-)fragen ist.
aber, es werden schon viele antworten gegeben, und, was noch viel wichtiger, es werden auch neue frage gestellt
gruss,
FateF8

Ich mag zwar Java als Sprache nicht, aber mache man mal bitte das hier:

mit" target="_blank">http://www.pixeltamer.net/?page=Fugu
mit Flash nach...
Von der unglaublichen Langsamkeit der Actionscript-Engine mal ganz abgesehen.

hmm, ohne mich jetzt einmischen zu wollen ;-), denke ich -das die entwicklungsumgebung das rennen machen wird, welche die beste kommunikation zwischen programmierer und grafiker/ 3D gewährleistet.
da die max. polygon oder flächen anzahl stetig wächst, wird sich wohl kein programmierer mit einem 3D programm auseinander setzen und umgekehrt.
ein paar würfel programmier technisch umzusetzen ist mit guten kenntnissen für flash/java etc. sicher recht leicht möglich, bei einer poly anzahl von ein paar hundert oder mehr( zb.12000) eher schwierig?!
letztendlich aber, entscheidet der user und die klickrates über sieg oder niederlage der jeweiligen technologie.

Das ist ein wunderbares Beispiel, für die Abhängigkeit von OS und Hardware, die ich ansprach:

Ich tippe mal auf MacOS...
Auf Randgruppen können wir leider keine Rücksicht nehmen

Weniger eine MacOS Problem, als eine Performance Sache

Wie ist denn das mit der Geschwindigkeit?
Laut http://www.tonypa.pri.ee/tbw/tut13.html ist Flash "extermely slow". Er bezieht sich da allerdings glaub auf Flash 5.
Hat sich das inzwischen geändert und wie ist das im vergleich zu Java?
Eigentlich könnte Flash ja genauso schnell wie einen Java sein.
Das Hauptproblem was ich bis jetzt an Java sehe ist, dass es viel länger zu laden braucht, man oft diese Sicherheitsnachrichten bestätigen und in der SysTray immer aufpopt, dass jetzt Java verwendet wird.

Theoretisch könnte Flash vielleicht genauso schnell wie Java sein. Ist es aber nicht.
Aus folgenden Gründen:
1. Programm-Ausführung
Java wird in praktisch allen Implementationen zur Laufzeit in nativen Maschinencode übersetzt.
Javascript/Actionscript ist von der Architektur der Sprache extrem ungeeignet, um in nativen Code übersetzt zu werden (ich möchte nicht sagen "unmöglich", aber es ist zumindest nahe dran).
2. 2D-Blitting
Java nutzt die nativen Blit-Routinen für 2D-Grafik, was im allgemeinen bedeutet: Die Grafikkarte macht das
Flash hat einen eigenen Software-Blitter. Der ist in praktisch jedem Szenario langsamer. Dafür verhält er sich definiert und hat mehr Möglichkeiten.
3. 3D
Java unterstützt per Jogl OpenGL. Zukünftig soll OpenGL sogar der Standard-Renderer für Java3D werden. OpenGL = hardwarebeschleunigt = schnell.
Flash hat keinerlei 3D-API. Es gibt ein paar beachtliche Software-Renderer, aber die haben nicht den Hauch einer Chance in Qualität und Leistung an selbst den billigsten Onboard-Chip heranzukommen.
Ich muss schockiert feststellen, dass ich als eingefleischter Java-Hasser die Platform hier verteidige. Aber Fakt ist, dass Java für rechen- oder grafikaufwendige Sachen einfach um Längen besser geeignet ist als Flash.
Dafür ist es natürlich einfacher, sich in Flash mal eben schnell was zusammenzuklicken. Sowas fehlt Java noch. Eclipse ist zwar ein guter Ansatz, aber einsteigerfreundlich ist es definitiv nicht.

Original von Agmemon
Weniger eine MacOS Problem, als eine Performance Sache

Na wenn ich den Screenshot sehe fällt mir auf:
1. Die Transformation ist zerschossen
2. Es fehlen fast (!) alle Texturen
Das ist also von Performanceproblem weit entfernt, da in dieser Form einfach mal nicht nutzbar.
Das kann an der Java-VM liegen, ein verkrüppeltes OpenGL ist aber wahrscheinlicher.

was hat euch eigentlich geritten, java zu benutzen? das hätte ich von euch als letzte erwartet.. ^^

Man möchte sich doch von anderen abheben und Gewinn machen, und das geht schlecht mit 0815-Tabellen.

Original von COrthbandt
Das ist also von Performanceproblem weit entfernt, da in dieser Form einfach mal nicht nutzbar.
Das kann an der Java-VM liegen, ein verkrüppeltes OpenGL ist aber wahrscheinlicher.

Also wie im Anhängendem Bild sieht es bei frisch gestartetem System aus. Schon ein Unterschied, oder? Ich vermute mal, die Texturen fehlen immer noch, wobei ich nicht an ein verkrüppeltes OpenGL glaube, was bei der OS X Systemarchitektur stark verwundern würde. Aber ist eigentlich auch egal. Es halt halt sehr schön meine Ausführung unterstützt
@Klaus: Warum herrscht eigentlich noch immer die Meinung vor, das es nur schwarz und weiß gibt. Also Flash/Java Feuerwerk und 0815 Tabellen. Was ist denn mit den Perlen dazwischen. Es gibt doch genug klassische BGs die sehr schön aufgemacht sind. Und es gibt sogar welche, die ohne Flash Interfaces haben, die so manches Flashgame nicht hin bekommt (AoP mal so als Beispiel)?

Zum Thema (D)HTML vs. Flash vs. Java:
Wir haben ja bei Parsec durchaus versucht, weitergehende Konzepte in DHTML umzusetzen und ich denke das ist ins auch gelungen.
Man kann in HTML sehr sehr viel machen. Für das nächste Projekt mussten wir aber feststellen, dass es in HTML einfach nicht funktioniert.
Das hat verschiedene Gründe, z.B. die Tatsache dass hochfrequente Timer in Firefox (2+3) einfach mal nicht funktionieren. Mit einer Timergenauigkeit von +-100ms kann ich nichts anfangen.
Die Behandlung von Transparenzen ist auch ein extrem schwieriger Punkt, da sich hier FF, IE und Opera auch nur in einem einig sind: Auf keinen Fall genauso interpretieren wie ein anderer Browser.
Flash würde sowohl das Timer-Problem als auch die Transparenz lösen. Speziell für Xcurse ist es aber sinnvoller voll auf 3D zu setzen. Das spart in diesem Fall viel Arbeit und Traffic.
Mittelfristig denke ich dass Hybridkonzepte an Bedeutung gewinnen, aber da gibt es leider viele Baustellen. Die Kommunikation zwischen einem Java-Applet und den umgebenden Website-Scripts ist alles andere als trivial.
Insofern geht es also nicht um Schwarz/Weiss, sondern um "the right tool for the job". Jede Platform (HTML, Flash, Java) hat Vor- und Nachteile. Je nach Projektziel ergibt sich also eine andere Abwägung welches nun die richtige ist. Zumindest solange der Hybridansatz an technischen Schranken scheitert.

Entschuldigung, wir reden hier vor Browserspielen und keinen Actionspielen.
Flash kann als solches kein 3D, das wird mit Swift gemacht, aber das würde ich, ausser für Spielerein nicht empfehlen.
Ich setzte z.B. Flash für die Karte ein. Flash ist im Cash und zieht nur noch die Infos aus der Datenbank, vielleicht nicht ganz so performant wie html-js-Lösungen, aber dafür viel besser programmierbar.

Mir war nicht bewusst, dass die Definitionshoheit für "Browsergame" schon vergeben ist
Ich definiere "Browsergame" für mich als: Ein Game, das im Browser läuft.
Und da ist mir irgendwie auch nicht ganz klar, warum ein solches Spiel nicht auch actionlastig sein dürfte. Was ist mit Spielen wie Dark Orbit? Kein Browsergame? Sagt wer?
Und sorry, aber Swift 3D hat absolut nichts mit dem zu tun was ich unter interaktivem 3D verstehe. Vorrendern und Vektorisieren mag ja für ein paar Frames ok sein, aber 3D ist es nicht. Ich möchte mal schwer bezweifeln dass Fugu in dieser Form mit Swift umsetzbar wäre.

Man sollte sich auch vor Augen führen für welche Bereiche was entworfen wurde. Klar ist mit HTML und JavaScript viel möglich. Aber HTML ist uralt und wurde zur Darstellung von Textinhalten entworfen. JavaScript soll dynamische HTML-Darstellungen ermöglichen.
Jetzt was mittels schön komplexer Hacks so hinzubiegen damit es im Browser läuft, ist zwar auch sicher interessant, jedoch weniger schlau. Warum sollte ich jeden Mist im Browser haben müssen? Nur damit ich ein Browsergame habe und sagen kann: es funktioniert im Browser (und man braucht "nur" Java- und Flashplugin, angeschaltetes JavaScript und Cookies). Wird es zu komplex, nimmt man geeignetere Ansätze für das Projekt. Sich auf einen zu versteifen halte ich für sehr schwach.
Brauche ich wirklich präzise Timer, ist man mit JavaScript natürlich an der falschen Stelle. Dafür wurde es auch schlichtweg nicht entwickelt - ich programmiere ja auch nicht in C# ne typische Unix-Socket-Verbindung. Geht auch alles durch mono, aber es ist nicht sehr schlau.
Übrigens: Java-Applets lassen sich super in eine Webseite integrieren, falls Java auch als serverseitige Engine verwendet wird.

Bevor wir in den Bereich Abrutschen, wo wieder zwanghaft versucht wird zu definieren WAS ein Browsergame ist, sollten wir bitte bei den technischen Dingen bleiben.
Die Jungs um COrthbandt gehen schon einen sehr guten Kompromiss ein.
Klar ist aber, daß je mehr Techniken auf der Clientseite verfügbar sein müssen, desto kleiner wird die erreichbare Zielgruppe sein. Wenn die Jungs diese Entscheidung für ihr Projekt gefällt haben, dann wird dies seine Gründe haben, welche uns nicht ersichtlich sein müssen.
JAVA war schon früher sehr umstritten, ist aber heute durch die Bemühungen von SUN und den vielen Programmierern eine sehr mächtige Sprache geworden. Auch die damals vorhandenen Hauptkritikpunkte zum Thema Performanze und GUI Design sind ausgemerzt worden.
Klar ist, daß Browsergames mit solchen Techniken auf einfachen Endgeräten (Handy/iPhone/PDA) nur noch sehr beschränkt einsetzbar sind. Und auch hier gilt wieder das die angepeilte Zielgruppe die verwendbaren technischen Mittel definiert.
Im großen und ganzen ziehe ich aber meinen Hut vor den Jungs von pixeltamer. Die wissen sehr wohl was sie sich vorgenommen haben, was technisch machbar ist und was man im Markt platzieren kann.
Meiner Meinung nach, zeigen diese uns gerade eine mögliche Zukunft der Browsergame Sparte. Es wird immer einfach gestrickte Browsergames geben, aber wie zu Zeiten der 8 Bit Rechner steht uns hier jetzt ein Paradigmenwechsel bevor.
Wollen wir den Endverbrauchen, sprich den Kunden, weiterhin mit HTML abspeisen, welches mit ein wenig JavaScript aufgewertet wird um ihm eine gewisse Art von Interaktivität vorzugaukeln, oder sind wir in der Lage die alten Vorurteile abzustreifen und neue Techniken auszuprobieren?
Den nächsten Part kann ein Mod gerne rauswerfen wenn es zu negativ ankommt...

Und mal ganz ehrlich... das ist viel mehr als einige von uns von sich sagen können. Ich zeige nur mal bedenklich in Richtung der Freischaltungen in letzter Zeit, wo man den Eindruck bekommt, daß hier jeder der "ich kann mit Frontpage was machen, also kann ich programmieren" reingelassen wird.

Da sagst Du viel Wahres MrMarco.
Also Apocalyptica und COrthbandt "in unser Leben traten", war ich sehr gespannt darauf, was Pixeltamer machen wird. Aber ehrlich gesagt, aus inhaltlicher Sicht, durch Ihre Erfahrung im klassischem Spiele Bereich. Aber was Pixeltamer auf technischer Seite gezeigt hat, ist noch beeindruckender.
Egal ob die Minispiele oder Parsec, es gibt hier kaum jemanden, der die technischen Möglichkeiten so ausgereizt hat. Und das mit angeblich ach so veralteten Technologien.
COrthbandt, hat einen Teil meiner Ausführung sehr schön zusammen gefasst: "the right tool for the job". Grundvoraussetzung dafür ist, dass man weiß, welche Technologie was ermöglicht und wo Ihre Grenzen sind.
Dies und die genaue Definition der Zielgruppe, bzw. der Anforderungen der Zielgruppe, machen von technischer Seite aus ein erfolgreiches Spiel aus. Und nicht ob BP jetzt Flash oder Java oder sonst was verwendet. Den "Erfolg" von BP, auf die zugrunde liegende Technik zu beziehen, und des wegen auf den Zug zu springen, ist der falsche Weg. Bei BP gab es noch viele, und vermutlich viel wichtigere Faktoren, warum sie da sind, wo sie sind.
Daher meine Empfehlung an den Thread-Eröffner: Macht euch erstmal Gedanken, was für ein Spiel ihr entwickeln wollt. Schreibt ein Konzept, definiert eure Zielgruppe und schaut dann, auf welcher Basis Ihr es am besten Umsetzen könnt. Klickibunti Flash/Java Interfaces allein machen noch kein Erfolgsprodukt.

Zunächst mal freuen wir uns natürlich, wenn unsere Arbeit so gewürdigt wird.
Und MrMarco und Agmemnon treffen den Nagel auf den Kopf:
Egal wie man nun Browsergame definiert, es geht letztendlich darum ein interessantes Angebot für eine bestimmte Zielgruppe zu liefern.
Wenn ich mir unsere Stats ansehe, haben über 98% der Besucher Flash, Java, Javascript und Cookies aktiviert. Für die restlichen 2% Abstriche bei der Qualität zu machen scheint mir nicht sehr sinnvoll.
Ich mache lieber ein herrausragendes Projekt für 98% der Zielgruppe als ein (durch technische Hürden) mittelmässiges für 100%.
Das aktuelle Minispiel ist zum Beispiel in erster Linie ein Test: Ist Java+OpenGL eine tragfähige Basis für Browsergames? Wieviele Spieler haben damit technische Probleme? Was sind die Probleme? Gibt es brauchbare Workarounds?
Wenn diese Fragen beantwortet sind, ergibt sich eine klarere Bewertung der Umsetzungsmöglichkeiten für eine gegebene Spielidee. Und die Spielidee sollte immer im Vordergrund stehen. Danach kommt die Technik. Sich künstliche Begrenzungen im Gamedesign aufzuerlegen nur um in irgendwelche Kategorien wie "klassisches Browsergame" zu passen ist zumindest nicht unser Ansatz.

Original von Agmemon
Weniger eine MacOS Problem, als eine Performance Sache

Vor allem funktioniert es hier problemlos.
Technologien sind doch immer am effizientesten, wenn man sie zielgerichtet einsetzt. Für manche Anwendungen reicht PHP allemal aus (Tatsache), für andere Dinge wiederum ist etwas mehr Richtung Java oder mittlerweile ja auch .NET & Co notwendig, vor allem im Hinblick auf vorhandene Frameworks und Bibliotheken.
Für richtige interaktive Spiele gibt es für den Browser eigentlich keine Alternative als Flash oder Java (klammern wir mal das eine oder andere krative Spiel auf Basis von AJax aus, aber seien wir ehrlich..). Sachen wie globolus.com, div. andere Flash- und Javaspieleseiten würden nicht anders funktionieren.
Aber ich bin strikter Verfechter solcher Java/Flash-Navigationen, weil es einfach "cool" aussehen soll - es aber nicht ist. Ohne Sinn und Zweck ist so eine Technologie nicht gut - und deshalb wohl in der Vergangenheit in Verruf geraten.
Zu dem Link Fugu, mal ganz allgemein: Ich würde so eine Seite nicht besuchen wollen, weil..
* Seite ein vertrauenswürdiges Zertifikat-Popup hat (und ich zwar weder paranoid noch sonstwas bin, aber wo ich nicht unbedingt hinwill, geht meine Bereitschaft schnell zurück)
* die Seite unheimlich lange braucht zu laden, verbunden mit NULL Informationsdarstellung, was da eigentlich geladen oder getätigt wird. Meine VM kann es nicht gewesen sein, ich hatte grad noch dick Eclipse mit Java am Laufen, also war es das Browserplugin selber => da sind Flashplugins besser, die mir einen dynamischen Fortschrittsbalken anzeigen, und der auch in den meisten Fällen stimmt.
Zum guten Schluss: Bei mir sträubts immer, bei einer solchen fetten Java-Applikation (und das geht ja hier wohl mal eindeutig an einem "unterstützenden" Applet vorbei) noch browserbasiert zu sprechen.. wofür ist hier eigentlich (technisch) noch der Browser notwendig?
Das ist keine Kritik direkt an dich, sondern eine allgemeine Frage an solche Applikationen..
PS: Was das iPhone angeht, das hat oben irgender erwähnt: Dort funktioniert derzeit weder das eine, noch das andere.

Das sind halt genau die Probleme, die wir mit Fugu ausloten wollen.
Im Detail hab ich da auch gleich drei Nachfragen:
1. Zertifikate: Alle angezeigten Zertifikate müssten von Sun sein. Wenn das nicht vertrauenswürdig genug ist weiss ich auch nicht... Oder wurde bei Dir irgendetwas andered angezeigt?
2. Ladezeit a: Sowohl das Java-Plugin als auch der Applet Launcher haben eigentlich einen Fortschrittsbalken. Wenn der bei Dir nicht angezeigt wurde sollten wir das näher untersuchen
3. Ladezeit b: Wie lange ist "ewig" in Deinem Fall gewesen? Der Download aller Komponenten sollte bei einer minimalen DSL-Verbindung beim ersten Laden nicht länger als 15 Sekunden dauern.
Wir haben bei Fugu übrigens extra darauf verzichtet, die Texturen usw. im Applet nachzuladen um halt genau auch herauszubekommen wie gross das Initialpaket in etwa werden darf.

Die Ladezeit paßt, wobei man hier bei vielen noch die Ladezeit für die VM selbst beachten muß und auf meinem Notebook... *grussel*
Das Zertifikat...
Ich habe nur die JavaVM drauf und keine Zertifikate von SUN per Hand installiert. Von daher kommt diese Frage IMMER auf allen meinen Maschinen.

Bei mir erscheint merkwürdigerweise keine Abfrage eines Zertifikats (Vista 64 Bit, IE 7, Java 6). Beim GN-Chat-Applet erscheint jedoch eines. Evtl hatte ich irgendwann mal 'Von Sun alles akzeptieren' geklickt, kann mich jedoch nicht daran erinnern. Es erscheint nur eine Frage ob Java Direct3d auf eine andere Art und Weise ansprechen soll (hab die Meldung nicht verstanden).
Zum Thema iPhone: Das unterstützt und Ajax. Weder Flash, noch Java wird es unterstützen. Wenn es nicht technologisch in der Lage ist mit anderen Handys zu konkurrieren, fällt es bei mir erstmal hinten herunter. Abgesehen von der fehlenden UMTS-Schnittstelle zum Übertragen großer Datenmengen.

1. Zertifikate: Alle angezeigten Zertifikate müssten von Sun sein. Wenn das nicht vertrauenswürdig genug ist weiss ich auch nicht... Oder wurde bei Dir irgendetwas andered angezeigt?

Wir wissen dass Sun vertrauenswürdig ist. "Dort draußen in der echten Welt" ist aber schon der Unterschied zwischen JavaScript und Java für viele nicht bekannt und bei Sun denken viele vielleicht an einen Sonnenstudiobetreiber.

Also, das Fenster sieht in einem OSX-Fx2 so aus:

Nach rund 30 Sekunden war alles geladen (inkl der Abfrage oben, die ich in 2 Sekunden angeklickt hatte).
Zwischenzeitlich gab es keinen Ladebalken, nur kurz vor Ende tauchte das Java (webstart?) Symbol aus, also das hier, Dauer der Einblendung: etwa 5 Sekunden, kurz vor Ende.

Aber auch der Balken war kein echter Fortschritt.
Weitere Infos: Das Applet war bereits im Cache, das ging im Verhältnis zu gestern relativ fix. (Aber eigentlich sind ja 30 Sekunden immer noch lahm, zumal es ja nicht am Download hapert).
Dann habe ich den Test nochmal wiederholt, diesmal mit Camino, das ist ja in "etwa" sowas wie der Firefox, zumindestens technisch unter der Haube.. im Camino war das Applet nicht zeischengespeichert.
Auch hier kommt die Zertifikatanfrage, allerdings bereits, wenn die Seite schon halb angezeigt wird (im Gegensatz zum Firefox, wo die Anfrage vor einer weißen Seite kommt).

Der Hintergrund ist weiß, sobald man aber scrollt, wird alles rot:

Ich habe nach 2 Minuten abgebrochen und einen normalen Refresh (Apfel-R, bzw Strg-F5) durchgeführt, dann war die Sache in rund 10 Sekunden geladen).
Fazit: Sehr lange Ladezeit, aber weniger durch die Größe (Bandbreite genug vorhanden), sondern durch die VM (was ich mir allerdings auch nicht erklären kann). Hier würde ich mal fragen, wie es mit Nachladen wäre? Also Minimalapplet, was dann einen WebClassloader nutzt?
Außerdem: Keine Fortschrittsbalken bei meinen getesteten Browsern Fix2 und Camino unter MacOSX.
Ich hab nen C2D 2,16Hgz mit ordentlich RAM, also auch keine lahme Kiste, die an Java schlapp machen würde
PS: iPhone: UMTS-Support aus einem einfachen Grund, in der USA gibt es keine bzw. kaum UMTS-Netze, und das iPhone ist derzeit komplett auf den US-Markt ausgelegt. Allerdings hätten die das "UMTS-Pendant" einbauen können Auf der anderen Seite.. mit nem WLAN-Modul und den vielen kostenlosen APs in den Cities, ist das auch kein Thema..

Können wir den Kugelfisch-Support vielleicht in einen anderen Thread verschieben und hier auf der abstrakten Ebene bleiben?

Original von Klaus
Können wir den Kugelfisch-Support vielleicht in einen anderen Thread verschieben und hier auf der abstrakten Ebene bleiben?

Ich hab nur die Frage beantwortet - und um es zu vervollständigen: Unter XP und Fx2 und IE7 funktioniert das auch irgendwie nicht sauber.. es dauert ewig zum Laden.
Und damit komme ich wieder auf meine Frage zurück: Warum muss sowas noch im Browser sein?

>Warum muss sowas noch im Browser sein?
Das sehe ich genauso. Java zieht den Browser auch gerne mal mit in den Tod und das Applet hat ja keinen Bezug mehr zum HTML, da fände ich es viel schöner dies als Client laufen zu lassen.

> Warum muss sowas noch im Browser sein?
Für mich hätte dies einen Grund: 'It just works'.
Der Nutzer geht auf die Seite, klickt eine Infomeldung bei Bedarf weg und kann sofort loslegen (vorausgesetzt die VM startet schnell genug ;-) ). Was wären Alternativen?
Echte native (C/C++)-Clientspiele: Runterladen, Installieren, evtl Patchen, los geht's. Das Patchen kann auch das Spiel selbst übernehmen, nur erscheint dann das Verlangen nach Admin-Rechten und man muss die gesamte Update-Routine selbst programmieren.
Java Webstart: Hässliches Icon öffnet sich links unten und Java Webstart hat schon einige fatale Sicherheitslücken hinter sich. Auch kommt der Nutzer mit einem meist für ihn unbekannten Framework mit seinen Dialogen in Kontakt.
.Net-One-Click-Deployment: Taugt irgendwie nichts. Da kann mir MS erzählen was es will. So etwas unzuverlässiges habe ich lang nicht mehr gesehen.
Java-Applets funktionieren einfach (von 'Randgruppen' wie Agamemon abgesehen, sry ;-) ) und das Java-Framework kümmert sich um alles notwendigt. Für mich als Nutzer sehr angenehm und ich assoziiere das Spiel sofort mit einer Url. Bei vielen Nutzern ist der Browser so oder so immer offen. Ein Clientspiel (am besten noch Vollbild) wäre ein weiteres Fenster und damit ein Störfaktor in der gewohnten 'Ich surf mich zu Tode'-Umgebung.
Nur folgenden Nachteil sehe ich gerade bei fugu:
- Die Maus wird nicht eingefangen. Bewegt man die Maus außerhalb des Fensters, so verliert das Applet die Kontrolle über diese und das Spiel läuft unkontrolliert weiter. Manchmal bewegt man die Maus aus Versehen aus dem Applet-Bereich und wundert sich was gerade am Spiel los ist. Dieser Nachteil ist meiner Meinung nach nicht geringfügig, da er zwischen Tod und Leben der Spielkugel entscheiden kann.
Ob man das Ding noch Browserspiel nennen kann ist für mich unwesentlich. Ich würde es nicht so nennen, aber warum muss ein Spiel auf Gedeih und Verderb ein Browserspiel sein. Der Browser ist nur ein Zugang zum Spiel, nicht wesentlicher Bestandteil des Spieles.

Ich kenne mich mit Java WebStart nicht aus, aber wo kann der noch der Unterschied sein, gegenüber dem "Applet" von Fugu, was ja auch einen erweiterten Sicherheitsmanager installiert und aktiviert haben möchte? Beim JavaWebStart ist meines Wissens aber der Fortschritt wesentlich besser, weil es eben doch für genau so ein Szenario entwickelt wurde. Oder?
It just works.. nun ja, das sei mal so dahingestellt. Schon mal auf etwas älteren Rechnern, evtl öffentlichen Rechnern Java und Flashapplets starten wollen (bsp. Icq2go)? Da ist beides eine Qual, meist läuft Flash noch einen Tick besser (fällt dann aber meist wg zu alter Version flach). Beides bringt den Rechner meist über die Wupper..

Zwischen einem Applet und einer WebStart-App bestehen für uns im Wesentlichen folgende Unterschiede:
1. Applet läuft mit eingeschränkten Rechten
2. Applet macht kein neues Fenster auf -> kein Medienbruch
3. Applet kann (in Grenzen) mit der umgebenden Website kommunizieren
4. Applet zeigt nur "vertrauenswürdige" Zertifikate an (von Sun eben)
Speziell der Medienbruch ist uns besonders wichtig. Dem gemeinen User ist nicht klar, dass der Browser eigentlich gar kein 3D usw kann. Ist ihm auch egal.
Wir vermuten allerdings, dass die Akzeptanz eines Applets höher ist eben weil es nicht ein eigenes Fenster öffnet. Das ist letztendlich auch eine Frage von "workplace safety" ;-)

Original von TheUndeadable
Java-Applets funktionieren einfach (von 'Randgruppen' wie Agamemon abgesehen, sry ;-) ) und das Java-Framework kümmert sich um alles notwendigt.

Ich weiß zwar, dass das mit der Randgruppe nett gemeint ist, es zeigt aber einen Denkfehler. Das Applet funktionierte nicht, nicht weil ich ein Mac Benutzer bin und zu einer 7,9% Randgruppe gehöre, sondern weil mein gutes PowerBook nicht mehr das jüngste ist, seit 14 Tagen nciht mehr neu gestartet wurde und zig Applikationen am arbeiten waren. Die Kombination Browser+Java+3D ist dann halt einfach tödlich.
COrthbandt hat das in einem der vorherigen Postings ganz gut geschrieben. In Ihren Statistiken konnten sie sehen, dass 98% Ihrer Besucher Flash, JavaScript und Java verarbeiten können. Aber die Zahlen allein, bringen Ihnen nichts, sondern sie entwickeln ein Minigame, um sehen zu können, wo die Problemfelder liegen.
Denn die Prozentzahlen sind nichts wert, denn sie geben nur Aufschluss darüber, ob ein Plugin installiert ist oder eine Technik aktiviert ist. Was die zahlen nicht sagen, ist, ob die richtige Java-Version installiert ist, ob die Verbindung schnell genug ist, ob die Hardware mitmacht, usw.
Schlussendlich hat das auch wieder was mit der Zielgruppe zu tun. Bei den Zockerkids kann ich mir sicher sein, dass die einen Rechner mit zig GHz und GB haben, mit einer dicken Grafikkarte. Ist meine Zielgrupper aber breiter, ändert sich das ganz schnell. Da ist man dann plötzlich in dem Bereich 1 GHz Rechner, 256 MB Speicher, 16 MB SharedMemory Grafikkarte, mit 356 KBit/s Anbindung. Und da ist dann plötzlich nichts mehr, mit "It just works".

Nun ja.. aber gerade bei kleinen Spielen bzw. Browsergames, die man mal zwischendurchspielen will, wird man uU häfiger öffentliche Rechner verwenden wollen. Und dort ist bekannterweise die Hardware nicht neuste, und meist auch die Sicherheitseinstellungen (teilweise unbegründet) streng.
Ich nehme als Beispiel einen PC-Pool in unserer FH: Alle Rechenr haben Flash 6 oder 7 und Java 5 installiert. Super Statistik, aber entweder läuft Flash nicht, weil mind. Version 8 vorausgesetzt wird, oder sogar das Flashplugin den Rechenr überlastet. Von den Java-Applets mal ganz zu schweigen, die urplötzlich den ganzen IE der Firefox auf installiertem Windows 2000 aus dem Speicher killen. It just works, das kann ich wirklich unterschreiben.
Zu den vier Punkten:
1. Abgehakt.
2. Medienbruch, okay..
3. Im Ernst - wofür braucht ihr das? Ich habe verstanden, die ganze Anwendung soll eh im Applet stattfinden.. wofür dann noch Kommunikation?
4. Auch abgehakt.
Ist der Medienbruch tatsächlich so groß? Wenn ich mir manchmal angucke, wie viele Fenster andere Webspiele öffnen (Werbung, SPiel, ..), dann wäre das für mich das kleine Übel - zugeben, spreche hier natürlich von mir..
Wie sieht es denn mit der Performance und auch Kompatibilität aus, wenn man mit WebStart arbeitet? Im direkten Vergleich zum Applet, vllt sogar die gleiche Anwendung?