Entscheidungshilfe: Plattform für Browsergames

[sfxon]

Hey Leute,
Ich möchte in meinen nächsten Projekten Browsergames erstellen. Was denkt Ihr denn wäre die richtige Plattform dafür?

Javascript und HTML5?
Damit kommt man relativ schnell an die Grenzen des Machbaren. Außerdem stören mich die Unterschiede zwischen den einzelnen Browsern und das zu häufige nicht standardkonforme Verhalten.
-Würd ich weiterhin nur für kleinere Projekte verwenden.
-Kommt bei langsameren Rechnern schnell an die Leistungsgrenze - gerade in Sachen Animation.
-Puzzlespiele: JA - Actionspiele: NEIN

Adobe Flex (Flash)
Bedeutet das es aufm iPhone/iPad nicht ausführbar ist. Das ist zwar schade.. aber nicht soo wichtig.
Meiner Meinung nach wohl die schnellste Plattform in der Ausführungsgeschwindigkeit.

Java Applets
Keine Ahnung ob das wirklich noch eine Alternative darstellt.
Soweit ich weiß auch eine gute Ausführungsgeschwindigkeit.
Ich habe vor einigen Jahren damit gearbeitet. Probleme hatte ich mit den Sicherheitsmeldungen der Browser. (Diese App ist nicht signiert..)
Wenn das noch immer so ist, kommt Java damit nicht in Frage. Das verunsichert die User zu sehr.
Vorteile sehe ich hier in der Verwendung von Protokollen wie TCP/IP..

Vielleicht habt ihr ja auch noch andere Ideen, oder könnt mir den einen oder anderen Hinweis geben.

