Blog Entry: Sprung ins Plattform-Chaos

Owned by Former user (Deleted)
Last updated: Jul 06, 2015 by Former user (Deleted)

Einleitung

Ein Geheimnis ist es sicher nicht, dass jedes Computerspiel irgendwelche Computer-Hardware (HW) braucht, um gespielt werden zu können. Die meisten Spiele benötigen darüber hinaus auch noch eine gewisse Basis-Software (SW) wie ein Betriebssystem (BS), dass auf dieser HW oder ihrem Medium vorinstalliert ist. Und dennoch besteht das traditionelle Plattform-Modell nahezu aller Videospiel-Webseiten da draußen aus einem wilden Mix von HW und SW. Man kann Konsolen wie die PlayStation direkt neben BSen wie Linux oder Windows finden, Seite an Seite mit "plattformunabhängiger" SW wie einem Browser oder gar Arcade-Boards, alle zusammengeführt zu einer einzigen Ebene von Plattformdaten. Diese Zusammenkunft der verschiedenen technischen Ansätze an einer Stelle bringt eine Reihe von Problemen mit sich, wenn es an die Dokumentation von Spieleveröffentlichungen geht.

Wenn der interessierte Leser das nächste Mal einer Plattform wie "PC", "DOS", oder "Mac" auf einer Webseite mit dem Thema Videospiele begegnet, dann bitten wir um einen Moment der Recherche, was diese Plattform eigentlich genau bedeutet. Höchstwahrscheinlich wird sich herausstellen, dass "PC" alle Spiele für Microsofts Desktop-BSe seit den Achtzigern beinhaltet, dass "DOS" alle für MS-DOS auf IBM-PC-kompatibler HW veröffentlichten Spiele abdeckt und dass "Mac" auf jeden Rechner mit dem Namen "Macintosh" verweist, unabhängig vom installierten Apple-BS. Diese Situation ist zwar nicht ideal, da beispielsweise der "PC" viel mehr als IBM-Maschinen umfasst oder der Begriff "DOS" viel mehr als Microsoft, aber die Mehrheit der Benutzer ist trotzdem zufrieden damit. Nur wenige haben nämlich schon einmal etwas von DEC PDP, CP/M oder dem alten Mac OS gehört. Nun ist Benutzerzufriedenheit aber etwas, dass wir bei den Planungen für Oregami sehr genau berücksichtigen müssen, weil wir unser Projekt natürlich nicht nur für Experten öffnen wollen.

Wir haben deshalb gründlich darüber nachgedacht, wie wir die existierenden Plattform-Modelle so verbessern können, dass zunächst die Gelegenheits-Benutzer nicht abgeschreckt werden. Sehr wichtig erschien uns dabei, den Benutzern die Plattformen anzubieten, die sie auch auf ihren Spieleverpackungen finden können. Wenn eine Sammlerin also "Amiga" oder "IBM PC" auf einem Spielekarton zu stehen hat, dann sollte sie diese Plattformen auch in der Oregami-Datenbank finden können. Andererseits wollen wir natürlich auch ein Schema implementieren, dass wesentlich feingliedriger als die bekannten Modelle ist und sich deshalb wesentlich besser eignet, die reichhaltige Historie der Videospiel-Plattformen abzubilden. Auf diese Weise hätten auch die Experten unter uns genau die Spielwiese, die sie sich wünschen. Können diese beiden Gegensätze in einer Datenbank vereint werden? Wir glauben fest daran.

Ein modernisierter Ansatz

Den Anfang sollen unsere Ideen für ein verbessertes Plattform-Modell bilden oder anders ausgedrückt: Lasst uns mit der Experten-Thematik beginnen, bevor wir viel weiter unten, nach den folgenden, ausführlichen Beispielen, wieder zur Benutzerfreundlichkeit zurückkehren wollen.

Zu allererst braucht jedes Spiel natürlich eine Umgebung, in der es laufen kann, wobei diese Umgebung in den allermeisten Fällen aus einer HW- und einer SW-Komponente besteht. Aus diesem Grund soll die zentrale Datenebene des Plattform-Modells von Oregami "Spielumgebung" (SU) genannt werden. Diese Datenebene wäre mit den "Plattformen" vergleichbar, die wir von anderen Internetseiten kennen, da die SUen letztlich das sind, wofür Videospiele veröffentlicht werden. Allerdings vermeiden wir das Wort "Plattform" bei der Bezeichnung dieser Ebene nicht ohne Grund, weil wir eine klare Trennlinie zwischen unseren HW-/SW-Kombinationen und dem losen Mix aus HW und SW anderer Projekte ziehen wollen.

Die zweite Datenebene unterhalb der SUen markiert dann den Beginn der Aufteilung in HW und SW, da jede SU genau eine bestimmte "Hardware-Plattform" (HWP) und eine bestimmte "Software-Plattform" (SWP) als Mussdaten zugewiesen bekommt. An dieser Stelle verwenden wir das Wort "Plattform" doppelt mit Bedacht, und zwar einmal für ein Stück HW, auf dem Spiele laufen können, und andererseits für verschiedene Arten von SW, die viele Spiele zusätzlich benötigen, nicht aber für Kombinationen dieser zwei Grundlagen. Natürlich gibt es Fälle, wo eine HWP oder SWP nicht benötigt wird oder für Dokumentationszwecke unwichtig ist. Beispielhaft wären hier die PC-Booter zu nennen (keine SWP) oder die "plattformunabhängigen" Spiele wie Browser-Veröffentlichungen (keine HWP). Da aber HWP und SWP zusammen Mussdaten für jede SU darstellen, wollen wir die entstehenden Lücken mit standardisierten Einträgen für jeden Spezialfall füllen, wie das z. B. "Kein installiertes BS benötigt" als SWP bei den Bootern sein könnte, oder "Jede kompatible HW" als HWP für Browserspiele.

Die dritte Datenebene wollen wir "Sub-Plattformen" nennen und unter jede HWP und jede SWP hängen. Der Plan für diese Ebene ist, dass sie ziemlich verschiedene Daten aufnehmen können soll. Beispielsweise werden wir unterhalb jeder HWP für die Dokumentation ihrer spezifischen Modelle oder ihrer Emulationssoftware die neue Datenebene nutzen. Unterhalb jeder SWP könnten wir damit zum Beispiel verschiedene Versionen eines BS oder eines Browsers abbilden oder ebenfalls Emulatoren für diese. In einer ausgebauten Version werden wir die Sub-Plattformen dann auch zur Abbildung von Kompatibilitätsproblemen nutzen können. Man stelle sich nur den Windows-Fall vor, wo die veröffentlichten Spiele nicht auf jeder Version dieses BS laufen, oder die Amiga-Familie von Heimcomputern, bei denen nicht jedes veröffentlichte Spiel auf jedem Modell läuft.

