Gestern berichtete JAXenter über die Google API Challenge, in der bei den eingereichten Tron-Implementierungen auffallend wenige Java-Versionen vertreten waren.
Ob dies nun – wie einige Kommentatoren anmerkten - der größeren Erfahrung von C++-Programmierern im Spielebereich geschuldet ist oder der unvollständigen JVM-Unterstützung durch das bereitgestellt Starterpaket - oder vielleicht gar den lokalen Sprachgeschmäckern (in den deutschen Charts scheinen die Java-Versionen besser abzuschneiden), sei einmal dahin gestellt.
Fakt ist, dass Java nicht die typische Sprache ist, in der heute groß angelegte professionelle Spiele programmiert werden (gemeint ist natürlich nicht der Mobile-Bereich…). Weshalb dies so ist, wird auf dem Blog Catnap Lab diskutiert.
Zwei mögliche Gründe zählt der Blogger auf:
- Die mangelnde Verfügbarkeit der Java-Runtime. Nur das Mac OS X komme mit einem vorinstallierten Java daher, der Windows-Installer für Java sei furchtbar, etwa wegen des mitinstallierten und nervenden Update-Checkers. Auf Konsolen wie XBox oder Playstation wird Java ohnehin nicht unterstützt.
- Keine der Java IDEs sei in der Lage, ein fertig auslieferbares Programmpaket für eine bestimmte Plattform zu generieren – man erhalte immer nur Jars. Um Dinge wie Build-Skripts, Exe-Launcher, Programm-Icons etc. müsse man sich alleine kümmern – und dies koste viel Zeit.
Lösungsvorschlag:
Java auf Windows-Plattformen erträglich machen.
This could be partially remedied by making a silent, non-intrusive Java installer for Windows.
Lösungsvorschlag:
IDE-Plug-ins für die Spiele-Entwicklung bereitstellen.
This could be fixed by adding functionality (possibly in the form of an IDE plugin) for making a NSIS installer / Mac app bundle / a Linux RPM/DEB package with the JAR and the associated game assets included.
Weitere mögliche Gründe für die Zurückhaltung der Spieleindustrie bei Java werden in den Reddit-Kommentaren zu dem Blogposting diskutiert:
Kommentator "Innervision" sieht das Hauptproblem etwa darin, dass die Entwicklerteams im Gaming-Bereich traditionell aus der C/C++-Ecke stammen. Dabei sei der Aufwand für das Schreiben von 3D-Code in C/C++ und Java in etwa derselbe. Wenn Java also hier keine massiven Vorteile biete, warum sollte eine Firma die bewährten Entwicklungsgewohnheiten über Bord werfen und plötzlich Java-Teams einstellen?
Aber vielleicht gibt es ja doch gute Gründe dafür, Spiele in Java zu entwickeln?
Kommentare
Der Vorteil liegt auf der Hand: Java wird auf einer VM interpretiert, das ist aus Performance sicht ziemlich schrecklich und ich denke, das ist der Hauptgrund, warum Java für die Entwicklung von Spielen kaum relevant ist.
@raksch, Punkt zwei ist wirklich an den Haaren herbeigezogen. Mein erster Gedanke: "lol!" :D #zitieren
About Catnap Lab
Catnap Lab = Tomas Andrle, Prague, Czech republic. Making games.
Ist es so, dass die "Spieleindustrie http://www.catnapgames.com" hat bisher alle (Type Raiders) Spiel(e) in Java programmiert hat und bisher noch nie einen (Java-) Programmierer einstellen konnte? #zitieren
Wen das schreckt, der kann trotzdem beruhigt schlafen:
Java kann auch "Ahead of Time" kompiliert werden (Excelsior JET).
Eigene Launcher für jede Plattform kann man in den Build-Prozess integrieren, das macht man exakt einmal, dank Continuous Integration kann dieser Build auch automatisiert ablaufen (Ant oder Maven mit Hudson oder CruiseControl), inklusive Testsuites, etc..
Das Spielestudio, was vor vielleicht ein oder zwei Tagen Aufwand Angst hat möchte ich sehen.
Eine kompatible JVM kann, darf und sollte man in dem Fall, auch mitliefern. statt sich auf das Vorhandensein einer JRE zu verlassen. Keine Installation notwendig! Der 3D-Shooter "Chrome" macht das z.B. so, er ist teilweise in Java implementiert.
Wrapper für OpenGL und Direct3D existieren, eine eigene Schnittstelle dahin kann man per JNI selbst anbinden.
Die Geschwindigkeit ist ein sekundäres Problem, auch wenn man in der Spielebrache gerne um einzelne fps feilt, betrifft dies längst nicht jedes Spiel.
Bis dahin gibt es also keine echten Hindernisse.
Das einzige was IMO gegen die Java-Entwicklung von Spielen sprechen könnte ist dass man, wenn man bei der Speicherverwaltung nicht aufpasst, Probleme mit dem unberechenbaren Timing des Garbage-Collectors bekommen kann. "Stop the world" Collections mag man bei Spielen nicht. Der G1-Collector kann hier bestimmt für etwas Abhilfe sorgen.
Ich denke es liegt in der Tradition und Ausbildung der Branche, welche nun mal C/C++-zentrisch ist und in den bereits existierenden Libraries, welche in diesen Sprachen verfasst wurden. #zitieren
BTW2: Schaut euch die jMonkey Engine (http://jmonkeyengine.com/) an, wenn ihr darüber nachdenken solltet ein eigenes Spiel zu programmieren. #zitieren
Java hat auch längst das Performance-Problem, das es anfangs sicherlich hatte, gelöst - und mit Performance Tuning Tools wird alles noch schneller: http://javaperformancetuning.com/
Allerdings stimmt das IDE-Argument: Kennt ihr ein Eclipse oder NetBeans, das auf die Spieleprogrammierung zugeschnitten ist? Wieso sollten die C-Leute sich mit einem langsamen Eclipse rumquälen? #zitieren
Gab auch einen Contest mit Sourcecode:
http://slick.cokeandcode.com/wiki/doku.php?id=open_source_games #zitieren
Wenn man wirklich will dass es nur noch Java geben soll muss man diese Entwicklung wieder einholen. (Will man das?) Ein Weg wäre die bessere Entwicklungs-Umgebung, APIs, Docs, etc.
Aber warum sollte man das tun ?
Ich kenne eine Menge Leute die früher in in C++ entwickelt haben und jetzt Java nutzen, und dass mittlerweile auch sehr gern, aber ein paar von dieses Leuten sind auch wieder zurück, einige zu Objective C, weil sie dort noch näher an der Hardware sind (Maschinensteuerungen, etc.)
Wenn ich diese Leute treffe gibt es keinen der fragt, warum diese Sprache, und nicht diese.
Jeder arbeitet in mit der Sprache, mit der er am schnellsten und besten realisieren kann. #zitieren