it-swarm.com.de

Java Game Engines

Ich habe mich kürzlich mit der Entwicklung von Spielen befasst und meine erste Programmiersprache ist Java. Nach vielen atemberaubenden Spielen, die in c ++ entwickelt wurden, habe ich mich gefragt, warum Java in der Spieleindustrie nicht so stark eingesetzt wird. Ich habe mir jMonkeyEngine 3 und ein paar andere Game Engine-Umgebungen angesehen, aber die Screenshots, die ich gesehen habe, sind weit weniger beeindruckend. Titel wie Need for Speed ​​Hot Verfolgung von EA und Assassins Creed von ubisoft vermitteln einen solchen Realismus. Warum kann Java keine branchenweit starken Spiele produzieren? Ist es das Kunstwerk? 

Java und C # verfügen über eine automatische Speicherbereinigung und C++ nicht. Der Programmierer muss der Speicherverwendung mehr Aufmerksamkeit schenken, als etwaige Zeiger und so weiter. 

Danke Leute.

17
Binaryrespawn

Java und C # haben automatisch Müll Collection und C++ nicht. Das Der Programmierer muss genauer aufpassen. Speicherauslastung, um nicht zu hängen Zeiger und so weiter.

Sie selbst haben Ihre Frage beantwortet.

Bei Spielen ist das Programmieren der Speicherbereinigung kein Vorteil. Selbst wenn die Leistung von Java für die meisten Aufgaben mehr oder weniger mit C++ vergleichbar ist und das JIT sogar sehr aggressive Optimierungen durchführen kann, die die der statischen Analyse übersteigen können. Die Speicherbereinigung kann dazu führen, dass die Frameraten im ungünstigsten Moment fallen.

Für grafikintensive Aufgaben ist Java nicht besonders geeignet, da viele Dinge von der Laufzeit als unsicher angesehen werden und daher verboten sind (z. B. das Umsetzen von Zeigern, um Daten neu zu interpretieren).

Ein weiteres wichtiges Thema ist das in der Branche bereits festgelegte Know-how. Die Trägheit von C++ in der Spieleindustrie ist enorm. Alle Spieleentwickler kennen heute C und C++. Wenn Sie einen großen Entwicklerpool für die Anstellung von Mitarbeitern mieten, verringert dies eine der Managementrisiken, die Schlüsselpersonen sind, die das Unternehmen verlassen.

Trotzdem gab es einige erfolgreiche Spiele mit einigen in Java geschriebenen Teilen, wie Vampire: The Masquerade - Redemption .

Ein neueres Spiel wie Minecraft ist vollständig in Java geschrieben. Es bietet jedoch keine hochmodernen Grafiken, da der Schwerpunkt eher auf der dynamischen Natur der virtuellen Umgebung liegt.

Und viele andere Spiele und Engines verfügen über eine Laufzeitumgebung, die eine verwaltete Skriptsprache (sichere automatische Speicherzuweisung und -sammlung) unterstützt, die auf einer Hochleistungs-Rendering- und Netzwerkplattform (in C/C++) aufgebaut ist, wie Unreal Engine for Beispiel.

20
fortran

Im Allgemeinen war alles, was hier gesagt wurde, ein Grund, für die Spieleentwicklung nicht auf Java zu portieren. war. Die Spielebranche befindet sich derzeit in einem Paradigmenwechsel. Drei Dinge haben sich geändert oder verändern derzeit die Spielebranche:

  • Piraterie
  • Client-Server-Programmmodelle
  • Programmmodelle für modulare Vernetzung

Ein Spiel ist nicht mehr ganz von sich selbst abhängig. Die Hauptvorteile, die in den ersteren (Low-Level-Sprachen) bestanden, werden durch die Vorteile, die in Sprachen wie C # und Java (High-Level-Sprachen) bestehen, abgewogen. Zwei grobe, aber unbestreitbare Beispiele sind Spiele, die mit Facebook und Remote-Medien wie Handys, Tablets usw. funktionieren.