Allgemein gesprochen werden diese drei Datenebenen der Ort sein, an dem sich die Experten austoben können, und wir werden damit in der Lage sein,  Spieleplattformen besser zu dokumentieren, insbesondere dann nämlich, wenn es an die vielen Spezialfälle geht.

Beispiele zum Durchdenken

Nachdem im vorherigen Abschnitt die Grundlagen gelegt wurden, soll nunmehr ein ausführlicher Blick auf einige Beispiele und deren Einordnung in das verbesserte Modell erfolgen.

1. Typische Konsolen, mobil wie stationär

Beispiele:
Die SU "PlayStation" wird definiert durch die HWP "PlayStation-Konsole" und die SWP "PlayStation-BIOS".
Die SU "PlayStation 3" wird definiert durch die HWP "PlayStation 3-Konsole" und die SWP "FreeBSD BS".

Wir beginnen mit einem relativ leichten Beispiel und wollen die typischen Videospielkonsolen abhandeln, ob nun stationär oder mobil. Die Konsolenhardware wird als HWP definiert und bekommt all ihre verschiedenen Modelle und Emulatoren als Sub-Plattformen zugewiesen. So bekäme beispielsweise die HWP "PlayStation-Konsole" all die verschiedenen PSX-Modelle und all die unterschiedlichen PSX-Emulatoren in ihren mannigfaltigen Versionen als Sub-Plattformen zugewiesen. Wenn irgendwann einmal all diese Sub-Plattformen an der richtigen Stelle sind, dann werden wir in der Lage sein abzubilden, welches PSX-Spiel sich nicht gut mit welchem Modell der Konsole verträgt oder welche Emulator-Version welches Spiel unterstützt. Und weil die PSX nur ein BIOS besitzt und kein BS, werden wir die SWP mit dem Wert "PlayStation-BIOS" befüllen.

Im Gegensatz zur PlayStation besitzen modernere Konsolen meistens ein richtiges BS, das unterhalb des BIOS arbeitet, weshalb wir dieses BS anstatt des BIOS als SWP benutzen werden. Beispielhaft arbeitet in der PlayStation 3 eine FreeBSD-Variante, die "CellOS" genannt wird. Demnach würden wir "FreeBSD BS" als SWP für diese Konsole definieren und dann "CellOS" als eine Sub-Plattform dazu addieren.

2. Die DOS / PC - Wirren der 80er

Beispiele:
Die SU "DOS PC" wird definiert durch die HWP "IBM-PC-kompatible HW" und die SWP "MS-DOS BS".
Die SU "IBM-PC-kompatibler Booter" wird definiert durch die HWP "IBM-PC-kompatible HW" und die SWP "Kein installiertes BS benötigt".
Die SU "Kaypro II" wird definiert durch die HWP "Kaypro Z80-Rechner" und die SWP "CP/M BS".
Die SU "DEC Rainbow (CP/M)" wird definiert durch die "DEC Rainbow 100" und die SWP "CP/M BS".
Die SU "DEC Rainbow (MS-DOS)" wird definiert durch die "DEC Rainbow 100" und die SWP "MS-DOS BS".
Die SU "CP/M @ Z80-Rechner" wird definiert durch die HWP "Z80-kompatible HW" und die SWP "CP/M BS".
Die SU "MS-DOS @ x86-Rechner" wird definiert durch die HWP "x86-kompatible HW" und die SWP "MS-DOS BS".

Die 80er sind ein echter Alptraum, wenn es um die Dokumentation von Computerspielen geht, und zwar aus einer simplen Tatsache heraus: Viele in dieser Ära veröffentlichte Spiele für Heimcomputer hatten die schlechte, aber meist notwendige Eigenart, das auf dem Rechner installierte BS teilweise oder gar komplett zu umgehen und direkt mit dem BIOS und / oder der HW zu interagieren. Das lag hauptsächlich an den damaligen BSen, die oft zu viel Ressourcen verschlangen, die für schnelle und hübsche Spiele gebraucht wurden, oder die nicht alle Hardwarezugriffsfunktionen besaßen, die die Spiele benötigten. Diese Beschränkungen resultierten in vielen Spielen, die fast nur noch auf den Maschinen liefen, für die sie geschrieben worden waren, und nicht mehr auf schon leicht modifizierter HW, und das sogar dann, wenn dort die gleiche CPU und das gleiche BS ihren Dienst versahen. Wie ich schon sagte, ein Alptraum.

Zu dieser Zeit versuchten viele Firmen, ihren eigenen Heimcomputer mit zugehöriger Software erfolgreich am Markt zu platzieren. Die unweigerlich daraus folgenden Kämpfe um die Marktführerschaft entschieden zwei der Firmen deutlich für sich: Microsoft mit MS-DOS, und IBM mit ihrem Personal Computer (PC). Diese beiden, kombiniert mit ihren unzähligen Klonen, waren eine der Standardkombinationen für elektronisches Spielen in den 80ern und frühen 90ern und sahen deshalb die Veröffentlichung von vielen, vielen Spielen, und zwar derart vielen, dass selbst heute noch sehr oft diese HW/SW-Kombination gemeint ist, wenn von der "DOS"-Spieleplattform die Rede ist. Und obwohl wir weiter oben den Grundgedanken aufgestellt hatten, dass jeder Benutzer die SU in der Oregami-Datenbank finden können sollte, die auf dem Spielekarton abgedruckt ist, müssen wir schon an dieser Stelle hier eine Ausnahme davon zulassen.

