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

77

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?

java game-development Anto
quelle
37
Und jetzt warten Sie, bis alle "Java ist langsam, C ++ ist schnell" -Antworten, die wirklich nur die Oberfläche des Problems in einer allzu breiten und vollständig korrekten Weise berühren. Beachten Sie, dass die Leute, die auf diese Weise antworten, mit ziemlicher Sicherheit keine professionellen Spieleentwickler sind.
Ed S.
20
In der Tat, Java ist für die Entwicklung von Spielen verwendet wird ; dh im mobilen Markt. Java ME, Android.
user281377
21
Warum sollte es verwendet werden? Was bietet Java einem Spieleentwickler, das die verbreiteten Sprachen nicht haben? Java bietet Geschäftsanwendungsentwicklern ein enorm umfangreiches Ökosystem, das die Sprachmängel überwiegt. Bei der Spieleentwicklung bietet die Java-Plattform jedoch nur wenige Tools im Vergleich zu einer Reihe von Alternativen.
back2dos
14
Interessanterweise basiert Minecraft auf Java.
Uri
5
@Coder Anscheinend wurde der C ++ - Code stark optimiert, der Java-Code jedoch nicht. Es ist also ein ungültiger Vergleich.
Izkata,

Antworten:

94

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.

Uri
quelle
14
+1 "Die meisten Konsolen (z. B. 360, PS3) haben keine 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." Wenn das Gerät nicht über die Laufzeit verfügt , Sie werden keine Spiele sehen, die auf der Basis dieser nicht verfügbaren Laufzeit entwickelt wurden. Xbox 360 und Windows Phone haben .Net-Laufzeiten verwaltet, so dass die Entwicklung von Spielen mit ihnen möglich ist und der Trend wahrscheinlich zunimmt. Da die Laufzeit jedoch nicht auf den anderen Hauptplattformen (PS3 und in viel geringerem Maße Wii) läuft, ist es schwierig, eine vollständig separate Codebasis zu rechtfertigen. Es ist wirklich überhaupt kein Leistungsproblem.
JustinC
2
Es heißt XNA und ist derzeit eine Teilmenge des .Net 2.0-Frameworks. Es gibt einige andere interessante Frameworks in freier Wildbahn: MonoXNA, MonoTouch und XnaTouch unter anderem.
JustinC
7
Eine Vorhersagbarkeit der Leistung ist mit einer JVM nicht möglich.
Klaim
5
Sehr gute Punkte. Ich möchte jedoch hinzufügen, dass der GC unvorhersehbare Pausen / Belastungen verursachen kann. Wenn dies für Server-Apps kein Problem ist, ist es für ein Echtzeitspiel. Dies ist zum Beispiel in Minecraft sichtbar.
Deadalnix
2
@Klaim Es ist auch nicht mit mallocoder möglich. newWenn Sie also Bedenken haben, werden Sie Pooling implementieren, egal was passiert . Unabhängig davon besteht ein großes Problem bei Java darin, dass es im Gegensatz zu C # keine Wertetypen unterstützt.
Doval
80

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.
mikera
quelle
19
Nein, die Java-Sicherheit in der Videospielwelt ist nicht besser. Die meisten Konsolen haben keine JVM. Aus Gründen der Portabilität wird C ++ in der Videospielwelt Java vorgezogen.
Deadalnix
5
Warum ist das Bibliotheksökosystem ein Bonus für Java? Networking, Sound, Schlüssel-Wert-Paare - das ist keine Sache; das gibt es heutzutage überall. Eigentlich würde ich argumentieren, dass AI und Bildverarbeitung mit C / C ++ - Bibliotheken (fann, OpenCV) viel einfacher sind.
MrFox
4
Wichtiger als FPS würde ich vielleicht konsistente Frameraten betonen . Ich kann mein Spiel mit 100 fps laufen lassen, aber wenn einige dieser Frames eine halbe Sekunde dauern, reicht das einfach nicht aus. Selbst wenn die GC schnell ist, ist sie immer noch ein Problem, wenn sie spürbare Unregelmäßigkeiten verursacht. (Dies sagt nichts über Javas Leistung aus, nur ein allgemeines Problem, an das man denken sollte)
Gankro
1
Ich habe einen Ego-Shooter in Java geschrieben und hatte nie Probleme mit dem Garbage Collector, auch wenn ich keinen mit geringer Latenz verwendet habe. Wie auch immer, wenn der Speicher nicht auf dem Java-Heap zugewiesen ist, liegt es an mir, ohne den Garbage Collector damit umzugehen, und der größte Teil meines Speicherbedarfs stammt von den VBOs. Mit anderen Worten, die Garbage Collection ist kein Problem, da sie funktioniert, wenn sie für den Zweck verwendet wird, für den sie entwickelt wurde, und nicht für die Verarbeitung großer Objekte auf der GPU oder auf dem nativen Heap (! = Java-Heap). Machen Sie einen Amboss nicht dafür verantwortlich, dass er nicht gut zum Zähneputzen geeignet ist.
Gouessej
1
@deadalnix Die Videospielwelt besteht nicht nur aus den Konsolen.
Gouessej
27

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.

