spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Es ist sehr traurig, dass iOS kein natives Java unterstützt. Das ist ja im Grunde fast ausschließlich aus lizenzrechtlichen Gründen so. Ich arbeite deshalb momentan mit Adobe AIR und bin sehr angetan.

Ich finde euer Ziel super und wünsche euch viel Erfolg. Ich habe mir auch schon öfter mal den Kopf zerbrochen, wie man Java vernünftig auf iOS bekommt.

Bisher läuft die Unterstützung in libGDX ja über Xamarin.iOS (nicht Alpha, aber ich kenne den Stand der Technik bei libGDX nicht).
Wenn ihr da selbst Hand anlegen wollt, wäre evt. auch https://code.google.com/p/j2objc/ (GWT Java zu iOS Translator von Google) einen Blick wert.

Java als Ausgangsbasis für ein Cross-Platform Framework zu verwenden, halte ich persönlich für keine gute Idee. Im Speziellen hat man bereits ein Problem bei iOS, ganz allgemein kommen noch die nicht vollständig standardkonformen Implementierungen von Java hinzu (z.B. Dalvik). LibGDX war ursprünglich für Android gedacht und das ist auch nicht zu übersehen. Diese ursprüngliche Fixierung auf Android hat nun ihre Konsequenzen. Warum nicht den umgekehrten Weg gehen? Anstatt auf allen Nicht-Androids eine VM mitzuliefern, damit der Java-Code läuft, wäre es besser, mithilfe des NDKs auf Android nativen Code ausführen (z.B. C++).

Zitat von »buzz-steve«

Java als Ausgangsbasis für ein Cross-Platform Framework zu verwenden, halte ich persönlich für keine gute Idee. Im Speziellen hat man bereits ein Problem bei iOS, ganz allgemein kommen noch die nicht vollständig standardkonformen Implementierungen von Java hinzu (z.B. Dalvik). LibGDX war ursprünglich für Android gedacht und das ist auch nicht zu übersehen. Diese ursprüngliche Fixierung auf Android hat nun ihre Konsequenzen. Warum nicht den umgekehrten Weg gehen? Anstatt auf allen Nicht-Androids eine VM mitzuliefern, damit der Java-Code läuft, wäre es besser, mithilfe des NDKs auf Android nativen Code ausführen (z.B. C++).

Auf das Problem mit iOS wurde bereits eingegangen. Ob die Abweichung vom "standardkonform" überhaupt relevant ist, kommt auf die Stärke der Abweichung an. Unter Mono dürfte mir Console.Beep() immernoch nicht den gewünschten Effekt liefertn, mal ganz abgesehen von WPF.
Anscheinend kennst du konkrete Fälle, in denen Dalvik nicht kompatibel mit dem Standard ist und in denen man die Nachwirkungen der Android-Fixierung im Falle der LibGDX spürt. Ich kenne diese nicht (und um ehrlich zu sein möchte ich mich nicht erst auf eine ewige Suche begeben, bei der nicht sicher ist, ob ich überhaupt das Richtige finde). Es wäre also ganz gut, wenn du zumindest ein paar Anhaltspunkte liefern könntest, damit andere ein paar (bessere) Suchbegriffe haben, die sie dann verwenden könnten.

C++ als Alternative zu nennen finde ich allerdings nicht besonders gut. Es hätte zwar den Vorteil, dass auf anderen Geräten keine VM notwendig wäre, allerdings wären die Nutzer der Engine dann dazu gezwungen, C++ und dessen Eigenheiten zu nutzen. Dazu gehört beispielsweise, dass man für jede Plattform exportieren müsste, was heißt, dass man für jede Plattform den Compiler bei sich auf dem Rechner haben muss und ggf. noch weitere notwendigen Tools. So wäre es möglich, dass die Engine ein Tool mitliefert, welches die Paketierung nach dem Kompilieren für die gewünschte Plattform übernimmt (der ggf. notwendige Code, um den Javacode auf der jeweiligen Plattform zu starten, dürfte unabhängig vom Java-Bytecode sein und müsste deswegen nicht jedes Mal neu gebaut werden.)
Wichtig in dem Zusammenhang wäre aber auch zu wissen, welche Beweggründe es seitens des Threaderstellers für Java gab.