Die zeitgenössischen Spielepublisher waren nämlich teils sehr kreativ in der Bewerbung der SU, für die sie ihre Spiele veröffentlichten, was insbesondere für MS-DOS-PCs galt. Das Spektrum der Aufkleber auf den Spieleverpackungen begann bei einem simplen "PC" oder "IBM", kombinierte diese beiden zu "IBM PC", gebrauchte öfters das aussagekräftigere "IBM PC & Compatibles", benutzte Hardware-Modelle oder Prozessor-Generationen, erwähnte nur das Betriebssystem oder kombinierte gar mehrere der zuvor erwähnten Varianten. Es ist wohl offensichtlich, dass eine SU für jede dieser Aufkleberklassen eine insgesamt eher sinnlose Einrichtung wäre. Stattdessen wollen wir zunächst das tun, was andere Seiten auch tun, und eine "DOS PC" genannte SU definieren, mit einer HWP "IBM-PC-kompatible HW", die all die verschiedenen Modelle und all die vielen Klone umfasst, und einer SWP "MS-DOS BS", die alle veröffentlichten Versionen von Microsofts BS enthält. Sowohl die HWP als auch die SWP würden zusätzlich noch DOSBox als Sub-Plattform erhalten, weil dieses Programm MS-DOS und die betreffende HW gleichzeitig emuliert. Im nächsten Schritt werden wir über Wege nachdenken müssen, den Benutzerinnen unsere SU "DOS PC" zu zeigen, wenn sie "IBM", "386" oder "AT" in die Oregami-Suche eingeben.

Nachdem der schlussendliche Standard modelliert ist, können wir einen genaueren Blick auf die HW- / SW-Kombinationen werfen, die nicht ganz so erfolgreich waren.

Wie weiter oben schon erwähnt wurden tatsächlich Spiele veröffentlicht, die das auf dem Rechner installierte BS komplett ignorieren konnten, weil sie entweder für direkten Zugriff auf das BIOS und / oder die HW programmiert waren oder weil sie gar ihr eigenen kleines BS auf dem Datenträger mitbrachten. Diese Spiele werden allgemein als "Booter" bezeichnet, und die Mehrheit von ihnen wurde ebenfalls für IBM-PC-kompatible Geräte veröffentlicht. All das bedeutet, dass wir zunächst eine SU mit dem Namen "IBM-PC-kompatible Booter" anlegen würden, um ihr dann die HWP "IBM-PC-kompatible HW" und die generische SWP namens "Kein installiertes BS benötigt" oder etwas Ähnliches zuzuordnen. Bei Bedarf können wir dann weitere SUen nach diesem Muster für andere HWP kreieren.

Und dann gab es da noch die Anderen. Wir reden hier nicht über die Heimcomputer der Firmen Apple, Atari oder Commodore aus den 80ern, die alle gut dokumentiert sind und große Spielebibliotheken besitzen. Sie werden sich alle ohne größere Probleme in unser Plattform-Modell pressen lassen. Wir reden über die obskureren Rechner-Veröffentlichungen, die CP/M-unterstützten Rechner mit Zilog-Z80-CPU oder die nicht-IBM-PC-kompatiblen Geräte mit x86-HW. Weil wir diese auch dokumentieren wollen, sollten wir uns an die Grundregel für neue SUen erinnern: Eine SU ist, was eine Sammlerin auf ihrer Spieleverpackung lesen kann. Denkt man diese Regel weiter, dann müssen wir die genannten Maschinen in zwei Grundfälle einteilen:

Der erste Fall beinhaltet Systeme, für die explizit Spiele veröffentlicht wurden. Diese Maschinen werden ihre eigenen SUen in Oregami bekommen, einige Beispiele solcher Hardware kann man hier bestaunen. Dort findet sich beispielsweise der Kaypro II, ein auf dem CP/M-Betriebssystem laufender Z80-Rechner. Für diesen Computer würden wir die SU "Kaypro II" erstellen, die aus der HWP "Kaypro Z80-Rechner" (weil Kaypro später auch Geräte mit x86-Prozessor produziert hat, teilweise sogar IBM-Kompatible darunter) und der SWP "CP/M BS" bestünde. Eine weitere interessante Maschine ist die DEC Rainbow 100, die gar ganze zwei CPU's in sich trug: Eine Z80 unter Kontrolle von CP/M  und eine 8088 aus der x86-Familie, wahlweise angesteuert von CP/M-86 oder MS-DOS. Schaut man sich diese Preisliste von Infocom aus dem Jahr 1988 genauer an, dann sieht man, dass Infocom deswegen zwei Veröffentlichungen für die DEC Rainbow im Verkauf hatte: eine CP/M-Option und eine MS-DOS-Option. Das würde dann auch zwei SU in der Oregami-Datenbank bedeuten: Die erste hieße "DEC Rainbow (CP/M)", die zweite natürlich "DEC Rainbow (MS-DOS)", wobei bei beiden die "DEC Rainbow 100" als HWP zugeordnet wäre, aber Unterschiede bei den beiden BSen als zugeordnete SWP bestünden.

Der zweite Fall beinhaltet dann die echten Außenseiter, den langen Schwanz des "Personal Computing" der 80er-Jahre, Rechner also, die so wenig erfolgreich waren, dass noch nicht mal Spiele explizit für sie veröffentlicht wurden. Gar fehlt mir ein Beispiel. Wenn wir diese Maschinen irgendwann in Oregamis ferner Zukunft dokumentieren wollen, dann werden wir wohl generische HWPen für sie erstellen, aufgeteilt nach zentraler Recheneinheit, und all diese unglücklichen Geräte dort als Sub-Plattformen zuordnen. Daraus folgt, dass es hauptsächlich zwei generische HWPen namens "Z80-kompatible HW" und "x86-kompatible HW" geben wird. Für Hersteller, die mehr als nur ein paar Modelle produziert haben, werden wir spezifische HWPen anlegen, wie zum Beispiel die Kaypro-Familie weiter oben zeigt. Und weil CP/M auf quasi jeder Z80-Maschine lief, und MS-DOS auf quasi jeder x86-Maschine, werden daraus zwei entsprechende SUen werden, nämlich "CP/M @ Z80-Rechner" und "MS-DOS @ x86-Rechner", mit denen wir später in der Lage sein werden, die Spielekompatibilität dieser Geräte abzubilden. Schon jetzt ist absehbar, dass diese zwei generischen SUen einige Spiele-Veröffentlichungen beinhalten werden, man werfe noch einmal einen genauen Blick auf die Zeile 8 der weiter oben verlinkten Infocom-Preisliste.

Das soll es mit dem Hardware-Wirrwarr der 80er gewesen sein. Ich bin sehr guter Hoffnung, dass wir diese Daten mit unserem aktualisierten Plattform-Modell in der ganzen Breite werden dokumentieren können.