user430788
quelle
8

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

Graeme Wicksted
quelle
Sie müssen JNI nicht selbst schreiben, sondern verwenden JogAmp oder eine ähnliche Bibliothek.
Gouessej
Guter Punkt. Ich habe JOGL und JMonkeyEngine in Java verwendet. Weitere Neuigkeiten in Ich habe XNA / MonoGame für DirectX und OpenTK für OpenGL mit nvorbis / naudio / openal in C # verwendet. Und sie eignen sich hervorragend für kleine bis mittelgroße Spiele, insbesondere wenn Sie mit Shadern arbeiten. Große Produktivitätsverbesserung gegenüber C ++. Dann ist Ihr einziges wirkliches Problem dasselbe wie bei jeder GC-basierten Sprache: Verhindern / Verringern des GC. Die Framerate wird in regelmäßigen Abständen verzögert, sodass Sie Arrays mit fester Größe, statische Zuordnungen oder langlebige Puffer benötigen, die geworfen werden können, wenn das Gameplay verzögert wird (Menüs, Laden, Filmsequenzen).
Graeme Wicksted
Ich benutze JOGL seit 2006 und hatte diese Art von Problem nicht einmal auf sehr Low-End-Hardware in einer Desktop-Umgebung. Der Garbage Collector ist nicht schuld, da sich die größten Objekte häufig entweder im GPU-RAM oder im nativen Heap befinden (normalerweise in den direkten NIO-Puffern). Ersteres wird nicht von der "normalen" Garbage Collection verwaltet und Letzteres nicht. Es wird direkt von der "normalen" Garbage Collection verwaltet, da es Java-Objekte auf dem Java-Heap verwaltet. Es ist Sache des Entwicklers, den auf dem nativen Heap zugewiesenen Speicher effizient freizugeben.
Gouessej
Meiner bescheidenen Meinung nach ist das Problem eher auf einige "Optimierungen" zurückzuführen, die sich Programmierer vorgestellt haben, die keine Java-Einstellung haben und die den Garbage Collector daran hindern, seine Arbeit zu erledigen. Wenn Sie starke Verweise auf nutzlose Java-Objekte beibehalten, die mit nativen Ressourcen verknüpft sind, werden sie vom Garbage Collector niemals als zurückforderbar eingestuft. Die Zuordnung außerhalb des Heapspeichers kann in einigen Fällen hilfreich sein. Wenn Sie sie jedoch missbrauchen, bleiben Ihre langlebigen Ressourcen im Speicher und Sie können keine neuen Objekte erstellen.
Gouessej
Einige Spieleprogrammierer bevorzugen es, zu Beginn große Puffer zuzuweisen, diese zur Laufzeit aufzuteilen und diesen Speicher selbst zu verwalten, aber sie werden es wahrscheinlich noch schlimmer machen, wenn das Betriebssystem und dann Java viel Zeit aufwenden, um Speicherplatz für die Erstellung neuer Objekte freizugeben. Das Vermeiden von Speicherverlusten ist in Java nicht schwieriger und eine praktikablere Lösung besteht darin, nur die Objekte zu verfolgen, deren Speicher nicht auf dem Java-Heap zugeordnet ist, um sie zu einem geeigneten Zeitpunkt freizugeben (während einer Pause, wenn von einer Ebene zu einer anderen gewechselt wird) , ...) hat es nichts mit dem müllsammler zu tun.
Gouessej
5

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.

