IMHO: Microsoft wollte Windows-Spiele auf Playstation und Nintendo-Konsolen portieren lassen

derStandard.at schreibt im Artikel Die Hintergründe der Konsolenschlacht, dass Microsoft eigentlich nur bestehende Windows-Spiele auf die Plattformen von Nintendo und Sony portiert haben wollte. Als diese sich angeblich weigerten, entschied sich Microsoft eine eigene Konsole herauszubringen, die Xbox.

Das ganze kommt in ungefähr hin, aber es steckt noch ein bisschen mehr dahinter. Ich war zu diesem Zeitpunkt in der Videospiel-Industrie als Entwickler tätig und möchte hier versuchen ein wenig Licht in die Angelegenheit zu bringenNatürlich ohne irgendwelche NDAs zu verletzen. .

Zum Verständnis: Programme für Konsolen werden normalerweise wesentlich näher an der Hardware programmiert als ihre Kollegen auf dem Personal Computer. Sie besitzen – wenn überhaupt – nur ein rudimentäres Betriebssystem. Die Hersteller der Konsolen stellen Spiele-Entwicklern ein oder mehrere SDKs zur Verfügung, so dass diese nicht direkt in Maschinensprache programmieren müssen. Diese SDKs können von den Entwicklern oder Dritt-Anbietern genutzt werden, um so genannte “Game-Engines” zu schreiben. Diese fallen in drei Kategorien:

1. Speziell auf das zu programmierende Spiel abgestimmt. Diese Variante ist, aus Kostengründen, mittlerweile eher selten anzutreffen.
2. Als Basis für mehrere Spiele für das entsprechende Entwickler-Studio. Eine etwas kostengünstigere Variante, die dem Studio erlaubt den eigenen Wünschen und Programmieranforderungen Rechnung zu tragen. Manche Studios bieten ihre Engines als Lizenz-Produkt anderen Entwicklern an.
3. Als eigenständiges Produkt zum Verkauf, bzw. zur Lizensierung an Entwickler-Studios. Zur damaligen Zeit beispielsweise RenderWare oder NDL

Die dritte Variante hat Vor- und Nachteile, ein grosser Vorteil ist die Tatsache, dass sich jemand anderes um Kompatibilität und Bug-Fixes kümmern mussIn diesem Fall auch gerne als OPP (other peoples problem) bezeichnet.. Der, in manchen Anwendungsfällen, spürbare Nachteil ist, die Engine soll – aus Sicht der Entwickler – eine Art “eierlegende Wollmilchsau” sein; soll heissen, es sollten alle gängigen Anforderungen der Entwickler befriedigt werden, was in einem so genannten “feature creep” enden kann. Die Engine schleppt also einiges an Funktionalität mit, welche nicht immer benötigt wird. Diese Situation lässt sich natürlich entschärfen, aber eine ausführliche Erklärung würde im Kontext dieses Artikels zu weit führen.

Zurück zur Portierung der Windows-Spiele: Um eine derartige Portierung wirtschaftlich durchführen zu können, muss zwischen der Logik des Spiels und der Hardware ein Abstraktions-Layer (eine wie auch immer geartete Engine) vorhanden sein. Wenn sich dieser Layer auf eine andere Hardware übertragen lässt, bzw. durch einen Layer gleicher Funktionalität ersetzt werden kann, dann ist das aber nur die “halbe Miete”. Im Gegensatz zu PCs verfügen Konsolen nicht über Tastaturen und, zum damaligen Zeitpunkt, auch nicht über Festplatten um Programmoperationen auf diese auszulagern. Die Architektur der Konsolen setzte voraus, dass die Spiele eben ohne Tastatur spielbar waren; und auch nur begrenzt Speicherplatz für “Swap-Operationen” zur Verfügung stand. Viele der Portierungs-Kandidaten setzten aber genau dies voraus, die Bedienung war nicht auf Game-Pads sondern auf Tastatur ausgelegt und der logische Aufbau des Spiels ging von wesentlich mehr zur Verfügung stehendem Speicher aus und erwartete eine Möglichkeit, fehlenden Speicher durch Festplatten-Platz auszugleichen.

