Warum wird Java nicht häufiger für die Spieleentwicklung eingesetzt? [geschlossen]

Ich bin kein Spieleentwickler oder so, aber ich weiß, dass Java für die Spieleentwicklung nicht sehr verbreitet ist. Java sollte für die meisten Spiele schnell genug sein. Wo ist also der Haken? Ich kann mir einige Gründe vorstellen:

• Mangel an Spielentwicklern mit Java-Kenntnissen
• Fehlende gute Spielentwicklungs-Frameworks
• Programmierer möchten Java nicht als Programmiersprache für Spiele akzeptieren. Akzeptieren die meisten nur C ++ als das?
• Keine Unterstützung für Spielekonsolen (obwohl der PC-Markt noch besteht)

Es könnte natürlich etwas anderes sein. Könnte jemand, der das Geschäft besser kennt als ich, erklären, warum Java bei der Spieleentwicklung nicht an Fahrt gewinnt?

Mehrere Gründe:

• Früher brauchten Sie "direkten Zugriff" für Leistung und Benutzeroberfläche. Dies ist älter als VM-Sprachen wie Java und C #.
• Die meisten Konsolen (z. B. 360, PS3) verfügen nicht über eine JVM, sodass Sie den Code aus der PC-Version nicht wiederverwenden können. Es ist viel einfacher, C ++ - Code zu kompilieren, um verschiedene Geräte zu unterstützen.
• Die meisten Mainstream-Spiele-Engines (z. B. Unreal) verfügen über C ++ - Bindungen. Es gibt einige Java-Konnektoren (zB für OpenGL), aber nichts Vergleichbares.
• Für PC-Spiele bietet DirectX (wenn überhaupt) keine starke Java-Unterstützung.
• Webbasierte Spiele laufen in JavaScript oder Flash. Sie könnten sie in Java schreiben, wenn Sie Dinge wie GWT verwenden.
• Auf dem iPhone läuft eine Objective-C-Variante.

Java wird heutzutage hauptsächlich in Android-Spielen verwendet, einfach weil es die Hauptsprache für diese Plattform ist.

Technische Gründe:

• Die meisten der besten 3D-Spiele-Engines sind in C / C ++ geschrieben. Dies ist eine große Sache, da die meisten Spieleentwickler keine Kompromisse bei ihrer 3D-Engine eingehen wollen, aber auch keine von Grund auf neu schreiben wollen. Java hat jMonkeyEngine, das Open Source ist und eigentlich wirklich gut, aber es kann noch nicht mit der Unreal Engine mithalten .
• In einigen sehr seltenen Situationen bietet es Vorteile, in C oder Assemblersprache "nah am Metall" zu sein , insbesondere für den Zugriff auf spezielle Hardwarefunktionen. Das ist heutzutage nicht so wichtig, aber professionelle Spieleentwickler möchten immer noch die Option haben .....
• Java hat eine müllsammelnde , verwaltete Laufzeit. In 99% der Fälle ist dies ein großer Vorteil, er macht das Codieren mit Sicherheit einfacher und weniger fehleranfällig und ist einer der Hauptgründe, warum Java so beliebt ist. Bei Spielen kann es jedoch gelegentlich zu Verzögerungen kommen, da Speicherbereinigungszyklen zu merklichen Pausen führen können. Dies wird bei den neueren JVMs mit niedriger Latenz immer weniger ein Problem sein, ist aber immer noch ein Problem bei grafisch intensiven Spielen, bei denen die Aufrechterhaltung einer hohen FPS von entscheidender Bedeutung ist.

Nichttechnische Gründe:

• Professionelle Spieleentwickler investieren viel in C / C ++ - Fähigkeiten und -Technologien. Dies erzeugt eine große Menge an Trägheit .
• Die weitgehend irrationale Wahrnehmung, dass Java langsam ist. Möglicherweise in den 90ern, jetzt definitiv nicht mehr - Sie können mit Java auf jeden Fall ein rentables, kommerzielles 3D-Spiel schreiben ( Runescape für jeden? Oder wie wäre es mit Minecraft ?)
• Eine ziemlich faire Vorstellung, dass Java sich mehr auf Geschäftsanwendungen und das Web konzentriert als auf Spiele. Dies könnte sich mit dem Wachstum von Mobile und der Notwendigkeit einer plattformübergreifenden Entwicklung ändern, ist aber derzeit sicherlich der Fall.