Zitat

Anscheinend kennst du konkrete Fälle, in denen Dalvik nicht kompatibel mit dem Standard ist und in denen man die Nachwirkungen der Android-Fixierung im Falle der LibGDX spürt.

Dass Dalvik nicht gleich Java SE/EE ist, ist ein ganz anderes Problem als das, was ich damit eigentlich ansprechen wollte. Meine Zeit mit LibGDX liegt 2-3 Jahre zurück, damals war es noch Android-only. Da die Crossplatform-Capability aber nicht von Anfang an berücksichtigt wurde, musste sie quasi dazugefrickelt werden, im Falle iOS mit einem externen Framework (Xamarin). Das sind bereits 2 Abhängigkeiten, die man in fremde Hände legt. Windows RT scheint überhaupt noch nicht unterstützt zu sein. Bzgl Dalvik: Diese VM hat stellenweise ganz eigene APIs, die in Java nicht vorkommen (diverse Container-Klassen und natürlich die plattform-spezifischen), umgekehrt fehlt u.a. AWT mitsamt allen Utility Klassen (z.B. Point2D). Wer seine Apps primär für Android schreibt und das nicht berücksichtigt, wird bei der Portierung mit einigen ClassNotFoundExceptions zu kämpfen haben. Aber das sind eigentlich Kleinigkeiten. Zu RoboVM: Wer garantiert mir, dass der generierte Code zuverlässig funktioniert? Die Probleme bei der Portierung beginnen ja bereits bei den unterschiedlichen Compilern.

Zitat

C++ als Alternative zu nennen finde ich allerdings nicht besonders gut. Es hätte zwar den Vorteil, dass auf anderen Geräten keine VM notwendig wäre, allerdings wären die Nutzer der Engine dann dazu gezwungen, C++ und dessen Eigenheiten zu nutzen.

Das ist für mich kein Argument, weil jede Programmiersprache ihre Eigenheiten hat, mit denen man leben muss. C++-Code ist nicht per se hässlich, wenn du das meinst. Er wird es erst durch Programmierer in Coding-Rage.

Zitat

Dazu gehört beispielsweise, dass man für jede Plattform exportieren müsste, was heißt, dass man für jede Plattform den Compiler bei sich auf dem Rechner haben muss und ggf. noch weitere notwendigen Tools. So wäre es möglich, dass die Engine ein Tool mitliefert, welches die Paketierung nach dem Kompilieren für die gewünschte Plattform übernimmt (der ggf. notwendige Code, um den Javacode auf der jeweiligen Plattform zu starten, dürfte unabhängig vom Java-Bytecode sein und müsste deswegen nicht jedes Mal neu gebaut werden.)

Das muss man sowieso. iOS-Apps lassen sich nur mit Xcode erstellen, Windows RT Apps nur mit Visual Studio (ohne das jetzt bestätigen zu können). Für Android braucht man die ADT. Ein Game-Studio hat deshalb auch alle Betriebssysteme im Haus versammelt, das sind Peanuts in der Anschaffung. Typischerweise verwendet man PCs mit Windows (Linux als Zweitsystem) mit einem Mac mini als Build-Rechner. Bei uns in der Firma ist es umgekehrt: Wir haben einen Windows-Build-Rechner und arbeiten selbst auf iMacs. Wenn man sich mit einem JAR-Bundle für die Desktop-Betriebssysteme zufrieden gibt, dann stimmt der Einwand natürlich. Aber wenn man heutzutage von Cross-Platform spricht, dann lassen sich die mobilen Plattformen kaum mehr ignorieren. Welche Tools den Build-Prozess dann schließlich erleichtern, hängt mehr vom Umfang der Engine selbst ab.

Zitat

Wichtig in dem Zusammenhang wäre aber auch zu wissen, welche Beweggründe es seitens des Threaderstellers für Java gab.

Wenn ich das richtig verstanden habe, dann war der Grund für Java die Tatsache, dass LibGDX (als Basis der Engine) darauf basiert. In diesem Fall führt wahrscheinlich auch kein Weg mehr dran vorbei.

Zitat von »buzz-steve«

Zitat

