Wie zielen Spieleentwickler auf mehrere Plattformen (Xbox 360, PS3, PC und Linux)?

Wie zielen Spieleentwickler auf mehrere Plattformen gleichzeitig ab? Zum Beispiel Xbox 360, PS3, PC und Linux. Ist es bei 2D-Spielen möglich, auch auf das iPhone abzuzielen? Ich interessiere mich für verwendete Engines (2D / 3D usw.), wie die Build-Pipeline eingerichtet ist und wie viel des "Kerncodes" im Allgemeinen zentralisiert werden kann, ohne plattformspezifische Codezweige schreiben zu müssen.

Oder wie werden Bibliotheken / Code (in Bezug auf Verknüpfung und Modularisierung) wiederverwendet, wenn normalerweise für jede Plattform vollständig separate Code-Trunks verwaltet werden?

Für die Entwicklung kommerzieller Konsolenspiele ist das Einrichten eines Build-Systems für 360, PC und PS3 gleichzeitig irritierend, aber nicht besonders schwierig. Das 360 Dev Kit ist einfach ein neues Ziel für Visual Studio + einige Tools und verwendet einen sehr ähnlichen Compiler wie der Standard-Windows MSVC ++ - Compiler. Die PS3 verwendet ein GCC-Compiler-Backend, lässt sich jedoch problemlos an das Visual Studio-Frontend anschließen. Für das Gameplay und den allgemeinen Dienstprogrammcode sollte es im Allgemeinen möglich sein, dass der Code zwischen den drei Plattformen zu 99% gleich ist. Es gibt einige Inkompatibilitäten zwischen GCC und MSVC ++, aber zum Glück wird es nicht viel schwieriger sein, wenn Sie diese Linux-Version (vorausgesetzt, Sie verwenden eine gcc-Version in der Nähe der PS3-Version) verwenden. Die letzten 1% des Codes, die sich unterscheiden, können Sie normalerweise mit kludgy #defines beheben.

Nach den grundlegenden Build-Schritten werden die Grafiksysteme sowie alle Hochleistungselemente Ihres Spiels die große Hürde sein. Für diese Elemente werden Sie am Ende realistisch benutzerdefinierten Plattformcode schreiben oder eine vorhandene Engine verwenden. Das Gedächtnis wird ein großes Problem sein, aber das ist eine andere Frage. Ein kommerzielles Projekt, an dem ich gearbeitet habe, war in der Lage, Konsolenversionen einer ursprünglichen PC-Quellbasis ziemlich einfach aufzubauen, aber es war ein ganz anderes Problem, sie tatsächlich gut funktionieren zu lassen.

Wenn Sie auch das iPhone integrieren möchten, können Sie eine vorhandene Engine / Middleware-Lösung verwenden. Das iPhone-Setup von openGL + Objective C passt nicht wirklich gut zu jeder anderen Plattform. Dies ist eine sehr wichtige Entscheidung von Apple, da die Verwendung von interpretierter Middleware in iPhone-Anwendungen stark davon abgehalten wird.

Für die meisten Plattformen können Sie Subsysteme schreiben, die von den spezifischen APIs abstrahieren, die zum Aufrufen und Abrufen von Informationen von der Plattform verwendet werden, auf der Sie ausgeführt werden. E / A-APIs sind normalerweise am einfachsten zu abstrahieren - alle Dateisysteme arbeiten mit einigen ziemlich grundlegenden Annahmen zum Öffnen, Schließen und Lesen von Dateien, selbst wenn Sie asynchrone Aufrufe berücksichtigen. Dann haben Sie Ihre Kernsysteme wie das Lesen von Controller-Eingaben, das Abfragen der Zeit, den Zugriff auf Speicher- und Thread-Grundelemente, von denen die meisten auf die gleiche Weise funktionieren.

Sogar Grafiken können weitgehend abstrahiert werden, und tatsächlich sind sie es in den meisten guten Engines. Aber Sie müssen die "renderbaren" Dinge in Blackboxen verpacken, in denen Sie nicht wissen dürfen, was in ihnen vor sich geht. Sie wissen, dass Sie ein „Ding“ haben, das Sie an einer bestimmten Position in der Welt rendern. Sie wissen nicht, wie es gerendert wird, nur dass es so ist. Und die Grafikabstraktionsschicht kümmert sich um alle Details, um sie auf den Bildschirm zu bringen. Die plattformspezifischen Build-Pipelines packen die grafischen Daten so zusammen, dass sie von der Engine aus referenziert werden können, ohne wirklich zu wissen, wie sie intern dargestellt werden.

Alles in allem gibt es jedoch bestimmte Teile, die man einfach nicht abstrahieren kann, wenn es darum geht, ein Spiel tatsächlich zu versenden. Es wäre lächerlich zu glauben, Sie könnten auf dem iPhone denselben Code wie auf 360 oder PS3 ausliefern, da die Eingabemechanismen, die grundlegende Funktionsweise und die Plattformfunktionen einfach zu unterschiedlich sind. Sie könnten einen Titel in iPhone-Größe auf 360 erstellen, aber er müsste seine Eingabemechanismen auf diejenigen beschränken, die der 360 unterstützen kann. Also ein virtueller Cursor auf dem Bildschirm, der einen Finger simuliert und möglicherweise den Joystick verwendet, bei dem die Eingabe des 3D-Beschleunigungsmessers verwendet wird.

Sinnvoller ist, dass Teile des Spiels wiederverwendbar geschrieben werden können und einzelne Codemodule zwischen Plattformen portiert werden können, obwohl der Großteil des Titels unterschiedlich ist. Wenn Sie beispielsweise eine KI-Zustandsmaschine haben, ist es egal, ob sie auf 360, PC oder iPhone ausgeführt wird. Ihr Spiel wird viele solcher Komponenten verwenden. Solange sie so konzipiert wurden, dass sie genau definierte Ein- und Ausgänge enthalten, kann der Rest eines Spiels unabhängig von der Plattform um sie gewickelt werden, ohne dass diese neu geschrieben werden müssen Komponenten.

Diese Wiederverwendbarkeit ist der Schlüssel für eine plattformübergreifende Entwicklung, ohne nach einer Einheits-Engine zu suchen, die auf allen Plattformen funktioniert. Selbst wenn es so etwas gäbe, wäre es so verkrüppelt, wenn man auf dem kleinsten gemeinsamen Nenner arbeiten müsste, dass es nicht viel nützen würde, Spiele damit zu machen.

Eine Möglichkeit ist die Verwendung einer Multiplatafom-Engine wie Torque oder Unity3D . Aber ich glaube nicht, dass sie an all diesen Plattformen arbeiten. Es gibt noch einen anderen Weg: einen Motor entwickeln ...