Interessanterweise gibt es auch einige gute Gründe, warum Spieleentwickler Java in Betracht ziehen sollten :

• Portabilität - Mit zunehmender Anzahl von Zielplattformen wird Java immer attraktiver, da es praktisch keine Plattform-übergreifenden Binärdateien mehr erstellen kann
• Bibliotheksökosystem - Mit Ausnahme der 3D-Game-Engines verfügt Java über das beste Bibliotheksangebot aller Plattformen. Networking, Sound, AI, Bildverarbeitung, Schlüssel- / Wertdatenspeicher, Sie nennen das Thema und es gibt wahrscheinlich eine Open-Source-Java-Bibliothek dafür.
• Serverseitige Entwicklung - Java ist eine großartige Sprache / Plattform für den Server, und da immer mehr Spiele Elemente für mehrere Spieler enthalten, wird die Serverseite immer wichtiger. Java unter Linux sieht hier als Plattform ziemlich überzeugend aus.
• Die JVM - ist wahrscheinlich die bestentwickelte VM-Ausführungsumgebung der Welt, mit fantastischer Garbage Collection, JIT-Compiler, Parallelitätsunterstützung usw. Sie wird nur noch besser und da Spieleentwickler zunehmend anfangen, dynamische Sprachen in ihren Spielen zu verwenden, werden sie es wollen die bestmögliche Laufzeitumgebung.
• Andere JVM-Sprachen - Java ist ein solides Arbeitstier, aber die eigentliche Innovation geschieht mit den neuen JVM-Sprachen (insbesondere Scala, Clojure). Diese Sprachen erhalten Sie alle Vorteile der Java / JVM - Plattform, und sie sind extrem leistungsfähig moderne Sprachen.

Okay, es gibt viele Fehlinformationen in diesem Thread.

Ich kenne das Spielegeschäft sehr gut, seit 25 Jahren. Ich kenne Java in Spielen auch sehr gut, da ich Suns technischer Evangelist für Java-Spiele und Dozent für Java-Performance-Programmierungsexperte war.

In Bezug auf die Rechengeschwindigkeit übertrifft Java C ++ heutzutage in vielen Benchmarks für wissenschaftliches Rechnen. Sie können pathologischen Code in jeder Sprache schreiben, die schlecht abschneidet, wenn Sie möchten, aber insgesamt sind sie gleichwertig und schon lange.

In Bezug auf die Speichernutzung hat Java einen gewissen Overhead. HelloWorld ist ein 4K-Programm in Java. In heutigen Multi-GB-Systemen ist dieser Aufwand jedoch ziemlich bedeutungslos. Schließlich hat Java mehr Startzeit. Ich würde nicht empfehlen, Java für kurze Laufzeitprogramme wie Unix-Kommandozeilenbefehle zu verwenden. In diesen Fällen dominiert das Starten Ihre Leistung. In einem Spiel ist es jedoch ziemlich unerheblich.

Bei ordnungsgemäß geschriebenem Java-Spielcode treten keine GC-Pausen auf. Genau wie C / C ++ - Code erfordert es eine aktive Speicherverwaltung, jedoch nicht auf der Ebene von C / C ++. Solange Sie Ihre Speichernutzung für langlebige Objekte (die für ein ganzes Level oder ein Spiel bestehen) und für sehr kurzlebige Objekte (Vektoren usw., die nach der Berechnung herumgereicht und schnell zerstört werden) beibehalten, sollte gc kein sichtbares Problem sein.