Anscheinend kennst du konkrete Fälle, in denen Dalvik nicht kompatibel mit dem Standard ist und in denen man die Nachwirkungen der Android-Fixierung im Falle der LibGDX spürt.

Dass Dalvik nicht gleich Java SE/EE ist, ist ein ganz anderes Problem als das, was ich damit eigentlich ansprechen wollte. Meine Zeit mit LibGDX liegt 2-3 Jahre zurück, damals war es noch Android-only. Da die Crossplatform-Capability aber nicht von Anfang an berücksichtigt wurde, musste sie quasi dazugefrickelt werden, im Falle iOS mit einem externen Framework (Xamarin). Das sind bereits 2 Abhängigkeiten, die man in fremde Hände legt. Windows RT scheint überhaupt noch nicht unterstützt zu sein. Bzgl Dalvik: Diese VM hat stellenweise ganz eigene APIs, die in Java nicht vorkommen (diverse Container-Klassen und natürlich die plattform-spezifischen), umgekehrt fehlt u.a. AWT mitsamt allen Utility Klassen (z.B. Point2D). Wer seine Apps primär für Android schreibt und das nicht berücksichtigt, wird bei der Portierung mit einigen ClassNotFoundExceptions zu kämpfen haben. Aber das sind eigentlich Kleinigkeiten. Zu RoboVM: Wer garantiert mir, dass der generierte Code zuverlässig funktioniert? Die Probleme bei der Portierung beginnen ja bereits bei den unterschiedlichen Compilern.

Das würde ich nicht unbedingt (direkt) der virtuellen Maschine zuschreiben, aber es ist tatsächlich ein Punkt, auf den man achten muss, wenn man Plattformunabhängig entwickeln will. Ich weiß nicht, in wie weit LibGDX auf entsprechenden Klassen aufbaut, aber wenn es ausreichend unabhängig davon ist, dann dürfte das keine größeren Probleme mit sich bringen. Andernfalls müsste man diese Klassen selbst schreiben, aus der Quelle extrahieren und der Engine hinzufügen oder LibGDX so stark abstrahieren, dass der Nutzer der Engine gar nicht mit solchen Klassen in Kontakt kommt.
Es sind also berechtigte Einwände, die sich aber durchaus handhaben lassen.

Zitat von »buzz-steve«

Zitat

Dazu gehört beispielsweise, dass man für jede Plattform exportieren müsste, was heißt, dass man für jede Plattform den Compiler bei sich auf dem Rechner haben muss und ggf. noch weitere notwendigen Tools. So wäre es möglich, dass die Engine ein Tool mitliefert, welches die Paketierung nach dem Kompilieren für die gewünschte Plattform übernimmt (der ggf. notwendige Code, um den Javacode auf der jeweiligen Plattform zu starten, dürfte unabhängig vom Java-Bytecode sein und müsste deswegen nicht jedes Mal neu gebaut werden.)

Das muss man sowieso. iOS-Apps lassen sich nur mit Xcode erstellen, Windows RT Apps nur mit Visual Studio (ohne das jetzt bestätigen zu können). Für Android braucht man die ADT. Ein Game-Studio hat deshalb auch alle Betriebssysteme im Haus versammelt, das sind Peanuts in der Anschaffung. Typischerweise verwendet man PCs mit Windows (Linux als Zweitsystem) mit einem Mac mini als Build-Rechner. Bei uns in der Firma ist es umgekehrt: Wir haben einen Windows-Build-Rechner und arbeiten selbst auf iMacs. Wenn man sich mit einem JAR-Bundle für die Desktop-Betriebssysteme zufrieden gibt, dann stimmt der Einwand natürlich. Aber wenn man heutzutage von Cross-Platform spricht, dann lassen sich die mobilen Plattformen kaum mehr ignorieren. Welche Tools den Build-Prozess dann schließlich erleichtern, hängt mehr vom Umfang der Engine selbst ab.