Eine Portierung wurde dadurch nicht unmöglich, aber zu einem wirtschaftlichen Risiko für die Spiele-Entwickler. Der gesamte Ablauf der Spiele musste auf den geringeren Speicherplatz und die fehlende Festplatte hin optimiert werden. Im schlimmsten Fall, müssten ganze Levels unterteilt werden, da sie nicht in den Speicher der Konsole gepasst hätten. Diese Änderung könnte aber den Charakter eines Spiels nachhaltig beeinflussen. Realistisch gesehen, wurde das Spiel ja von der Idee, zur Auswahl der Hardware und von da ab in allen Feinheiten entwickelt. Das bedeutet, nachdem die Hardware ausgewählt wurde, nutzten die Entwickler natürlich auch die zur Verfügung stehenden Möglichkeiten der Eingabe; beim PC (theoretische) 102 Tasten, bei den Konsolen die Bewegungssteuerung und die Anzahl der Tasten auf dem Controller – meist zwischen sechs und acht. Das Problem liegt auf der Hand: Wer bei der Entwicklung davon ausgehen konnte, dass fast hundert Tasten mit Funktionen belegbar sind, macht sich weniger Gedanken darüber wie viele Funktionen auf einen der gängigen Controller für Konsolen verteilbar sind, warum auch. Wenn sich dieses Problem [auf die eine oder andere Weise] umschiffen liess, ging es bei der Portierung ans Eingemachte.

Windows-Spiele wurden (und werden), in verschiedenen Varianten, mit DirectX programmiert, dass heisst, eine – wie auch immer geartete – Engine setzte so nahe wie möglich auf diesem Abstraktions-Layer auf. Jede Engine die ihr Geld wert ist, lässt einen direkten Zugriff auf die tieferen Schichten des Systems zu; jeder dieser Zugriffe erschwert die Portierung eines Spiels. Auf zum nächsten und komplexesten ProblemHat irgend jemand gedacht, dass wir schon fertig wären? .

Ich hatte am Anfang erwähnt, dass Konsolen normalerweise wesentlich näher an der Hardware programmiert werden (müssen). Ein Beispiel: Das anti-aliasing auf der PS2, lässt sich problemlos mit einem Flag, welches an einer bestimmten Stelle gesetzt werden muss, einschalten“Problemlos” wenn man in der japanischen Dokumentation auf einen bestimmten Nebensatz geachtet hat. Später wurde die Vorgehensweise besser dokumentiert.. Am Anfang liess sich dieser Vorgang am einfachsten durch einen Assembler-Zugriff bewerkstelligen. Assembler? Ja junger PaduanSchreibt man das in deutsch so?, Assembler. Und damit kommen wir zum nächsten Problem.

Die damaligen Konsolen-Programmierer(innen) liessen sich in zwei Fraktionen einteilen:

1. C++, also im weitesten Sinne objekt-orientiert, “Ich habe die Collision-Detection über nur 70 iunknown realisiert, ich denke damit können wir leben”.
2. Hardcore, “Ich habe mir gerade den Maschinen-Code angesehen, wenn ich diese drei Anweisungen in umgekehrter Reihenfolge ablaufen lasse, dann ruckelt die Darstellung der 150.000 schattierten Polygone überhaupt nicht, wir können also unsere hundert Krieger leicht im Level herumlaufen lassen”.

Beide Aussagen habe ich persönlich gehört. Dieses Problem war das grösste Hindernis. Ich habe exzellente Windows-Programmierer kreidebleich vor den Konsolen-SDKs sitzen sehen. Sie wurden mit einer völlig anderen Welt konfrontiert. Unnötig zu erwähnen, dass sie zur ersten Fraktion gezählt werden mussten. Nur das wir uns richtig verstehen, ich mache den Leuten keinen Vorwurf, aber bei der hardwarenahen Programmierung ist eine andere Herangehensweise gefragt. Diejenigen Spiele, welche die Fähigkeiten von Konsolen kurz nach dem Verkaufsstart derselben richtig ausgenutzt haben, wurden von Personen der zweiten Fraktion programmiertManche Bezier-Berechnungen in Super Mario 64 wurden per Assembler auf den Sound-Chip ausgelagert, wenn dieser nichts zu tun hatte..

Die angesprochenen Portierungen hätten also eine Mischung aus Fraktion eins und zwei erfordert, diese Programmierer-Spezies ist allerdings recht selten. Den “schwarzen Peter” also nur den Konsolen-Herstellern und den Studios zuschieben zu wollen, greift IMHO zu kurz, Sorry.

[Nochmal zur gefälligen Beachtung: Dieser Artikel bezieht sich auf den damaligen Stand, ich kenne die neueren SDKs der aktuellen Konsolen nicht so genau und kann daher auch nichts dazu sagen. ]