(Ich bin gerade dabei wieder in die Spieleprogrammierung einzusteigen. Hab mein erstes Projekt in JavaScript/HTML5 so gut wie abgeschlossen (nur noch letzte Grafikgestaltungen (da ich kein richtiger Grafiker bin dauert das eben länger).
Jetzt möchte ich weiter in Richtung Spieleentwicklung gehen. (Eigentlich bin ich ja Anwendungsentwickler..))

[rüp]

Adobe Flex (Flash)
Bedeutet das es aufm iPhone/iPad nicht ausführbar ist.

Soweit ich weiß stimmt das nicht mehr. Hier gibt es z.B. ein Anleitung wie man mit der Flash-Game-Engine Flashpunk ein iOS-Spiel macht.

Ansonsten, beliebtester Tipp hier: Unity3D. Damit erstellte Spiele laufen allerdings (noch) nicht auf Linux; gibt es in einer eingeschränkten kostenlosen Version und einer 1100 Euro teuren Pro-Version.

[Tejio]

Hi sfxon und willkommen im Forum!

Also..
Wieso sollten sich mit Javascript und HTML5 keine Actionspiele realisieren lassen? o_Ô Die Portierung von Quake 3? auf WebGL und Javascript wäre ein gutes Beispiel dafür, dass es durchaus klappen kann. Das nicht-standardkonforme Verhalten bessert sich allmählich bei den Browserherstellern und es gibt auch einige Frameworks, die einen browserübergreifenden Zugriff auf die Browser-API erlauben. Außerdem gibt es mit dem Websocket auch einen standardisierten Javascript-Zugriff zur Kommunikation mit einem Server. Die Geschwindigkeit ist bei den modernen Webbrowser recht hoch, da dieser den Code in Maschinencode kompiliert.
Ich würde behaupten, dass sich Javascript und HTML5 für ein Browsergame anbieten würden.

Gruß, Tejio

€dit: Wenn man Websocket nutzen möchte, dann kann man den Server auch in Javascript entwickeln, dank NodeJS.

[Chromanoid]

Ich würde entweder Flex/Flash nehmen oder GWT (ggf. in Kombination mit Nutzung von HTML5 Komponenten)... (bezügl. Mobile/iOS mit Flash fand ich diesen Artikel auch ganz gut: http://www.gamedev.net/page/resources/_ ... lash-r2797)
Flash hat demnächst auch eine gute 3D API, daher ist es für mich momentan Favorit.
Bezügl. HTML5 und Co. habe ich recht häufig Beschwerden über Unausgereiftheit und vor allem eine schwierige Sound-API gehört.

Von Applets würde ich absehen, da sie nicht in einem besonders guten Ruf stehen (aus technischer Sicht IMO unbegründet) und sie sich dadurch eher für komplexe Spiele wie MMORPGs und Co. eignen (a'la Runescape), da Spieler solcher Spiele eher bereit sind gewisse Hürden zu überwinden (Applets sind da schon etwas unheimlicher als Flash, da die Dinger ja auch DLLs laden können).

Wie rüp schon schrieb: Unity könnte vielleicht auch was sein (soll ja auch demnächst nach Flash exportieren können)...
Außerdem ist da noch Silverlight - ist auch recht bequem, aber ich weiß nicht inwieweit Moonlight (Silverlight für Unix/Linux) überhaupt noch mit Silverlight kompatibel ist.

Dann gibt es noch weitere etwas unausgereifte Systeme wie HaXe oder http://code.google.com/p/forplay/ (eine Art GWT, das nach Flash, Java Desktop/Android, HTML5 exportiert).

Bezügl. Netzwerk HTML5 und Flash:
Wenn du größere Datenmengen schnell versenden möchtest, bieten AFAIK HTML5 keine und Flash nur sehr bedingt die Möglichkeit UDP Pakete zu empfangen. Gerade bei Client/Server Architekturen bin ich mir nicht sicher, ob das proprietäre RTMFP geeignet ist (Ich gehe mal davon aus, dass Projekte wie https://github.com/OpenRTMFP/Cumulus [achtung gpl] in Zukunft da weiter helfen).

Noch mal bezügl. Flash vs. HTML5:
Zynga setzt AFAIK momentan im Mobile Sektor vermehrt auf HTML5 (siehe Mafiawars), aber Flash ist bei Zynga weiterhin führend was Desktop-Browser-Spiele wie Zynga Poker oder CityVille angeht. Auch interessant dazu: http://www.insidesocialgames.com/2011/0 ... nd-mobile/ http://www.insidesocialgames.com/2011/0 ... l5-mobile/

Insgesamt kommt es wirklich darauf an, in welche Richtung deine Spiele gehen sollen. Hardcore-Browsergame-Spieler wollen sicher lieber eine schnelle eher trockene HTML Oberfläche (ggf. sogar ohne javascript) während Facebook-Spielerinnen solange sich die Ladezeiten in (engen) Grenzen halten sicher nicht auf Animationen und chice Grafiken verzichten wollen.

PS: Willkommen :)

[sfxon]

Wow. Danke für den guten Einstieg. Die Community hier ist ja richtig aktiv. :D
Danke auch für die Links zu weiteren Beiträgen. Das ist STARK!
Okay. Ich geh die ganzen Dinge mal der Reihe nach durch.

Ich habe nicht vor speziell für Hardcore-Gamer zu entwickeln. Die nächsten Projekte werden teils im Puzzle/Logik/Adventure Bereich (um es einfach zu halten und mich weiter mit der Technik vertraut zu machen). Und was mir noch wichtiger ist -anschließend im Jump'N'Run Sektor.
Komplexe 3D Ballerorgien oder MMORPGs sind gar nicht das, was ich entwickeln möchte. Selbst mit 3D-Grafik halte ich mich noch zurück.

HTML5 und WebGL:
Ist auch meiner Meinung nach noch nicht so weit. Bis das zum richtigen Standard wird, kann es auch noch eine ganze Weile dauern. Ich hab auch n Auge darauf, denn wenn es wirklich irgendwann richtig gut und einheitlich läuft ist das ne sehr gute Lösung.

Flash:

Flash hat demnächst auch eine gute 3D API,

Klingt sehr sehr gut. Dadurch, und durch die Tipps das es sich wohl auch fürs iOS verwenden lassen soll, für mich jetzt tatsächlich der Favorit. Mal sehen was noch so an Meinungen kommt. Bis dahin werde ich mir erstmal ein paar Tutorials zu Flex ansehen.
Kam früher für mich nicht in Frage, da es kostenpflichtig war. Aber wenn ich das richtig verstehe, kann man mit Flex jetzt eben eine OpenSource Variante nutzen.

Websockets:
Die Idee an sich ist wirklich toll. Ich hab das Thema auch interessiert verfolgt. Aaaaber: Gerade das Websockets im Firefox von Hand freigeschalten werden muss, hat es voerst ins Ausseits geschupst. (Auch durch diverse Sicherheitsrisiken.) Außerdem ist es nur ne Empfehlung ans Konsortium. Bis zum Standard ist es auch hier noch weit.

Haxe, Unity, etc..
Ich weiß nicht. Ursprünglich komm ich aus dem C++/Assembler-Bereich. Arbeite also lieber so nah am System wie möglich.
Heben diese Systeme/Engines nicht die Systemanforderungen viel zu weit an? Und erzeugen die nicht zu große Dateien, dadurch das oftmals viel Code mit kompiliert wird, der gar nicht benötigt wird?

Silverlight
Mhm.. nee. ^^

[Chromanoid]

HTML5 und WebGL:
Ist auch meiner Meinung nach noch nicht so weit. Bis das zum richtigen Standard wird, kann es auch noch eine ganze Weile dauern. Ich hab auch n Auge darauf, denn wenn es wirklich irgendwann richtig gut und einheitlich läuft ist das ne sehr gute Lösung.

Besonders wenn man bedenkt, wie sich Microsoft zu WebGL positioniert.

Flash:

Flash hat demnächst auch eine gute 3D API,

Klingt sehr sehr gut. Dadurch, und durch die Tipps das es sich wohl auch fürs iOS verwenden lassen soll, für mich jetzt tatsächlich der Favorit. Mal sehen was noch so an Meinungen kommt. Bis dahin werde ich mir erstmal ein paar Tutorials zu Flex ansehen.
Kam früher für mich nicht in Frage, da es kostenpflichtig war. Aber wenn ich das richtig verstehe, kann man mit Flex jetzt eben eine OpenSource Variante nutzen.

Den kostenlosen Flex SDK gibt es schon ziemlich lange :). FlashDevelop oder besser der (leider kostenpflichtige) Adobe Flash Builder sind komfortable Entwicklungsumgebungen (FlashDevelop hinkt leider etwas hinter her). Für den schnellen Einstieg ohne Adobe Flash CS sind Engines wie die schon erwähnte Flixel Engine zu empfehlen (ich hab damit mal einen kleinen ZFX Action Beitrag

Code: Alles auswählen

 probiert und das ging in gewissen Grenzen echt ziemlich gut). Die Tutorials auf der Seite sind auch gut für den Einstieg in AS3 geeignet. Es gibt aber sicher noch dutzende andere gute Bibliotheken für Flash ohne Flash CS...

[quote="sfxon"][b]Haxe, Unity, etc..[/b]
Ich weiß nicht. Ursprünglich komm ich aus dem C++/Assembler-Bereich. Arbeite also lieber so nah am System wie möglich.
Heben diese Systeme/Engines nicht die Systemanforderungen viel zu weit an? Und erzeugen die nicht zu große Dateien, dadurch das oftmals viel Code mit kompiliert wird, der gar nicht benötigt wird?
[/quote] Naja Haxe und Unity sollte man nicht zusammenwürfeln. Unity ist eine "handelsübliche" (vergleichsweise leicht zu benutzende) crossplatform Engine, die sich auch einigermaßen für den Browser durchgesetzt hat. Man kann soweit ich informiert bin mit C# und JavaScript programmieren. Mit entsprechendem Kleingeld kann man die meisten Projekte wohl recht angenehm auf sehr viele Plattformen (demnächst Android, iOS, PC, Mac usw.) deployen.

Haxe ist eine Programmiersprache, die in andere Programmiersprachen übersetzt werden kann. Dazu gibt es eine Flash ähnliche API. Wie gut HaXe funktioniert, weiß ich nicht, es gibt einige Fans...

GWT ist Programmieren in Java mit kompilieren nach javascript von Google. Diese Übersetzung ist dabei sehr optimiert (Browser abhängig usw.). GWT wird in großen Projekten eingesetzt, als Spiel wurde AFAIK bspw. der Chrome App Store Port von Angry Birds entwickelt. Das schöne ist, dass man auch ganz leicht direkt javascript im java code ansprechen kann. Nützlich ist der ganze Kram, weil man ggf. Java Klassen wiederverwenden, alles in einer Sprache programmieren kann und außerdem eine dicke API mit GUI Komponenten etc zur Verfügung steht. WebGL Quake2 ist auch mit GWT entstanden (so konnte man große Teile von der Java Variante übernehmen). Ich glaube kaum, dass man javascript Code per Hand besonders performanter hinbekommt. Ich habe mit GWT mal eine IMO wirklich performante Favoritenleiste für Chrome entwickelt (das ging wirklich gut) und kenne mehrere Programmierer/Projekte, die GWT begeistert einsetzen.

forplay ist soweit ich das verstehe ein Unterfangen von Google (oder zumindest einiger Google Mitarbeiter) das von GWT Gelernte auf andere Systeme für die Plattform unabhängige Entwicklung von Spielen zu übertragen. Das ganze ist aber AFAIK noch jünger als HaXe und deshalb wohl wirklich nicht für den Einstieg oder einen mittelfristigen Releasetermin zu empfehlen.

Serverseitig wird übrigens bei vielen Facebook Spielen auf PHP gesetzt. Das [url=http://www.rightscale.com/info_center/white-papers/social-gaming-in-the-cloud-technical.php]Whitepaper[/url] ist dazu vielleicht ganz interessant. Für GWT empfiehlt sich dabei aber eher ein Java EE Server, da Client-Server-Kommunikation so wirklich sehr reibungslos und transparent entwickelt werden kann.

Wenn du im Jump'n Run Sektor entwickeln willst, ist Flash IMO wirklich die beste Lösung. Spiele wie [url=http://www.glitch.com/]Glitch[/url] oder [url=http://www.facebook.com/MapleStoryAdventures]Maple Story Adventures[/url] laufen wirklich gut mit Flash und das sind gleich MMORPGs. Glitch hat mich dabei besonders in der Closed Beta überzeugt... Mit [url=http://flixel.org]Flixel[/url] oder z.B. [url=http://flashpunk.net]FlashPunk[/url] kannst du Oldschool Jump'n Runs im Nu erstellen.

[sfxon]

Okay. Das hat mir n gutes Stück weitergeholfen. Der Überblick ist jetzt viel besser.
Ich werde wohl bei Flash bleiben, da ich keine wirkliche Alternative sehe.
Kleinere Projekte werd ich sicherlich auch weiterhin in HTML5 und JavaScript umsetzen.

Sicher steckt in den Engines wie Flixel und FlashPunk einiges an Potential. Ich finde nur, das die Beispiel-Projekte auf deren Webseiten nicht gerade für diese Engines sprechen. Deswegen werde ich wohl so nah am System wie möglich arbeiten, auch wenn das am Anfang noch etwas mehr Arbeit bedeutet.
Ich weiß man soll das Rad nicht neu erfinden.. usw. Aber meine bisherigen Jobs haben mir gezeigt, das es zu 90% besser ist so wenig Bibliotheken zwischen sich und dem eigentlichen System zu verwenden. :D

[Chromanoid]

Naja Flixel (und wahrscheinlich auch FlashPunk) ist ziemlich nah am System/an der VM. Flixel nutzt das recht schnelle BitmapData Blitting von Flash aus, viel schneller sollte man das nicht hinbekommen können. Aber das lässt sich auch sehr leicht selbst machen. Es geht da ja im Grunde nur um eine Klasse (FlxSprite), die man nachbauen muss. Sound und Co. ist ebenfalls schnell selbst gemacht. Flixel bietet im Grunde einfach einen leichteren auf Oldschool Spiele spezialisierten Zugang zu Flash. Viel neu erfinden wirst du also sowieso nicht müssen. Wenn es um Physik geht, kann ich den AS3 Port von Box2D empfehlen. Es gibt auch eine C++ Variante, die mit Adobe Alchemy für die Flash VM kompiliert wurde. Die soll noch etwas schneller sein als die mit AS3 programmierte Version...