3. Der Aufstieg von Windows

Beispiele:
Die SU "MS-Windows-PC" wird definiert durch die HWP "x86-kompatible HW" und die SWP "MS Windows PC-BS".
Die SU "MS Windows NT @ DEC-Alpha-Rechner" wird definiert durch die HWP "DEC-Alpha-kompatible HW" und die SWP "MS Windows PC-BS".

Die erste Hälfte des "Personal Computings" der 90er Jahre wurde ebenfalls von den sogenannten IBM-PC-kompatiblen Geräten dominiert, obwohl IBM schon lange die Marktführerschaft verloren hatte. Aber mit der Einführung der Windows-Familie von Desktop-BSen (seit Windows 95), und ihrer mitgelieferten Hardwareabstraktionsebene, verschob sich der Fokus der Hardware-Hersteller von der Kompatibilität zum IBM PC zur Windows-Kompatibilität. Wenn Windows auf einem Gerät lief, hatten die Kunden den Zugriff auf die riesige Software-Bibliothek dieses BS, was natürlich ein gewichtiges Kaufargument darstellte.

Und weil die Windows-Familie der 90er (fast) eine Veranstaltung auf einer einzelnen HW-Plattform war (x86), und weil alle ihre Versionen bis zurück zur DOS-Erweiterung Windows 3.1 weitgehend abwärtskompatibel sind, brauchen wir bei Oregami nur eine SU: den "MS-Windows-PC". Diese SU würde durch die HWP "x86-kompatible HW" definiert werden und nicht mehr durch "IBM-PC-kompatible HW", um die Veränderungen in der Hardware-Hersteller-Landschaft abzubilden, die SWP wäre natürlich "MS Windows PC-BS". Weiterhin würden wir Sub-Plattformen mit all den verschiedenen Windows-, ReactOS- und Wine-Versionen erstellen, mit denen wir später die Kompatibilität einer Spielveröffentlichung innerhalb der Windows-Familie abbilden können. Aber was wäre dann mit einem Rechnermodell, auf dem sowohl MS-DOS als IBM-PC-kompatible HW läuft, als auch Windows als x86-kompatible HW? Nun ja, wir verbinden es einfach mit beiden HWPen.

Im Allgemeinen eher unbekannt ist die Tatsache, dass die Windows-Subfamilie NT viel mehr als nur x86-kompatible Systeme unterstützte, was aus diesen Produkten Multi-Plattform-BSe macht (mehr dazu weiter unten beim Thema Linux). Die Multi-Plattform-Unterstützung wurde jedoch später mit der Veröffentlichung von Windows 2000 gestrichen. Das bedeutet, dass wir neben der Pflicht-SU "MS-Windows-PC" zusätzliche SUen wie zum Beispiel "MS Windows NT @ DEC-Alpha-Rechner" oder Ähnliches werden bereitstellen müssen, wenn wirlich jemand die Spielelandschaft von Windows NT auf anderen Plattformen als x86 dokumentieren möchte.

4. Linux und andere Multi-Plattform-Betriebssysteme

Beispiel:
Die SU "Linux @ x86-Rechner" wird definiert durch die HWP "x86-kompatible HW" und die SWP "Linux BS".

An dieser Stelle möchte ich ein paar Bemerkungen zu Linux verlieren, die sich natürlich problemlos auch auf andere Multi-Plattform-BSe übertragen lassen. Glaubt man seinem Wikipedia-Eintrag, dann unterstützt Linux derzeit 28 verschiedene HW-Architekturen. Das ist eine beeindruckende Zahl und gleichzeitig auch ein Alptraum für jeden Computerspielforscher, denn die wichtigste sich aufdrängende Frage ist doch, ob ein "für Linux veröffentlichtes" Spiel dann auch auf jeder dieser 28 Plattformen laufen wird? Die kurze Antwort zu dieser Frage ist: Höchstwahrscheinlich nein.

Ab und an beobachte ich ein wenig die Linux-Entwicklung und habe dabei schon Fälle gesehen, wo eine offiziell unterstützte HW-Architektur über mehrere Linux-Versionen derartig kaputt war, dass man sie nicht mal kompilieren konnte. Offensichtlich hatte das keiner der Entwickler oder Benutzer bemerkt oder sich nicht dafür interessiert, denn so etwas kann nur passieren, wenn die besagte Plattform für eine lange Zeit nicht getestet wurde. Der Grund dafür liegt darin, dass Linux eine Kollektion von 28 verschiedenen HW-Portierungen ist (oder kleine BSe), die alle grundlegende technische Konzepte und Einiges an gemeinsamen Quellcode teilen. Und jeder dieser Ports wird wiederum von einem anderen Entwicklerteam gepflegt und ist deshalb in einem unterschiedlichen technischen Zustand. Wenn also ein Spiel für irgendeine dieser Linux-Portierungen veröffentlicht werden soll, dann wird wahrscheinlich eine Rekompilierung auf der betreffenden Hardware nötig sein, was im Endeffekt theoretisch 28 verschiedene "Für Linux"-Veröffentlichungen des Spiels bedeutet. Für Oregami ist es also schlicht nicht möglich, genau eine SU namens "Linux" zu kreieren und dann zusätzlich dazu für jedes Spiel eine Kompatibilitätsmatrix anzubieten, die alle Linux-Versionen auf allen unterstützten Architekturen für dieses Spiel abbildet.

Denkt man diese Erkenntnis weiter, dann werden wir uns zunächst auf die erfolgreichste Linux-Portierung für Spieler konzentrieren, die Version für x86-kompatible Computer. Wenn später das Bedürfnis entsteht, können wir unsere Linux-Abdeckung leicht auf andere Portierungen ausweiten. Konkret würde die besagte x86-SU für Linux vielleicht "Linux @ x86-Rechner" heißen können und ebenfalls die HWP "x86-kompatible HW" zugeordnet bekommen (Genau wie bei Windows weiter oben, weil dieses BS auf den gleichen Rechnern läuft.). Als SWP würden wir "Linux BS" definieren und dort all seine verschiedenen Versionen als Sub-Plattformen zuordnen. Dieses Muster funktioniert natürlich genauso bei anderen Multi-Plattform-BSen wie zum Beispiel FreeBSD oder MorphOS, nur um mal ein paar genannt zu haben.

5. Das Amiga-Ökosystem