Bezüglich des direkten Speicherzugriffs hat Java dies für eine lange Zeit getan; seit Java 1.4 in Form von Native Direct Byte Buffers. Bit Twiddling in Java kann aufgrund des Fehlens von vorzeichenlosen Integer-Typen etwas ärgerlich sein, aber die Arbeitsrunden sind alle bekannt und nicht besonders lästig.

Während sein wahres Java noch nie eine Direct3D-Bindung hatte, ist dies darauf zurückzuführen, dass Java-Technologien Portabilität anstreben. Es verfügt über ZWEI OpenGL-Bindungen (JOGL und LWJGL) und OpenAL-Bindungen (JOAL) sowie eine portable Eingabebindung (JInput), die unter Windows an DirectInput, unter OSX an HID Manager und eine Linux-Bindung (ich vergesse welche) gebunden wird.

Es ist wahr, dass keine vollständige Game-Engine Java wie Unity unterstützt, und das ist eine Schwäche im unabhängigen Bereich. Auf der anderen Seite gab es zwei gute APIS auf Scenegraph-Ebene, die plattformunabhängig für Windows, OSX und Linux waren. Beide wurden von Josh Slack geschrieben, der erste hieß JMonkey Engine und der zweite Ardor3D.

Das Top-Poster zeigt, dass die beiden größten Hindernisse für Java bei der Spieleentwicklung Vorurteile und Portabilität waren. Letzteres war das größte Problem. Obwohl Sie ein Java-Spiel schreiben und es unter Windows, OSX und Linux ausliefern konnten, gab es nie eine Konsolen-VM. Dies war auf die völlige Unfähigkeit des Sun Middle Management zurückzuführen. Die wenigen von uns, die in Spielen an Java arbeiteten, hatten mindestens dreimal mit Sony zu tun, um eine VM auf einer Playstation zu bekommen, und alle dreimal, wenn das mittlere Sun-Management es tötete.

Während Sun mit Client-Technologien flirtete, war es eine Tatsache, dass das Sun-Management niemals Konsumgüter bekam. Das ist der Grund, warum Java als Client-Sprache von Sun in keiner Form erfolgreich war und warum Google und Dalvik (die Java-ähnliche Android-VM) erforderlich waren, um Java überall zu einer erfolgreichen Plattform zu machen.

Und deshalb programmiere ich heute Spiele in C #. Weil Mono dahin ging, wohin sich das Sun-Management geweigert hatte.

Java eignet sich hervorragend für Geschäftslogik, Server und plattformunabhängigen Code, der zuverlässig ausgeführt werden muss. Es gibt verschiedene Faktoren, warum Java in Spielen nicht oft verwendet wird:

• Grenzwertprüfung und andere Sicherheitsmechanismen (geringfügiger Leistungsunterschied in diesen Tagen)
• zwischen C ++ - und Java-Datenstrukturen konvertieren müssen (Speicher kann nicht einfach zwischen Puffern kopiert werden)
• Viele der Bücher und Tutorials folgen der Masse, so dass es schwierig ist, nicht-C ++ - Spieleentwicklerinformationen zu finden
• Die wichtigsten Grafikbibliotheken (DirectX und OpenGL) und viele Standard-Engines basieren auf C / C ++
• Viele Spiele versuchen, so schnell wie möglich zu laufen, damit sie optisch ansprechendere Funktionen hinzufügen können

Es ist nicht einfach, mit C ++ - Bibliotheken aus Bytecodesprachen wie Java (Schreiben einer JNI-Schicht) und .net (viele Marshalling- / Unmarshalling-, API- / Strukturattribute) zu arbeiten. Es ist also ein ziemlicher Arbeitsaufwand bei geringem Nutzen.

Eine Randnotiz: Einige Spieleserver verwenden Java.

Ein ähnlicher Beitrag ist hier zu finden : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java ist für die meisten Spieleentwicklungen nicht schnell genug. Es ist viel langsamer als die Verwendung von C ++ / Assembly, was der Standard ist. Es ist der gleiche Grund, warum mehr Spieleentwicklung nicht mit C # oder VB gemacht wird. Spieleentwickler benötigen und planen jeden letzten Taktzyklus, den sie für Aufgaben wie physikalische Berechnungen, KI-Logik und Interaktionen mit der Umgebung benötigen.

