Plattformübergreifende eigenständige Entwicklung

Wenn Sie vor einigen Jahren in C und einer Teilmenge von C ++ geschrieben und eine ausreichende Anzahl von Plattformabstraktionen (über SDL oder was auch immer) verwendet haben, könnten Sie auf jeder Plattform laufen, auf der ein Indie laufen könnte - Linux, Windows, Mac OS in verschiedenen Versionen , obskure Sachen wie BeOS und die offenen Konsolen wie GP2X und Post-Death Dreamcast. Wenn Sie irgendwann einen Vertrag für eine geschlossene Plattform haben, können Sie Ihr Spiel auch mit "minimalen" Codeänderungen auf diese Plattform portieren.

Heutzutage müssen Indie-Entwickler XNA verwenden, um auf die Xbox 360 (und das kommende Windows Phone) zuzugreifen. darf XNA nur für Windows verwenden; bis vor kurzem musste Java auf Android verwendet werden; Flash läuft nicht auf Handys, HTML5 funktioniert nicht im IE. Anders als zB DirectX vs. OpenGL oder Windows vs. Unix, sind dies Änderungen an der Kernsprache, in der Sie Ihren Code schreiben und die nicht ohne das Schreiben eines Compilers überarbeitet werden können. Sie können einige Spielelogiken in Skripte verschieben und einen Interpreter einbinden - es sei denn, dies ist nicht möglich, da das iPhone SDK dies nicht zulässt und die Leistung leidet, weil niemand JIT zulässt.

Was können Sie also tun, wenn Sie ein wirklich plattformübergreifendes tragbares Spiel oder nur eine erhebliche Menge an Engine- und Logikcode möchten?

Ist dies kein Problem, da die Plattformen grundlegend auseinander gegangen sind - es lohnt sich einfach nicht, ein iPhone und die Xbox 360 mit gemeinsam genutztem Code anzugreifen, da ein solches Spiel schlecht wäre? (Ich finde das sehr unwahrscheinlich. Ich kann leicht erkennen, dass ich ein Spiel zwischen einem Windows Mobile-Telefon und einem Android-Gerät oder einer Xbox 360 und einem iPad teilen möchte.) Sind die Schnittstellen jetzt so hoch, dass die Portierungszeit vernachlässigbar ist? (Ich könnte das für Geschäftsanwendungen glauben, aber nicht für Spiele mit strengen Leistungsanforderungen.)

Wird dies in Zukunft noch deutlicher werden? Wird die Spaltung noch etwas beängstigend für die Anbieter sein? Werden wir uns alle auf High-Level-Middleware wie Flash oder Unity verlassen, um plattformübergreifende Aufgaben zu erledigen?

tl; dr - Ist die Portierung ein Problem, wird es in Zukunft ein größeres Problem sein, und wenn ja, wie können wir es lösen?

Die Unity-Engine verschafft Ihnen einen riesigen Teil des Weges dorthin. Schreiben Sie einmal und Sie haben Mac / Windows Standalone und Webplayer-basiert. Optimieren Sie Ihre Eingaben und achten Sie auf Ihre Draw Calls, und Sie arbeiten mit iOS / Android.

Für einen kleinen Indie-Entwickler mit begrenzten Mitteln / Zeit (und vielleicht eher dem Ziel, "etwas cooler zu machen" als "etwas rentabler zu machen") könnte es kontraproduktiv sein, von Anfang an plattformübergreifend zu arbeiten. Es ist sehr aufwändig, solide plattformübergreifende Tools und Technologien (verschiedene Grafik-APIs, Endianness, Eingabegeräte und mehr) zu entwickeln - Zeit, die für die kreativere Seite der Spieleentwicklung aufgewendet werden könnte.