Mein Hintergedanke dabei war, dass der eigentliche Code, der auf dem jeweiligen System ausgeführt wird und die VM startet, bereits in kompilierter Form vorliegt und man dieses Paket nur noch um die "Nutzdaten" (den Java-Bytecode) ergänzen muss. bei iOS weiß ich nicht, ob evtl. eine Verschlüsselung/Signierung der Apps durchgeführt werden muss oder ob es andere Gründe dafür gibt, dass man an entsprechenden Tools (XCode) nicht vorbei kommt, allerdings werden Windows 8 Apps (und sehr wahrscheinlich auch Windows Phone 8 Apps) signiert und für diese wäre dann wohl die Verwendung des entsprechenden Tools erforderlich (evtl. reicht das Tool, welches im Hintergrund von Visual Studio verwendet wird). Bei Andriod und den Desktop-Systemen sehe ich aber keine größeren Probleme.
Aber es stimmt, man wird um separate Tools für diverse Plattformen nicht gänzlich drumrum kommen. Dennoch wäre es so aber besser, als für ausnahmslos jede Plattform auch noch ein separates Tools installieren zu müssen (bzw. auf der jeweiligen Plattform bauen zu müssen).

Zitat von »buzz-steve«

Zitat

Wichtig in dem Zusammenhang wäre aber auch zu wissen, welche Beweggründe es seitens des Threaderstellers für Java gab.

Wenn ich das richtig verstanden habe, dann war der Grund für Java die Tatsache, dass LibGDX (als Basis der Engine) darauf basiert. In diesem Fall führt wahrscheinlich auch kein Weg mehr dran vorbei.

Und vielleicht gab es ja noch einen anderen Grund...
Aber zumindest würde das Alleinstellungsmerkmal bleiben: eine Crossplattform-Engine auf Java-Basis.

@Sacaldur: Das gleiche "Build" nutzen, kann man bei Cross-Plattform vergessen, alleine schon vom Deployment her. Die Frage ist einfach in welcher Sprache man programmieren will. Ich sehe bei Java vor allem große Vorteile für Spiele, die einen Server benötigen (gemeinsamer Code für Server und Client) oder natürlich für Entwickler, die gerne in Java programmieren. Ein Cross-Plattform-Framework lässt sich über C++ sicher recht gut entwicklen (ein eigenes Plugin, Adobe Alchemy oder Emscripten könnten für den Browser als Plattform herhalten). Fertige Lösungen wie Flash/AIR oder Haxe wären aus meiner Sicht allerdings die erste Anlaufstelle.

@buzz-steve: Cross-platform mit Java ist natürlich nur dann sinnvoll, wenn man eine gemeinsame Bibliothek für alle Plattformen zur Verfügung hat. Und genau da setzen ja libGDX und dieses Projekt an. Genau das würde man sich ja auch für die C++ Cross-platform Entwicklung basteln. Wenn man also Programmieren in Java als Voraussetzung nimmt, dann bleibt einem ja gar nichts anderes übrig als robovm & Co. auszuprobieren. Dass für viele Entwickler für Java ein Bedarf nach Cross-Platform-Frameworks besteht, zeigt ja auch Google mit seinen Projekten zur Übersetzung von Java nach JavaScript oder Objective-C. Auch das PlayN-Projekt versucht ja das, was hier angegangen werden soll.

Zitat von »Chromanoid«

Die Frage ist einfach in welcher Sprache man programmieren will.

Ich denke nicht, dass das die wichtigste Frage ist, sondern eher: "Wie kann ich für möglichst viele Platformen entwicklen ohne dabei Mehraufwand zu verursachen?"
Ich habe da erst kürzlich mich intensiv mit dieser Frage beschäftigen dürfen und muss sagen, bis auf Qt5.1, das leider auch noch Schwächen im Workflow hat, war nichts überzeugend. Entweder ist die Programmierung und das Debugging umständlich bis masochistisch (HTML5,JS,CSS in PhoneGAP und IBM Worklight / Adobe Flex) oder aber man hat den doppelten Aufwand bei der Gestaltung und Programmierung der Benutzeroberfläche (Xamarin, RoboVM). Letzteres gilt dann natürlich nicht mehr, wenn die Oberfläche eh nur aus einem FullScreen OpenGLES-Screen besteht. Als Fazit bleibt für mich nur die Hoffnung auf Qt5.2 und dass es hält was es für iOS verspricht.

P.S.: Sorry wenn ich etwas Offtopic gepostet habe.