Für einfachere Spiele könnte Java sehr effektiv eingesetzt werden. Wenn Sie einen Tetris-Klon oder Bejeweled oder etwas anderes mit diesem Detaillierungsgrad erstellen möchten, funktioniert Java einwandfrei. Aber Java kann unmöglich Spiele wie Halo, Medal of Honor, Command & Conquer usw. erstellen und spielbar machen. Zumindest wie es heutzutage existiert.

Und die Gründe, die Sie in Ihrer Frage auflisten, sind ebenfalls gültig. Ausgenommen, ich denke, für den Mangel an Spieleentwicklern mit Java-Kenntnissen. Viele Spiele auf Handys und anderen tragbaren Geräten sind in Java geschrieben (einschließlich der meisten Android-Spiele), und einige der Spiele sind ausgezeichnet. Ich denke, es gibt eine anständige und wachsende Basis von Spieleentwicklern mit Java-Kenntnissen.

Der Gedanke ändert sich hinsichtlich der Fähigkeit, diese höheren Sprachen für einige der fortgeschritteneren Spiele zu verwenden. Zum Beispiel ist eines meiner Lieblingsspiele, Auran's Train Simulator, mit großen Teilen in C # geschrieben und es funktioniert ziemlich gut. Die Basis wächst also und wird sich weiterentwickeln.

In modernen Spielen dreht sich alles um 3D-Grafiken, die auf Spezialhardware ausgeführt werden.

Bereits im Jahr 2002 stellte Jacob Marner in seinem Bericht "Evaluating Java for Game Development" fest, dass Java mit Ausnahme der leistungsabhängigsten Teile durchaus für Spiele geeignet ist und aufgrund der Robustheit der Sprache und der zugrunde liegenden JVM billiger ist um es so zu machen.

http://java.coe.psu.ac.th/FreeOnline/Evaluating%20Java%20for%20Game%20Development.pdf

Ich persönlich bin der Meinung, dass dieser Nachteil mit den Fortschritten, die seitdem vor allem in der 3D-Grafik zu verzeichnen sind, und mit den hervorragenden Bindungen an OpenGL et al. Heutzutage viel weniger ausgeprägt ist.

Daher muss das Problem woanders liegen. Ein wahrscheinlicher Grund ist die Größe der Java-Laufzeit (die heutzutage bei Multi-DVD-Spielen weitaus weniger ein Problem darstellt) und ein anderer die Trägheit des vorhandenen Codes. Es ist bekanntermaßen spröde, mit nativem Code in Java zu arbeiten. Ein dritter Grund ist der, mit dem die Star-Entwickler, die die Spiele entwickeln, vertraut sind. Ein vierter ist, ob Java überhaupt auf der Plattform verfügbar ist.

Eines ist jedoch sicher: Die meisten Spiele werden skriptfähig, anstatt von Anfang an alles in C-Code zu brennen, und Sie möchten die beste Laufzeit unter Ihrer Skriptsprache. In diesen Tagen bedeutet dies im Wesentlichen entweder die CLR oder die JVM.

Spieleentwickler sind gerne nah am Metall und schreiben oft ihre engen inneren Schleifen beim Zusammenbau. Java bietet nicht die gleiche Leistung, sowohl was die Geschwindigkeit als auch die Speichernutzung betrifft.

Ich denke, der limitierende Faktor für die meisten Leute ist die (fehlende) Verfügbarkeit guter Game-Engines. Um weit zu kommen, müssen wir uns ansehen, warum diese nicht verfügbar sind.

Ich würde das für einen Moment aus der anderen Richtung betrachten. Das Entwickeln einer Game Engine (zum Beispiel) ist eine Menge Arbeit. Wer würde genug von der Entwicklung eines solchen Systems profitieren, um die Zeit und den Aufwand dafür zu investieren?