Es ist wichtig festzustellen, dass in allen beiden Szenarien alle drei oben aufgeführten Probleme gelöst sind. Ein Spiel, das ohne einen Server nicht funktionieren kann, muss sich keine Sorgen über Kopierverletzungen machen (privates Hosting durch Reverse Engineering nicht inbegriffen). Die Nachfrage nach netzwerkabhängigen Spielen erfordert eine Sprache, die die Systemleistung mit der Netzwerkleistung (normalerweise ein Patt zwischen Java und C ausgleichen kann/C++, bevorzugt C/C++ (aufgrund der Fülle bereits vorhandener Bibliotheken). Es wäre jedoch unpraktisch, ein Spiel, das in einem modularen Netzwerkprogramm-Modul entwickelt wurde, in einfachen Sprachen wie C/C++ zu entwickeln. Ein Unternehmen, das daran interessiert wäre, ein Spiel in C/C++ für ein Modular-Networking-Programmmodell zu entwerfen, müsste eine virtuelle Maschine erstellen, die sich ausschließlich diesem einen Spiel widmet, oder das Spiel einige Male neu programmieren/kompilieren, um es für verrückt zu halten. IMO, obwohl es möglicherweise zu früh ist, um die bevorzugte Sprache anzugeben, setze ich meine Wetten aus drei Hauptgründen auf Java.

  • 1) Mit der JVM können auf Java basierende Anwendungen auf jeder Plattform ausgeführt werden, unabhängig davon, ob Apple, Android, Windows 8 oder Linux/UNIX (praktisch auch auf jeder Hardwareplattform unterstützend).

  • 2) Java verwendet OpenJL (das OpenGL-Derivat, das unter OpenGL als Client ausgeführt wird - jMonkey ist eine in OpenJL entwickelte Engine). Es ist wichtig zu beachten, dass nur Microsoft Windows DirectX verwendet, so gut es auch sein mag, es hat nur einen Nachteil. Praktisch jedes Betriebssystem, auf dem Spiele ausgeführt werden können, ist in der Lage, in OpenGL zu rendern, und das modulare Design treibt dies voran wie nie zuvor. (Bitte beachten Sie, dass Microsoft versucht, dieses Problem durch Monopolisierung der Distribution von Windows 8 zu umgehen.).

  • 3) Java unterstützt das interne Threading in der JVM, wodurch Multi-Core-Prozessoren ohne die Verwendung einer Drittanbieter-Bibliothek voll genutzt werden können. Derzeit ist dies ein Handicap für alle anderen Sprachen (insbesondere für Telefone).

Während die JVM Bedenken hinsichtlich der Latenzzeit aufwirft, sollte beachtet werden, dass solche Bedenken durch Threading beseitigt werden könnten. Ich würde mir auch keine Sorgen um Windows 8 und den Push von Microsoft machen. Google hat einen Aktienanteil von 720 USD/Aktie, Apple von 526 USD/Aktie, wobei Microsoft derzeit 27 USD hat. Während Apple wahrscheinlich hauptsächlich aufgrund der Verwendung von C # von Microsoft Push betroffen ist, wird Google wahrscheinlich davon profitieren. Microsoft hatte im Wettbewerb mit Google noch nie viel Glück und Google/Android verwendet Java in hohem Maße. Angry Birds wurde ursprünglich in Java FYI entwickelt und für das iPhone nach C # portiert. Wenn Google/Android die Standardisierung erzwingt, fällt Microsoft wie eine Fliege und nimmt Apple mit.

18
C.Jepson

Die Antwort auf Ihre Frage sind Kunstwerke und finanzielle Ressourcen. Und Minecreft wurde ursprünglich von einer Person in Java entwickelt. Tits wie AC oder NFS werden von Tausenden von Menschen entwickelt. Vergleichen Sie die Ressourcen. Darüber hinaus verwendet Ubisoft die Custrom Game Engine. Wenn Sie der einzige Entwickler sind, sollten Sie sich auf die Idee konzentrieren, da es an Ressourcen fehlt. Und wenn Sie eine Idee haben, ist der Garbege-Collector in normalen Sonderspielen für Entwickler unerreichbar. Als einziger Entwickler sollten Sie sich für die schnellste Entwicklungstechnologie entscheiden.

4
fil mihaylov

Ich wollte nur ein Nebenthema dieser Frage ansprechen, aber die Garbage Collection ist nicht unbedingt hilfreich, um die leistungsschwachen Aspekte einer AAA-Engine zu erstellen. Tatsächlich ist es jedoch hilfreich, ein solches Referenzierungs- und Erfassungssystem für Objekte zu vermeiden. Sie möchten, dass auch benutzerdefinierte Typen im Speicher zusammenhängend sind und angrenzende Objekte in den Cache usw. passen.

Abgesehen von den Leistungsproblemen des Sammelns von Müll in regelmäßigen Abständen und des Zerstreuens von Objekten im Gedächtnis können Spiele es sich nicht leisten, mit ihren sperrigen Ressourcen undicht zu sein, und der Müllsammler hindert die Dinge dort. Ja, ich habe gerade gesagt, dass GC die Möglichkeit, Leckagen zu vermeiden, behindert.

Garbage Collection ist keine Silberkugel gegen Ressourcenlecks.

So uninteressant es sich auch anhört, sollten Sie sich die derzeit am wenigsten verbreiteten Apps ansehen. Je länger Sie sie verwenden, umso mehr steigt der Speicherbedarf. Normalerweise handelt es sich nicht um C- oder C++ - Anwendungen. C/C++ - Anwendungen können für Abstürze berüchtigt sein, nicht jedoch für das Auslaufen. Diese undichten werden viel häufiger in Sprachen mit Müllsammlung programmiert.

Nehmen Sie zum Beispiel Flash-Spiele. Es gibt viele und nicht nur komplette Amateur-Software, die mehr und mehr Ressourcen benötigt und je länger Sie das Spiel spielen, umso langsamer und langsamer wird, so dass Sie manchmal Ihren Browser neu starten müssen, um das Spiel wieder schnell zu machen. Sie sind jedoch in ActionScript, einer Sprache mit Garbage Collection, codiert.