Aber Sie möchten wahrscheinlich sicherstellen, dass Sie ein großartiges Spiel haben, das auf einer Plattform wirklich gut funktioniert, bevor Sie sich zu viele Gedanken darüber machen, wie Sie es auf so viele Plattformen wie möglich bringen können! Wenn das Spiel ein Flop ist, ist es sinnlos, Zeit und Mühe zu verschwenden, um es zu einem Multi-Plattform-Flop zu machen, oder?

Wenn Sie in C / C ++ codieren, meistens von Grund auf, sollten Sie, solange Sie den Code relativ modular halten und vernünftige Entscheidungen über Datenformate und Middleware / Bibliotheken treffen, die Unterstützung anderer Plattformen später nicht allzu schmerzhaft sein.

Wenn für Ihr Projekt plattformübergreifende Technologien / Tools von Drittanbietern (z. B. Unity) in Frage kommen, sollten Sie dies in Betracht ziehen.

Die Hauptproblemplattformen für Indies scheinen Xbox360-Indiespiele (nur C #, eingeschränkter Netzwerkzugriff usw.) und möglicherweise Android (massive Unterschiede in der Geräteleistung / Bildschirmgröße / Eingabegeräten) zu sein. Wenn Sie entschlossen sind, diese zu unterstützen, erwarten Sie einen umfangreicheren Portierungsjob, oder planen Sie, sich ausschließlich auf diese zu konzentrieren.

Sie sagen, plattformübergreifende unabhängige Entwicklung. Die größte Hürde sind dann die Ressourcen, und das bedeutet meistens Zeitmangel, aber auch mangelndes Know-how und möglicherweise fehlende Finanzen (Lizenzgebühren, Gerätekauf usw.).

Indie oder nicht, die größte Hürde ist eigentlich Design. Wie Sie sagen, funktioniert ein Spiel, das auf Xbox360 und iPad ausgeführt wird, aber es muss sich auch in Bezug auf das Design grundlegend unterscheiden. Das 360 hat einen Controller, das iPad einen Touchscreen. Die Entwicklung für das 360 erfolgt unter Windows unter Verwendung von C # als Sprache. Das iPad kann nur auf Mac OS-Computern und unter Verwendung von C, C ++ oder Objective-C als Ziel verwendet werden. Oder Javascript, wenn Sie es vorziehen. Manche Dinge passen einfach nicht so gut zusammen, was auch immer Sie tun.

Was Sie über die verschiedenen Plattformen sagen, gilt heute. Verwenden Sie C / C ++ und SDL, und Sie können Ihr Programm plattformübergreifend auf PC-ähnlichen Maschinen schreiben, wahrscheinlich viel reibungsloser als vor Jahren. Es war jedoch immer ein Problem und wird immer ein Problem bleiben, Spiele vom PC zur Konsole zum Mobiltelefon zu portieren und umgekehrt. Es ist in den letzten Jahren immer ausgeprägter geworden, indem Indie-Entwicklern ermöglicht wurde, für Konsolen zu programmieren (oder Entwickler, die den Zugriff darauf hacken, um Homebrew-Spiele zu erstellen), und durch den Aufstieg mobiler Geräte, die leistungsfähig genug sind, um Spiele auszuführen.

Portierung hat die gleichen Probleme wie jemals zuvor, aber es gibt mehr Geräte, auf die portiert werden kann. Und einige Ports machen einfach keinen Sinn, ohne den Kern des Spiels neu zu gestalten. Dies ist kein Problem, das gelöst werden kann, sondern eines, das Sie von Anfang an berücksichtigen müssen, bevor Sie Ihre erste Codezeile schreiben. Dann wird es handhabbar sein, nicht mehr und nicht weniger.

Ich denke, ein einfaches, portables und offenes Interface-Framework wird wirklich benötigt. Einige Überlegungen:

Derzeit scheint es vier gängige Arten von Spiel-Eingabemethoden zu geben: Tastaturen, Mäuse, Controller und Multi-Touch-Oberflächen. (Ich werde im Moment die Probleme mit den unterschiedlichen Fähigkeiten von beispielsweise Gamepads und Joysticks beschönigen, obwohl dies eventuell behoben werden sollte.)

Im Idealfall kann unser Entwickler einige verschiedene Benutzeroberflächen generell angeben, die für die Art des zu schreibenden Spiels sinnvoll sind. (Möglicherweise möchten sie eine Tastatur- und Maus-Benutzeroberfläche, eine Nur-Maus-Benutzeroberfläche und eine Multi-Touch-Benutzeroberfläche als willkürliches Beispiel bereitstellen.)

Das Framework ist dann für die Vermittlung von E / A zwischen der Plattform und dem Spielcode verantwortlich, ähnlich wie plattformübergreifende GUI-Frameworks wie QT und GTK funktionieren.

Ein solches Framework würde das Problem der inkompatiblen Sprachanforderungen nicht lösen, aber zumindest alle systemspezifischen Aufrufe hinter einer gemeinsamen API zusammenfassen, was die Sprachportierung wesentlich einfacher machen dürfte.

Nun, da ich das alles geschrieben habe: Weiß jemand, ob ein solches Framework bereits existiert?

Bei Projekten wie MonoTouch und XNATouch sah es so aus, als würde XNA Sie auf den meisten Plattformen mit ein wenig Optimierungsaufwand unterstützen. Leider hat Apple das irgendwie torpediert, als sie ihre Allgemeinen Geschäftsbedingungen geändert haben, um einzuschränken, welche Sprachen Sie verwenden können. Unity geht jetzt über so ziemlich alles, obwohl es Sie auf XBOX auf XBLA bringen wird, aber nicht auf XBLIG, also keine Option für kleinere Indies.

Ein Ansatz könnte darin bestehen, ein Framework zu erstellen, das die gleichen Konventionen für mehrere Sprachen / Plattformen verwendet. Dann ist es nur eine Frage der Syntaxoptimierung, um Spiele zu portieren. Möglicherweise möchten Sie Ihr Spiel in Flash starten, das schnell entwickelt werden kann und ein breites Publikum erreicht. Wenn es dann erfolgreich auf iPhone, XNA usw. portiert wurde, können Sie sicher sein, dass Sie ein unterhaltsames Spiel haben, bevor Sie sich zu sehr festlegen.

Ich denke, das ist ein wirtschaftliches Problem, kein technisches Problem. Plattformen wie xbox360 haben einen starken Anreiz, ausgeschlossen zu sein, da sie versuchen, Benutzer dazu zu bringen, ihre Plattform anstelle einer anderen Plattform zu wählen. "Wir haben diese coolen exklusiven Spiele" ist viel interessanter als "wir können auch diese Spiele spielen, die alle anderen haben". Das Ökosystem wird von den Hardware-Herstellern dominiert.

Ich vermute, dass sich dies ändern wird, wenn das Gameplay in sozialen Netzwerken ausgereift ist, da es möglicherweise viel mehr Geld kostet, alle in dasselbe Social-Gaming-System zu bringen, als noch einen FPS mit sexy Grafiken zu erstellen.

Ich habe gerade Haxe und NME entdeckt . Es soll sich um eine plattformübergreifende App handeln, die alle wichtigen Desktops und Mobilgeräte sowie Flash von einer einzigen Codebasis aus unterstützt. Einen Blick wert.

Ein plattformübergreifendes Entwicklungstool, das so neu ist, dass ich es nicht unbedingt empfehlen muss: http://www.monkeycoder.co.nz/

Es trifft jede Plattform, die Sie erwähnt haben.

Obwohl es zu neu ist, um es wirklich beurteilen zu können, hat es einen großartigen Stammbaum: Es wurde von Blitz3D und BlitzMax entwickelt, die großartige Entwicklungswerkzeuge für Indie-Spieleentwickler waren.

Ich hatte Glück mit dem Airplay-SDK - zumindest auf x86 und zielt anscheinend gut auf das iPhone ab (obwohl ich noch keine App auf einem iPhone installiert habe).