BBlake
quelle
17
Sie lassen einen der wichtigsten Punkte aus; Die überwiegende Mehrheit der Tools und APIs, die man verwenden würde, ist in C ++ geschrieben, und das Umschreiben auf Java oder eine andere Sprache wäre eine Menge Arbeit. Außerdem ist Ihre Verallgemeinerung, dass "[Java] viel langsamer ist als die Verwendung von C ++ / Assembly ", zu weit gefasst, um genau zu sein. Assembly wird in PC-Spielen nicht so oft verwendet, wie Sie vielleicht denken, da ein guter Compiler wahrscheinlich effizienteren Code generiert, als Sie Assembler schreiben. Deterministische Ressourcennutzung und die Fähigkeit, direkt an der Hardware zu arbeiten, sind jedoch erforderlich.
Ed S.
15
Jemand muss wirklich ein besseres Beispiel für die Fähigkeiten von Java erstellen als Minecraft. Bis jemand das Äquivalent von WoW oder C & C oder MOH oder Starcraft in Java oder C # erstellen kann, werde ich weiter an dem festhalten, was ich gesagt habe.
BBlake
12
"Assembly wird in PC-Spielen nicht so oft verwendet, wie man denkt, weil ein guter Compiler wahrscheinlich effizienteren Code generiert, als Sie Assembler schreiben." Das ist eine andere Verallgemeinerung. Ich habe noch keinen Compiler gesehen, der eine bessere IA32-Maschinensprache erzeugen kann als ein erfahrener IA32-Assembler-Programmierer. Compiler generieren Code für einen abstrakten Computer, der einem Zielcomputer zugeordnet ist. Ein Assembler-Programmierer nutzt den zugrunde liegenden Prozessor einschließlich der Maschinensprachen voll aus.
Bit-Twiddler
10
Vergessen Sie nicht die Speichernutzung. Die Speichernutzung ist wahrscheinlich wichtiger als die Geschwindigkeit. Java ist nicht für die direkte Speichersteuerung wie C ++ und den Garbage Collector ausgelegt. Dies bedeutet, dass die Speichernutzung für dieselbe Aufgabe immer erheblich höher ist als in C ++.
Matthew Read
9
Dies ist nicht 1985. Wir haben mehr als 640k Speicher, besser als 50 mghz Prozessoren und mehr als 1,44 mbs Wechselspeicher. Die Herausforderung der Spieleentwickler ist heute nicht mehr dieselbe wie vor 25 Jahren. Machen Sie weiter und finden Sie ein Beispiel für handgefertigten x86 / oder ia64-Code für ein modernes Spiel. Bestimmte Mythen sind einfach falsch. Die Herausforderung besteht in der Portabilität und in älteren Clients, die relativ alte Betriebsumgebungen verwenden. Kleinster gemeinsamer Nenner gegen zwingendes Eintauchen.
JustinC
5

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.

user1249
quelle
1
oddlabs.com/technology.php - "Unsere Entwicklung basiert auf der Kombination von LWJGL und Java, mit der das Spiel auf jeder von LWJGL unterstützten Plattform ohne Änderungen und mit einer Geschwindigkeit ausgeführt werden kann, die mit plattformabhängigem nativem Code vergleichbar ist."
Jake2 hat Quake2 vor mehr als 10 Jahren übertroffen. Wir sind nicht mehr im Jahr 2002.
Gouessej
4

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.

dan_waterworth
quelle
4

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.