Beispiele:
Die SU "Amiga" wird definiert durch die HWP "Amiga M68K-Rechner & Kompatible" und die SWP "AmigaOS BS".
Die SU "AmigaOS 4 @ PowerPC-Rechner" wird definiert durch die HWP "Amiga PowerPC-Rechner & Kompatible" und die SWP "AmigaOS 4 BS".
Die SU "CDTV" wird definiert durch die HWP "CDTV-Konsole" und die SWP "AmigaOS BS".
Die SU "Amiga CD32" wird definiert durch die HWP "Amiga-CD32-Konsole" und die SWP "AmigaOS BS".
Die SU "MorphOS @ PowerPC-Rechner" wird definiert durch die HWP "PowerPC-kompatible HW" und die SWP "MorphOS BS".
Die SU "AROS @ x86-Rechner" wird definiert durch die HWP "x86-kompatible HW" und die SWP "AROS BS".

Ein Commodore Amiga 500+ war mein erster eigener Heimcomputer, weswegen dieses Computermodell heute einen sehr speziellen Platz in meinem Gamer-Herz einnimmt. Allerdings muss ich zugeben, dass ich noch nie tiefergehende Recherche über diese Rechnerfamilie durchgeführt habe. Ein Grund dafür wird wohl sein, dass ich meinen Amiga vor etwa 20 Jahren verschenkt habe, lange bevor ich ein echtes Interesse an Videospiel-Dokumentation und -Hardware entwickeln konnte. Nunja, diese Situation muss eine bessere werden, und ein erster Schritt in die richtige Richtung ist meine Recherche, wie sich das ganze Hard-/Software-Ökosystem mit Namen Amiga in unser Datenmodell einpassen lässt.

Schon mit den ersten vorsichtigen Blicken auf all die über die Jahre veröffentlichten Amiga-Modelle und die vielen verschiedenen Varianten des exklusiven BSs AmigaOS fällt eine Sache sofort ins Auge: Es gibt eine verblüffende Ähnlichkeit dieser Heimcomputer-Familie mit der weiter oben besprochenen IBM-PC- / MS-DOS-Familie. Beide Ökosysteme waren durch die stete Neuveröffentlichung verschiedener Modelle mit verbesserter Hardware und durch ein mitwachsendes Einzelplattform-BS gekennzeichnet, wie auch durch eine riesige Spielebibliothek, die größtenteils kompatibel zu den vielen Modellen / BS-Varianten war (unter Berücksichtigung der minimalen Systemanforderungen, versteht sich). In beiden Welten gab es sogar je drei (Haupt-)Grafik-Architekturen, die berühmten CGA / EGA / VGA - Chips in der PC-Welt sowie die OCS / ECS / AGA - Architekturen in den Amigas. Diese große Ähnlichkeit bedeutet nichts anderes, als das wir, wie beim IBM-PC- / MS-DOS-Komplex weiter oben, nur eine SU zur Repräsentation dieses riesigen Spielebergs benötigen werden. Sie soll schlicht "Amiga" heißen und eine HWP namens "Amiga M68K-Rechner & Kompatible" als auch ihr wohlbekanntes "AmigaOS BS" als SWP zugewiesen bekommen. Die HWP wird dann alle Amiga-Modelle von Commodore sowie alle Klone von anderen Unternehmen als Sub-Plattformen erhalten, während die SWP alle Kickstart-Versionen (speicherresidenter Teil von AmigaOS) bis 3.9 zugewiesen bekommt.


Der interessierte Leser wird sich vielleicht wundern, was denn mit AmigaOS 4 und den neueren AmigaOne-Rechnern ist, die teilweise sogar heute noch verkauft werden. Nun, diese Geräte stellen eine der Ausnahmen von der Regel dar, dass die Amigawelt nur eine SU benötigt, weil hier vereinfacht gesagt nur die Marke "Amiga" für Rechner benutzt wurde, die sehr verschieden zu den alten Amigas von Commodore sind. Der heftigste Unterschied ist natürlich die neue Prozessor-Architektur, die dort benutzt wird, der PowerPC nämlich. Das alte AmigaOS wurde folgerichtig auf die neue Architektur portiert, wobei die Unterstützung für die alten Motorola-basierten Modelle entfernt wurde. Demnach handelt es sich hier schlicht um eine neue SU, die den Namen "Amiga" mit der Haupt-SU teilt, nennen wir sie also "AmigaOS 4 @ PowerPC-Rechner". Die zugeordnete HWP wären dann die "Amiga PowerPC-Rechner & Kompatible", welche auch verschiedene Spezialkonfigurationen alter Amigas mit PowerPC-Erweiterungskarte umfassen würden, die zugeordnete SWP wäre natürlich "Amiga OS 4 BS".

Commodore hat außerdem zwei Multimedia-Konsolen mit CD-ROM-Laufwerk für das interessierte Publikum veröffentlicht, die beide auf Amiga-Technologie basierten. Die erste Konsole erblickte im Jahr 1991 das Licht der Welt und trug den Namen CDTV, was eine Abkürzung für Commodore Dynamic Total Vision darstellt. Dieses Gerät bestand quasi aus einem Amiga 500 mit integriertem CD-ROM-Laufwerk, der in ein hübsch anzuschauendes Gehäuse verbaut und mit einer gamepadartigen Fernbedienung ausgestattet worden war. Das System lief mit einem verbesserten AmigaOS 1.3 und hatte eine überschaubare Spielebibliothek von vielleicht einigen Dutzend Titeln für sich. Die Nachfolgerin der CDTV-Konsole wurde bereits zwei Jahre nach deren Erstveröffentlichung vorgestellt. Sie hieß Amiga CD32 und war die erste 32-bit-Konsole auf dem euopäischen Markt. Dieses Gerät basierte auf der Technologie des Amiga 1200 mit AmigaOS 3.1, hatte aber zusätzlich einen besonderen Chip namens Akiko zu bieten, der die Benutzung von 3D-Grafik stark vereinfachen sollte. Und obwohl die Spielebibliothek der neuen Konsole deutlich größer war als die ihrer Vorgängerin, verkaufte sich die Amiga CD32 aufgrund einiger Probleme trotzdem nicht gut und konnte deshalb auch die Firma Commodore nicht vor dem baldigen Untergang retten. Datenmodelltechnisch gesehen hatten diese beiden Konsolen Spiele zu bieten, die spezifisch für sie veröffentlicht und zudem auf einem Medium geliefert wurden, dass relativ ungewöhnlich für die Zeit und die sonstige Amigawelt war. Beide verdienen deshalb ihre eigene SU, wobei die erste Konsole die SU "CDTV" mit der HWP "CDTV-Konsole" zugewiesen bekommt, und die zweite die SU "Amiga CD32" mit der HWP "Amiga-CD32-Konsole". Beide SUen bekommen natürlich noch die SWP "AmigaOS BS".