Theoretisch sollte die Sammlung von Abfällen die Undichtigkeit reduzieren. In der Praxis werden dadurch häufig die kostengünstigeren und leichter zu reparierenden physischen Lecks (Whoop, die ich vergessen habe, diese Zeichenfolge zu löschen) im Austausch für die viel teureren und schwer zu isolierenden logischen Lecks (Whoops, die Logik von Das System verursacht sperrige Ressourcen, bis das gesamte Spiel heruntergefahren ist.

Wenn Sie in einer GC-Sprache gemeinsam genutzten Besitz einer neuen Ressource (R) erstellen möchten, müssen Sie lediglich einen Handle/Verweis darauf in einem anderen Objekt (A) speichern. B und C können auch ein Handle für R speichern, und jetzt hat R drei Besitzer und wird nur freigegeben, wenn alle drei Besitzer die Referenz freigeben. Der Benutzer sieht und arbeitet nur mit dem, was A speichert, so dass die Spielelogik das periodische Entfernen von R aus A einschließt, aber die Verweise darauf in B und C verweilen, die der Code nicht freigibt. In C/C++ kann der schlaffe Zeiger hier in B und C tatsächlich vorzuziehen sein, da er während des Abspieltests zu einem sofort erkennbaren und korrigierbaren Problem führt, bei dem der Entwickler, der einen Debugger ausführt, das Problem sehr schnell erkennt und behebt. In einer GC-Sprache ist es extrem schwer zu erkennen und während das Programm nicht abstürzt, kann es zu großen Verlusten kommen.

Daher vermeidet GC definitiv das Aufhängen von Zeigern. Wenn jedoch etwas in C/C++ baumelte und nicht in einer GC-Sprache baumelte, wäre dies ein logisches Ressourcenleck in einer GC-Sprache und ein Segfault in C/C++. Anders ausgedrückt: GC tauscht baumelnde Zeiger gegen baumelnde Ressourcen, die für immer bestehen bleiben. Es tauscht einen krassen Absturz in ein lautloses Leck aus, das einen Alptraum für die Fehlersuche darstellen kann (und möglicherweise sogar lange nach der Veröffentlichung des Produkts unbemerkt bleibt). Für so etwas wie ein Spiel, das massive, dynamische Welten, Grafik- und Physikobjekte und so weiter und möglicherweise in jedem Rahmen erzeugt, sind logische Ressourcenlecks eine große Sache.

Müllsammlung ist am besten, wenn Ressourcenlecks keine große Sache sind.

Dieses vorige Szenario ist leider in einer großen Teamumgebung mit GC allzu verbreitet, insbesondere wenn jeder Programmierer die Fallstricke der Speicherbereinigung und den starken Bedarf an schwachen Referenzen nicht sehr genau kennt. Daher ist GC nicht unbedingt etwas, was man als Vorteil für das Erstellen von Spielen anführen kann, es sei denn, es handelt sich nur um die menschliche Logik auf höchstem Niveau. Die untergeordnete, heikle Systemlogik, die ständig Ressourcen erstellen, darauf zugreifen und sie zerstören muss, wird im Allgemeinen besser laufen, selbst wenn es um das Vermeiden von Lecks geht.

3
Dragon Energy

Es ist nicht ganz richtig, dass die Müllabfuhr in der Glücksspielbranche ungenutzt bleibt. In Unreal Engine 3 wurde die Speicherbereinigung für "Script" -Klassen implementiert. Für sie ist die Leistung akzeptabel, wenn sie leicht verwendet wird. Das schwere Anheben erfolgt durch C/C++ - Code, der seinen eigenen Speicher verwaltet.

Wie Fortran gesagt hat, wird Java in der Gaming-Branche nicht wirklich verwendet, da es Bedenken hinsichtlich der Geschwindigkeit gibt (Java führt auf einer VM Code aus, meistens nicht nativ ...) und weil es bereits eine große Anzahl talentierter Spielprogrammierer gibt viel geschriebener Code in C und C++ geschrieben. Das bedeutet nicht, dass Sie Java nicht verwenden können, um ein Spiel zu erstellen, da es ein paar Java-Spiele gibt, aber die "Mainstream" -Spielindustrie hat stark in ein C/C++ - Backend investiert.

1
James

fortran und James haben es bereits ziemlich gut behandelt, aber ich möchte noch etwas erwähnen. Was Fortran angedeutet hat, wenn man von Trägheit spricht, ist der riesige Pool an Bibliotheken, der in C++ verfügbar ist. Das Vorhandensein mehrerer C++ - Bibliotheken für fast alles, was Sie sich vorstellen können, ist ein großer Grund, nicht auf Java zu wechseln. Das heißt nicht, dass es derzeit keine Bibliotheken für Java gibt, aber die C++ - Bibliotheken sind bereits ausgereift und verfügen über große Communitys mit erfahrenen Entwicklern. Nicht dasselbe, was Sie bereits 1000x getan haben, zu überschreiben, ist eine große Zeitersparnis.

0
Gemini14