Jerry Coffin
quelle
Ich denke, Sie haben ein wichtiges Problem mit den Spiele-Engines getroffen - ich denke, dies ist der Hauptgrund, warum Java C / C ++ nicht eingeholt hat. Es ist jedoch möglich, dass Open Source das Spielfeld ein wenig angleicht - ich war sehr beeindruckt von jMonkeyEngine ( jmonkeyengine.com ).
Mikera
Und vergessen Sie nicht, dass Spieleentwickler insgesamt (technisch) äußerst konservativ sind und die meisten großen (einflussreichen) Shops schon seit Jahrzehnten existieren und C (++) / ASM-zentriert sind. Sie werden also nicht in die Java-Entwicklung investieren Wenn eine vollständige C (++) / ASM-Architektur einsatzbereit ist, bedeutet dies eine erhebliche Investition in Zeit, Geld und andere Ressourcen.
28.
1

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.

Meh
quelle
0

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.

Mahmoud Hossam
quelle
3
Aber C ++ wurde auch nicht als Spielesprache entwickelt, sondern als Programmiersprache für Systeme wie C. Und Sun hat Java tatsächlich als Spielesprache getestet. Ich glaube, sie haben mit Sony zusammengearbeitet, um Java auf die PS2 oder PS2 zu bringen etwas, aber es ist nie passiert ...
Anto
1
@Phobia: Aber es wurde entworfen für die Systemprogrammierung.
Anto
1
@ Phobia: Ich sage , es ist eine Allzweck-Programmiersprache , genau wie C ++. In Ihrer Antwort sagen Sie, dass Java nicht als Spielprogrammiersprache entwickelt wurde, aber Sie vergessen, dass C ++ auch nicht so entwickelt wurde.
Anto
2
@ Joe Blow: Von der Wikipedia-Seite über C: "Obwohl C für die Implementierung von Systemsoftware entwickelt wurde , wird es auch häufig für die Entwicklung von portabler Anwendungssoftware verwendet." Ich denke, das ist ziemlich klar, nicht wahr?
Anto
2
@Phobia Es tut mir leid wegen Ihrer persönlichen Vorlieben, aber sie sind für die Diskussion völlig irrelevant. Darüber hinaus möchte ich nicht bestreiten, dass C ++ heutzutage fast ausschließlich in der Anwendungsprogrammierung verwendet wird. Darum ging es in dieser Diskussion nicht. Ihre Behauptung, dass Java mit Blick auf die Webprogrammierung entwickelt wurde. Nun, C ++ wurde unter Berücksichtigung der Systemprogrammierung entwickelt. Sagt sein Designer. Ende der Diskussion.
Konrad Rudolph
-1

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.

hotpaw2
quelle
-4

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.

Echo
quelle
Dies liest sich eher wie ein Kommentar, siehe Wie man antwortet
Mücke
-8

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.

mythicalprogrammer
quelle
1
Sie sollten ernsthaft über die JIT-Kompilierung lesen und sich einige Benchmarks ansehen, bei denen Java gegen C ++
Anto
1
Wer zum Teufel hat diese Antwort abgelehnt? Diese ganze Frage wird unglaublich lächerlich! Guter Kummer.
Fattie
7
@ Joe Die Antwort ist falsch. Java wird nicht interpretiert.
Konrad Rudolph
3
@Anto Vergiss diese albernen Benchmarks. C ++ ist um Größenordnungen schneller als Java, wo es zählt, siehe programmers.stackexchange.com/questions/29109/29136#29136 und programmers.stackexchange.com/questions/368/13888#13888 .
Konrad Rudolph
1
@Anto Worauf soll ich wohl achten? Geschwindigkeit? C ++. Speichernutzung? C ++. Schauen Sie sich minecraft an und versuchen Sie, einen Server zu hosten, um zu sehen, wie viel Speicher das Spiel belegt. Java verbraucht viel mehr Speicher als C ++. Ich würde mir vorstellen, dass es in Java ziemlich schwer ist, ein Online-Spiel zu machen. Jeder Benchmark, den ich bisher in Java gesehen habe, verbraucht mehr Speicher. Jetzt klingt ein MMORPG-Spiel, bei dem der zentrale Server in Java codiert ist, nur dann gut, wenn Sie den Speicheraspekt ignorieren oder die Definition von Massive in MMORPG ändern.
mythicalprogrammer