Der letzte Aspekt der sehr lebendigen Amiga-Community, der hier angesprochen werden soll, ist die Existenz zweier alternativer BSe. Neben dem bereits öfter angesprochenen AmigaOS 4 verdienen nämlich noch das Single-Plattform-BS MorphOS und das Multi-Plattform-BS AROS eine Erwähnung in dieser Sektion. MorphOS ist der Versuch, ein BS für moderne Computersysteme zu programmieren, auf dem alte Amiga-Software ohne Veränderung laufen kann, wobei allerdings derzeit nur die PowerPC-Architektur unterstützt wird. Dabei erreicht MorphOS seine binäre Amiga-Kompatibilität durch eine fest verdrahtete Emulation der Motorola-68K-Architektur, mit denen die klassischen Amigas ausgerüstet waren. Dieses BS würde also seine eigene SU namens "MorphOS @ PowerPC-Rechner" mit der HWP "PowerPC-kompatible HW" und der SWP "MorphOS BS" bekommen. AROS versucht dagegen nicht, binäre Kompatibilität mit AmigaOS zu erreichen, sondern zielt stattdessen auf API-Kompatibilität und Portabilität ab. Das bedeutet nichts Anderes, als das Entwickler ihre alte Amiga-Software auf modernen, von AROS unterstützten Architekturen ohne größere Probleme rekompilieren können, was letztlich zu einer Neuveröffentlichung dieser Software für die neue Architektur führt. Wenn die rekompilierte Software zufällig ein Spiel ist, dann kann sie später auf Oregami eingestellt werden, und zwar für eine neue SU pro unterstützter HW-Architektur. Ein Beispiel für so eine SU wäre "AROS @ x86-Rechner" mit der HWP "x86-kompatible HW" und der SWP "AROS BS" auf der nächsthöheren Datenebene.

Das soll es an dieser Stelle erst einmal zur vielfältigen und florierenden Amiga-Familie gewesen sein. Für Oregami hoffe ich inständig, dass eines Tages relativ komplette Bibliotheken des reichhaltigen Spiele- und HW-Angebots dieser Familie in unserer Datenbank verfügbar sein werden.

6. Plattform-Unabhängigkeit

Beispiele:
Die SU "Browser / HTML" wird definiert durch die HWP "Kompatible HW" und die SWP "HTML-Interpreter".
Die SU "Z-Maschine" wird definiert durch die HWP "Kompatible HW" und die SWP "Z-Code-Interpreter".

Wenn jemand Unbedarftes den Begriff "plattformunabhängige" Spiele zum ersten Mal hört, dann schießt vielleicht einer der folgenden zwei Gedanken durch seinen / ihren Kopf: Entweder brauchen diese Spiele keine HW um zu laufen oder sie laufen auf jeder HW. Beide Annahmen sind natürlich nicht richtig. Aber was genau bedeutet dann Plattform-Unabhängigkeit und wie kann sie in Oregamis Datenmodell abgebildet werden?

Nun, ich habe diesen längeren Beitrag mit dem schlichten Fakt begonnen, dass jedes elektronische Spiel eine HW zum Laufen benötigt, und viele Spiele darüber hinaus auch noch ein BS, wobei das BS bei einem solchen Aufbau hauptsächlich dafür zuständig ist, den Computerspielen einen standardisierten Zugriff auf die vorhandene HW zu ermöglichen. Vereinfacht beschrieben bedeutet das, dass die Veröffentlichung eines Spiels auf einem anderen BS als dem, für das es geschrieben wurde, sein Umprogrammieren auf die HW-Zugriffsmöglichkeiten des anderen BS erfordert. Wenn also 100 Spiele auf ein anderes BS umgeschrieben (portiert) werden sollen, dann muss jedes einzelne von ihnen für sich angepasst werden, was letztlich 100 neue Spielveröffentlichungen bedeutet.

Was passiert aber, wenn man zwischen das BS und das Spiel eine weitere Softwareebene schiebt (weiterhin "Virtuelle Maschine" (VM) genannt), die allen für sie geschriebenen Spielen einen vereinfachten Hardwarezugriff zur Verfügung stellt, sodass sie nicht mehr direkt mit dem BS kommunizieren müssen? Wenn nun die 100 Spiele für ein anderes BS veröffentlicht werden sollen, dann muss nur noch die VM an das andere BS angepasst werden, und sämtliche Spiele werden auch dort unverändert und wie durch Magie laufen. In diesem Fall gibt es also keine zusätzlichen Spielveröffentlichungen, stattdessen funktionieren die alten einfach so auf einer weiteren Plattform. Das ist Plattform-Unabhängigkeit.

Die meistverbreitetste VM ist heutzutage eine Programmklasse, die der geneigte Leser wahrscheinlich im Moment auch gerade benutzt: Ein Browser bietet nämlich die Möglichkeit, auf Online-Inhalte in vielen verschiedenen Formaten von vielen verschiedenen BSen aus zuzugreifen. Einige dieser Inhalte können auch interaktiv sein und machen damit den Browser zum Werkzeug für plattformunabhängiges Spielen. Ein anderes Beispiel findet sich auf der in einem obigen Absatz verlinkten Infocom-Preisliste. Wie hat es die Firma Infocom damals geschafft, alle ihre Spiele für solch eine wilde Vielfalt von SUen anzubieten? Die Antwort ist natürlich eine VM, die Z-Maschine. Infocom portierte schlicht ihre Z-Maschine auf jede wichtige zeitgenössische Plattform und lieferte sie mit all ihren Spieleveröffentlichungen mit. Genial!