Die meisten offensichtlichen Kandidaten für eine Framework-ähnliche Entwicklung in / für Java (z. B. IBM, Oracle) scheinen kein Interesse an Spielen zu haben. Die offensichtlichen Kandidaten für die Spieleentwicklung (z. B. Id, EA) scheinen fast ebenso wenig Interesse an Java zu haben.

Fast der einzige Kandidat, an den ich denken kann, scheint überhaupt vernünftig, wäre Google. Die primäre Entwicklungssprache für Android ist Java, und die Förderung der Spieleentwicklung für Android könnte der Plattform einen echten Vorteil verschaffen.

Soweit ich weiß, haben sie dies (noch?) Nicht getan, was für fast alle anderen ziemlich strenge Grenzen lässt. Die Verwendung von Java für moderne, leistungsstarke Spiele-Engines ist mit einem erheblichen Mehraufwand verbunden, mit (meiner Meinung nach) geringen Aussichten, im Gegenzug für diese Mehrarbeit eine Menge Vorteile zu erzielen.

Die Frage ist gleichbedeutend mit folgenden Fragen:

Was ist besser, um Ihr Auto, ein Bootsmotor oder ein Düsentriebwerk anzutreiben?

Es kommt auf Skalierbarkeit, Fehlervermeidung, Geschwindigkeit, Speichersignatur, Modularität und eine ganze Reihe von Dingen an. Die Frage sollte nicht sein, was als Industriestandard besser ist, sondern "was ist besser für mich", wie in dem, was Sie wissen oder wie gut Sie es wissen. Wenn es den Job macht, dann macht es den Job, wenn Sie die Idee tatsächlich verkaufen können, dann funktioniert es und wer weiß, Sie könnten sogar ein paar Löffel biegen.

Java wurde nicht für die Spieleentwicklung entwickelt, Java wurde als Sprache "für das Web" konzipiert.

Bei der Spieleentwicklung hat Sun Java als Spieleentwicklungssprache nicht wirklich unterstützt, da Microsoft C # unterstützt.

Ich denke, das Fehlen überzeugender Frameworks für die Spieleentwicklung hat Java in dieser Hinsicht wirklich umgebracht.

Es ist einfacher, C direkter auf brandneue, unkonventionelle Hardware und Treiber zu kleben. Je früher und näher ein Spielprogrammierer an die Hardware herankommt, desto besser kann er konkurrierende Spiele übertreffen. Spätere Spielprogrammierer bleiben bei der gleichen Methodik und den gleichen Werkzeugen wie die zuvor erprobten Spiele.

Bei Spielen, bei denen die Optimierung auf die neueste Hardware weniger wichtig ist, wie beispielsweise bei Gelegenheitsspielen für Mobiltelefone, ist die Verwendung von C auf diese Weise weniger wichtig als die größere Portabilität von Java.

Für manche Menschen hat Grund nichts mit Geschwindigkeit, Bibliotheken oder Verfügbarkeit zu tun. Es liegt einfach an der Sprache selbst. Manche Leute mögen Java einfach nicht. Andere verwenden lieber ihre Lieblingsprogrammiersprache als Java, um Spiele zu erstellen.

Es könnte natürlich etwas anderes sein. Könnte jemand, der das Geschäft besser kennt als ich, erklären, warum Java bei der Spieleentwicklung nicht an Fahrt gewinnt?

Es ist eine interpretierende Sprache, dh langsam. Sie haben es mit Grafik und Grafikkarte zu tun, die Hardware sind. Was ist eine gute Sprache für den Umgang mit Hardware? Nun, C ++ ist ziemlich niedrig und Sie beschäftigen sich mit Zeigern und was auch immer.

Wenn Sie verrückte Grafiken wie Crysis und was auch immer herauspumpen möchten, werden Sie Java dafür nicht tun.

Nicht nur das, Oracle besitzt Java, der Gedanke, dass ein Unternehmen Sie verklagen kann, ist nicht gut. Vor allem, wenn Sie einen eigenen Interpreten für JAVA erstellen möchten, der auf Spiele abzielt, ohne wegen Fragmentierung von FUD zu klagen.