Die Möglichkeit, Spiele für eine VM zu veröffentlichen, bringt Probleme mit sich, wenn es an das Datenmodell für SUen bei Oregami geht. Solcherlei Spiele werden nämlich nicht mehr für eine klassische HW/SW-Kombination veröffentlicht, sondern für eine VM, die ihrerseits wieder auf verschiedenen HW/SW-Kombinationen läuft. Es ist sogar möglich, verschiedene VMs zu kombinieren, beispielsweise wenn jemand einen in JavaScript geschriebenen Z-Maschinen-Interpreter innerhalb eines Browsers benutzt, um Spiele zu spielen. Wegen all dieser Besonderheiten benötigt der VM-Fall eine spezielle Behandlung. Mein Vorschlag ist es daher, für jede einzelne VM, der wir begegnen werden, eine eigene SU zu schaffen. Als HWP würde dort überall das generische "Kompatible HW" zugeordnet werden, als SWP dagegen für jede VM eine eigene.

Schaut man sich die beiden Beispiele mit den gewonnenen Erkenntnissen erneut an, dann bedeutet das, dass wir zwei SUen namens "Browser / HTML" und "Z-Maschine" kreieren und ihnen die HWP "Kompatible HW" zuweisen würden. Als SWP würden sie "HTML-Interpreter" und "Z-Code-Interpreter" bekommen. Auch all die anderen populären, meist in Browsern benutzten VM-Technologien wie die bekannten Marken Flash oder Unity würden demnach ihre eigenen SUen bekommen. Unterhalb der SWPen könnten wir dann die ganzen verschiedenen Versionen der VM's addieren, um später ihre Spielekompatibilität abbilden zu können. Auf diese Weise werden wir in der Lage sein, plattformunabhäniges Spielen adäquat in die Datenbank aufzunehmen und damit die Tür weit aufzustoßen für eine umfassende Dokumentation dieses reichen Zweigs des Videospiels, der zehntausende Veröffentlichungen umfasst.

7. Gedanken zu Arcade-Automaten

Beispiel:
Die SU "Arcade / Sega Model 3" wird definiert durch die HWP "ASP Sega Model 3" und die SWP "Sega Konsolen-BIOS".

Habt Ihr den Film "Ralph reicht's" gesehen? Dieses wichtige Stück Filmgeschichte hat ein Schlaglicht auf einen sehr wichtigen Teil der Videospielhistorie geworfen: Arcade-Automaten. Bevor dieser Film in die Kinos kam, hatten viele junge Spieler wahrscheinlich noch nie von diesem Milliongeschäft der 80er Jahre gehört, als Dutzende von mannshohen Automaten mit integrierten Videospielen von hoffnungslos spielsüchtigen Jugendlichen gegen Geld benutzt wurden. Einige wichtige Videospielserien nahmen ihren Anfang auf einem Arcade-Automaten, bevor sie dann auf technisch ausreichende Heimcomputer oder Konsolen portiert wurden. Deshalb führt für Oregami kein Weg daran vorbei, die Arcade-Historie zu dokumentieren.

Das Problem mit diesen Geräten ist ihr grundsätzlicher Aufbau - und wie dieser sich in unser SU-Modell pressen lässt. Die Arcade-Unternehmen produzierten Hardware-Platinen, die den Hauptplatinen (Motherboards) moderner Rechner nicht unähnlich waren, und die alle HW-Komponenten für die Darstellung von Videospielen mit sich trugen. Diese Platinen wurden in schön anzuschauende Gehäuse verbaut, zusammen mit Eingabemöglichkeiten wie einem Joystick, einem oder mehreren Bildschirmen und natürlich einem Einwurfschlitz für's Geldverdienen. Die Spiele selbst waren entweder fest auf der Platine verdrahtet oder wurden auf einem Wechselmedium wie Steckmodul oder Disc geliefert. Reden wir also über Arcade-Spieleveröffentlichungen, dann reden wir zunächst über voll ausgebaute Spieleschränke mit allem Drum und Dran, um die geneigten Spieler anzuziehen. Aber über welche SUen reden wir?

Mein erster Gedanke zu diesem Thema war eine SU namens "Arcade-Automat", die eine HWP "Arcade-Platine" und eine SWP "Arcade-BIOS" oder Ähnliches zugewiesen bekommen sollte. Die HWP hätte dann noch all die verschiedenen Platinenarten als Sub-Plattformen erhalten sollen. Aber dieser Ansatz stellte sich im weiteren Verlauf doch als zu arm für die reichhaltige Welt der Arcade-System-Platinen heraus, weil einige von ihnen noch in mehreren Revisionen produziert wurden, wie beispielsweise die Stufen des Sega Model 3. In der Konsequenz bedeutete diese Entdeckung schließlich, die Platinen eine Datenebene weiter oben anzusiedeln und damit die Platinen-Revisionen als Sub-Plattformen zu definieren.

Die Problematik soll noch an einem Beispiel verdeutlicht werden, wir wollen hierfür das bereits erwähnte Sega Model 3 benutzen. Für diese Platinenfamilie würden wir eine SU mit dem Namen "Arcade / Sega Model 3" kreieren und ihr die HWP "ASP Sega Model 3" zuweisen, wobei ASP eine Abkürzung für Arcade-System-Platine darstellen soll. Meine Recherchen zur enthaltenen SWP brachten leider kein eindeutiges Ergebnis zu der Frage, ob in den Platinen ein BIOS integriert war oder nicht. Wahrscheinlich war eins integriert, weswegen wir wohl eine SWP "Sega-Konsolen-BIOS" oder Ähnliches haben werden. Diese Arcade-Platine wurde von Zeit zu Zeit mit mehr Rechen- und Grafikleistung aktualisiert, weshalb wir dann die verschiedenen veröffentlichten Platinenversionen der HWP als Sub-Plattformen zuordnen würden. Falls sich bei weiteren Recherchen mehr Details zu einem eventuell verwendeten SEGA-BIOS herausstellen sollten, könnten wir diese Informationen als Sub-Plattformen zur SWP dokumentieren.

So viel zu den Beispielen für Spielumgebungen, die zwar recht umfangreich geraten sind, die aber trotzdem nur einen Bruchteil der mannigfaltigen Welt der Videospiele abdecken können. Es gibt noch viel, viel mehr Problemfälle zu erforschen und abzubilden, und ich freue mich schon sehr darauf, wenn wir unsere Datenbank eines Tages am Laufen haben werden.

Zurück zur Benutzerzufriedenheit

Nachdem nun ein paar Beispiele abgearbeitet sind, möchte ich zum Blickwinkel der Benutzerzufriedenheit bzw. Benutzerfreundlicheit zurückkehren. Liest man sich nämlich die oben ausgebreiteten Beispiele nochmals unter diesem Gesichtspunkt durch, dann fällt allzu deutlich ein großes Problem dieses Ansatzes auf: Bis zu 28 SUen für Linux in der Datenbank? Eine separate SU für jede Arcade-Platine oder VM-Software? Dutzende SUen für Heimcomputer der 80er Jahre? Was für eine aufgeblähte Spielumgebungsliste! Wie können wir hier nur erwarten, den gelegentlichen Oregami-Benutzer NICHT zu verprellen?

Ja, an dieser Stelle gibt es ein Problem. Die Videospielplattform-Landschaft ist genauso riesenhaft wie komplex und zwingt uns damit dazu, die aufgeblähte Spielumgebungsliste als notwendiges Übel zu akzeptieren und nach einem Weg zu suchen, deren Komplexität zur Zufriedenheit der Benutzer so weit wie möglich zu verstecken. Nun, die Lösung, die wir uns für dieses Problem ausgedacht haben, ist eine zusätzliche, vierte Datenebene namens "Spielumgebungsgruppe" (SUG). Wir werden all diese Linux-SUen zu einer SUG namens "Linux" zusammenfassen und all die vielen SUen für Arcade-Platinen in einer SUG namens "Arcade" vereinen und so weiter. Wenn wir dann unsere Standard-Datenansichten und Suchoptionen auf der SUG-Ebene aufsetzen, geben wir dem Gelegenheitsbenutzer eine einigermaßen verständliche Plattformliste und dem Experten die Möglichkeit, seine Seitenbenutzung auf die komplexere Ebene der SU zu verlagern.

Natürlich wollen wir die SUG-Datenebene auch für andere schöne Dinge benutzen, lässt sich mit ihr doch auch gut ein Gesamtüberblick über alle Veröffentlichungen eines Spiels vermitteln. Beispielsweise würden wir wahrscheinlich alle vier PlayStation-Konsolen in eine SUG namens "PlayStation-Konsolenfamilie" packen, und die PSP und die PS Vita in eine SUG mit der Bezeichnung "PlayStation-Handheld-Familie". Wenn wir aber dann zusätzlich dazu noch eine SUG "PlayStation-Familie" mit allen sechs genannten Sony-Geräten kreieren würden, hätten wir die einfache Möglichkeit, den Benutzern ganz schnell zu zeigen, dass ein Spiel eine Veröffentlichung in der PlayStation-Welt gesehen hat, und dass deshalb sehr gute Chancen bestehen, dieses Spiel in der Zukunft auf den neuesten Sony-Geräten spielen zu können. Selbstverständlich würden diese zusätzlichen SUGen nicht in der normalen Plattformliste erscheinen, um die Benutzer nicht unnötig zu verwirren.

Ein paar abschließende Bemerkungen zur Kompatibilität

Die letzten Absätze dieses Mammut-Beitrags sollen der Plattform-Kompatibilität gewidmet sein. Stellen wir uns kurz eine Nintendo-3DS-Besitzerin vor, die nach allen Spieleveröffentlichungen sucht, die auf ihrem Gerät laufen, und einen Gameboy-Besitzer auf der Suche nach allen Gameboy-Color-Veröffentlichungen mit einem "Schwarz/Weiß-Modus". Wir sollten die 3DS-Zockerin mit einer Datenliste versorgen, die zusätzlich zu den 3DS-Spielen alle Nintendo-DS-Spiele beinhaltet, und den Gameboy-Benutzer mit einer Liste aller betreffenden GBC-Spiele. Um all das aber tun zu können, müssen wir Kompatibilitätsdaten in die Oregami-Datenbank integrieren, und zwar für die folgenden drei Hauptanwendungsfälle.

Den ersten Anwendungsfall habe ich bereits im obigen Modellierungsbeispiel Nummer 3 erwähnt. Die Kompatibilitäts-Probleme innerhalb einer SU wie beispielsweise die Unterscheidung, auf welchen Versionen des BS ein Windows-Spiel lauffähig ist, werden wir durch die Benutzung von Sub-Plattformen abbilden können. Wir werden die einzelnen Veröffentlichungen eines Spiels mit allen Sub-Plattformen seiner SU verbinden und dabei zusätzliche Informationen wie "Offizielle Unterstützung", "Lauffähig", "Spielbar" oder "Durchspielbar" ergänzen können.

Der zweite Anwendungsfall ist die oben benannte Nintendo-3DS-Besitzerin. Um diesen Fall lösen zu können, werden wir zwei SUen mit Kompatibilitäts-Informationen verbinden können, hauptsächlich für die häufig vorkommende Abwärts-Kompatibilität. Wie im Beispiel bedeutet das, dass jedes Spiel, das für eine SU veröffentlicht wird, auch auf deren Nachfolger gespielt werden kann. Wenn also alle DS-Spiele auch auf einem 3DS laufen, dann werden wir diese beiden SUen mit einer "Generellen Abwärts-Kompatibilität" verbinden.

Der letzte und schwierigste Anwendungsfall ist eine spielspezifische Kompatibilität zwischen zwei SUen, d.h. dass nur bestimmte Spiele aus der Bibliothek einer SU auf der jeweils anderen laufen, oder gar nur auf einigen Subplattformen der jeweils anderen SU. In diesem Fall würden wir zunächst die beiden betreffenden SUen mit einer "Spielspezifischen Kompatibilität" verbinden und danach alle Spiele markieren, die diese neue Verbindung unterstützen. Um im obigen Gameboy-Beispiel zu bleiben: Wir würden also zunächst die SU "Gameboy" mit der SU "Gameboy Color" mittels einer "Spielspezifischen Aufwärts-Kompatibilität" namens "Schwarz/Weiß-Modus" verbinden. Wenn dann eine Benutzerin ein neues GBC-Spiel einstellt, würde das System sie fragen, ob das Spiel diese spezifische Verbindung unterstützt oder nicht, und es dann entsprechend markieren, falls das der Fall wäre.

 

So viel dazu, wie man sehen kann, sind unsere Köpfe prall gefüllt mit Ideen zur Verbesserung der existierenden Modelle der Plattform-Dokumentation. Wir werden aber einige Zeit brauchen, das alles zu programmieren und in eine ordentliche Benutzeroberfläche zu verpacken. Aber am Ende wird es gut werden, versprochen! (smile)